Хоть Virens частично и раскрыл эту тему в своем последнем посте, пост, приведенный ниже уже был наполовину готов. И я подумал — а не буду я отменять выкладывание этого поста. Что лучше, что хуже пусть судят остальные ;). Вопросы, касающиеся пакетного менеджмента я, в свое время, тоже опишу.

В первой части были рассмотрены основные определения, касающиеся понимания дистрибутива Linux. Теперь, собственно, я попытаюсь собрать это все воедино.

Как получается очередной дистрибутив Linux?

Первый этап — это появление человека, которого не устраивают существующие дистрибутивы. По этому поводу у него будут обоснованные аргументы. Вопрос этих аргументов достаточно тонкий и лежит обычно в области «нравится — не нравится», поэтому тут сильно углубляться не стоит. Обычно, чтобы дистрибутив не был очередной однодневкой, у этого человека должны быть определенные харизматические качества (он становится во главе нового сообщества и должен сплотить его) и организаторские способности (мир свободного ПО слабо поддается деспотическому управлению, поэтому тут применяются иные методы руководства).

Чтобы понять, о чем я тут пишу, достаточно посмотреть на таких ярких личностей, как Патрик Фолькердинг (основатель, архитектор и пожизненный лидер Slackware), Ян Мердок (основатель Debian, хоть он в настоящее время и не имеет отношения к этому проекту, но заложенные им идеи живут по сей день) и Марк Шаттлворт (основатель Canonical и Ubuntu).

Второй этап — этот человек и сообщество вокруг него принимает решение о том, будет ли дистрибутив базироваться на существующем или будет самостоятельным. У любого подхода есть свои преимущества и недостатки.

Дистрибутив, претендующий на независимость:

• Берет исходные коды для своих пакетов непосредственно на сайтах разработчиков открытого ПО.
• Обладает своей собственной системой пакетного менеджмента (чтоб не зависеть от других). Имеется в виду, конечно же, не совсем и не всегда разработка с нуля. Дистрибутив может использовать, допустим rpm, со своими расширениями, но высокоуровневый пакетный менеджер (такой как yum, zipper или apt) у независимого дистрибутива будет свой. Можно, конечно, взять имеющийся пакетный менеджер, но если вдруг его бросят оригинальные разработчики, то можно огрести кучу проблем. Пример, который сходу приходит на ум, — это ALT Linux со своим apt-rpm, который заброшен оригинальными разработчиками и поддерживается теперь только альтовцами.

Обладает собственным сообществом разработчиков. Это тоже большая проблема, потому что свободные разработчики они на то и свободные, что заставить их сделать что-то невозможно. Если им что-то не понравится — они уйдут в другой проект. И отдельная проблема — это убедить их в том, что новый проект будет нужен другим и к нему действитель