30 июня 2011 г.

Из чего состоят дистрибутивы Linux. Часть I


Дистрибутивов Linux огромное количество. Откуда они берутся, как получаются и почему именно такие — этому и посвящена статья. Статья адресована прежде всего новичкам в мире Linux, поскольку большинство из тех, кто начинал им пользоваться раньше появления Ubuntu, обычно знают все, что приведено ниже.

Представьте себе огромное количество разного ПО от маленьких (но важных) проектов по отдельным библиотекам до огромных типа KDE, GNOME, Libre- и OpenOffice, ядра Linux. Все эти отдельные проекты развиваются каждый сам по себе, иногда с оглядкой на остальные, иногда нет. Конечно, каждый может собрать это все ПО вместе и объявить дистрибутивом Linux, но в случае серьезных дистрибутивов (я к ним отношу те, что занимают первые 10 мест в рейтинге Distrowatch) все обычно гораздо сложнее.


Немного о терминах.
Разработчиками дистрибутива (или майнтейнерами) обычно называют тех, кто берет какое-то ПО и упаковывает его в пакет для конкретного дистрибутива (пакетная система, для чего она нужна и что делает - отдельный большой вопрос).
Место, откуда это ПО берется - называется апстрим (от английского upstream). Адекватного перевода на русский язык я пока не нашел, да и слово апстрим стало уже устоявшимся термином. Для серьезных дистрибутивов апстримом являются конкретные проекты свободного (и не очень) ПО. Для производных дистрибутивов - другие дистрибутивы Linux. Например, для CentOS - апстримом является Red Hat Enterpise Linux, для Ubuntu - Debian, для Debian - оригинальные разработчики ПО. Еще раз - апстрим это или разработчик конкретной программы, или родительский дистрибутив.
Пакетом называется отдельный атом дистрибутива (в смысле неделимости), который несет в себе конкретную программу (или набор программ), библиотеку (или набор библиотек), документацию, темы оформления или что-то еще. Короче говоря, все, что составляет дистрибутив Linux - это меньшее или большее количество пакетов. Пакет - это обычно:

  • архив дерева файлов в том виде, в котором они должны лежать на диске после установки;
  • набор метаданных, содержащих информацию о пакете (имя майнтейнера, описание пакета, зависимости);
  • набор скриптов, облегчающих установку пакета для пользователя и/или производящих те или иные настройки.

Пакетная система - то, что помогает пользователям дистрибутива искать, ставить, обновлять пакеты и автоматически отслеживать зависимости между ними. Пакетные системы в мире Linux делятся на три больших и хорошо очерченных класса:

  • пакетная система Debian и ее deb-пакеты.
  • пакетная система rpm, придуманная в свое время Red Hat и теперь имеющая не всегда совместимые между собой пакеты разных rpm-дистрибутивов (Red Hat/Fedora, SUSE, Mandriva и т.п.). Имеется в виду, что, например, пакет для Mandriva может и встанет на SUSE (зависит от положения звезд на небе), но работать скорее всего откажется.
  • все остальные пакетные системы. В качестве примера сюда можно отнести и пакеты ArchLinux, и Slackware, и отчасти Gentoo.

