От переводчика: этот текст — перевод записи в личном блоге Михаэля Штапельберга (Michael Stapelberg) видного open source-разработчика (профиль GitHub), который внес значительный вклад в развитие Debian.
Этот пост было сложно написать с эмоциональной точки зрения, но я и не ограничился «коротким письмом, потому что у меня не было времени». Пожалуйста, перед прочтением этого текста учтите, что пишу я его с лучшими намерениями и не ставлю себе целью демотивировать или принизить вклад кого-то из разработчиков. Скорее, я хочу объясниться, почему мой уровень разочарования превысил все допустимые значения.
Debian был частью моей жизни на протяжении 10 лет.
Несколько недель назад, на посвященной Debian встрече, проходившей в Цюрихе, я встретился со своими старыми друзьями, которых не видел много лет. Когда я уже ехал домой на велосипеде, меня осенило, что все обсуждаемые нами темы так или иначе сводились к тому, что мы обсуждали с ними в прошлый раз. Мы дискутировали о достоинствах systemd, который вновь привлек внимание участников open source сообщества, затронули тему процессов в Debian. Кульминацией стало обсуждение демократии как таковой и соответствующие теоретические и практические ошибки. Но, на самом деле, это уже чисто швейцарская тема.
Это не обзор прошедшего митапа, я просто хочу объяснить, что побудило меня задуматься о своем текущем отношении к Debian и подходит ли он мне.
Итак, я принял решение, которое должен был принять давно: я сворачиваю свое участие в развитии Debian.
Что это значит?
В ближайшие недели произойдет следующее:
- я передам важные пакеты maintained-команде;
- удалю себя из Uploaders пакетов, в которых есть другие сопровождающие;
- пакеты, в которых я был единственным сопровождающим, станут «сиротами».
Я постараюсь и дальше поддерживать страницы manpages.debian.org и сервис codesearch.debian.net, но высоко оценю любую помощью по этому направлению.
Если у вас возникнут вопросы или какие-то задачи, считайте, что я в бессрочном отпуске. Я постараюсь принимать участие в каких-то административных вопросах (например, передачи разрешений) и задачах, адресованных лично мне, но только если это не займет много времени.
Почему?
Когда я только присоединился к работе над Debian, я еще учился, то есть у меня было много свободного времени. Теперь, спустя пять лет работы фулл-тайм, я многому научился — как в плане того, как и что работает в крупных проектах по разработке программного обеспечения, так и в плане понимания своих личных предпочтений в компьютерных системах. Сейчас я четко отдаю себе отчет в том, на что я трачу ту небольшую часть свободного времени и что у меня остается в конце дня.
Каждый из следующих разделов будет посвящен вещам, причиняющим мне как разработчику боль. Список этот приводится в произвольном порядке. Некоторые из этих проблем влияют друг на друга, например — если бы изменения системы проводились качественнее, у нас был бы шанс на то, что пакеты будут легче обрабатываться машиной.
Процесс изменений в Debian
Последние несколько лет моя текущая команда работала над различными реорганизациями по всей кодовой базе (затрагивая тысячи проектов), поэтому мы получили множество ценных уроков, как эффективно эти изменения вносить. Меня раздражает то, что Debian во всех смыслах работает практически противоположным образом. Я ценю то, что каждый проект отличается, но я думаю, что многие далее перечисленные мою пункты применимы к Debian целиком.
В Debian разработка пакетов направляется в нужное русло с помощью документа, который называется «Debian Policy», либо же его программным вариантом «Lintian».
Несмотря на то, что lint очень удобен для получения быстрого прямого или локального/автономного фидбека, еще лучше вообще не требовать пользоваться таким инструментом. Например, команда C++, которая вводит новый флаг защиты для всех пакетов, должна быть в состоянии сделать свою работу прозрачной и для меня (судя по профилю GitHub, основным языком Михаэля является Go, — прим. пер.).
Вместо этого сейчас все пакеты делаются «грязно» (ориг. — lint-unclean): все сопровождающие должны прочитать, что это за новая вещь, как она может сломаться, влияет ли она на их работу вообще и если да, то как именно. Потом надо вручную запустить некоторые тесты и, наконец, отказаться от изменений. Все это — множество накладных и выполняемых вручную механических операций между пакетами.
В модели Debian решение о раскатке новинки ложится на сопровождающих пакетов, а не на разработчиков. На моей основной работе мы обнаружили, что эффективнее делать наоборот: если написанное изменение затрагивает значительную часть пользователей, то именно разработчики должны принимать решение о необходимости его внедрения. Такой подход делает развитие проекта более эффективным и сокращает временные и трудозатраты. Конечно, существуют исключения, например, на крупных участках, где используются языковые фишки, о которых должны позаботиться соответствующие владельцы-кураторы, но важно то, что по умолчанию все должно быть иначе, нежели есть сейчас.
В Debian отсутствуют инструменты для внесения крупных изменений: программно сложно работать с раздробленными пакетами и репозиториями (об этом детальнее в разделе ниже). Наиболее близким событием к дефолтной «отправке изменения на ревью» является процесс открытия баг-репорта с прикрепленным к нему патчем. Мне казалось, что существующий процесс принятия баг-фикса слишком сложен, и я начал работать над мерж-ботом, но интерес к нему проявил только Гвидо и никто больше (по всей видимости, автор говорит о Гвидо agx Гюнтере, еще одном Debian-разработчике, — прим. пер.).
Если выражаться литературно, то реакция на пуши и, соответственно, получение обратной связи проходят медленно. Там просто нет сроков. Иногда я получаю электронные письма, уведомляющие меня о том, что отправленный мною несколько лет назад (!!!) патч наконец-то смержили. Это растягивает недельные проекты на много лет, что для меня является мощным демотиватором.
Любопытно отметить, но практика черепашьей онлайн-активности проецируется и на офлайн-культуру, а я не хочу обсуждать достоинства systemd спустя 10 лет после того, как впервые услышал о нем.
Ну и наконец, любые изменения могут быть застопорены несогласными, которые в итоге отказываются идти на сотрудничество. Мой каноничный пример подобной ситуации — rsync. Куратор отказался от моих патчей, добавляющих в пакет поддержку debhelper, исключительно из собственных убеждений.
Предоставление такой степени личной свободы отдельным сопровождающим мешает всем нам, участникам проекта, повысить уровень абстракции сборки Debian, что, в свою очередь, усложняет инструментарий разработки.
Как бы все это выглядело в идеальном мире?
- Как проект, мы должны стремиться к унификации. Ведь унификация не исключает экспериментов, она просто меняет текущий компромисс между более простыми экспериментами и более сложной автоматизацией на компромисс между более сложными экспериментами и более простой автоматизацией.
- Наша культура разработки должна уйти от парадигмы «этот пакет — мое хозяйство, да как ты смеешь к нему прикасаться», к общему чувству сопричастности, при котором любой участник может легко вносить или проверять изменения, даже без вовлечения конкретных кураторов-сопровождающих.
Чтобы понять, как могут выглядеть успешные крупные изменения (патчи), я рекомендую ознакомиться с выступлением моего коллеги Хайрама Райта «Крупномасштабные изменения в Google: уроки, извлеченные из пятилетних массовых миграций».
Фрагментированный рабочий процесс и инфраструктура
Обычно Debian предпочитает децентрализованные подходы, а не централизованные. Например, отдельные пакеты хранятся в отдельных репозиториях, а каждый репозиторий может использовать любой SCM (обычно git и svn) или вообще не использовать. Плюс, каждый репозиторий может быть размещен на любом сайте. Конечно, и содержимое каждого репозитория также слегка различается от команды к команде, да даже и внутри команды.
На практике нестандартные варианты хостинга используются достаточно редко, так как они не оправдывают свою стоимость, но достаточно часто, чтобы причинять огромную боль при попытках автоматизировать процесс внесения изменений в пакеты. И вот вместо того, чтобы использовать API GitLab для создания запросов на мерж, вам надо разработать совершенно другую, более сложную систему, которая работает с периодически (или постоянно!) недоступными репозиториями, абстрагирует различия в доставляемых патчах (отчеты об ошибках, запросы на слияние, запросы на извлечение) и прочее, и прочее…
Радикально отличающиеся процессы разработки — это не просто проблема пустой траты рабочего времени. Я участвовал в долгих разговорах о различных процессах разработки git во времена DebConf 13 и понял, что и тогда велись подобные дискуссии.
Лично я не могу держать в голове достаточно подробностей о различных методологиях разработки. Каждый раз, когда я прикасаюсь к пакету, который работает не так, как мой, я очень расстраиваюсь, потому что мне приходится заново изучать аспекты его работы.
Я заметил подобную фрагментацию рабочего процесса в моей собственной команде по пакетированию Go и попытался исправить это с помощью внесения предложений об изменениях в workflow, но не смог их реализовать. Отсутствие эффективной автоматизации и малый темп изменений в инструментарии, несмотря на мою готовность тратить собственное время и энергию, убивали любую мотивацию.
Устаревшая инфраструктура: загрузка пакетов
Когда вы хотите сделать пакет доступным в Debian, вы загружаете файлы с подписью GPG через анонимный FTP. Существует несколько видов заданий (the queue daemon, unchecked, dinstall и другие), которые выполняются по фиксированному расписанию (например, dinstall выполняется в 01:52 UTC, 07:52 UTC, 13:52 UTC и 19:52 UTC).
Я подсчитал, что в зависимости от времени суток вы можете подождать более 7 часов (!!!), прежде чем ваш пакет будет установлен.
Но хуже всего для меня то, что обратная связь асинхронна относительно загрузки. Мне нравится что-то сделать, покончить с этим и перейти к следующему заданию. Текущая настройка требует длительного ожидания и, по сути, дорогостоящего переключения между задачами без веских на то технических причин. Вы можете заметить, что несколько минут не имеют большого значения, но когда все время за день, которое я могу потратить на Debian, измеряется минутами, это имеет огромное значение для восприятия собственной производительности и удовлетворенности от проделанной работы.
Последнее сообщение, которое я могу найти об ускорении этого процесса — пост Георга Ganneff Яспирта от 2008 года.
Как бы все это выглядело в идеальном мире?
- Анонимный FTP был бы заменен веб-службой, которая принимает мой пакет и возвращает в своем ответе официальное решение о его принятии или отклонении.
- Для принятых пакетов есть страница, отображающая статус сборки и время, когда пакет будет доступен через сеть зеркал.
- Пакеты должны быть доступны в течение нескольких минут после завершения сборки.
Устаревшая инфраструктура: багтрекер
Я боюсь взаимодействовать с трекером ошибок Debian. Debbugs — это кусок кода прямиком из 1994 года, который сейчас используется только Debian и проектом GNU.
Процессы Debbugs основаны на использовании электронной почты, то есть проходят асинхронно и громоздко. Несмотря на то, что он работает на самых быстрых машинах, которые мы имеем на проекте Debian (ну так мне сказали, когда эта тема в последний раз поднималась), его веб-интерфейс загружается крайне медленно.
Примечательно, что веб-интерфейс на bugs.debian.org доступен только для чтения. Настроить рабочую зону электронной почты для reportbug (1) или вручную работать с вложениями — довольно серьезный челлендж.
По каким-то причинам, которых я не понимаю, каждое взаимодействие с debbugs приводит к созданию множества цепочек писем.
Помимо технической реализации я также никак не могу запомнить различные способы, в рамках которых Debian использует псевдопакеты генерации для ошибок и процессов. Нужны они мне слишком редко, чтобы я наконец-то уложил это все в голове и запомнил, как именно они функционируют и используются, но я периодически с ними сталкиваюсь, так что это разнообразие раздражает.
Как бы все это выглядело в идеальном мире?
- Debian переключится с нестандартного способа отслеживания ошибок на (любой) уже устоявшийся.
- В Debian появляется автоматизация этих процессов. Основной интерфейс должен быть более удобным (например, веб-форма).
Устаревшая инфраструктура: архивы email-переписок
Меня сбивает с толку тот факт, что в 2019 году у нас по-прежнему нет удобного инструмента для просмотра архивных цепочек обсуждений в почте. Так широко, как в Debian, Email и цепочки писем нигде больше не используются, так что это даже несколько иронично. Использование Gmane вроде и решало эту проблему, но его доступность за последние несколько лет была, мягко говоря, урывистой (сейчас, на момент написания этого поста, он вообще не работает).
Я пытался создать многопоточный архив, но наши лист-мастеры не впечатлились и отказались поддерживать проект.
Машинам сложно работать с Debian
Хотя очевидно, что с пакетами Debian можно работать программно, этот опыт сложно назвать приятным. Все кажется медленным и громоздким. Я выбрал три небольших примера, чтобы проиллюстрировать мою позицию по этому вопросу.
debiman нуждается в помощи от piuparts в проведении анализа альтернативного механизма каждого пакета по отображению страниц документации, например, PSQL(1). Это потребовалось, так как сценарии модифицируют альтернативную базу через вызов shell-скриптов. Но без фактической установки пакета вы не узнаете, какие изменения он вносит.
pk4 должен поддерживать свой собственный кеш для поиска метаданных пакета на основе его имени. Другие инструменты анализируют базу данных apt с нуля при каждом вызове. Правильный формат базы данных или, по крайней мере, двоичный формат обмена будет иметь большое значение для этого процесса.
Debian Code Search хочет как можно быстрее получать новые пакеты. Раньше использовался инстанс fedmsg, но его больше не существует. Неясно, откуда получать уведомления о новых пакетах и ??где лучше всего их получать.
Сложный билд-стек
Тут можно просто почитать мой пост «Инструменты сборки пакетов Debian». Меня действительно беспокоит тот факт, что рост числа инструментов не считается проблемой.
Debian — это болезненный опыт для разработчика
Большинство поднятых мной вопросов касаются опыта разработки Debian, но, как я недавно описал в своем посте «Опыт дебага в Debian», опыт разработки с использованием Debian также оставляет желать лучшего.
У меня есть больше идей
Статья получилась достаточно объемной, но я надеюсь, вы получили приблизительное представление о моей мотивации.
Хотя выше я описал ряд конкретных недостатков, последний гвоздь в крышку гроба — это отсутствие позитивного прогноза на будущее. У меня есть другие идеи, которые кажутся мне действительно убедительными, но, исходя из того, как продвигались мои предыдущие проекты, я не думаю, что смогу реализовать что-либо из них в рамках проекта Debian.
Я намерен опубликовать еще несколько постов о конкретных способах по улучшению операционных систем в своем блоге. Так что заглядывайте.
Ну и наконец, я надеюсь, что этот пост вдохновит кого-нибудь, в идеале — группу людей, на то, чтобы сделать жизнь разработчиков Debian лучше.
Комментарии (57)
linux_id
12.03.2019 21:01И что хотел подчеркнуть автор написав, в начале заметки, что со встречи он уехал на велосипеде?
selivanov_pavel
12.03.2019 21:07По-моему, в английском слово «велосипед» не используется для обозначения самопального решения давно решённой проблемы, но зато в русском переводе появляется дополнительная ирония :)
Tarik02
12.03.2019 21:25В английском используется для этого слово "wheel" ("колесо").
selivanov_pavel
12.03.2019 21:29«Reinvent the wheel» — да, но я не видел, чтобы использовалось в этом смысле как отдельное слово, в духе «Deploy is done by some ugly wheel written in bash». Так можно?
Tarik02
13.03.2019 00:13Не знаю… я не эксперт в английском, просто знал про выражение «to reinvent a wheel».
Detuner
13.03.2019 09:56Мне кажется, вы в данном случае имеете в виду не велосипед, а костыль. Велосипед — не обязательно плохо, это просто применение чего-то самодельного вместо уже придуманного и проверенного.
ainoneko
13.03.2019 12:08Зато уже есть такой формат:
Wheel — это современный формат распространения пакетов в Python среде, который пришел на замену eggs.
vdonich
12.03.2019 21:15Возможно, что он ездит на велосипеде?
Или что он побыл один — но это уже, что называется, навеяло.
4umak
13.03.2019 08:43Учитывая богатые швейцарские традиции езды на велосипеде, теорий можно насочинять много и разных:)
ShockwaveNN
13.03.2019 16:43Я кстати из оригинала статьи не понял — имелся в виду все таки велосипед или мотоцикл, тут надо бы провести исследование расстояния между местом проживания автора и Цюрихом
selivanov_pavel
12.03.2019 21:04+2Я когда-то собирал deb-пакетики для некоторых задач, и это было не слишком удобно. Куча тулзов, которые нужно применять строго в определённой последовательности, чтобы получить на выходе собранный по фен-шую пакет. Я, конечно, с помощью гугла и какой-то там матери нашёл нужную последовательность шагов и запихнул в скрипт, но мне больно думать, как мучаются парни, которым нужно во всём этом хорошо разбираться и активно использовать.
Надеюсь, резонансная статья и уход Михаэля сподвигнут мой любимый дистрибутив к каким-то изменениям в этом плане.
gecube
13.03.2019 16:53я собирал checkinstall и fpm, но это было ад-хок решение, не претендующее на красоту и вывод в продакшн. Т.е. пакеты были чисто для передачи артефакта между элементами пайплайна и установкой в целевую систему в докере.
selivanov_pavel
13.03.2019 22:06Да, checkinstall действительно выручает, если надо изредка собрать пару простых пакетиков. Но для более сложных случаев он, увы, не годится.
saipr
12.03.2019 21:44-2Это статью должны прочитать все производители "отечественных ОС", участвующих в импортозамещении!
КВИНТЭССЕ?НЦИЯ:
Хотя выше я описал ряд конкретных недостатков, последний гвоздь в крышку гроба — это отсутствие позитивного прогноза на будущее.
Revertis
12.03.2019 23:09Наверное, пора кому-то форкнуть Debian. Но не добавлять свистоперделок, а поднять просто хорошую инфраструктуру.
QtRoS
13.03.2019 01:28+4А разве мало поделок на ее основе? Полноценный форк мало кто сможет вывезти, судя по описанным сложностям…
sumanai
13.03.2019 22:27Кажется у дебиана рекордное число форков, а если учесть форки форков…
Revertis
13.03.2019 23:13Да это понятно. Но форки обычно кучу всего меняют, добавляют новый UI, стараются как можно быстрее собирать пакеты и так далее. Но нет такого же стабильного, но не через одно место организованного форка :)
sumanai
13.03.2019 23:35+2Так стабильность судя по всему и достигается тем, то патч протолкнуть стоит больших трудов.
ExplosiveZ
13.03.2019 01:48-3А не он форсил systemd в среде debian?
dartraiden
15.03.2019 00:16Михаэль положительно относится к systemd, но при чём тут systemd? Речь об инфраструктуре проекта, а не о компонентах дистрибутива.
litos
13.03.2019 06:22А что там у Ubuntu?
Есть вебинтерфейс для багов
Есть ppa где можно создавать репозитории
Может стоит присмотреться разработчикам Debian?selivanov_pavel
13.03.2019 19:32+1Ubuntu собирается из Debian Unstable, без него она просто не сможет существовать.
embden
13.03.2019 08:05Я когда-то вынужден был связаться со сборкой пакетов в debian. Это было просто ужасно — даже имея человека, которого можно было спросить, я всегда натыкался на неочевидные трудности, часто статьи по сборкам пакетов, хоть и предлагали некие способы создания пакетов — эти способы оказывались неверными. Мануалы самого debian были или частично неверными, или частично устаревшими. Теперь стараюсь всеми силами избегать сборки пакетов для debian.
kmansoft
13.03.2019 11:30Точно. Я когда-то пересобирал nginx на основе уже готовых пакетов (apt-get source) из дистрибутива, только включил одно расширение (+ добавил суффикс к версии).
И даже в такой простой ситуации я намучился пока сумел собрать и получить свои пакеты, при этом я смотрел в официальную документацию.
capgelka
13.03.2019 11:46+2А у вас была необходимость собирать пакеты «правильно и канонично»? (Под этим я имею ввиду когда пишется debian/rules а потом все собирается при помощи
dpkg-buildpackage -us -uc)
Просто, если делать это для внутренних нужд, то шаблон control.in, куда подставляются нужны значения версий, posints/postrm скрипты если нужны, директория с деревом файлом +fakeroot dpkg-deb --buildи готовый пакет. Вроде совсем небольно. Можно еще fpm использовать, но если нет необходимости собирать пакеты под другие дистрибутивы, то какого-то особого преимущества он имхо не даст.
А если совсем «для себя», то можно checkinstall использовать.embden
13.03.2019 11:57Именно канонично под руководством одного из майнтейнеров debian. Надо было заполнить debian/ и отправить все это на mentors.debian.net.
ainoneko
13.03.2019 12:10+1Мануалы самого debian были или частично неверными, или частично устаревшими.
А разве это не везде так?embden
13.03.2019 12:13+1Для меня было неожиданностью, что по мануалам самого debian я не мог собрать полностью корректный .deb пакет.
ainoneko
13.03.2019 12:16+1Верю.
Про какую-то другую программу или пакет (не помню, что это было) я в её документации читал, что она развивается так быстро, что свежей и полной документации не будет никогда.
FanatPHP
13.03.2019 14:29Пожалуйста, не занимайтесь переводами.
Для переводчика, как и для программиста, очень важно понимать, что он пишет. У вас, к сожалению, это понимание отсутствует. Вы переводите механически, не понимая смысла получившейся фразы на русском языке. В итоге переводимое предложение полностью теряет всякий смысл, как например "Я ценю то, что каждый проект отличается". Если у вас не возникает вопросов к этому предложению, то пожалуйста, не занимайтесь переводами.
Londoner
13.03.2019 14:30Мой традиционный вопрос — на какой дистрибутив стоит перебегать, если даже Дебиан сдулся?
atoshin
13.03.2019 14:40Londoner
13.03.2019 15:35+1Ой не знаю, этот дистрибутив сделан с нуля, и ему всего несколько годиков. Насколько он надёжен по сравнению с Дебианом? Сколько процентов пользователей линукса его используют? Сторонние пропертарные софтины вроде скайпа или тимвьюера под ним тестируются производителями и реально работают? Есть ли отзывчивое комьюнити? Поддержка кодировок реально работает или сделана «на отвали»? И ещё сотня аналогичных вопросов к дистрибутивам-новичкам.
arheops
13.03.2019 17:57Rhel/centos если не напрягает замороженный на 5 лет код.
opensuse вроде тоже пока живет.
Ubuntu чтото при обновлении ломатся часто стал.
embden
13.03.2019 15:00Мне интересно, а как сделать так, чтобы дистрибутивы и открытые программы не сдувались? Ведь у разработчиков нет мотивации что-то менять — нет пути для эффективного фидбека (как минимум финансовое благополучие разработчика не зависит от успешности его продукта).
Londoner
13.03.2019 15:54Вести рейтинги. А линуксовое комьюнити даже не может собрать реальную статистику популярности по дистрибутивам…
mkovalevskyi
14.03.2019 16:19+2отсутствие телеметрии — чуть-ли не главный плюс линуксоводов ;)
а при ее отсутствии, достаточно сложно собрать статистику, да…
kmansoft
13.03.2019 15:57Если Вы разработчик и нужны свежие версии стороннего софта (скажем Visual Studio Code, Mongo, MariaDB, и так далее) — то нужно смотреть есть ли они в дистрибутиве (достаточно свежие).
И если нету — то выбор зависит от пакетного менеджера. Как правило сторонний софт пакуется в .deb / .rpm. Если конечно не хочется извращений (типа распаковать .deb, скопировать то что внутри).
PS: лично мой выбор — Fedora XFCE уже лет 5, старая болячка со шрифтами наконец-то была исправлена какое-то время назад с обновлением libfreetype, даже ничего не нужно дополнительно ставить.
А «запасной» Ubuntu недавно удалил так как достало что всё-время что-то ломается, правда у меня там тоже был XFCE, как бы не самый официальный вариант. И так как в Федоре со шрифтами теперь тоже всё в порядке, то Ubuntu в моих глазах всё равно перестал быть чем-то уникальным (как это было раньше).
EvgeniiR
13.03.2019 18:28Разве проблема версионирования всякого инфрастуктурного софта(БД, веб сервер etc.) не решается Докером?
А вобще, вопрос по прежнему весьма холиварный, и даже никаких причин слезать с Дебиана пока не вижу. Я в поисках самого удобного дистрибутива остановился на Manjaro. Пол года сидел с KDE, уже пару месяцев с XFCE(Так и не решил какой DE выбрать, Cinnamon из Минта кстати тоже классная вещь).
Путь был Debian => Kubuntu => Mint => Manjaro, с параллельной пробой elementaryOS. В принципе проблемы(шрифты, драйвера) возникали только в Debian, у всех остальных дистрибутивов с этим всё сразу было отлично. Manjaro выбрал за Rolling Release(и ещё возможность юзать систему во время установки: ))kmansoft
13.03.2019 18:43Ну можно и Докер, да. Можно и Flatpack или Snap какой-нибудь.
Просто это ещё какие-то дополнительные сущности (хотя у Докера есть и плюсы в более широком контексте «а как дальше в прод», да).
Но в общем вот лично мне как-то привычнее что вещи типа MariaDB, Go, Mongo, и т.д. на моей машине «просто есть» (и кстати, вот использовать тулчейн Go через Докер — вот это кажется странным… в отличие от баз данных скажем).
> никаких причин слезать с Дебиана пока не вижу
Да в общем я с Вами согласен. Небо не падает. Мой комментарий был больше про Ubuntu vs.… Там выше просили мнения «на что перелезать».
Опять-таки чуть личного опыта — у меня на серверах (личные проекты) по-прежнему Debian (testing), работает, обновляется, и переходить на что-то не планирую.
А те вещи которые описываются в оригинальной статье — они скорее могут сработать в долгорочной перспективе, по мере того как они будут затрагивать больше людей (если будут).
nebularia
13.03.2019 20:30+1А он разве сдулся? Тут как раз пишут, что такое положение у разработчиков уже давно, но существует же проект все эти годы. Думаю, если вы не пакетируете пакеты, то проще всего оставить как есть.
gecube
13.03.2019 16:55Теперь понятно, почему докер взорвал рынок — запаковать в докер большого ума не надо, в отличие от запаковки в deb/rpm. Продолжаем наблюдение за развитием технологий…
dartraiden
15.03.2019 00:18Скорее не ума, а геморроя… Если один способ быстрый и удобный, а второй медленный, нкудобный, да ещё и требует, чтобы я как следует потратил время в поисках документации, то что же я выберу?
aPiks
Всё, что описано в статье — это прям на любой должности программиста в большой компании, у которой свой IT отдел. Мне кажется, человеку просто надоело тратить личное время на всё это. Появились дети и приоритеты сместились в сторону семьи, поддержания здоровья и тд…
ValdikSS
Да нифига.
Пакеты для других современных дистрибутивов, например, ArchLinux (PKGBUILD), Fedora/CentOS/RedHat (RPM SPEC), можно создать достаточно быстро, все директивы документированы и структурированы, документация подробная и понятная, с примерами. Поддерживать такие пакеты тоже несложно. Инфраструктура у этих дистрибутивов вменяемая: можно сообщить авторам пакетов о проблемах лично, или удобно и быстро создать баг для пакета. Это можно сделать с любого компьютера.
Для сборки пакета в Debian существует несколько утилит, оберток. Найти нормальные инструкции по созданию пакета сложно, полноценной и полной документации нет, всё разбросано по разным местам, написано в разное время.
Инфраструктура в Debian практически не меняется. Значительное изменение, произошедшее в последние годы — переход к salsa.debian.org (GitLab, конец 2017). Добавить сообщение в багтрекер можно только через почту, а сообщить о спаме в багтрекере можно только через веб-интерфейс.
Чтобы сообщить об ошибке в пакете, нужно (по-хорошему) создавать сообщение об ошибке с того компьютера, с которого эта ошибка наблюдается, через специальную программу, которая сформирует email-сообщение. Тот ещё квест, если у вас Debian установлен в виртуальную машину, без сети.
Когда годами ничего не меняется, неудобные инструменты не становятся удобней, плохая документация не становится лучше, это угнетает.
AlexanderS
Я знаю эту систему только со стороны пользователя. Взгляд со стороны разработчика как-то… угнетает.
А почему так получается? Если люди признают, что неудобно — почему не становится удобно? Слишком большое комьюнити? Большая кодовая база и организаторы не хотят резких изменений? Инерция возраста большинства этого комьюнити? В чём причина, с вашей точки зрения?
dklm
вот мой любимый постер на тему оптимизации процессов =) мне кажется он все объясняет =)
propell-ant
Причина в отсутствии воли к изменениям у кого-то, кто всем командует.
Недавно объяснял коллеге что нужно для качественного рефакторинга — время, полномочия, видение результата и воля.
Если чего-то не хватает, то лучше не начинать.
Под волей я понимаю решимость довести дело до конца, добиться результата, несмотря на необходимость чем-то пожертвовать.
khim
third112
Вот и мне показалось, что статье не хватает сравнений с другими приблизительно похожими проектами — что из отмеченного там лучше, а что хуже.
snp
Вообще, мне лично понравилась идея NixOS. Кажется, что это как раз логичный следующий шаг как для deb-based, так и для rpm-based дистрибутивов. А snap и подобные решения — например, как распространяется GitLab, в виде огромного пакета «всё в одном» — скорее выглядят костылями.
danfe
Справедливости ради, в прошлом с пакетами у фри были известные проблемы, но с появлением
pkg(8)в 9.1 всё стало значительно лучше (read: примерно как у всех остальных).aPiks
Ну так я и не отрицаю. Но если вы из мира IT и не работаете в стартапе или какой-то компании, типа ЕПАМ, где каждый проект для нового заказчика можно стартовать с нуля, то вы столкнетесь с бюрократией, устаревшими технологиями и неудобными архитектурой, инструментами и тп. Я имею ввиду, что всё перечисленное в статье у него было и 5 лет назад. За 5 лет никуда не сдвинулось. Но понять, что оно никуда не двигается и не развивается можно и за 2 года, а разработчик там сидел 10 лет. Также, как и много других разработчиков в крупных компаниях. Поэтому, как мне кажется, причина ухода другая, описанная мной в первом комментарии. А статья — это просто попытка сдвинуть хоть как-то всё это с места, раз уже ушел.