Вчерашнее событие - пятичасовое падение ФБ, инстаграма и пр меня не коснулось. Нет у меня аккаунтов в этих местах. Посмеялась над оптимизмом высокомудрых инженеров, которые не предусмотрели возможности войти в служебные помещения иначе, чем с применением карты с чипом.
Пришлось бедолагам вспоминать, что такое болгарка.
И вспомнилась мне недавняя дискуссия на АШ, где юные подаваны с пеной у рта доказывали всю прелесть цифрового мира. Ругали приверженцев материальных носителей ретроградами.
Но мне упорно не кажется безопасным электронный документооборот, удостоверения личности, трудовые книжки, дипломы и сертификаты , которые нельзя прочесть без специальных приблуд.
"Написано пером - не вырубишь топором" не работает в мире виртуальных документов.Помер сервер, сошел с ума сисадмин, поссорился с биг боссом программист..Да мало ли поводов для цифрового коллапса.
Локальные падения баз проходят незаметно. Пару лет назад заметили (не сразу), что на счет супруга перестала приходить энная сумма денег, льгота по квартплате. Подумали, что отменили. Позвонили в военкомат, те отправили нас в социальную службу, а там полная печаль - восстанавливают пропавшие данные. Деньги вернули через пару месяцев.
То, что зависит от розетки, от человека, от сложных устройств никогда не может быть надежным.
Открываю фотоальбом. Некоторым снимкам около ВОСЬМИДЕСЯТИ лет. Лежат себе на картонном носителе.. Лежат пергаменты древнего Египта, глиняные таблички Месопотамии, берестяные грамоты Новгорода)). Лежат свидетельства о рождении, браке, о собственности.
Лежат дискеты... Недавно перетряхивала дальний угол в городской квартире. Дискету сейчас и воткнуть то некуда. Ау, что там??
Потому и советую работающим студентам с каждого рабочего места брать копии приказов о приеме, увольнении, справку 2-НДФЛ. И складывать это добро в папочку дома.
Материально ответственным лицам стоит хранить товарные отчеты на бумажных носителях.
Цифровизация прекрасна, удобна и где то даже экологична. Но отказываться от материальных носителей - глупость полная. По крайней мере финальные бумаги документооборота стоит фиксировать и хранить на бумаге.
Комментарии
Архивы бывают не только исторические, камрад)) Бухгалтерские книги хранят, документы по движению товара и многое другое, что ценно для специалистов, но больше никому не нужно. ОНо вам надо, например, закупки эссенции для рощения бороды в губернской аптеке Самары?
Вот как раз бухгалтерские книги и являются самыми ценными для Истории, но их уничтожают в первую очередь и пишут фантазии на тему кто кого трахал в замковом саду.
Это твоё прошлое, дипломированный специалист по архивному делу. Из такой "свалки" вы и организовали архив "сильно иначе".
:) это не моё прошлое. И да, даже из бумажных архивов (только настоящих) постепенно организовывались архивы "сильно иначе". Но это не значит, что при исчезновении возможности вести архив "сильно иначе", я вернусь к свалке, а не нормально организованному бумажному архиву :)
Ваш нормально организованный бумажный архив уже ущербный, ввиду его фрагментарности и копий с каких-то утерянных копий с несуществующих оригиналов. А так - да. Что имеем, то и храним.
Ещё вацап упал. Которым, полагаю, пользуются гораздо большее число потребителей.
Это одно и то же.
Люди подписали на single point of failure - люди его получили. Падает редко и обычно всё легко и просто и экономит кучу мелких усилий, но уж если упадёт - то сразу "ковровая бомбардировка".
....а я тут подумал, а вот если бы у Майкрософта упало?
Сначала всех выкинет из Скайпа. Потом из Гитхаба.
....а потом всех, кто в Windows 10 подписался на удобный ("легко и просто и экономит кучу мелких усилий") Microsoft Account - превратиться в тыкву их обычный рабочий стол. Вот это бы был блокбастер! :-D
Причём выброс из гитхаба, даже навсегда - это самое безобидное из последствий падения мелкомягких. Просто потому, что репозитории восстанавливаются буквально в первозданном виде простым `git push` на любой другой сервер.
git push восстановит исходники, а вот сопутствующие материалы - wiki, трекер - не восстановит.
Все же git не fossil :-)
Умер
Вадимтрекер - да и чёрт с ним. Заинтересованные пользователи быстро восстановят всё самое важное - сразу же, как только найдут где новый дом проекта.А кто ведёт документирование не в репке, а в отдельной вике - сам себе злобный Буратино!
Упд.: `git push` - только из-за гитхаба. Соображения актуальны для любой распределёнки, в не только этого торвальдсовского ушлёпища.
вести трекер и вику в виде набора текстовых файлов - то ещё удовольствие, а интегрировали это из DVCS только в fossil, но там изначально делали "швейцарский ножик" для небольших pet projects, а не промышленный высоконагруженный узкоспециализированный инструмент как git.
так-то и весь SVN/GIT можно вручную делать, без инструмента, если про удобство и скорость не думать
аналогично можно руками комменты и статусы в ticket0123.txt мёржить, в режиме разрешения конфликтов
Мне представляется, что вы путаете git и GitHub. Первый - инструмент управления патчами, в ядро Линукс в частности, второй - сервис ведения проектов на основе git.
Можно, но любая распределённая система контроля версий будет в нынешних условиях чаще всего лучше, чем централизованный Subversion или файловая система git. Особенно лучше чем git: файловая система со снапшотами состояний - это совсем не система управления изменениями.
Все пользователи git таким образом разрешают конфликты и не жужжат.
Вы про концепцию literate programming никогда не слышали? Однако именно она снимает указанные вами проблемы централизованных сервисов ведения проектов. Что самое характерное - именно переносом ведения проекта в том числе в чисто текстовые файлы. См., например, Org Mode.
> Первый - инструмент управления патчами, в ядро Линукс в частности
Не в частности, а именно для этого. И ключевое требование в разработке было максимально быстро накатывать/откатывать патчи любого размера на всё немаленькое "ядро" (в которое несмотря на название - ещё и огромная пачка драйверов входит).
То, что на безрыбье и на волне хайпа git стали использовать для других проектов - это уже пoтом случилось, но разрабатывался он именно как инструмент для LKML
> второй - сервис ведения проектов на основе git
...и поэтому вы говорите, что от фактической смерти этого сервиса, никому не будет больно, ведь есть git push.
Который, следовательно, по вашему полностью заменяет все эти сервисы GitHub'a.
Так что это вы их путаю, а я вам как раз и указываю на сервисы GitHub'а, которые находятся вне git и которые через простое git pull / git push перетащить на другие хостинги не получится.
> Все пользователи git таким образом разрешают конфликты и не жужжат.
Точно? никаких других способов ведения баг-трекеров и документации кроме ручного редактирования (3-way diff) txt-файлов у пользователей git нету? ой вей...
> См., например, Org Mode.
Просто ещё один полу-текстовый формат. Маркдауном больше, маркдауном меньше. А речь шла о совместной работе, а не о формате.
Так что и документы офиса возможно в блокноте редактировать, что там, zip да XML, но всё-таки в специально для того созданном офисе удобнее.
> Вы про концепцию literate programming никогда не слышали?
Это которая "while in literate programming, code is embedded in documentation, with the code following the structure of the documentation" - ну типа не взлетевшего IDE Component Pascal и опять же офисы, где внутрь документов можно макросы вставлять.
Концепция интересная, как и любая альтернативная история, но при чём тут реальное массовое программирование и, наконец, github ?
Так, про git мы имеем консенсус: это не система управления изменениями. Разночтения начинаются дальше:
Больно будет в любом случае. Хотя бы потому, что сервис только что был - и вот его не стало. И теперь надо мэйнтэйнеру искать куда заново выкатить проект, а всем остальным - как-то узнать где его потом потом взять. И если сам репозиторий - вещь самодостаточная, то данные багтрекеров и вики - уже очень специфическая, вообще говоря несовместимая при переходе с одного сервиса на другой. Это не упоминая о той маленькой беде, что никто не делает бэкапы тикетов и вики с гитхаба: M$ позаботится! Поэтому в случае падения гитхаба эти данные будут просто потеряны. Впрочем, всем... Ну вы понимаете.
Mea culpa. Mea maxima culpa! Рассуждения, приведённые выше я должен был вот к этому высказыванию про конфликты сразу приклеить. Безусловно вкупе с замечанием: пользователи git как системы управления изменениями должны страдать. С другой стороны, для текстовых файлов ничего больше и не надо.
Надёжная совместная работа обеспечивается системой контроля версий текстовых файлов. Всё остальное неизбежно завязывается на реализацию сервисов и тонет вместе с этими сервисами.Org-mode - это лишь один из вариантов, позволяющий вести проектную документацию в широком смысле этого слова в чисто текстовом виде. А сервисы.. Ну что сервисы? Вы почти наверняка с одного багтрекера на другой переезжали же? Понравилось? Считайте это учебно-боевой имитацией смерти гитхаба.
А теперь - при чём здесь реальное массовое программирование, гитхаб и даже статья, под которой мы всё это обсуждаем: хранить данные надо в видах и форматах, которые можно максимально безболезненно восстановить и привести в рабочее состояние на любой приемлемой для этого платформе. "Массовое реальное программирование", как вы его назвали, полностью игнорирует саму возможность смерти гитхаба в частности и аналогичных сервисов вцелом. Впрочем, здесь работает тот же эффект, который сейчас приводит к выбору git в качестве системы управления изменениями в новых проектах: миллионы мух не могут ошибаться! А значит, в случае исчезновения гитхаба все данные багтрекеров с него будут неизбежно и необратимо утеряны.
Да, вы пару раз упоминали офис. А в чём разница при согласовании правок? merge есть merge, и разницы нет никакой. По крайней мере пока работа ведётся в рамках подходящей платформы. Кстати, насколько я понимаю, для MS Office все варианты Linux сразу оказываются неподходящими платформами. Особенно какой-нибудь mips. Или Linux с вашей точки зрения не есть платформа разработки в "реальном массовом программировании"?
> И если сам репозиторий - вещь самодостаточная, то данные багтрекеров и вики - уже очень специфическая
В случае git и гитхаба - да. В случае fossil - нет. Плюс и минусы есть у обоих подходов.
Но в любом случае, тезис "падение гитхаба - фигня, git push и всё решилось" - это был ваш тезис. Я как раз утверждал обратное, что "потеря исходников" при падении Майкрософта - только часть проблемы. Её, действительно, решить удастся быстро. А вот всё остальное - увы. Всё остальное, что хранится на гитхабе, через git push не восстановить.
> Поэтому в случае падения гитхаба эти данные будут просто потеряны.
Т.е. по вопросу "что будет" тут вы согласились со мной. Разногласия остались только по вопросу, важно ли это.
> Впрочем, всем...
До падения ваццапа и компании - всем тоже было ровно так же. Никто даже и не задумывался. И через неделю уже опять забудет.
> Надёжная совместная работа обеспечивается системой контроля версий текстовых файлов. Всё остальное неизбежно завязывается на реализацию сервисов и тонет вместе с этими сервисами.
Не обязательно. Пока это так. Ну так и исходные тексты не всегда лежали в текстовых файлах. В IBM Visual Age и в Кларионе они лежали как бинарные файлы, по сути специализированные БД. И на тот момент это было круто и прогрессивно, когда коллективная работа без блокировок была не нужна, а на парсинг и поиск зависимостей в реальном времени не хватало мощности компьютеров.
А сейчас наоборот уже получается, языки и среды программирования должны быть VCS-friendly или останутся в тупиковой нише. Но это не значит, что остался один единственный язык программирования, скорее сложился консенсус о текстовых файлах, способах их разбиения на строчки, и достаточности учёта изменения по строке. За десятилетия нащупали золотую середину.
Те же XML/HTML прекрасно ложатся в git в режиме "один тэг на строку" и не лягут в режиме "одна строка на файл" - но ровно то же и с C/Java/Pascal/etc
"Персональных вики" с хранением в текстовых файлах уже сегодня в наличие. Вплоть до самомодифицирующейся самосохраняющейся вебстранички.
Вопросом об интеграции трекеров и вики с исходниками просто пока никто всерьёз не занимался, решали более насущные проблемы. Но попытки найти "общий делитель" на уровне GUI (Eclipse Mylar/Mylyn, плагины к TortoiseGit/SVN) уже делают. Вероятно, это уже будет некое 4-е поколение VCS. Вики и трекеры останутся разными, как и ЯП остались, но они найдут способ хранить себя вместе с исходниками проекта в едином DVCS.
Но это будет не сегодня. Сегодня же "потеря гитхаба" будет болью, не решаемой одним лишь git push.
> "Массовое реальное программирование", как вы его назвали, полностью игнорирует саму возможность смерти гитхаба в частности
Как вы это можете утверждать? Вы же сами сказали, что можно git push на любой другой сервис, в том числе просто в папку на USB-флешке или яндекс-диске, не говоря про ZeroNet/IPFS
Вот во времена Sourceforge + CVS/SVN это было куда ближе к правде.
> и аналогичных сервисов вцелом.
А это уже что-то масштаба "закроем завтра этот ваш интернет". Если это случится - то многие проекты станут невозможными хоть с гитом, хоть без. Хотя DVCS в принципе, хотя и с трудом, могут выжить даже в режиме флоппи-нета. ОСОБЕННО если смогут интегрировать в себя трекеры.
> выбору git в качестве системы управления изменениями в новых проектах: миллионы мух не могут ошибаться
Не самый плохой критерий, если лично ты пока ещё понимаешь в новой теме ещё меньше мухи.
Кроме того, это просто удобно, если нужные тебе библиотеки УЖЕ ушли в Git, тогда банально проще сделать подмодуль, чем городить несколько разных DVCS. Опять же, и импорт из SVN изначально был.
Условно говоря, кому нужен Veracity, если в нём не будет никого, кроме автора Veracity?
Тут в общем-то тот же эффект "проще/полезнее быть с толпой", что и среди соцсетей, среди мессенджеров, и внезапно среди ЯП.
> Да, вы пару раз упоминали офис. А в чём разница при согласовании правок? merge есть merge, и разницы нет никакой
Я упоминал в контексте удобства обычных действий. Гораздо удобнее и быстрее "нажать кнопочку" в Экселе или Либре, чем раззиповывать и править XMLи и зазиповывать обратно. Настолько быстрее, что кроме редких и очень специальных случае... Еще проще: настолько проще и быстрее, что люди подняли себе этот геморрой "написания и поддержки офиса".
Так же и с трекерами, нажать стандартную кнопочку по добавлению комментария, скриншота, перевода тикета между соседними состояниями - банально проще и быстрее, чем редактировать в блокноте. И конфликтов при этом скорее всего не возникнет. Если вы добавляете комментарий и в то же самое время я добавляю комментарий и закрываю тикет - хоть для Мантиса, хоть для Жиры это три разных действия, взаимно дополняющих и без конфликта. А вот при редактировании копий маркдаун-файла это будет типовой конфликт.
> для MS Office все варианты Linux
я ни разу не конкретизировал какой именно офис, и намеренно не писал его с большой буквы. Хотя бы потому, что OASIS был хронологически раньше Office OpenXML. Раньше Оазиса, вероятно, были Excel XML-SS (2002, возможно даже 97) и особенно RTF - но эти не являются явно мною проговоренными XML/Zip.
Ответы - инлайн, раз уж вы так не любите цитирование этого форума. Угловые скобки - это же так приятно и радует глаз!
> > И если сам репозиторий - вещь самодостаточная, то данные багтрекеров и вики - уже очень специфическая
> В случае git и гитхаба - да. В случае fossil - нет. Плюс и минусы есть у обоих подходов.
Также да - в случае практически всех систем управления изменениями. Fossil здесь - просто исключение.
> Но в любом случае, тезис "падение гитхаба - фигня, git push и всё решилось" - это был ваш тезис. Я как раз утверждал обратное, что "потеря исходников" при падении Майкрософта - только часть проблемы. Её, действительно, решить удастся быстро. А вот всё остальное - увы. Всё остальное, что хранится на гитхабе, через git push не восстановить.
И опять - вопрос только в способе хранения. Включение всего управления проектом в репозиторий вместо сервиса этот вопрос решает.
> > Поэтому в случае падения гитхаба эти данные будут просто потеряны.
>
> Т.е. по вопросу "что будет" тут вы согласились со мной. Разногласия остались только по вопросу, важно ли это.
>
> > Впрочем, всем...
>
> До падения ваццапа и компании - всем тоже было ровно так же. Никто даже и не задумывался. И через неделю уже опять забудет.
>
> > Надёжная совместная работа обеспечивается системой контроля версий текстовых файлов. Всё остальное неизбежно завязывается на реализацию сервисов и тонет вместе с этими сервисами.
>
> Не обязательно. Пока это так. Ну так и исходные тексты не всегда лежали в текстовых файлах. В IBM Visual Age и в Кларионе они лежали как бинарные файлы, по сути специализированные БД. И на тот момент это было круто и прогрессивно, когда коллективная работа без блокировок была не нужна, а на парсинг и поиск зависимостей в реальном времени не хватало мощности компьютеров.
Вы более экстремальные варианты не пробовали вспомнить? Например, программирование сразу в шестнадцатиричных кодах посредством монитора? Внезапно RCS появилась на два года раньше Клариона. Парсинг и поиск зависимостей как задачи компиляторов отлично решались ещё в 60х годах, а для управления варсиями они немного не нужны.
> А сейчас наоборот уже получается, языки и среды программирования должны быть VCS-friendly или останутся в тупиковой нише. Но это не значит, что остался один единственный язык программирования, скорее сложился консенсус о текстовых файлах, способах их разбиения на строчки, и достаточности учёта изменения по строке. За десятилетия нащупали золотую середину.
Требования читаемости исходного кода появились несколько ранее систем управления версиями. Фактически все RCS делались под них.
> Те же XML/HTML прекрасно ложатся в git в режиме "один тэг на строку" и не лягут в режиме "одна строка на файл" - но ровно то же и с C/Java/Pascal/etc
>
> "Персональных вики" с хранением в текстовых файлах уже сегодня в наличие. Вплоть до самомодифицирующейся самосохраняющейся вебстранички.
Страдающих от тех же проблем, что и любые сервисы? Нет уж, нет уж! Документация - только вместе с кодом. В крайнем случае в параллельном репозитории - если уж очегь надо разделить доступ.
> Вопросом об интеграции трекеров и вики с исходниками просто пока никто всерьёз не занимался, решали более насущные проблемы. Но попытки найти "общий делитель" на уровне GUI (Eclipse Mylar/Mylyn, плагины к TortoiseGit/SVN) уже делают. Вероятно, это уже будет некое 4-е поколение VCS. Вики и трекеры останутся разными, как и ЯП остались, но они найдут способ хранить себя вместе с исходниками проекта в едином DVCS.
Консенсус опять есть. Это, безусловно, неизбежно.
> Но это будет не сегодня. Сегодня же "потеря гитхаба" будет болью, не решаемой одним лишь git push.
Только лишь потому, что всем, как я уже отмечал, по барабану. Вы отмахнулись от Org-Mode, а он позволяет реализовать баг-трекер, сопутствующую документацию, да даже учёт времени - и всё это в текстовом формате. С визуализацией тоде проблем нет. Кому хочется кнопочек - их есть.
> > "Массовое реальное программирование", как вы его назвали, полностью игнорирует саму возможность смерти гитхаба в частности
>
> Как вы это можете утверждать? Вы же сами сказали, что можно git push на любой другой сервис, в том числе просто в папку на USB-флешке или яндекс-диске, не говоря про ZeroNet/IPFS
А вы, с другой стороны, сказали, что вика и баги тоже нужны. Из того, что никто их в репозиториях не хранит, я делаю вывод об их малозначительности.
В качестве отступления: у моих нанимателей практически вся документация, относящаяся к продукту, хранится в репозитории с кодом. Баги и общение с заказчиками хранится у себя (с резервным копированием). Тут достаточно выпукло видно: документация продукта - важнее, чем документация проекта в смысле управления.
> Вот во времена Sourceforge + CVS/SVN это было куда ближе к правде.
Пережил переезд крупного проекта с Subversion на Bazaar на Assembla. Ну да, ужас. Но не ужас-ужас-ужас! Локальные бэкапы - наше всё.
> > и аналогичных сервисов вцелом.
>
> А это уже что-то масштаба "закроем завтра этот ваш интернет". Если это случится - то многие проекты станут невозможными хоть с гитом, хоть без. Хотя DVCS в принципе, хотя и с трудом, могут выжить даже в режиме флоппи-нета. ОСОБЕННО если смогут интегрировать в себя трекеры.
Вы неверно как-то истолковали моё высказывание. Исходный посыл: не только гитхаб, но и любой аналогичный сервис с централизованным багтрекером и т. п.
> > выбору git в качестве системы управления изменениями в новых проектах: миллионы мух не могут ошибаться
>
> Не самый плохой критерий, если лично ты пока ещё понимаешь в новой теме ещё меньше мухи.
> Кроме того, это просто удобно, если нужные тебе библиотеки УЖЕ ушли в Git, тогда банально проще сделать подмодуль, чем городить несколько разных DVCS. Опять же, и импорт из SVN изначально был.
> Условно говоря, кому нужен Veracity, если в нём не будет никого, кроме автора Veracity?
>
> Тут в общем-то тот же эффект "проще/полезнее быть с толпой", что и среди соцсетей, среди мессенджеров, и внезапно среди ЯП.
Для реально компилирующих языков программирования очень мало разницы на каком языке написан модуль: его определённо можно использовать из другого языка. Проблемы тут могут быть только у интерпретируемых языков программирования вроде, скажем, Java: с п-кодом особо не покомпонуешься, да. JIT-компилятор - это немного про другое: полноценной компоновки уже не получится никак и из С++ позвать жабу - тем более. Только изврат с межпроцессным взаимодействием. Это при условии, что жабомашина вообще есть для целевой платформы.
То же самое и с VCS: "компоновка" с разными VCS и системами сборки уже давно решена, и не один раз. В частности - bitbake или west. Обычно на платформе разработки питон имеется.
> > Да, вы пару раз упоминали офис. А в чём разница при согласовании правок? merge есть merge, и разницы нет никакой
>
> Я упоминал в контексте удобства обычных действий. Гораздо удобнее и быстрее "нажать кнопочку" в Экселе или Либре, чем раззиповывать и править XMLи и зазиповывать обратно. Настолько быстрее, что кроме редких и очень специальных случае... Еще проще: настолько проще и быстрее, что люди подняли себе этот геморрой "написания и поддержки офиса".
А, вы всё ещё только лишь в этом смысле? Я про документацию уже в офисных форматах, которую так любят накоторые управленцы. (И чего им в PDF мало? Или они не в силах простейший markdown даже освоить? Я не говорю уже про LaTeX - хотя его у меня умудрялись знать все студенты с самой непопулярной кафедры.)
> Так же и с трекерами, нажать стандартную кнопочку по добавлению комментария, скриншота, перевода тикета между соседними состояниями - банально проще и быстрее, чем редактировать в блокноте. И конфликтов при этом скорее всего не возникнет. Если вы добавляете комментарий и в то же самое время я добавляю комментарий и закрываю тикет - хоть для Мантиса, хоть для Жиры это три разных действия, взаимно дополняющих и без конфликта. А вот при редактировании копий маркдаун-файла это будет типовой конфликт.
Который нормальная DVCS (не git) почти наверняка разрешит самостоятельно.
> > для MS Office все варианты Linux
>
> я ни разу не конкретизировал какой именно офис, и намеренно не писал его с большой буквы. Хотя бы потому, что OASIS был хронологически раньше Office OpenXML. Раньше Оазиса, вероятно, были Excel XML-SS (2002, возможно даже 97) и особенно RTF - но эти не являются явно мною проговоренными XML/Zip.
Пример был про почти всегда имеющиеся ограничения офисных пакетов относительно сред разработки и, хотя это и осталось за скобками, предпочтений разных офисных стулопросиживателей. Пример из сферы рядом: у меня установлено 8 мессенджеров только для работы - чтобы было удобно заказчикам. Хотя всё отлично решается и по почте. Более того, в итоге всё равно производится рассылка резюмирующего письма. В теории хватило бы 3 мессенджеров с функцией видеозвонков. Но - вот так.
Также хранение документации проекта в текстовом виде соответствует широко разрекламированному принципу KISS.
> Угловые скобки - это же так приятно и радует глаз!
Это банально удобнее: быстрее и проще. Не нужна третья рука для мышки и не нужно вспоминать, куда именно на (n+1)-м форуме (n+1)-й дезигнер кнопку засунул, и какое у неё поведение.
Для инлайнового цитирования, кстати, оверквотинг не является обязательным.
Но я не настаиваю, чтобы вы этим пользовались, у вас своё представление о прекрасном и удобном.
В принципе, всю цивилизацию можно рассматривать, как движение за снижение накладных расходов = повышение удобства и скорости. От изобретения колеса и до изобретения разного ИИ, в том числе, увы, и мошенниками.
>> В случае git и гитхаба - да. В случае fossil - нет. Плюс и минусы есть у обоих подходов.
> Также да - в случае практически всех систем управления изменениями. Fossil здесь - просто исключение.
Сейчас да. Как когда-то исключениями были все новые VCS. Те же bazaar 1 и что там до него было, GNU ar? То ли слишком рано, то ли не нашли оптимум, то ли не было рекламного скандальчика - но не взлетели. А BitKeeper и git взлетели. Наверное и Fossil когда-то останется курьёзом истории, как Bazaar 1, когда нащупают оптимум хранения доков и трекеров в репе.
>> Всё остальное, что хранится на гитхабе, через git push не восстановить.
> И опять - вопрос только в способе хранения. Включение всего управления проектом в репозиторий вместо сервиса этот вопрос
решает.
Безусловно, если кто-то УЖЕ этим озаботился. Но пока на лицо отсутствие мейнстрима. Нет достаточно удобного большинству людям способа.
Хотя лично вы или лично я можем в режиме человек-оркестр вводить любую удобную для нас лично автоматизацию. Но на мейнстрим это же не повлияет.
>> Не обязательно. Пока это так. Ну так и исходные тексты не всегда лежали в текстовых файлах. В IBM Visual Age и в Кларионе
....
>> на парсинг и поиск зависимостей в реальном времени не хватало мощности компьютеров.
> Вы более экстремальные варианты не пробовали вспомнить?
Мне кажется забавным продвижение emacs и жалобы на экстремальные случаи одновременно.
И git в момент появления тоже был экстремальным случаем. Это он сейчас мейнстрим. Не взлети CVS/SVN - и подход спец-форматов мог бы и стать мейнстримом, а экстремальным вы бы сегодня называли пачку раздельных текстовиков, даже не zip'ованных.
> Парсинг и поиск зависимостей как задачи компиляторов отлично решались ещё в 60х годах,
Вы как-то пропустили ключевое "в реальном времени". Мне не нужна подсказка по методам или параметрам функции, которую вечером принесёт девочка-машинистка на бумажном рулоне, мне она нужна в момент набора текста, и 5 секунд - максимум задержки. И чтобы проект при всём этом открывался за одну минуту плюс-минус.
> а для управления вeрсиями они немного не нужны.
Верно. И пришлось выбирать где что важнее.
А рост скорости и памяти привёл в итоге к тому, что частичная компиляция одновременно с чтением множества файлов с диска "брутфорснул" парсинг даже в форматах хранения, удобных для СКВ.
> Требования читаемости исходного кода появились несколько ранее систем управления версиями.
Равно, как и холивары о стилях форматирования.
> Фактически все RCS делались под них.
Не думаю, что прямо под "требования читаемости", скорее под "наибольший общий делитель" всех языков.
Чтобы не встраивать в RCS парсер каждого конкретного языка программирования.
>> "Персональных вики" с хранением в текстовых файлах уже сегодня в наличие. Вплоть до самомодифицирующейся самосохраняющейся вебстранички.
> Страдающих от тех же проблем, что и любые сервисы? Нет уж, нет уж!
Не обязательно. Если информация хранится в текстовом файле (а wiki-разметки по определению текстовые, а отличие от Конфлюэнс и аналогов) - то чем вам "IDE" для редактирования документации принципиально отличается от IDE для редактирования кода ?
Я пока вижу две потенциальные разницы:
1) доступ к документации без IDE и без клонирования всего репозитория. Это не актуально для "человека-оркестра", но актуально для не-программиста или для мимокрокодила, который пока только почитать хочет.
2) количество BLOBов, которые из DVCS хрен удалишь, раз они туда попали. Одно дело тысяча мелких картинок-иконок, которые меняются редко, а если меняются - то целиком один файл, а другое - какой-нибудь условный файл visio или corel Draw! Ну ладно, их можно в SVG перегнать, и наверное найти VCS-friendly редактор SVG.
Всё это когда-то, наверное, устаканится и придёт к 2-3 мейнстримным вариантам, но не сегодня.
>> Вики и трекеры останутся разными, как и ЯП остались, но они найдут способ хранить себя вместе с исходниками проекта в едином DVCS.
> Консенсус опять есть. Это, безусловно, неизбежно.
Кстати, я забыл ещё один признак этой подводной движухи. Разделение трeкеров на issue tracker и прочие CRM - и чисто технические bug tracker. Потому что во-первых там вовсе не one-to-one, а во-вторых - "8 мессенджеров" и первичные отчёты в стиле "открываем
кошёлкуdocx, достаём из него PDF, достаём из него скриншот". Понятно, что в DVCS по возможности должны попадать минимизированная и выверенная информация.Которую удалить невозможно, но и хорошо, потому что не нужно.>> Но это будет не сегодня. Сегодня же "потеря гитхаба" будет болью, не решаемой одним лишь git push.
> Только лишь потому, что всем, как я уже отмечал, по барабану.
Накладные расходы, всякие learning curve, не говоря о выборе неизвестного инструмента из неизвестного множества.
Те же СКВ далеко не сразу стали мейнстримом, а полтора десятка вложенных снепшотов в virtualbox вместо коммитов в git я видел совсем недавно.
Чтобы подсесть на наркоту - нужно её попробовать. Возможность дёрнуть историю изменений в DVCS за долю секунды, а не за десятки секунд, как в SVN - это круто, очень, но только когда ты это попробуешь и на это подсядешь.
Что, впрочем, не специфично для IT, любые изменения в цивилизации проходят от "а что, разве можно жить с этим?" до "а что, разве бывает жизхнь без этого?".
> Вы отмахнулись от Org-Mode, а он позволяет реализовать баг-трекер, сопутствующую документацию, да даже учёт времени - и всё это в
текстовом формате. С визуализацией тоде проблем нет. Кому хочется кнопочек - их есть.
вот только "миллион мух" не спешат себе ставить "хорошую операционку с плохим текстовым редактором" ради одной этой фичи
аналогично и LISP не стал единственным языком программирования, вобравшим все прочие
так что пока emacs - это локальные эксперименты на уровне fossil
более того, у fossil есть выход на PMа, который будет писать в трекер в обычном браузере, без установки себе спец-программы и клонирования полного репозитория, так что если сравнивать эти два варианта IMHO у подхода fossil больше шансов на выход из ниши человека-оркестра.
Но в любом случае, в мейнстрим пойдет(?) что-то другое, которое синтезирует опыт и того и другого.
> А вы, с другой стороны, сказали, что вика и баги тоже нужны. Из того, что никто их в репозиториях не хранит, я делаю вывод об их малозначительности.
Сравнительно с реальными или воображаемыми затратами на подбор и обучение инструментам.
Равно, как и СКВ когда-то воспринимались безумными экспериментами яйцеголовых из IBM, которым деньги девать некуда. Побочкой от всяких ClearCase. А простые люди и папочку на сервер zip'анут батничком раз в день.
А потом появились SourceForge, TortoiseCVS и вдруг оказалось что это может быть просто и удобно. Более того, появились проекты, которые иначе разрабатывать было бы почти невозможно практически. Что склонировать репозиторий на локальный комп практически проще, чем скачивать и распаковывать тарболлы. И всё заверте...
> В качестве отступления: у моих нанимателей практически вся документация, относящаяся к продукту, хранится в репозитории с кодом.
Молодцы, что отстроили процесс. И молодцы, что у них есть/было кому отстраивать этот процесс.
> Баги и общение с заказчиками хранится у себя (с резервным копированием).
А вот тут уже организационный процесс, который влияет на инструменты, и на который влияют инструменты.
Потому что end users несут пургу и присылают дампы БД, а в модификацию ТЗ/диздоков должны попадать уже конкретные reproducible case. До которых ещё дойти надо (кому-то). А потом еще решить/договориться в какую сторону их исправлять.
> Тут достаточно выпукло видно: документация продукта - важнее, чем документация проекта в смысле управления.
Абсолютной ценности не существует, если проект действительно кому-то нужен, то даже полностью потерянный он будет написан с нуля.
В то время "потеря багов" чревата тем, что придётся заново набивать шишки и злить пользователей.
Ну и наконец, если у вас действительно есть контур, которые за считанные дни близко к идеальному перерабатывает баги в изменения ТЗ - тогда вам историю переписок можно в самом деле не хранить. Но к большинству проектов на GH это едва ли относится.
> > и аналогичных сервисов вцелом.
>
> А это уже что-то масштаба "закроем
завтра этот ваш интернет". Если это
случится - то многие проекты станут
невозможными хоть с гитом, хоть без. Хотя
DVCS в принципе, хотя и с трудом, могут
выжить даже в режиме флоппи-нета.
ОСОБЕННО если смогут интегрировать в себя
трекеры.
> Исходный посыл: не только гитхаб, но и любой аналогичный сервис с централизованным багтрекером и т. п.
Ну на самом деле исходный посыл был "а что, если навернется SSO-инфраструктура не у фейсбука, а у майкрософта". Отсюда взялся и GH.
А так-то да, все аналогичные сервисы аналогичны. Но на гипотетический SPoF от майков завязан именно GH.
> > Кроме того, это просто удобно, если нужные тебе библиотеки УЖЕ ушли в Git
> Для реально компилирующих языков программирования очень мало разницы на каком языке написан модуль: его определённо можно использовать из другого языка.
Если свести весь интерфейс до уровня машинных форматов и plain C.
Либо если суметь сделать обёртку более высокого уровня, те же COM или REST-RPC
Но в последнем случае через REST можно и с JVM/.Net общаться.
> полноценной компоновки уже не получится никак и из С++ позвать жабу - тем более.
Так и обратное чревато. Если только некто, знающий сразу плюсы, ассемблер и жабу, не наладит процесс, то первая же проблема "на стыке миров" ставит "просто жабиста" в ступор. А "просто плюсист" даже понимая суть проблемы на уровне байтов не сможет решить её в терминах Жабы. Тупо неправильно оттранслировали calling convention какого-нибудь из MIPS на жаргон Java. Проглядели & или const по запарке. А когда наткнулись - кто это делал и знал давно уволен, как избыточное звено. И это даже не предполагая ошибок компиляторов и прочего тулчейна, которые тоже - чем сложнее тулчейн, тем вероятнее.
Но... в этом что-то новое? Чем сильнее различаются языки - тем потенциально больше проблем в их компоновке. Из условного Lisp или Erlang тоже хрен дёрнешь объект C++ с множественным наследованием. И даже, если нет исходников, объёкты собранные в C++ разных вендоров.
> Это при условии, что жабомашина вообще есть для целевой платформы.
Аналогично для любого компилятора. Просто так сложилось, что какой-нибудь C++ есть почти везде, а где нет - есть хотя бы picoC :-D
> То же самое и с VCS: "компоновка" с разными VCS и системами сборки уже давно решена, и не один раз.
Это пока она работает automagically.
> В частности - bitbake или west. Обычно на платформе разработки питон имеется.
А потом какой-то тупой сбой - и лихорадочно ищем гуру, который знает одновременно Питона, Питона конкретно на этом CPU/OS, конкретно bitbake или west и конкретно в применении к паре например git+Hg.
Потому что без такого гуру - даже просто понять ГДЕ случился сбой невозможно.
Хотя ЕСЛИ вы лично - человек-оркестр, знающий все эти инструменты, то конечно лично для вас нет причин ими не пользоваться.
> > Я упоминал в контексте удобства обычных действий. Гораздо удобнее и быстрее "нажать кнопочку" в Экселе или Либре
> А, вы всё ещё только лишь в этом смысле?
Всего лишь? снижение накладных расходов и повышение удобства/cкорости - суть цивилизации :-D
> Я про документацию уже в офисных форматах, которую так любят накоторые управленцы.
Ну в общем виде - это да, абьюз.
> > Так же и с трекерами..... Если вы добавляете комментарий и в то же самое время я добавляю комментарий и закрываю тикет - хоть для Мантиса, хоть для Жиры это три разных действия, взаимно дополняющих и без конфликта. А вот при редактировании копий маркдаун-файла это будет типовой конфликт.
> Который нормальная DVCS (не git) почти наверняка разрешит самостоятельно.
Без парсинга некоего tracker markup language? а как ?
В конце файле ticket1234.md в двух конкурирующих ветках (своей и вашей) появились новые РАЗНЫЕ блоки. Это просто таки букварный случай конфликта правок. А если комменты вешаются не в онец файла, а в конце файла у нас метаданные тикета отдельным блоком идут, которые ТОЖЕ изменились при добавлении комментариев - так и вовсе.
Тут уже VCS должна понимать семантику языка. А пока развитие идёт в обратную сторону, как бы "роботу" достаточно эффективно управлять исходными текстами, не зная ни языка, ни даже его примерной структуры.
> Также хранение документации проекта в текстовом виде соответствует широко разрекламированному принципу KISS.
Это всё же далеко не всегда наглядно. какой-нибудь конечный автомат в виде графа переходов нагляднее, чем в виде списка правил. А псевдорафику весьма неудобно редактировать и подгонять под размер экранов.
Но в принципе да, развитие personal wiki c хранилищами в виде plain text к этому приведёт. Какое-нибудь TiddlyWiki в режиме "один тэг на строку" туда хоть сейчас ляжет. Особенно, если дописать back-end, чтобы сохранение странички транслировалось в git commit.
Кстати, то ли провайдер чудит, то ли википедию опять отцензурили, по HTTPS не открывается :-) Стараниями Яровой уже возникает задача об автоматическом дублировании и обновлении ВСЕЙ документации по всему стэку используемых технологий. Ну или всем уходить в i2p/IPFS/ZeroNet, пока реально не пришлось кодировать в 8-ричных кодах в пультовом терминале :-D
Резюме примерно 90% вами написанного: для 80% программистов в "реальном массовом программировании" инженерный подход к программированию - это скорее исключение, чем правило. В частности потому что они не знают историю отрасли и не представляют её сколь-либо приемлемо. Это выражается, в частности, в изобретении костылей и велосипедов. Вторая популярная причина таких изобретений - неспособность воспользоваться существующими (см. Python по отношению к Perl). Например:
Ага, точно, можно. В каком-нибудь WROVER с его FreeRTOS, например. А вот нормальные компилируемые языки - используй сколько влезет! Это был пример традиционного уже в отрасли игнорирования фактора ограниченности языков с виртуальными машинами исполнения в смысле поддержки аппаратных платформ.
Второй пример:
А вы сами-то её пробовали, или просто транслируете стереотипное мнение? Вот вам ещё одно за компанию: "Vi умеет только пищать и портить". И что? Для того, чтобы подобные мнения транслировать, надо иметь хотя бы какой-то опыт работы, а не прочтения анекдотов. Маленький плюс изучения Emacs на начальном уровне - радикальное повышение эффективности работы с командной строкой в sh-образных средах. Точнее, в средах на базе libreadline. C-p, C-f, C-b, C-w и тому подобное. Впрочем, примерно 80% современных фанбоев просто не понимают зачем нужна командная строка - и теряют примерно 50% эффективности.
"Я - гений! Прочь, сомнения!", как пел В. С. Высоцкий. И при этом я лично знаю несколько человек, до которых мне ещё расти и расти. Просто почему-то так получается последние 10 лет, что меня постоянно назначают на мультиязыковые проекты. То есть там пара нормальных языков программирования, питон и шелл - или пара шеллов дёргается из CMake в зависимости от платформы. Кстати, в сборочных средах особенно приятно то, что их гораздо меньше применяется, нежели целевых платформ. И в моём опыте это чаще всего - Linux. Потому что из Windows сборка оправдана только для Windows и некоторых совсем уж специфичных платформ вроде техасовских ССшек (хотя и для них уже можно под Linux собирать).
Всего лишь оптимизации. И при условии освоения технологии гораздо быстрее оказывается сделать изменения именно в текстовом файле. Например, конечный автомат в виде графа переходов можно отлично хранить в виде текста. Красивую картинку обеспечит graphviz и более специальные инструменты на его основе. Вплоть до UML-диаграмм на выходе, если их очень захочется.
Что-то я всё это перечитал и стало грустно. А самое забавное - мы начинали совсем о другом. Также я ни в коем случае не хотел бы вас обидеть: в конце концов, у всех свой специфический опыт работы.
По большому счёту я хотел сказать, что почти всё новомодное изобретено ещё до нас. Тот же Smalltalk: модульные тесты, рефакторинг, паттерны, что-то там ещё наверняка. Autotools сегодня умеет готовить в лучшем случае один из тысячи, хотя автотулзы не сильно сложнее CMake и однозначно эффективнее в POSIX-средах. Хочется IDE одну на все случаи жизни - вот тебе две на выбор: Vim и Emacs. Бери, настраивай и пользуйся. Не нравятся ванильные реализации - есть достаточное количество альтернативных, но совместимых. Тебе в них мало простых тэгов? Clang предоставляет инструменты для синтаксического анализа C-подобных языков. Плагины есть для обоих классов редакторов. Хочется чего-то не столь классического, например erlang - там тоже всё в порядке, по крайней мере - для Emacs. Причём, обратите внимание, документация по Erlang Mode находится прямо на официальном сайте Erlang. А также sed, awk и прочее давно забытое "потому что некогда изучать - надо бежать делать новое". В результате имеем в отрасли то, что имеем: костыльные велосипеды. страдающие от детских болезней давно отработанных технологий.
> Резюме примерно 90% вами написанного: для 80% программистов в "реальном массовом программировании" инженерный подход к программированию - это скорее исключение, чем правило. В частности потому что они не знают историю отрасли и не представляют её сколь-либо приемлемо.
Это относится к любой популярной отрасли. Когда то для жарки мяса были специальные королевские повара, а сейчас купил в условном магните пакет условных ростиксов и кинул на сковородку или в микроволновку, плеснув любого там же купленного масла.
Собственно, популярность в этом и заключается, что заходят не только элиты.
Хорошо это или плохо - это уже будет отдельная спец-олимпиада. Но у миллиона мух большая потребительская способность (не важно, выражается ли она в деньгах, в разных опросах, в лайках и прочем эго-чесании). А кроме того, если потребности седовласых мудрецов они сами и удовлетворили ещё в 1980-х, то потребности миллиона мух ещё предстоит удовлетворить.
> см. Python по отношению к Perl
Тут опять же, скорее замедление общего развития и соответственно сдвиг фокуса с "напиши один раз как угодно и выкинь" к долгосрочному maintenance, для чего читаемость текста хорошо бы заводить начиная с языка.
Впрочем, тут и инерция, конечно. Язык для обучения тащится с собой после школы, и если он достаточно хорошо для решения начальных практических задач - то почему бы и нет.
> Маленький плюс изучения Emacs на начальном уровне - радикальное повышение эффективности работы с командной строкой в sh-образных средах. Точнее, в средах на базе libreadline.
Вот только вопрос - насколько это актуально? Конечно, приятно пройтись по википедии и поразглядывать разнообразие клавиатур 1970-х годов. Полторы сотни клавиш - ага! Но сегодня почти везде Microsoft 105 key. И все эти meta- из полезных переменных превратились в "забивающий оперативку" ненужный слой абстракции. Не для всех, но для большинства.
> языков с виртуальными машинами исполнения в смысле поддержки аппаратных платформ
А набор библиотек не надо портировать под каждую новую платформу? Начиная с базового RTL и дальше по стеку. Нет, конечно в идеальном мире код всех библиотек будет идеально переносим с любой мыслимой и немыслимой системой будущего, так что после портирования условной libc всё остальное "просто соберется". Но ведь и с виртуалками так же, в идеально написанное виртуалке останется портировать только abstraction layer, а остальное "само собёрется". А особенно "сами соберутся" как раз прикладные библиотеки, которые вообще ничего про железо не знают, даже размера байта.
Да, кстати, как там LISP - полностью компилируется, или тоже JIT-виртуалка?
> хотя автотулзы не сильно сложнее CMake и однозначно эффективнее в POSIX-средах
Вот только необходимость в POSIX-средах сильно упала. Увы, UNIX Wars даром не прошли.
Соответственно, в 21 веке это уже звучит "пониженная эффективность в не-POSIX средах" и, возможно, фрагментация платформы.
Вот Apache 2 например отвязали от необходимости fork'аться на каждый чих, а autoconf?
А проще говоря, мало кому в мире autotools интересны проблемы виндовозников, яблочников и андроидников, и одновременно мало кому в мирах в/я/а интересны проблемы ат.
Как там, кстати, будет практические АТ-системы сборки больших проектов на платформе без bash, а возможно даже и без sh? А то ведь необходимость портирования VM - это минус, а необходимость портирования bash и скриптов под него? И банальные башевские rm -rf $(empty_var) и rm -rf /bin /GeForceDrivers - это тоже проблема autotools, если вам хочется, чтобы им пользовались "миллионы мух".
> И при условии освоения технологии гораздо быстрее оказывается сделать изменения
Вот только это условие - это отнюдь не фея волшебной палочкой взмахнула. У вас просто ошибка выжившего, лично для вас оно бесплатно, потому что вы УЖЕ их выучили, а вот привыкание к альтернативам - для вас это затраты времени и нервов. Но у свежевылупившейся мухи ситуация не такая.
> Впрочем, примерно 80% современных фанбоев просто не понимают зачем нужна командная строка - и теряют примерно 50% эффективности
Забавно, что последний мне встретившийся фанбой командной строки и линукса - это тот самый, кто вместо комиттов в гит делал снапшоты virtualbox. Хотя уже нарывался дома на то, что перетащенный на домашний линукс многосоставной образ Windows 7 со всеми тулзами не взлетел. То ли он какой-то из снэпшотов забыл скопировать, то ли просто на баг в VirtualBox'e нарвался.
Но ведь в VB достаточно кнопочку тыцнуть, а в git'е надо командную строку вспоминать, с vim'ом общаться...
Но в теории он вес из себя за командную строку и самописные скрипты, пока лично ему не надо в повседневной работе. А тут резко вся пламенная идеология идёт лесом и побеждает "кнопочку тыц, и чтобы мозг не включат не выпадать из потока".
А когда мне потом понадобилось удалить строку на винде из нескольких десятков файлов (какой-то добрый человек когда-то singleton объект "бросил на формочку", причём на базовую форму, и он растиражировался по всем потомкам), я таки, мышевозник и виндузятник, зарылся в man sed, а он - предложил скриптик на perl'е написать (что вообще говоря за собой тянет не всегда тривиальную задачу поиска работоспособной реализации perl для конкретной версии винды, хотя в данном случае я бы знал что брать, просто потому что не так давно патчил сборку FrozenBalls, но это просто совпадение). Потому что каждому проще использовать уже изученное, и ключи проще искать под фонарём, а не где потеряли.
До "языков с виртуальными машинами" у вас идёт, уж простите, обсуждение полезности кустарей в индустриальном обществе. На самом деле кустари чуть менее чем не нужны в сообществе инженеров, потому что не владеют ни методами, ни зачастую даже необходимыми для применения этих методов систематическими знаниями. А большинство и не хотят их получать. Это обычные жертвы рекламы информтеха как отрасли с большими зарплатами и низким порогом входа. Кстати, если вы не в курсе, мета - это тот же альт. Присутствует на всех современных клавиатурах. Более того, на современных клавиатурах есть дополнительные клавиши Cmd и Menu - и ничего, никто не жужжит, а наоборот: в довольстве хавают. У меня вообще 88 клавиш - но всё это богатство присутствует.
Про HAL вы заметили правильно: он обеспечивает совместимость на уровне исходных кодов. А вот перекомпиляция виртуальной машины под целевую платформу такой совместимости вообще говоря не обеспечивает: например, платформа не может вместить виртуальную машину, исполняющую нетривиальную программу. Привет, Java на AVR. Хотя 128К NVRAM - это же просто роскошь простора! Это я вам по собственному опыту говорю: там уже FreeRTOS заводится с нетривиальными задачами.
Лисп, равно как и жаба, и питон, и все-все-все, вполне приемлем в средах разработки: там традиционно машинки достаточно пухлые, причём гарантированно пухлые. Для разработки можно себе позволить даже IDE на Eclipse. Хотя и не до конца понятно зачем.
И поэтому десктоп позиксный чуть менее чем полностью, в том числе M$ мало того, что сделали (и давно уже) единый корень файловой системы, так ещё и добавили вполне съекдобный WSL! Действительно, POSIX не нужен.
Нет. Это проблемы самописных скриптов инсталляции проприетарных драйверов. Не надо перекладывать с больной головы на здоровую: чаще всего ошибки - именно в одноразовых рукодельных скриптах. И живут они там иногда годами.
Для меня затраты нервов и времени на освоение ещё одной системы сборки (в частности) не сильно превышают таковые на донесение ладони до лба. Кстати, именно по озвученной вами причине: я приемлемо освоил автотулзы, CMake, собственно make и в минимально необходимой степени - ещё кучу всего. Ещё одной больше - не проблема. Подавляющее большинство новичков не утруждаются разобраться в принципах функционирования даже той единственной системы сборки, на которой они работают и переходят в опарышей, использующих эту систему на основе устоявшихся рецептов, как и велит межушный ганглий. Ситуация свежевылупившейся мухи именно такова.
Снапшоты виртуалки вместо контроля версий - это вообще за гранью добра и зла. И это не "кнопочку нажать удобнее", а просто шизофрения очередного опарыша. Решается переквалификацией в дворники: из такого даже QA не выйдет как мне представляется.
И ещё момент: не с вимом, а "с текстовым редактором, установленным в системе по умолчанию" - всего-то надо прочесть инструкцию, и будет это что угодно: vim, emacs, nano или даже gedit. Переменные среды EDITOR и VISUAL в помощь.
А также потому что проще использовать специальный инструмент (потоковый редактор) вместо универсального (Perl). Универсальный инструмент - это автоматизация, а у вас была в чистом виде разовая задача. Тут даже не надо быыло искать: автоматизация на один раз - зло злостное, так как съедает неоправданное количество ресурсов. Хотя если он версии контролировал снапшотами виртуалки...
Всё это, опять же, об одном: кустари в индустриальном производстве не нужны. А эти миллионы мух, невзирая на их дипломы, так и остаются кустарями. Некоторые компании пытаются выращивать инженеров. Иногда даже получается. Далеко не всегда. Наблюдение из опыта: инженер обычно имеет достаточно хороший опыт как минимум с одним из двух основных *nix-редакторов. Иногда даже с обоими. На самом деле это просто следствие разнообразия проектов, на которых он работал, а не самоцель. Другое дело, что даже этот опыт основательно развивает его как инженера: исторический опыт - он такой, да.
> кустари чуть менее чем не нужны в сообществе инженеров
Вот только что считать сообществом? Безусловно, специализация помогает. Есть специалист по левым рукавам, специалист по правым, специалисты по пуговицам для левых и правых рукавов, специалисты по пришиванию готовых рукавов друг к другу...
Но это требует достаточно большого размера самого сообщества. Что не везде присутствует.
> Кстати, если вы не в курсе, мета - это тот же альт.
Я в курсе, но ЗАЧЕМ мне засорять память этим уже лет 30 не имеющим никакого значения вывихом истории? Карго-культ.
> например, платформа не может вместить виртуальную машину, исполняющую нетривиальную программу. Привет, Java на AVR
Количественно вы правы: GC-языки требуют больше памяти "в целом", особенно если "остановки мира" нежелательны. Поэтому для специальных применений ARC-языки и malloc/free будут лучшим выбором, а может быть и подход Rust взлетит.
Качественно же - я просто напомню про JavaME на телефонах 20-летней давности.
> 128К NVRAM - это же просто роскошь простора!
В терминах страниц флэш-памяти - это сколько штук?
Вам не хочется использовать специализацию (RAM+flash)? Вам хочется использовать кустарную jack of all trades NVRAM? Нишевым задачам - нишевые инструменты.
> в средах разработки: там традиционно машинки достаточно пухлые, причём гарантированно пухлые
И это, кстати, само по себе не всегда хорошо. В тестовых прогонах и отладке не видно, как программа себя поведёт на железе в несколько раз слабее. Не наглядно. Впрочем, непонимание масштабирования - стандартная тема DailyWTF и количеством ядер и RAM не исчерпывается.
> так ещё и добавили вполне съекдобный WSL
POSIX был ещё в NT4 для армии США.
А сейчас там Убунта - относительно популярный десктоп. Не "просто POSIX" и даже не дебиан, а конкретно Убунта.
> Нет. Это проблемы самописных скриптов инсталляции проприетарных драйверов. Не надо перекладывать с больной головы на здоровую
Это в вас заговорил кустарь, обиженный пренебрежением к "опыту предков".
Для кустарей типично пренебрежение безопасностью. Во-первых просто нет лишних ресурсов, поэтому "срезать угол" при любой возможности - нормальный рефлекс. Во-вторых, чем опаснее инструмент, тем больше учеников отсеется, тем больше цена на переживших естественный отбор гуру.
А с инженерной точки зрения - это навязывание unsafe by design инструментов. Случайная ошибка должна приводит к минимальным посоледствиям, а не к максимальным.
Bash сделан ровно наоборот. Autotools завязаны на использование bash. То есть autotools - это unsafe by design инструмент, сделанный седоволосыми гуру таким образом, чтобы максимизировать последствия ошибок. "Тупые ученики должны страдать, вместе с нарушающими конвенцию нанимателями новичков, это порождает полезный страх нанимать их на работу и повышает ценность сообщества седобородых мудрецов".
> А также потому что проще использовать специальный инструмент (потоковый редактор) вместо универсального (Perl)
Не только проще (хотя и это тоже, не надо писать бойлерплейт по поиску/открытию/чтению/закрытию файлов), но и безопаснее (вот в написании этого рутинного бойлерплейта можно так опечататься, что потом время и нервы потеряешь).
> это просто следствие разнообразия проектов, на которых он работал, а не самоцель
Я бы не назвал это инженером, во всяком случае - не в смысле индустриального поточного производства.
Для "конвейера Форда" не нужно владение 10 инструментами и 100 операциями, наоборот, во всех смыслах лучше, если работник владеет ровно одной операцией.
> Кстати, именно по озвученной вами причине: я приемлемо освоил автотулзы, CMake, собственно make и в минимально необходимой степени - ещё кучу всего
Ну так это только усиливает мой тезис про ошибку выжившего. Вы УЖЕ ПОТРАТИЛИ время и силы на изучение N инструментов, а там убывающая кривая в самом деле, учить (N+1)-й тем проще, чем больше N
Т.е. в сравнении с молодой мухой, которая пока "кнопочку тыц в IDE", и которой придется изучать autotools с нуля, вы "выводите за скобки" всё УЖЕ ПОТРАЧЕННОЕ вами время на изучение N систем. И для вас - дельта затрат на изучение N+1 от затрат на изучение N очень невелика. А для мухи затраты на изучение второй, если не первой, системы - намного больше. Learning curve...
До позиксности современных окошек - вообще ни о чём. Особенно часть про встраиваимые системы: что заказчик дал, с тем и надо работать.
Винду делают всё более и более позиксной под капотом прежде всего именно для удобства копипасты уже не просто кода, а целых подсистем. Да здравствует sendmail.dll! В NT4 ЕМНИП.
Отлично! Я говорю, что какие-то корпоративные дебилы используют кустарные технологии - и это во мне говорит кустарь, причём обиженный! Уважаемый, вы как-то уж очень вольно обращаетесь со смыслами. Ну или тогда приведите пример функции в autotools 2.69, которая была бы небезопасной в себе. То есть без непосредственных команд шелл.
Потрясающее по своей некорректности построение. Из небезопасности sh не следует небезопасность autotools. Также как из небезопасности Очень Острой Фрезы для пальцев слесаря не следует опасность фрезерного станка по сравнению с многокоординатным обрабатывающим центром.
Непредвзятое сравнение autotools и cmake утверждает несколько обратное. В частности потому, что именно cmake требует более интенсивного непосредственного использования возможностей оболочки. И это не говоря о пошлой традиции оформлять всё макросами, хотя с версии 3.0 доступны функции.
Ну да, ну да. Этот адский learning curve. Специальное образование для программирования не нужно, ага! Да я не спорю, всё так. И пока это так, я получаю оплату выше рынка. Потому что я - ведущий инженер, а не по низу 3 категории. Потому что я способен адекватно спроектировать и реализовать в одиночку или в составе группы инженеров (в том числе руководя группой) функциональную подсистему программного решения или же менее сложное программное решение вцелом. В том числе и потому, что я постоянно изучаю новые (для меня) системы и совершенсвую знание уже изученных.
Сейчас уже не 2000 год, когда info autoconf содержало нечто неудобопонимаемое: там отличная понятная книга. Причём для начала работы совершенно не обязательно читать её всю - как и везде. Скорее уж потребуется более подробно читать про automake. Пример из обычной жизни: все знают, что законно купить оружие обычному гражданину - это ужасно дорого и сложно. Фактически же это занимает два месяца и стоит начиная от менее чем 20 000 рублей, причём не единомоментно: сейф, справки, две госпошлины и собственно оружие.
Кстати, почему не применяется "конвейер Форда" в индустрии в описанном вами смысле? Может ли быть так, что он применяется в другом смысле? Например, умение решать задачи определённой сложности в определённой сфере в качестве "ровно одной операции"? И может быть именно поэтому такую "ровно одну операцию" выполняет не рабочий, а инженер? Также именно поэтому до решения большинства задач в производстве ПО, то есть когда требуется предсказуемость, "мухи" не допускаются.
> Да здравствует sendmail.dll! В NT4 ЕМНИП.
И кто его использует? Кроме перенесённых из юниксов систем, скорее всего для армии США.
В ту же степь еще cygwin/MSYS в одну сторону и WinE в обратную. Означает ли существование WinE, что под Linux трудно писать нативные программы без WIn32 API ?
> Особенно часть про встраиваимые системы: что заказчик дал, с тем и надо работать
Так я не против. Я же и сказал - что это ниша, в которую именно этот инструмент помещается лучше. Я против обобщения этой ниши на программирование-вообще.
Вы, конечно, можете предположить, что IoT и встройки станут новым мейнстримом. Но пока это только гипотеза.
> Ну или тогда приведите пример функции в autotools 2.69, которая была бы небезопасной в себе. То есть без непосредственных команд шелл.
Мы просто возвращаемся назад по треду, где я вам спрашивал о примерах больших проектов, в которых AT иcпользовалась бы без шелловых скриптов, тогда вы промолчали.
> И пока это так, я получаю оплату выше рынка
По идее, это просто признак зрелости индустрии, когда головоломный бег вперёд замедляется и за пионерами подтягиваются обычные селяне. Работающий на кассе в макдаке или магните кассир не обязан мечтать изменить мир или "стать генералом".
> Кстати, почему не применяется "конвейер Форда" в индустрии в описанном вами смысле?
Я предположу, что применяется. В крупных местах типа LuxSoft. Потому что глубокая специализация оправдана только там, где есть постоянная работа для каждого узкого специалиста (в нулевом приближении).
Там, где программисту оптимальнее не самому для себя настраивать autotools, а "открыть тикет" в поддержку, чтобы ему "пришли и настроили". В том числе и стоимость объяснения другому человеку, что тебе надо. Где это (в смысле как сообществ/организаций, так и процессов) достаточно регулярный и отработанный процесс и наличие узкого спеца окупается - будет "конвейер", где нет - "человек-оркестр".
Я приведу ещё пример, контрактника, работающего в DMZ. ОН потребовал себе доступ на мой git-сервер, который я себе поднимал (заодно с Мантисом) для совсем другого проекта (и делать себя заложником других проектов не собираюсь, если "мой" сервер упадет на практике никто его кроме меня не поднимет, и чтобы другие проекты мне сроки ставили - нафиг). На что я ему сказал, что у него и так есть сетевая шара, в которой он вполне может себе создать удаленный репозиторий и туда всё скидывать для надёжности. А если этого мало - он может затребовать себе копию моего сервера и там себе создавать, что надо. Но - на отдельной копии, которую я мейнтейнить не буду. Его ответ был вполне "конвейерным" - "я нанимался не на это, это вы должны мне предоставить работающий сервер по моим требованиям". А "кустарь" на его бы месте либо взял и сделал бы (если ему надо), либо не требовал бы (если не надо). Так я вижу разделение кустарей и промышленных рабочих.
> И может быть именно поэтому такую "ровно одну операцию" выполняет не рабочий, а инженер?
Если сообщество(компания) может себе позволить набрать "полный стэк" подчинённых, от "винтика" до "гения" - так и надо делать.
Но не только лишь все могут это позволить себе, причём вопрос не только денежный.
> Также именно поэтому до решения большинства задач в производстве ПО, то есть когда требуется предсказуемость, "мухи" не допускаются.
Если так, то не понимаю вашу тревогу о наплыве "вайтишников" и будущем отрасли?
> > Да здравствует sendmail.dll! В NT4 ЕМНИП.
> И кто его использует? Кроме перенесённых из юниксов систем, скорее всего для армии США.
Недостаточно?
> В ту же степь еще cygwin/MSYS в одну сторону и WinE в обратную. Означает ли существование WinE, что под Linux трудно писать нативные программы без WIn32 API ?
Вот только не надо изображать из себя не знающего! Я бы посмотрел на человека, который для окошек разрабатывает под WinE. А вот окошки чем дальше, тем больше становятся позиксными, и не только под капотом. Это, очевидно, из-за замшелой устарелости никсов и прогрессивности Особого Пути Виндоуз.
> > Особенно часть про встраиваимые системы: что заказчик дал, с тем и надо работать
> Так я не против. Я же и сказал - что это ниша, в которую именно этот инструмент помещается лучше. Я против обобщения этой ниши на программирование-вообще.
> Вы, конечно, можете предположить, что IoT и встройки станут новым мейнстримом. Но пока это только гипотеза.
Есть много разных не-мэйнстримов, которые мэйнстримом никогда и не станут. Вы предлагаете для них иметь отдельные языки программирования? Да я не против: "мухи", как вы их систематично называете, от этого будут только проигрывать, а я - всегда иметь икру на хлеб с маслом. Причём икру не баклажанную отнюдь.
Совместимость на уровне кода - это очень большое достижение. Отказ от обобщения опыта программирования игнорированием не-мэйнстримных областей неизбежно приведёт к обеднению. И, конечно же, к несовместимости даже на уровне исходного кода.
> > Ну или тогда приведите пример функции в autotools 2.69, которая была бы небезопасной в себе. То есть без непосредственных команд шелл.
> Мы просто возвращаемся назад по треду, где я вам спрашивал о примерах больших проектов, в которых AT иcпользовалась бы без шелловых скриптов, тогда вы промолчали.
GIMP. Ни одной небезобпасной команды sh. Или приведите пример как можно что-то повредить командой test.
> > И пока это так, я получаю оплату выше рынка
> По идее, это просто признак зрелости индустрии, когда головоломный бег вперёд замедляется и за пионерами подтягиваются обычные селяне. Работающий на кассе в макдаке или магните кассир не обязан мечтать изменить мир или "стать генералом".
Пользователь не производит.
> > Кстати, почему не применяется "конвейер Форда" в индустрии в описанном вами смысле?
> Я предположу, что применяется. В крупных местах типа LuxSoft. Потому что глубокая специализация оправдана только там, где есть постоянная работа для каждого узкого специалиста (в нулевом приближении).
А о каком, простите, конвейере может идти речь тогда в "небольшом месте" на 10, скажем, человек? Просто механистический перенос концепции конвейера не программирование приводит к идиотии: вот специалист по присваиванию целых беззнаковых, вот - по присваиванию целых со знаком, а вот наш ведущий специалист: он циклы пишет! Внезапно, инженерное программирование - это не промышленное производство, а промышленное проектирование. Где инженеры последовательно уточняют проект (программного продукта) поэтапно при спуске по цепочке проектирования (реализации). И вот тут действительно появляются специализации: вот архитектор, вот - специалист по подсистемам ввода-вывода, вот - по вычислениям каких-то особо хитровывернутых численных вещей, а вот - толпа низкоуровневых детализаторов, которые пишут малоинтересные простые вещи и, изучая как эти вещи вписываются в систему, набираются инженерного опыта.
> Там, где программисту оптимальнее не самому для себя настраивать autotools, а "открыть тикет" в поддержку, чтобы ему "пришли и настроили". В том числе и стоимость объяснения другому человеку, что тебе надо. Где это (в смысле как сообществ/организаций, так и процессов) достаточно регулярный и отработанный процесс и наличие узкого спеца окупается - будет "конвейер", где нет - "человек-оркестр".
Там, где программист пишет тикет в поддержку, он называется пользователь.
> Я приведу ещё пример, контрактника, работающего в DMZ. ОН потребовал себе доступ на мой git-сервер, который я себе поднимал (заодно с Мантисом) для совсем другого проекта (и делать себя заложником других проектов не собираюсь, если "мой" сервер упадет на практике никто его кроме меня не поднимет, и чтобы другие проекты мне сроки ставили - нафиг). На что я ему сказал, что у него и так есть сетевая шара, в которой он вполне может себе создать удаленный репозиторий и туда всё скидывать для надёжности. А если этого мало - он может затребовать себе копию моего сервера и там себе создавать, что надо. Но - на отдельной копии, которую я мейнтейнить не буду. Его ответ был вполне "конвейерным" - "я нанимался не на это, это вы должны мне предоставить работающий сервер по моим требованиям". А "кустарь" на его бы месте либо взял и сделал бы (если ему надо), либо не требовал бы (если не надо). Так я вижу разделение кустарей и промышленных рабочих.
Опять пример какого-то неумного человека. Нормальный инженер в таких случаях делает заявку в условный АХЧ, и ему выдают всё это настроенное. В похожих обстоятельствах в одной конторе таскали упакованные репки меркуриала на номерных флешках - и ничего, не жужжали. На флешках, в частности, потому что общая сеть была только для административных отделов, но не для инженерных. Режим, все дела. Опять же, ещё и в этом меркуриал отлично помог - кроме того, что с SVN никого не надо было переобучать на идиотский альтернативно одарённый синтаксис.
> > И может быть именно поэтому такую "ровно одну операцию" выполняет не рабочий, а инженер?
> Если сообщество(компания) может себе позволить набрать "полный стэк" подчинённых, от "винтика" до "гения" - так и надо делать.
Нет, не надо: см. выше о различии производства и проектирования.
> Но не только лишь все могут это позволить себе, причём вопрос не только денежный.
> > Также именно поэтому до решения большинства задач в производстве ПО, то есть когда требуется предсказуемость, "мухи" не допускаются.
> Если так, то не понимаю вашу тревогу о наплыве "вайтишников" и будущем отрасли?
Я не тревожусь об этом. Я просто говорю о том, что не надо называть безграмотного кустаря инженером. А именно таковым безграмотным кустарём и является, как вы выразились, "вайтишник". В том числе из-за незнания практической истории отрасли даже в рамках своей в самом узком смысле квазиспециализации.
>> Кроме перенесённых из юниксов систем, скорее всего для армии США.
> Недостаточно?
Для того, чтобы утверждать, что винде без позикса каюк - нет.
Пока я вижу ценовую конкуренцию, бесплатный Линукс (обычный на серверах и Андроид у консьюмеров) медленно выедает ниши Windows, пока Майкрософт не может найти, что бы ещё такое придумать новенькое за деньги, что будет нужно, и что бесплатные Линуксы будут повторять еще несколько лет.
Но ровно то же самое происходило, когда дешевый Windows NT выедал ниши дорогих UNIX. И вопрос был вовсе не о технологическом совершенстве VMS vs IRIX/HPUX/AIX/Solaris, а о цене.
> Я бы посмотрел на человека, который для окошек разрабатывает под WinE.
А я б посмотрел на человека, который бы под Убунту разрабатывал под Windows 10
Хотя все зависит от толщины промежуточного слоя, какой-нибудь сетевой сервис на Java или JavaScript без пользовательского интерфейса можно разрабатывать на чём угодно. И тут у Линукса опять ценовое преимущество, я могу штамповать виртуалки и таскать их между физическими машинами ни на секунду не задумываясь о лицензиях. Это удобно. Но это вопрос EULA и ценника, а не POSIX vs VMS.
> А о каком, простите, конвейере может идти речь тогда в "небольшом месте" на 10, скажем, человек?
Не может, к этом и веду. И в этом месте всегда будет нужен "человек-оркестр" в той или иной мере.
Вы почему-то называете кустарём необразованного человека, но если речь об индустриальном производстве - то отличительная черта кустаря - его самодостаточность, full stack в каком-то смысле. Он владеет, хорошо или плохо, всеми навыками, чтобы начать своё "ручное производство" на голом месте. В пустой деревенской избе, если хотите.
Конечно же построенный современный завод с конвейером его по скорости зарулит и не заметит - но после того, как толпа специалистов такой завод спроектирует построит и отладит.
А учитывая, что произвести экземпляр программы - это просто ещё один раз нажать кнопочку "скачать" в браузере - то ценность конвейера в форме "сделать миллион копий товара на продажу" отсутствует. Ценность в виде "разбить типа уникальную задачу на набор типовых проблем" - теоретически есть, и весь аутсорсинг и девопс именно на это делает упор, типа мы могём. Это модно и молодёжно. На практике же оказывается не всегда и не совсем.
И соответственно вопрос, может ли себе позволить такое счастье арендовать "небольшом месте на 10, скажем, человек" ? Теоретически - почему бы и нет, берём LuxSoft или freelance.ru и нанимаем хоть помесячно, хоть поминутно. На практике же - не везде и не всегда.
> Нормальный инженер в таких случаях делает заявку в условный АХЧ, и ему выдают всё это настроенное
А если условный АХЧ - на аутсорсе в "лидере российского рынка по администрированию" ? со всяким там ITILом и красивым списком бизнес-партнёров и клиентов? Но когда требуется поставить Mantis и привязать его к Active Directory в целях SSO - то через полгода вялой переписки получаем машину, на которой стоит Windows Server (поддержка нестандартных ОС - за отдельный прайс), MySQL 4.xxx (при минимальном требовании 5.3 и рекомендуемом 5.7), Mantis "показывает недокументированные производителем ошибки", а на SSO получаем жалобу о ничем необоснованных требованиях и необходимости разработки нестандартного программного обеспечения (за оооочень отдельный прайс), хотя в "заявке в АХЧ" была даже дана ссылка на документацию Mantis по включению AD-интеграции.
Так что я верю в существовании "своих" хороших, отлаженных и выстроенных конвейеров, в "больших" местах. Но в существовании конвейеров в аренду для "небольшом месте на 10, скажем, человек" - не верю. Либо такие места найдут себе набор кустарей-многостаночников, либо нет. Конвейеры их просто прокатят, начиная с разработки ТЗ по принципу "что нам нужнее продать" (а если "место на 10 человек" как-то сможет выкатить своё ТЗ - его все равно переделают по тому же принципу).
"Вы можете купить автомобиль любого цвета, но при одном условии." Когда "место на 10 человек" сталкивается с конвейером - результат будет только такой. И не важно, что пекут на конвейере - автомобили, ноутбуки, программные продукты или услуги девопс.
> В похожих обстоятельствах в одной конторе таскали упакованные репки меркуриала на номерных флешках - и ничего, не жужжали.
Значит в этой конторе были либо инженеры-кустари, готовые сами решать свои проблемы, лишь бы им не мешали, либо минимум три специальных человека - один построит такой процесс, другой "научит" инженеров, третий - "заставит" инженеров.
> Нет, не надо: см. выше о различии производства и проектирования.
Это из серии, что лучше быть богатым и здоровым, чем бедным и больным.
Хоть производство, хоть проектирования, хоть уборка улиц: либо место достаточно большое чтобы поддерживать специализацию (в том числе - понимать, на какие операции разбит общий процесс и как это поддерживать в исправном состоянии) - либо нет.
Точнее: до какого-то предела место может вкладываться в усиление и углубление специализации. Но не более того. Где-то будет один "многорукий Шива", где-то уже пара аникейщик и сисадмин, где-то уже появится три отдельных админа на винду, Oracle Database и Oracle Linux, и так далее, по мере возможностей и размеров места.
> не надо называть безграмотного кустаря инженером
Кустарь вовсе не обязан быть безграмотным. Его главное отличие - от индустриального работника в bootstrapping.
"Высаженный" в пустой корпус цеха или избы - индустриальный работник "пишет заявки в АХЧ", а кустарь - начинает делать доски и сколачивать верстак.
И строго говоря, конкретный "индустриальный работник" тоже не обязан быть безграмотнее конкретного кустаря, вполне возможно, что он и сам способен сколотить верстак, но не будет. А уже отсюда - преимущество у тех и.р., которые не учились в виде хобби сколачивать верстаки, а вложили эту экспу в прокачивание скилла своей главной конвейерной операции, чтобы выполнять её на 5% быстрее "кустаря", и опередить его при найме. И в пределе - специалистов "по присваиванию целых со знаком".
> >> Кроме перенесённых из юниксов систем, скорее всего для армии США.
> > Недостаточно?
> Для того, чтобы утверждать, что винде без позикса каюк - нет.
Я тоже такого и не утверждал. Но именно винда движется в сторону позикса, а не линукс - в сторону виндоинтерфейсов. Из этого я делаю вывод, что классические опробованные решения пока что кроют наследие наколеночной разработки как бык тёлку.
> Пока я вижу ценовую конкуренцию, бесплатный Линукс (обычный на серверах и Андроид у консьюмеров) медленно выедает ниши Windows, пока Майкрософт не может найти, что бы ещё такое придумать новенькое за деньги, что будет нужно, и что бесплатные Линуксы будут повторять еще несколько лет.
> Но ровно то же самое происходило, когда дешевый Windows NT выедал ниши дорогих UNIX. И вопрос был вовсе не о технологическом совершенстве VMS vs IRIX/HPUX/AIX/Solaris, а о цене.
Вот именно, о цене. В том числе - о стоимости поддержки. Пока что я наблюдаю удешевление поддержки линухов при одновременном расширении подерживаемого оборудования. В основном, конечно, за счёт того что в винде поддержка оборудования в среднем сужается.
> > Я бы посмотрел на человека, который для окошек разрабатывает под WinE.
> А я б посмотрел на человека, который бы под Убунту разрабатывал под Windows 10
> Хотя все зависит от толщины промежуточного слоя, какой-нибудь сетевой сервис на Java или JavaScript без пользовательского интерфейса можно разрабатывать на чём угодно. И тут у Линукса опять ценовое преимущество, я могу штамповать виртуалки и таскать их между физическими машинами ни на секунду не задумываясь о лицензиях. Это удобно. Но это вопрос EULA и ценника, а не POSIX vs VMS.
Под десяткой для убунты разрабатывать - смотря что по правде говоря. Какой-то гуй на Qt - да только в путь. По крайней мере препятствий я не вижу: в том же вижуале поддержка имеется. Другое дело, что это отдаёт некоторой дурниной. А вот под зоопарк из двух центосей, макоси и четырёх виндов я как-то участвовал в разработке. ЧСХ, собственно разработка шла под линуксом. И ничего: всё отлично работало везде, где должно было.
> > А о каком, простите, конвейере может идти речь тогда в "небольшом месте" на 10, скажем, человек?
> Не может, к этом и веду. И в этом месте всегда будет нужен "человек-оркестр" в той или иной мере.
На самом деле не обязательно: специализация коллектива в отрасли позволяет отлично жить. Но если они не будут расти, в том числе количественно - их съедят. Впрочем, это особенность индустриального производства.
> Вы почему-то называете кустарём необразованного человека, но если речь об индустриальном производстве - то отличительная черта кустаря - его самодостаточность, full stack в каком-то смысле. Он владеет, хорошо или плохо, всеми навыками, чтобы начать своё "ручное производство" на голом месте. В пустой деревенской избе, если хотите.
Вы зачем-то опять приписываете мне слова, которых я не говорил. "Необразованный кустарь" - это во-первых кустарь, причём во-вторых - обязательно необразованный. Параллельно с ним существуют и мне лично известны кустари весьма образованные, просто в силу различных обстоятельств не желающие постоянно работать в коллективе. Кстати, что забавно: все такие известные мне люди очень даже в курсе "доисторических" с точки зрения "вайтишника" инструментов, их сильных и слабых сторон. Другое дело, что кустарю - разработчику драйверов для винды они все до лампочки: у него есть DDK и настройки его любимого редактора.
> Конечно же построенный современный завод с конвейером его по скорости зарулит и не заметит - но после того, как толпа специалистов такой завод спроектирует построит и отладит.
> А учитывая, что произвести экземпляр программы - это просто ещё один раз нажать кнопочку "скачать" в браузере - то ценность конвейера в форме "сделать миллион копий товара на продажу" отсутствует. Ценность в виде "разбить типа уникальную задачу на набор типовых проблем" - теоретически есть, и весь аутсорсинг и девопс именно на это делает упор, типа мы могём. Это модно и молодёжно. На практике же оказывается не всегда и не совсем.
"Разбить уникальную задачу на набор типовых проблем" - это, насколько я понимаю, называется инженерный подход к проектированию. И именно он позволяет разрабатывать программное обеспечение предсказуемым по срокам, стоимости и качеству образом. Причём на основе этого подхода реально конкурентная фирма действительно может начаться человек с 10.
> > Внезапно, инженерное программирование - это не промышленное производство, а промышленное проектирование. Где инженеры последовательно уточняют проект (программного продукта) поэтапно при спуске по цепочке проектирования (реализации)...
> И соответственно вопрос, может ли себе позволить такое счастье арендовать "небольшом месте на 10, скажем, человек" ? Теоретически - почему бы и нет, берём LuxSoft или freelance.ru и нанимаем хоть помесячно, хоть поминутно. На практике же - не везде и не всегда.
Потому что тот, кто арендует это счастье - заказчик, а "это счастье" как раз и называется "инженеры". И есть серьёзные подозрения, что 10 человек, которые это арендовали - это не инженеры вовсе, хотя особенную роль на рынке этих 10 человек тоже отрицать нельзя: они придумали продукт, который можно продать. Мне известен человек, который придумал значки для галош (!), и эти значки продавались "на ура" - потому что они были нереально прикольные. Хотя галоши в результате были дырявые, факт.
> > Нормальный инженер в таких случаях делает заявку в условный АХЧ, и ему выдают всё это настроенное
> А если условный АХЧ - на аутсорсе в "лидере российского рынка по администрированию" ?..
То это уже не АХЧ, а внешний провайдер сервисов. У которого, ЧСХ, что есть - то и предоставляет. И апельсинов он с гречишного поля не поставит. В частности потомы, может быть, что лень ему апельсиновую рощу разводить.
> Так что я верю в существовании "своих" хороших, отлаженных и выстроенных конвейеров, в "больших" местах. Но в существовании конвейеров в аренду для "небольшом месте на 10, скажем, человек" - не верю. Либо такие места найдут себе набор кустарей-многостаночников, либо нет. Конвейеры их просто прокатят, начиная с разработки ТЗ по принципу "что нам нужнее продать" (а если "место на 10 человек" как-то сможет выкатить своё ТЗ - его все равно переделают по тому же принципу).
Можно сколько угодно в это не верить, но по какой-то причине производства имеют свои конвейеры или не имеют их вообще. Во втором случае способ производства называется кустарной технологией. Для качественного описания рекомендую "Оружие Победы" В. Г. Грабина: ситуация на 92м заводе описана достаточно подробно. Также там описан потрясающий технологический успех при разработке ЗИС-2, побочный результат которого - отгрузка в войска серийно производимых пушек (с военной приёмкой, естественно) ещё до того, как их поставили на вооружение.
> "Вы можете купить автомобиль любого цвета, но при одном условии." Когда "место на 10 человек" сталкивается с конвейером - результат будет только такой. И не важно, что пекут на конвейере - автомобили, ноутбуки, программные продукты или услуги девопс.
Уточню: "мксто на 10 человек", работающее по кустарной технологии. То есть, повторюсь ещё раз, работающее "каждый раз как в первый".
> > В похожих обстоятельствах в одной конторе таскали упакованные репки меркуриала на номерных флешках - и ничего, не жужжали.
> Значит в этой конторе были либо инженеры-кустари, готовые сами решать свои проблемы, лишь бы им не мешали, либо минимум три специальных человека - один построит такой процесс, другой "научит" инженеров, третий - "заставит" инженеров.
Значит, в конторе по требованию 101 отдела не было ЛВС, связывающей инженерные отделы.
> > Нет, не надо: см. выше о различии производства и проектирования.
> Это из серии, что лучше быть богатым и здоровым, чем бедным и больным.
> Хоть производство, хоть проектирования, хоть уборка улиц: либо место достаточно большое чтобы поддерживать специализацию (в том числе - понимать, на какие операции разбит общий процесс и как это поддерживать в исправном состоянии) - либо нет.
Как ни странно, но 10 человек закроют весь спектр специализаций в некоторой, естественно достаточно узкой, сфере проектирования софта. Для разговора с заказчиками и своими инженерами нужны не более 2 человек (из них один должен быть продажник, да), 2 - архитекторы и техлиды по совместительству, остальные - линейные инженеры нормал+. Даже более того, один или два из них могут быть и ниже квалификацией, но тогда у них должны быть какие-то интересные и ценные дополнительные специализации. Кстати, изначальная конфигурация (без студентов) - это реальный боевой и численный состав одной фирмы при начале. Успех этой фирмы обусловлен именно инженерным подходом к разработке ПО.
> Точнее: до какого-то предела место может вкладываться в усиление и углубление специализации. Но не более того. Где-то будет один "многорукий Шива", где-то уже пара аникейщик и сисадмин, где-то уже появится три отдельных админа на винду, Oracle Database и Oracle Linux, и так далее, по мере возможностей и размеров места.
Это если они нужны. Чаще всего такие персонажи - это ресурс заказчика. Хотя я работал некоторое время в одной небольшой, но преуспевающей конторе, которая имела выделенного админа MS SQL Server при менее 20 инженеров штата. Но там АСУчивали предприятия ровно одной отрасли, и этот админ занимался как раз поддержкой серверов БД на этих предприятиях - и конторского сервера, само собой, тоже.
> > не надо называть безграмотного кустаря инженером
> ... Его главное отличие - от индустриального работника в bootstrapping.
> "Высаженный" в пустой корпус цеха или избы - индустриальный работник "пишет заявки в АХЧ", а кустарь - начинает делать доски и сколачивать верстак.
> И строго говоря, конкретный "индустриальный работник" тоже не обязан быть безграмотнее конкретного кустаря, вполне возможно, что он и сам способен сколотить верстак, но не будет. А уже отсюда - преимущество у тех и.р., которые не учились в виде хобби сколачивать верстаки, а вложили эту экспу в прокачивание скилла своей главной конвейерной операции, чтобы выполнять её на 5% быстрее "кустаря", и опередить его при найме. И в пределе - специалистов "по присваиванию целых со знаком".
Вы опять описываете грамотного кустаря. Что к теме не относится. Высаженный в пустой цех даже не незнакомой, а просто непривычной отрасли, безграмотный кустарь потеряется, грамотный - начнёт обживаться, а инженер - сделает запрос в АХЧ и станет разбираться как дальше здесь работать, когда ему привезут необходимое оборудование. Безграмотный кустарь проиграет любому из них за счёт отсутствия знаний, в том числе - о различных (исторических, ага) способах работы.
Причём, если сравнивать объём технических знаний в отрасли - ещё не известно у кого он больше будет: у грамотного кустаря или инженера. Важно, что они будут сравнимые. Но даже грамотный кустарь вдолгую проиграет инженеру за счёт того, что работает он всё равно по кустарной технологии. Впрочем, в этом преимуществе индустриального производства перед кустарным мы, насколько я понимаю, согласны.
А вот с чем я категорически не согласен - так это с приравниванием разработчика софта к индустриальному рабочему. Я всё же настаиваю, что разработка, которая производится по систематической технологии с раздалением труда - это промышленное проектирование, а не производство. Есть сходство, но есть и довольон сильные отличия. Имея опыт работы в НИИ с собственной мелкосерийной производственной базой имею основания это утверждать.
> По большому счёту я хотел сказать, что почти всё новомодное изобретено ещё до нас
Ну и чтоб утешить.
В автомате Калашникова нет ни одной новой идеи. Но есть синергия удачно подобранных "дружественных друг к другу" идей.
Но до него были десятилетия наработки "палитры" идей.
В программировании постепенно происходит то же самое. От четкого разделения импративных и функциональных, через Nemerle/Scala и вот уже лямбды заносят в C++.
От оставшегося любопытным экспонатом кунсткамеры для гиков D мы приходим к уже почти мейнстримным Go и Rust, которые (хотя и по разному) начертали на знамёнах "хватит изобретать новое, давайте выбирать и комбинировать удачное старое".
Конечно, хотелось бы ещё быстрее. Но сравнивая с остальными индустриями, ну в самом деле, и так довольно быстро :-)
Луддизмом повеяло. И ретроградством. Будем размышлять сколько энергии тратит переброска документа физически курьером из НСК в Москву, а сколько документ с ЭЦП?
Да? И с чего бы до сих пор существует служба фельдегерей? Иногда секретность дороже скорости.
Иногда. Но в случае обеспечения достаточного уровня секретности и гарантированности доставки, служба потеряет такую функцию. Бумага точно такой же носитель с горой недостатков. Все что у нее из ирациональных преимуществ - инерция человеческого мышления.
Так в общем так и делают почти все.
но есть нюансы, как в анекдоте с Чапаевым и Петькой. могут вашими документами просто подтереться.
Проблема не в носителях информации, а в головах. Даже для хранения бумажных носителей нужны соотвествующие условия. Скажем, с контролем влажности.
Для хранения информации тоже нужны соответствующие условия. Хранить важную информацию на одной-единственной дискете -- всё равно, что хранить важные бумаги в стиральной машине.
Тут дело такое -- физические носители неизбежно деградируют. Аналоговые или цифровые -- неважно. Но в случае с информацией в цифровом виде, её можно перенести на другой носитель без потери качества. Аналоговые фотографии рано или поздно придут в негодность. Цифровые можно резервировать, пока для этого есть инфраструктура.
Так же бензин может кончится. И дрова. Но у кого будет солнечная или ветряная электростанция, то ещё немного поживут...
Но, гораздо вернее, кончатся программисты.
вернее - пока не сменится тип носителей/кодирование информации/дофига всего.
Перспективный чат детектед! Сим повелеваю - внести запись в реестр самых обсуждаемых за последние 4 часа.
В свете вчерашнего коллапса фейсбука (и потеря шести оТБМлиардов) вспомнилась G7, а затем G20 (июль сего года), поддержавшая решение первой ввести 15% корпоративный налог на трансграничные IT-гиганты. И тут подгоняют ящик пандоры с информацией, как "сотни мировых лидеров и политиков" крысят бабло как не в себя. Не, ну может, и не связано.
Цифровизация это прекрасно ,в смысле нажал на кнопку и *спина мокрая* ( аА... может и ещЁ кое где ).
1. Как всегда ,можно обсасЫвать с разных сторон и главное, везде дЫрки.
0. А, есть ли будущее у такого соСтояния ? ( молчу, в какИх руках )
с уважением,Оптимист
Как уже указали, чеки обесцвечиваются. Не беда, есть ксерокс... нет, беда - тонер осыпается с бумаги. Не сразу, лет через пятнадцать-двадцать. Струйные принтеры могли бы стать решением, но вот беда - в массе своей они используют водорастворимые чернила. Разумеется, есть эпсон с кэноном, где применяют чернила пигментные - да только не жалует их офисный пользователь, сохнут в них головки без работы. Неделю не попечатал - и Изя всё.
Так что настоящее решение, дающее гарантию - это кондовый матричный принтер. Такой, чтобы оттиск давал и на четвёртом листе в бутерброде из бумаги и копирки. Вот тут да, отпечаток прочтут и через сто лет, если бумага выживет.
Сбер на них фигачит чеки. ))
То же вчера так подумал. Но нет, не показатель. Пейсбук исчезнет и никто не заметит. А вот если так же упадут Виза с Мастеркартом.., тогда да, задумаешься.
Сбер? Тоже нет индульгенции на бессмертие. Много сейчас говорят о том, где сервера расположены. Нет в этом вопросе полного импортозамещения
Неправда. Вы просто "не умеете их готовить". Прекрасно все читается с переходника дискета - усб. В свое время прикупил. Может и сейчас есть. Правда это все на 3,5 дюйма. На 5,25 поди нет ничего уже. Если что и на диски тоже есть внешние ридеры - диск - усб.
Спасибо за совет, может откроется
У меня есть ридеры не только на 3.5" и 5.25", но и на 8-и дюймовые дискеты.
Да Вы эстет. ))
Ахах - круть! А это вообще законно иметь ридеры на 8 дюймовые дискеты :))))??? Это же что-то типа сокровищ Нарнии :))
8-ми дюймовый привод - типа отечественный, с Электроники-79?
Нет. Дисковводы от какого-то здоровенного научного прибора, забугорского, давно списанного и разобранного.
Страницы