Важный составляющих элемент пакетной системы - менеджер пакетов. Это программа, позволяющая управлять пакетами на конкретной машине. И обычно она имеет только текстовый интерфейс, но разработчики большинства дистрибутивов, как правило, поставляют графические утилиты, взаимодействующие с пакетным менеджером и таким образом значительно облегчающие жизнь тех, кто еще не познакомился с консолью Linux или не хочет с ней знакомится вовсе.
Вопрос какая пакетная система лучше, какая хуже - относится к сфере личных пристрастий и потому спорный. Желающие могут в этом убедиться, открыв на каком-нибудь Linux-форуме тему «Что лучше rpm или deb?». Если Вас сразу не забанят модераторы форума за провокацию, то флейм по этому поводу займет не один десяток страниц.
Зависимости - это следующая непонятная новичкам штука. Бывают жесткие и мягкие. Жесткая зависимость в общем виде - это все то, без чего содержимое пакета работать не будет. Обычно это какие-то библиотеки, обеспечивающие функционал конкретной программы. Мягкая зависимость - это то, что обеспечивает дополнительный функционал для программы. Такой тип зависимостей есть, по большому счету, только в deb-пакетах.
Следующее непонятное определение - репозиторий пакетов. Это место, откуда пользователи берут ПО для своего дистрибутива. Обычно это некое сетевое (но может быть и локальным) хранилище пакета, в котором помимо собственно пакетов для дистрибутива находится набор метаданных, которые используются пакетным менеджером для управления ПО на машине пользователя. Именно благодаря этим метаданным пользователям достаточно легко найти нужные пакеты в репозитории, а пакетному менеджеру выяснить, какое ПО требует обновлений.
По способу поддержки репозитория можно выделить три типа дистрибутивов:

  1. Дистрибутивы со скользящим релизом (или безрелизные). На английском они обычно называются rolling release. Типичный (и достаточно популярный) тут - Archlinux. В таких дистрибутивах после обычно малого периода тестирования пакеты попадают к пользователям практически сразу после релиза конкретного пакета его разработчиком. Главное преимущество таких дистрибутивов - то, что в репозитории находится очень свежее ПО. Это имеет и обратную сторону (за все в жизни приходится платить) - в этом ПО зачастую имеются ошибки, которые с переменным успехом отлавливаются пользователями такого дистрибутива. По причине того, что большая часть проектов развивается без оглядки друг на друга, иногда встречается какая-либо несовместимость между какими-то пакетами, вызывающая неработоспособность определенной программы. Иногда (при серьезных изменениях) меняется формат конфигурационного файла программы или демона, что требует работы руками. Но те, кто используют такие дистрибутивы, обычно знают, на что идут, и достаточно квалифицированы для того, чтобы решить все возникающие проблемы. Тут из всех дистрибутивов, на мой взгляд, самый выдержанный подход у Gentoo, который представляет собой дистрибутив с rolling release-моделью, но тем не менее все пакеты попадают в его стабильную ветвь после значительного периода тестирования, что обеспечивает достаточно высокую надежность его работы.
  2. Дистрибутивы с релизной моделью. Проблема получения стабильного дистрибутива давно уже решена и используется большинством разработчиков разных дистрибутивов Linux, таких как Debian, Ubuntu, Red Hat, SUSE и проч. У таких дистрибутивов есть обычно тестовая ветвь с rolling release-моделью, на которой обкатываются (и решаются) разные проблемы несовместимости и нестабильной работы конкретного ПО. Периодически эту ветвь замораживают, блокируя попадание туда новых пакетов. Затем в таком репозитории вычищают по максимуму все имеющиеся в нем проблемы и ошибки. Когда ошибок, по мнению разработчиков, уже достаточно малое количество, выпускается очередной релиз, на протяжении жизни которого в нем не будут уже меняться версии имеющегося ПО. Обновления такого дистрибутива включают в себя исправление оставшихся ошибок и устранение возникающих время от времени уязвимостей. Иногда ошибки устраняют и разработчики апстрима. Тогда задача майнтейнера пакета проанализировать исходный код разработчиков ПО (он же открыт) и выделить из него только те изменения, которые отвечают за исправление ошибок. Затем эти изменения накладываются на те программы и библиотеки, которые находятся в стабильном релизе. Благодаря этому получается, что версия ПО в стабильном дистрибутиве старая, но тем не менее в ней исправлено большинство уязвимостей, найденных к этому моменту. Другое дело, что длительная поддержка ПО по такой схеме - вещь трудная. Ведь чем больше проходит времени с момента релиза, тем более высокая квалификация требуется от разработчика, чтобы выделить только то, что исправляет ошибки и ни в коем случае не ломает совместимость с другими программами и библиотеками. Именно по этой причине длительную поддержку релиза могут позволить себе немногие. По сути лишь те, кто имеет большое количество квалифицированных программистов, то есть коммерческие компании Red Hat и Novell. Такие дистрибутивы прекрасно подходят для консервативной корпоративной среды, где редко происходят сильные изменения и поэтому нужна высокая стабильность работы.
  3. Дистрибутивы со смешанным циклом. В таких дистрибутивах стабилизируется (замораживается) только одна часть репозитория. Как правило, это все, что относится к сборочной среде, - компилятор, библиотека C, разные важные библиотеки, ядро Linux. А ПО, относящееся к десктопам (типа Firefox, OpenOffice, разные игры), обновляется регулярно (но обязательно после продолжительного тестирования).

