company_banner

Почему я сворачиваю свою работу над Debian

Original author: Michael Stapelberg
  • Translation


От переводчика: этот текст — перевод записи в личном блоге Михаэля Штапельберга (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, что, в свою очередь, усложняет инструментарий разработки.

Как бы все это выглядело в идеальном мире?

  1. Как проект, мы должны стремиться к унификации. Ведь унификация не исключает экспериментов, она просто меняет текущий компромисс между более простыми экспериментами и более сложной автоматизацией на компромисс между более сложными экспериментами и более простой автоматизацией.
  2. Наша культура разработки должна уйти от парадигмы «этот пакет — мое хозяйство, да как ты смеешь к нему прикасаться», к общему чувству сопричастности, при котором любой участник может легко вносить или проверять изменения, даже без вовлечения конкретных кураторов-сопровождающих.

Чтобы понять, как могут выглядеть успешные крупные изменения (патчи), я рекомендую ознакомиться с выступлением моего коллеги Хайрама Райта «Крупномасштабные изменения в 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 года.

Как бы все это выглядело в идеальном мире?

  1. Анонимный FTP был бы заменен веб-службой, которая принимает мой пакет и возвращает в своем ответе официальное решение о его принятии или отклонении.
  2. Для принятых пакетов есть страница, отображающая статус сборки и время, когда пакет будет доступен через сеть зеркал.
  3. Пакеты должны быть доступны в течение нескольких минут после завершения сборки.

Устаревшая инфраструктура: багтрекер


Я боюсь взаимодействовать с трекером ошибок Debian. Debbugs — это кусок кода прямиком из 1994 года, который сейчас используется только Debian и проектом GNU.

Процессы Debbugs основаны на использовании электронной почты, то есть проходят асинхронно и громоздко. Несмотря на то, что он работает на самых быстрых машинах, которые мы имеем на проекте Debian (ну так мне сказали, когда эта тема в последний раз поднималась), его веб-интерфейс загружается крайне медленно.

Примечательно, что веб-интерфейс на bugs.debian.org доступен только для чтения. Настроить рабочую зону электронной почты для reportbug (1) или вручную работать с вложениями — довольно серьезный челлендж.

По каким-то причинам, которых я не понимаю, каждое взаимодействие с debbugs приводит к созданию множества цепочек писем.

Помимо технической реализации я также никак не могу запомнить различные способы, в рамках которых Debian использует псевдопакеты генерации для ошибок и процессов. Нужны они мне слишком редко, чтобы я наконец-то уложил это все в голове и запомнил, как именно они функционируют и используются, но я периодически с ними сталкиваюсь, так что это разнообразие раздражает.

Как бы все это выглядело в идеальном мире?

  1. Debian переключится с нестандартного способа отслеживания ошибок на (любой) уже устоявшийся.
  2. В 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 лучше.
ITSumma
262.19
Собираем безумных людей и вместе спасаем интернет
Share post

Comments 84

    +18
    Всё, что описано в статье — это прям на любой должности программиста в большой компании, у которой свой IT отдел. Мне кажется, человеку просто надоело тратить личное время на всё это. Появились дети и приоритеты сместились в сторону семьи, поддержания здоровья и тд…
      +36
      Да нифига.
      Пакеты для других современных дистрибутивов, например, ArchLinux (PKGBUILD), Fedora/CentOS/RedHat (RPM SPEC), можно создать достаточно быстро, все директивы документированы и структурированы, документация подробная и понятная, с примерами. Поддерживать такие пакеты тоже несложно. Инфраструктура у этих дистрибутивов вменяемая: можно сообщить авторам пакетов о проблемах лично, или удобно и быстро создать баг для пакета. Это можно сделать с любого компьютера.

      Для сборки пакета в Debian существует несколько утилит, оберток. Найти нормальные инструкции по созданию пакета сложно, полноценной и полной документации нет, всё разбросано по разным местам, написано в разное время.
      Инфраструктура в Debian практически не меняется. Значительное изменение, произошедшее в последние годы — переход к salsa.debian.org (GitLab, конец 2017). Добавить сообщение в багтрекер можно только через почту, а сообщить о спаме в багтрекере можно только через веб-интерфейс.
      Чтобы сообщить об ошибке в пакете, нужно (по-хорошему) создавать сообщение об ошибке с того компьютера, с которого эта ошибка наблюдается, через специальную программу, которая сформирует email-сообщение. Тот ещё квест, если у вас Debian установлен в виртуальную машину, без сети.

      Когда годами ничего не меняется, неудобные инструменты не становятся удобней, плохая документация не становится лучше, это угнетает.
        +3
        Я знаю эту систему только со стороны пользователя. Взгляд со стороны разработчика как-то… угнетает.

        А почему так получается? Если люди признают, что неудобно — почему не становится удобно? Слишком большое комьюнити? Большая кодовая база и организаторы не хотят резких изменений? Инерция возраста большинства этого комьюнити? В чём причина, с вашей точки зрения?
          +12
          вот мой любимый постер на тему оптимизации процессов =) мне кажется он все объясняет =)

            +2
            Причина в отсутствии воли к изменениям у кого-то, кто всем командует.
            Недавно объяснял коллеге что нужно для качественного рефакторинга — время, полномочия, видение результата и воля.
            Если чего-то не хватает, то лучше не начинать.

            Под волей я понимаю решимость довести дело до конца, добиться результата, несмотря на необходимость чем-то пожертвовать.
              +3
              Причина в отсутствии воли к изменениям у кого-то, кто всем командует.
              Всё гораздо хуже, чем вам кажется: там никто не командует. Почти все важные решения, по конституции, должны приниматься консенсусом, что приводит к затрате дикого количества времени и сил.
            +4
            Да нифига.
            Пакеты для других современных дистрибутивов, например, ArchLinux (PKGBUILD), Fedora/CentOS/RedHat (RPM SPEC), можно создать достаточно быстро, все директивы документированы и структурированы, документация подробная и понятная, с примерами. Поддерживать такие пакеты тоже несложно.

            Вот и мне показалось, что статье не хватает сравнений с другими приблизительно похожими проектами — что из отмеченного там лучше, а что хуже.
              +8

              Вообще, мне лично понравилась идея NixOS. Кажется, что это как раз логичный следующий шаг как для deb-based, так и для rpm-based дистрибутивов. А snap и подобные решения — например, как распространяется GitLab, в виде огромного пакета «всё в одном» — скорее выглядят костылями.

              +2
              Пакеты для других современных дистрибутивов [...] можно создать достаточно быстро, все директивы документированы и структурированы, документация подробная и понятная, с примерами. Поддерживать такие пакеты тоже несложно. Инфраструктура у этих дистрибутивов вменяемая: можно сообщить авторам пакетов о проблемах лично, или удобно и быстро создать баг для пакета. Это можно сделать с любого компьютера.
              Зашел написать примерно то же самое, но про порты/пакеты FreeBSD. :-) Портировать и пакетировать софт под неё имхо приятнее всего, на втором месте редхатовский rpm, позади (с довольно большим отрывом) — dpkg.

              Справедливости ради, в прошлом с пакетами у фри были известные проблемы, но с появлением pkg(8) в 9.1 всё стало значительно лучше (read: примерно как у всех остальных).
                +1
                Ну так я и не отрицаю. Но если вы из мира IT и не работаете в стартапе или какой-то компании, типа ЕПАМ, где каждый проект для нового заказчика можно стартовать с нуля, то вы столкнетесь с бюрократией, устаревшими технологиями и неудобными архитектурой, инструментами и тп. Я имею ввиду, что всё перечисленное в статье у него было и 5 лет назад. За 5 лет никуда не сдвинулось. Но понять, что оно никуда не двигается и не развивается можно и за 2 года, а разработчик там сидел 10 лет. Также, как и много других разработчиков в крупных компаниях. Поэтому, как мне кажется, причина ухода другая, описанная мной в первом комментарии. А статья — это просто попытка сдвинуть хоть как-то всё это с места, раз уже ушел.
              +7
              И что хотел подчеркнуть автор написав, в начале заметки, что со встречи он уехал на велосипеде?
                0
                По-моему, в английском слово «велосипед» не используется для обозначения самопального решения давно решённой проблемы, но зато в русском переводе появляется дополнительная ирония :)
                  0

                  В английском используется для этого слово "wheel" ("колесо").

                    0
                    «Reinvent the wheel» — да, но я не видел, чтобы использовалось в этом смысле как отдельное слово, в духе «Deploy is done by some ugly wheel written in bash». Так можно?
                      0
                      Не знаю… я не эксперт в английском, просто знал про выражение «to reinvent a wheel».
                        0
                        Мне кажется, вы в данном случае имеете в виду не велосипед, а костыль. Велосипед — не обязательно плохо, это просто применение чего-то самодельного вместо уже придуманного и проверенного.
                          +1
                          Зато уже есть такой формат:
                          Wheel — это современный формат распространения пакетов в Python среде, который пришел на замену eggs.
                      +1
                      Возможно, что он ездит на велосипеде?
                      Или что он побыл один — но это уже, что называется, навеяло.
                      0

                      Я кстати из оригинала статьи не понял — имелся в виду все таки велосипед или мотоцикл, тут надо бы провести исследование расстояния между местом проживания автора и Цюрихом

                      +11
                      Я когда-то собирал deb-пакетики для некоторых задач, и это было не слишком удобно. Куча тулзов, которые нужно применять строго в определённой последовательности, чтобы получить на выходе собранный по фен-шую пакет. Я, конечно, с помощью гугла и какой-то там матери нашёл нужную последовательность шагов и запихнул в скрипт, но мне больно думать, как мучаются парни, которым нужно во всём этом хорошо разбираться и активно использовать.

                      Надеюсь, резонансная статья и уход Михаэля сподвигнут мой любимый дистрибутив к каким-то изменениям в этом плане.
                        +1
                        я собирал checkinstall и fpm, но это было ад-хок решение, не претендующее на красоту и вывод в продакшн. Т.е. пакеты были чисто для передачи артефакта между элементами пайплайна и установкой в целевую систему в докере.
                          +1
                          Да, checkinstall действительно выручает, если надо изредка собрать пару простых пакетиков. Но для более сложных случаев он, увы, не годится.
                          0

                          Когда это когда-то было? Потому что даже тогда, когда эта последовательность была в самом деле важна, на интернете (в т.ч. в официальной документации) была куча примеров. Теперь же, когда эта последовательность делается автоматически через dh, важно только знать, в какой конфиг что написать. Как правило, для пакетов, у которых апстрим нормальный, debian/rules может выглядеть так:


                          #!/usr/bin/make -f
                          
                          %:
                              dh $@
                            0

                            Это когда-то было в 2014 году.


                            Насколько я помню, как минимум для начала надо было сказать dch -i и написать changelog в специальном формате. Ну и rules там были похитрее чем dh $@.

                          –14

                          Это статью должны прочитать все производители "отечественных ОС", участвующих в импортозамещении!


                          КВИНТЭССЕ́НЦИЯ:


                          Хотя выше я описал ряд конкретных недостатков, последний гвоздь в крышку гроба — это отсутствие позитивного прогноза на будущее.
                            –4
                            Наверное, пора кому-то форкнуть Debian. Но не добавлять свистоперделок, а поднять просто хорошую инфраструктуру.
                              +9
                              А разве мало поделок на ее основе? Полноценный форк мало кто сможет вывезти, судя по описанным сложностям…
                                +2
                                Кажется у дебиана рекордное число форков, а если учесть форки форков…
                                  –1
                                  Да это понятно. Но форки обычно кучу всего меняют, добавляют новый UI, стараются как можно быстрее собирать пакеты и так далее. Но нет такого же стабильного, но не через одно место организованного форка :)
                                    +4
                                    Так стабильность судя по всему и достигается тем, то патч протолкнуть стоит больших трудов.
                                –10
                                А не он форсил systemd в среде debian?
                                  0
                                  Михаэль положительно относится к systemd, но при чём тут systemd? Речь об инфраструктуре проекта, а не о компонентах дистрибутива.
                                  +3

                                  А что там у Ubuntu?
                                  Есть вебинтерфейс для багов
                                  Есть ppa где можно создавать репозитории
                                  Может стоит присмотреться разработчикам Debian?

                                    +2
                                    Ubuntu собирается из Debian Unstable, без него она просто не сможет существовать.
                                    +12
                                    Я когда-то вынужден был связаться со сборкой пакетов в debian. Это было просто ужасно — даже имея человека, которого можно было спросить, я всегда натыкался на неочевидные трудности, часто статьи по сборкам пакетов, хоть и предлагали некие способы создания пакетов — эти способы оказывались неверными. Мануалы самого debian были или частично неверными, или частично устаревшими. Теперь стараюсь всеми силами избегать сборки пакетов для debian.
                                    • UFO just landed and posted this here
                                        +2
                                        А у вас была необходимость собирать пакеты «правильно и канонично»? (Под этим я имею ввиду когда пишется debian/rules а потом все собирается при помощи dpkg-buildpackage -us -uc)

                                        Просто, если делать это для внутренних нужд, то шаблон control.in, куда подставляются нужны значения версий, posints/postrm скрипты если нужны, директория с деревом файлом + fakeroot dpkg-deb --build и готовый пакет. Вроде совсем небольно. Можно еще fpm использовать, но если нет необходимости собирать пакеты под другие дистрибутивы, то какого-то особого преимущества он имхо не даст.

                                        А если совсем «для себя», то можно checkinstall использовать.
                                          +2
                                          Именно канонично под руководством одного из майнтейнеров debian. Надо было заполнить debian/ и отправить все это на mentors.debian.net.
                                          +2
                                          Мануалы самого debian были или частично неверными, или частично устаревшими.
                                          А разве это не везде так?
                                            +3
                                            Для меня было неожиданностью, что по мануалам самого debian я не мог собрать полностью корректный .deb пакет.
                                              +1
                                              Верю.
                                              Про какую-то другую программу или пакет (не помню, что это было) я в её документации читал, что она развивается так быстро, что свежей и полной документации не будет никогда.
                                          +4

                                          Пожалуйста, не занимайтесь переводами.


                                          Для переводчика, как и для программиста, очень важно понимать, что он пишет. У вас, к сожалению, это понимание отсутствует. Вы переводите механически, не понимая смысла получившейся фразы на русском языке. В итоге переводимое предложение полностью теряет всякий смысл, как например "Я ценю то, что каждый проект отличается". Если у вас не возникает вопросов к этому предложению, то пожалуйста, не занимайтесь переводами.

                                            0
                                            Мой традиционный вопрос — на какой дистрибутив стоит перебегать, если даже Дебиан сдулся?
                                              0
                                                +1
                                                Ой не знаю, этот дистрибутив сделан с нуля, и ему всего несколько годиков. Насколько он надёжен по сравнению с Дебианом? Сколько процентов пользователей линукса его используют? Сторонние пропертарные софтины вроде скайпа или тимвьюера под ним тестируются производителями и реально работают? Есть ли отзывчивое комьюнити? Поддержка кодировок реально работает или сделана «на отвали»? И ещё сотня аналогичных вопросов к дистрибутивам-новичкам.
                                                  0
                                                  Rhel/centos если не напрягает замороженный на 5 лет код.
                                                  opensuse вроде тоже пока живет.
                                                  Ubuntu чтото при обновлении ломатся часто стал.
                                                  0

                                                  Оттуда не то что мейнтейнер, оттуда недавно основатель ушёл  : )                         /s

                                                  0
                                                  Мне интересно, а как сделать так, чтобы дистрибутивы и открытые программы не сдувались? Ведь у разработчиков нет мотивации что-то менять — нет пути для эффективного фидбека (как минимум финансовое благополучие разработчика не зависит от успешности его продукта).
                                                    –1
                                                    Вести рейтинги. А линуксовое комьюнити даже не может собрать реальную статистику популярности по дистрибутивам…
                                                      +3
                                                      отсутствие телеметрии — чуть-ли не главный плюс линуксоводов ;)
                                                      а при ее отсутствии, достаточно сложно собрать статистику, да…
                                                        –2
                                                        Вот ведь проблема-то. Ну опрос что-ли провели бы. А user-agent смотреть не пробовали, хотя бы на том же Хабре?
                                                          0
                                                          Вы серьезно предлагаете на все серваки поставить юай, открыть им доступ в инет, и всем дружно зайти на хабр? )))
                                                          И даже не считая серверы (ну, вот, допустим, нас интересуют только физические юзеры), лазящие по инету. Причем юзеры, которые НЕ меняли информацию юзер агента и НЕ скрывали ее.
                                                          Смотрим на на предмет что там в том том агенте бывает:
                                                          * Linux x86_64
                                                          * Windows NT 6.1; Win64
                                                          * Macintosh; Intel Mac OS X
                                                          * iPhone; CPU iPhone OS 10_3_1 like Mac OS X


                                                          Судя по примерам, единственный случай когда вы достаточно четко сможете понять что за система у пользователя — это мобильный сафари (вообще-то, вроде, андроиды тоже пишут довольно подробно, но их миллионы, за всех сказать нельзя). Остальные ограничиваются битностью и семейством.
                                                        0
                                                        А ведь Вы правы! Ведь большинство продуктов open-source как раз и разрабатываются для повышения собственной самооценки, признания. Думаю, рейтинги были бы действенным фидбеком.
                                                          0
                                                          Хм…
                                                          Если посмотреть на тему статьи — нет, я не призываю оставаться исключительно в ее рамках. Разработчик Дебиана — вполне действенный фидбек для повышения собственной самооценки. Я полагаю, в жизни довольно немного фидбеков такого уровня.
                                                            0

                                                            А проблема-то глобальная для open-source. Я очень часто вижу, как разработчики делают продукт для себя, без какой-либо определенной цели. К примеру, Haiku или Lxqt. Вы можете прямо сейчас зайти в лист рассылки devel Haiku и увидите, как разгораются страсти, а не забанить ли одного из разработчиков. Формальная причина — оскорбил другого разработчика, если копнуть глубже — он старается продвигать нововведения в хайку, сделать её более удобной для пользователей, попутно критикуя излишний консерватизм (часть хайку до сих пор компилируется gcc 2.95). Я и сам лично заснял видео о своем опыте с хайку, выложил на обсуждение, указал, что мне показалось непонятным и был проигнорирован. А путей для того, чтобы эффективно донести свой фидбек у меня просто нет. Я не могу влиять на решения разработчиков ни деньгами, ни рейтингом. Так же и с системой сборки пакетов — я не могу проголосовать рублем или рейтингом за разработку новой системы сборки и мануалов к ней, то есть сегодня механизм обратной связи от пользователей к разработчикам очень неэффективен.

                                                              0
                                                              я не могу проголосовать рублем или рейтингом за...
                                                              Это правда.
                                                              Но насколько я понимаю (я не являюсь ни разработчиком опенсурса, ни вообще разработчиком, это вводит определенные коррективы для моего понимания), разработчиками опенсурса становятся по очень разным причинам, и немалую роль в этом списке причин играет то, что здесь можно делать продукт «для себя», а не для унылого менеджера на унылой работе. Эрго, когда кто-то пытается (в глазах разработчика) заместить виртуальную вакансию унылого менеджера и влиять на решения — он может столкнуться с серьезным сопротивлением. Даже если, повторюсь, все это происходит исключительно в глазах разработчика.

                                                              Я сталкивался с таким явлением в некоммерческих организациях, и не сказал бы, что это был вдохновляющий опыт.
                                                                0
                                                                Так ведь разработчик может продолжать творить для себя. К примеру, вот есть видео-редактор без возможности добавлять субтитры. Пользователь создает запрос на такую возможность и кладет на счет этой возможности 1 доллар. Разработчик продолжает пилить приложение для себя. Приходят еще 10 пользователей и кладут по 1 доллару. В общем-то, 11 долларов погоды не делают. Но если придут еще 200 пользователей с 1 долларом, то разработчик подумает «программу я знаю, как свои пять пальцев, а чего бы и не подзаработать» и, возможно, сделает фичу. А если не сделает, то появится еще разработчик, готовый за 200 долларов и разобраться в программе, и код доработать. При этом первый разработчик все так же может пилить программу для себя. Тут, конечно, подход требует продумывания деталей, но он возможен.
                                                                  0
                                                                  Любопытная идея, кстати: по крайней мере мне нравится. Такой целевой донат на фичу.

                                                                  Хотя конечно, разработчик, готовый за 200 долларов и разобраться в программе, и код доработать вызывает некоторый трепет в помыслах…
                                                                    0
                                                                    Зря.
                                                                    Во-первых — все еще есть страны, где 200 долларов это нормально, для фичи которую не надо делать годами )
                                                                    во-вторых — есть люди, которые могут что-то сделать просто потому что могут. И немного денег на пиво в качестве дополнительной стимуляции что б чуток улучшить прогу который ты сам пользуешься (а собственно, в дебри гитхаба, именно за тем и лезут, что б пофиксить что-то что не нравится, или скопировать себе что нравится) — им будут просто приятны.
                                                                    А вот в-третьих — эти кадры из пункта 2, очень часто обламываются что-то делать, из-за всех выше по теме перечисленных причин ) А если к этим причинам, еще добавится геморой в виде общения с налоговой на тему дополнительных доходов…
                                                                      0
                                                                      все еще есть страны, где 200 долларов это нормально, для фичи которую не надо делать годами )
                                                                      Именно.
                                                                      Как я уже отметил, я не разработчик, но шуточки про индусский код мимо меня не прошли.

                                                                      Впрочем, с моей стороны это тоже была попытка пошутить. Если неудачная — приношу извинения.
                                                                        0
                                                                        Для того контингента который вы имели ввиду, 200 уе, это месячный доход. Если точнее — то это высокий месячный доход.
                                                                        Но остановятся они на пункте — как войти в гитхаб, так что все норм )
                                                                          0
                                                                          Вы меня утешили :)
                                                                      0
                                                                      Нужен сервис, по типу краудфандинга, только для программ.
                                                                        0

                                                                        Есть уже такой: BountySource. Как раз то что тут обсуждается:


                                                                        • есть список фич
                                                                        • за них можно голосовать рублём
                                                                        • можно добавить свою фичу
                                                                        • кто смог и сделал — получает плюшки

                                                                        А может и не один (нужно отфильтровать по тегу donation).

                                                                          0

                                                                          Только сделан он очень топорно, там, к примеру, минимальный платеж 5 евро. Я готов перевести 1 евро на баг, но за 5 евро мне легче купить аналогичную программу. Кроме этого, сервис должен быть удобным и интегрированным в менеджер программ дистрибутива, возможно, совмещен с системой контроля версий и отслеживания задач.


                                                                          Решить нужно две проблемы: дать возможность оценивать и сортировать по оценке (где-то уже реализовано), дать возможность обратной связи деньгами. И эти возможности должны быть доступны за 3-4 клика.

                                                        0

                                                        Федора?

                                                        • UFO just landed and posted this here
                                                            0
                                                            Разве проблема версионирования всякого инфрастуктурного софта(БД, веб сервер etc.) не решается Докером?

                                                            А вобще, вопрос по прежнему весьма холиварный, и даже никаких причин слезать с Дебиана пока не вижу. Я в поисках самого удобного дистрибутива остановился на Manjaro. Пол года сидел с KDE, уже пару месяцев с XFCE(Так и не решил какой DE выбрать, Cinnamon из Минта кстати тоже классная вещь).
                                                            Путь был Debian => Kubuntu => Mint => Manjaro, с параллельной пробой elementaryOS. В принципе проблемы(шрифты, драйвера) возникали только в Debian, у всех остальных дистрибутивов с этим всё сразу было отлично. Manjaro выбрал за Rolling Release(и ещё возможность юзать систему во время установки: ))
                                                            • UFO just landed and posted this here
                                                            +1
                                                            А он разве сдулся? Тут как раз пишут, что такое положение у разработчиков уже давно, но существует же проект все эти годы. Думаю, если вы не пакетируете пакеты, то проще всего оставить как есть.
                                                              0
                                                              Gentoo :)
                                                                0
                                                                Вы серьёзно?
                                                                0

                                                                Я последние года три сижу на арч линухе. Очень простой, всегда самые свежие пакеты всех приложений в силу простоты дистрати отсутствия каких-то мажорных релизов, при этом обалденная стабильность: за все эти годы я установил и настроил себе арч лишь единожды, с тех пор просто копировал свою папку линуха с одного устройства на другое, когда менял ноутбук и когда пожелал иметь арч в том числе на своей пекарне. практически ни разу ничего не сломалось. Я забыл о переустановках своей ос. Я просто работаю в ней и обновляю ее время от времени. В данный момент я считаю арч лучшим вариантом для десктоп системы.

                                                                  0
                                                                  Я поставил Manjaro, он на основе Arch, сильно недоволен. Везде какие-то глючки по-мелочи, кодировка кое-где поломана, после апдейта не даёт делать некоторые вещи без перезагрузки, ну совсем как Microsoft. Add/remove software поломался через неделю, pacman работает. Проблемы с регулировкой яркости и громкости.
                                                                    0

                                                                    Я то здесь причём?) Манжаро и арч — это разные дистрибутивы. Первый для тех, кто хочет нажать две кнопки и получить полностью рабочий десктоп, при этом не желает ни в чём разбираться самостоятельно. Лично я не имею к таким людям и такой идее никакого отношения. Второй дистрибутив для тех, кто не видит ничего страшного в необходимости почитать мануал по установке ОС через несколько команд в консоли, в число которых входит разбивка разделов, копирование файлов, настройка загрузчика и небольшая настройка конфигурации запуска ядра линуха. Далее предполагается всё также открывать вики-страницы и изучать инструкции по установке и настройке того графического окружения, которым вы любите пользоваться. В общем, это совершенно отличные дистрибутивы и идеологии. Я лишь один раз настроил себе всё в арч линухе, и с тех пор просто живу с ним и обновляю свою ОС на самые последние версии пакетов. Пока что у меня не было ни одной ситуации, когда что-то просто вдруг взяло и перестало работать. И я вполне допускаю, что если вы сядете и постараетесь разобраться именно с арчем, а не с каким-то другим дистрибутивом с отличной идеологией — то у вас может случиться примерно такая же история.

                                                                      +1
                                                                      Извините, но это как с жигулями — если можно не настраивать карбюратор и антикорить, а сразу ездить, то выбор в пользу иномарки очевиден.
                                                                        0

                                                                        Ну тогда вам на вин10 или макос ведь. Проблем нет, выбирайте, я не против. Но меня лично привлекает то, что я описал)

                                                                          0
                                                                          Ну почему? Линукс, но надёжный и работающий из коробки. Если Убунту научатся не увеличивать число багов с каждым релизом, а уменьшать, то будет счастье.
                                                                            +1
                                                                            Не получится. Ubuntu, как и все остальные дистрибутивы, создаются из частей, которые делаются без особого плана — потому проблемы на стыках неизбежны и решать их, по большому счёту, некому. Кроме, собственно, пользователя.

                                                                            То есть если не хочется ни в чём разбираться, а хочется просто пользоваться, то остаются только Android и ChromeOS — а это, как бы, уже совсем-совсем другая история.
                                                                +1
                                                                Теперь понятно, почему докер взорвал рынок — запаковать в докер большого ума не надо, в отличие от запаковки в deb/rpm. Продолжаем наблюдение за развитием технологий…
                                                                  0
                                                                  Скорее не ума, а геморроя… Если один способ быстрый и удобный, а второй медленный, нкудобный, да ещё и требует, чтобы я как следует потратил время в поисках документации, то что же я выберу?
                                                                    +1
                                                                    Вендоринг — решение проблемы до тех пор, пока вендоринг не становится проблемой.
                                                                    +1
                                                                    20 лет назад я пытался уйти с маздая на линух.
                                                                    Поковырял его годик — решил что сыроват, подожду.
                                                                    Прошло 20 лет — пожалуй все еще сыроват, посижу ка пока еще на Win NT ver X.X

                                                                    Only users with full accounts can post comments. Log in, please.