Для таких популярных дистрибутивов как openSUSE и Ubuntu есть выбор - либо использовать стабильную базу конкретного релиза их дистрибутива, или подключить дополнительные репозитории (репозитории OBS для SUSE и ppa для Ubuntu), получая таким образом более свежее ПО для своей системы.
Вроде как все, что хотелось бы сказать по данному поводу. Если что осталось неясно, постараюсь ответить в комментариях на вопросы, касающиеся данной статьи. В меру сил и наличия свободного времени постараюсь внести все необходимые изменения, если потребуется в приведенный текст статьи.

15 комментариев:

  1. В целом хорошо, но статье нехватает структуры, на мой взгляд:
    - репозитории
    ------ пакеты
    ------- пакетные менеджеры
    - релизы

    В "способах поддержки репозитория" воды столько, сколько хватит для заполнения Аральского моря :-)

    Про ебилды стоит упомянуть отдельно, ибо это не совсем пакеты. Вернее, не такие, как deb/rpm. Ну и source-based (Слака, к примеру) к пакетным как-то слабо относятся.

    Раздел "зависимости" - Антон, ты сказал там всё, кроме, собственно, главного. Из сказанного остаётся мутное впечатление. Вместо воды про "поддержку репозиториев" стоит этот момент пояснить лучше. Можно взять отсюда или особенно отсюда.

    Опять-таки, из-за обилия воды в конце главная тема остаётся нераскрытой - что отличает один дитсрибутив от другого (кроме нескучных обоев).

    P.S. автор подумывает запилить что-нибудь такое же баянное с блэкджэком и азартными барышнями :-)

    ОтветитьУдалить
  2. Критика принимается, но только отчасти ;).

    > В "способах поддержки репозитория" воды
    > столько, сколько хватит для заполнения
    > Аральского моря
    Тут скорее попытка, основанная на опыте преподавания, растолковать максимально понятно начинающему. Да в общем-то я и написал выше, что опытным линуксоидам это все не сильно интересно будет.

    > Про ебилды стоит упомянуть отдельно,
    > ибо это не совсем пакеты. Вернее, не такие,
    > как deb/rpm. Ну и source-based (Слака, к
    > примеру) к пакетным как-то слабо относятся.
    Да в общем у меня была идея про пакетные системы попытаться отдельное что-то написать. Там же и про зависимости поподробнее.

    ebuild по большому счету - это не пакет, а файл спецификации, такой как spec-файл rpm или debian/rules.

    А Слака - дистр, основанный на бинарных пакетах все-таки. Просто они у нее особенные. И то, что ты имеешь в виду - это slackbuild скрипты, по сути, повторяющие ebuild'ы. Но это дополнение и базовому репозиторию (он же не такой огромный, как у Debian ;) )

    > Опять-таки, из-за обилия воды в конце
    > главная тема остаётся нераскрытой.
    Посмотрим как и что со временем будет, или эту поправлю, или обзову ее часть1 и напишу часть 2 :).

    ОтветитьУдалить
  3. Честно говоря даже и не знал что Арч и Генту не имеют релизов... в общем достаточно интересно, но мне кажется что статья не совсем отвечает на вопрос "как получаются дистрибутивы". Скорее классифицирует дистрибутивы по тем или иным признакам. Естественно ИМХО.

    ОтветитьУдалить
  4. Пытаюсь сейчас вторую часть дописать, думаю на днях выложу.

    ОтветитьУдалить
  5. @stranger

    Пытаюсь сейчас вторую часть дописать, думаю на днях выложу.
    Поздно, Дубровский, я замужем (С)классика. Собственно, запилил своё.

    Критика принимается, но только отчасти ;).
    Я в общем-то не троллил.

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

    Да в общем-то я и написал выше, что опытным линуксоидам это все не сильно интересно будет.
    Это ты так комментатора вежливо посылаешь в сад, да? :-)
    Опытные всё знают, а новичкам будет понять сложно. Но дело твоё. Я мимо проходил.

    Да в общем у меня была идея про пакетные системы попытаться отдельное что-то написать. Там же и про зависимости поподробнее.
    Заместо этого можешь присоединиться к бросающим тухлые яйца и помидоры в мой пост.

    Кстати, отдельно не надо. Надо сразу, в тему, кратко и ёмко.


    ebuild по большому счету - это не пакет, а файл спецификации, такой как spec-файл rpm или debian/rules.
    Я в курсе, но в тексте этого нет. А зря.


    Посмотрим как и что со временем будет, или эту поправлю, или обзову ее часть1 и напишу часть 2 :).

    Антон, воды и в первой выше крыши. Дело в том, что где не надо, воды дофига, а где надо - пара скупых фраз. Впрочем, в моём баяне лирики тоже хватает.

    ОтветитьУдалить
  6. > Я в общем-то не троллил.
    А я это писал? ;)

    Насчет твоей статьи, все конечно круче, да... Даж завидно :). Было бы у меня времени побольше...

    ОтветитьУдалить
  7. @stranger комментирует...
    Насчет твоей статьи, все конечно круче, да... Даж завидно :)
    Так это... талант-то, Сальери, не пропьёшь :-)

    На самом деле я этот баян написал из своего же комментария, который выше, и частей твоего текста. Подумал, посмотрел на свой коммент и сказал себе: "ба, да это ж пост!". В комменте структура есть - а это главное. Структура текста это как рельсы - если есть, дальше проще. Опыт написания научных статей и конференций тоже даёт себя знать.

    Ты меня этим постом по-хорошему раззадорил, надо сказать. Поэтому я за этот баян и взялся.


    Было бы у меня времени побольше...
    Не в этом дело. Я свой пост написал за час. Потом в воскресенье поправил чуток, и всё.

    У тебя текст написан одним потоком. Кстати, в постах, где ты не переводчик, ситуация та же - обрати внимание. В последней части ты немилосердно топишь деталями. Нет разделения по смысловым блокам, нет переходов, нет примеров и скриншотов. Цветовая подсветка так же придаёт посту определённый шарм. Рецепт-то в общем незатейлив. Как говорили классики, "достигается упражнением".

    С наилучшими пожеланиями,
    [:|||||||||:] Virens :-)

    ОтветитьУдалить
  8. Да, отсутствие структуры,это моя беда. Сказывается, наверное, что я уже года три не писал научных статей. Но к слову, в статье про LVM со структурой все нормально было и она заработала заслуженные отзывы. А вторую часть я все-таки сделал, не выбрасывать же ее ;).

    ОтветитьУдалить
  9. Анонимный8 июля 2011 г., 20:40

    Антон, Вы молодец. Хорошее дело делаете, полезное.

    Пожалуйста, не пишите слово "функционал", там где его не должно быть. Вы имеете ввиду "функциональность", так и пишите это слово.

    Спасибо за статью.

    ОтветитьУдалить
  10. Анонимный9 июля 2011 г., 12:15

    openSUSE, но ни как не OpenSUSE. Это важно.
    http://ru.opensuse.org/Справка:Стиль#.D0.9A.D0.B0.D0.BA_.D0.BF.D1.80.D0.B0.D0.B2.D0.B8.D0.BB.D1.8C.D0.BD.D0.BE_.D0.BF.D0.B8.D1.81.D0.B0.D1.82.D1.8C_openSUSE

    ОтветитьУдалить
  11. Спасибо, поправил в этой статье и во второй части тоже.

    ОтветитьУдалить
  12. Анонимный9 июля 2011 г., 13:51

    >но в случае серьезных дистрибутивов (я к ним отношу те, что занимают первые 10 мест в рейтинге Distrowatch)

    дальше не читал.

    ОтветитьУдалить
  13. Автор, в русском языке нет слова апстрим. Учи русский язык, да и английский. Похоже, что ты ни тот, ни другой не знаешь.

    Да и упоминание "серьезных дистрибутивов" и "distrowatch" в одном контексте о многом говорит.

    ОтветитьУдалить
  14. Вот только граммар-наци строить не надо :). Вам известно слово - "заимствование"? Многие специализированные термины заимствуются и адаптируются. Слова "компьютер" и "монитор" тоже как бы не совсем русские.

    Не нравится - жми ALT+F4. Я ж читать не заставляю.

    ОтветитьУдалить