Автор Тема: Из чего состоят дистрибутивы Linux  (Прочитано 4510 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн Voltmeter

  • Moderator
  • Hero Member
  • *****
  • Сообщений: 3547
Из чего состоят дистрибутивы Linux
« : Суббота 9 Июля 2011 03:37:51 »
Из чего состоят дистрибутивы Linux. Часть I

30 июня 2011 г.

Дистрибутивов 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-пакетах.
Следующее непонятное определение - репозиторий пакетов. Это место, откуда пользователи берут ПО для своего дистрибутива. Обычно это некое сетевое (но может быть и локальным) хранилище пакета, в котором помимо собственно пакетов для дистрибутива находится набор метаданных, которые используются пакетным менеджером для управления ПО на машине пользователя. Именно благодаря этим метаданным пользователям достаточно легко найти нужные пакеты в репозитории, а пакетному менеджеру выяснить, какое ПО требует обновлений.
По способу поддержки репозитория можно выделить три типа дистрибутивов:

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


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

Автор: Антон Чернышов

Источник: TuxThePinguin.RU
« Последнее редактирование: Суббота 9 Июля 2011 03:46:54 от Voltmeter »
"Свободен лишь тот, кто потерял все, ради чего стоит жить." Э. Ремарк

Оффлайн Voltmeter

  • Moderator
  • Hero Member
  • *****
  • Сообщений: 3547
Дистрибутивы Linux. Часть II
« Ответ #1 : Суббота 9 Июля 2011 03:45:52 »
Дистрибутивы Linux. Часть II

5 июля 2011 г.

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


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

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


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

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

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

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

Например, Ubuntu берет бОльшую часть пакетов из репозитория Debian, не модифицируя их, что примерно показано вот здесь. Все свои улучшения вносятся набором дополнительных пакетов, таких как ubuntu-artwork, ubuntu-branding. А Linux Mint, в свою очередь, делает то же самое (но в значительно меньшем объеме) с Ubuntu, потому что является даже не производным дистрибутивом, а надстройкой над Ubuntu.

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

Ниже приведен примерный список всего того, что делает дистрибутив Linux особенным (и одновременно это набор показателей оценки его качества и серьезности задела):

    То, ради чего создается дистрибутив, - его миссия. У Debian - это создание максимально свободной универсальной операционной системы для всех. У Red Hat - примерно то же самое, только для корпоративных заказчиков. У Archlinux и Slackware - это создание дистрибутива на основе принципа KISS (максимально возможная простота), то есть отсутствие (либо минимальное наличие) каких-либо средств конфигурирования дистрибутива и ПО, в него входящего. Сюда же относится лицензионная политика для ПО дистрибутива. Есть ряд дистрибутивов, относимых к максимально свободным, – из них удален весь проприетарный софт, закрытые прошивки для устройств. Какой выбирать по данному критерию – каждый решает самостоятельно. Найти всю интересующую информацию по данному вопросу для конкретного дистрибутива нетрудно. Чтобы узнать ее, достаточно знать английский язык и название официального сайта дистрибутива.
    Анонсируемая сфера применения дистрибутива - встроенные системы, десктопы, сервера, облачные вычисления, роутеры или «и то и другое, и можно без хлеба» (c). Сходу сделать самостоятельный проект, рассчитанный на универсальность, вряд ли у кого получится (а если кто обещает это сделать – или дурак, или маркетолог :) ), поэтому многие проекты идут на то, что поддерживают определенную часть репозитория, оставляя сообществу другую часть - например, как в Ubuntu, где есть репозитории main и restricted, поддерживаемые Canonical, и multiverse и universe, поддерживаемые сообществом. Примерно та же схема у Red Hat/Fedora. Fedora - фарм-дистрибутив, в который сообщество собирает пакеты, а Red Hat отбирает из их репозитория то, что подходит для Red Hat Enterprise Linux, чтобы потом поддерживать это все безобразие максимально возможный срок. Плюс во всему часть пакетов Fedora пересобирается сообществом для пользователей RHEL в рамках проекта EPEL.
    Список поддерживаемых дистрибутивом архитектур. Обычно это вездесущие x86-совместимые - i386/i686 и x86_64. Сейчас в список широко поддерживаемых архитектур все чаще добавляется ARM. Самый большой список поддерживаемых архитектур – у Debian и Gentoo.
    Объем пакетов во всех репозиториях дистрибутива. Большинство проектов позволяют выполнять поиск пакетов через обычный веб-интерфейс без необходимости установки дистрибутива. Таковы Gentoo, Fedora, ArchLinux, openSUSE, Debian, Ubuntu и даже ALT Linux. Это позволяет оценить наличие в дистрибутиве нужного ПО и его версию.
    Анонсируемый уровень пользователей дистрибутива. В данном случае под пользователями понимаются все, кто будет эксплуатировать этот дистрибутив, будь то десктопные пользователи или администраторы серверов. Есть дистрибутивы для очень опытных пользователей (например, новичок в мире Linux просто не сможет поставить Gentoo) и для не искушенных пользователей, как, например Ubuntu.
    Конечная форма доставки пакетов пользователям - поставляется ли дистрибутив в бинарном виде или, как Gentoo, собирается на локальной машине. Тут могут быть и смешанные варианты. ArchLinux, например, имеет репозиторий бинарных пакетов и свою собственную систему для их сборки – ABS. Если пакета нет в базовых репозиториях, то можно легко найти файл спецификации для сборки пакета PKGBUILD в пользовательском репозитории AUR и собрать его самостоятельно. Та же схема и у Slackware. В этом дистрибутиве есть базовый репозиторий, подерживаемый на основе релизов. Все дополнительное ПО, по каким-то причинам не включенное Патриком в дистрибутив его пользователям предлагается собирать с помощью специальных скриптов SlackBuild.
    Политика релизов дистрибутива - выпускаются ли релизы или дистрибутив безрелизный. Обычно анонсируется срок жизни релиза (срок поддержки, за время которого выпускаются обновления) и примерные или точные сроки выхода новых релизов. Например, у Debian релиз выходит по готовности (примерно раз в два-три года), Ubuntu выпускает релизы точно в срок: релизы с долгим временем поддержки – раз в два года, с коротким – раз в полгода.
    Немаловажный фактор, отражающий качество сборки пакетов и квалификацию их майнтейнеров, – это стабильность репозитория для выпущенного релиза (и пакетов в нем). К сожалению, это познается только на собственном опыте. В некоторых дистрибутивах есть тенденции, что обновления нет-нет да и ломают что-нибудь. Не так серьезно, конечно, как в дистрибутивах со скользящими релизами, но все равно неприятно.
    Для дистрибутивов, выходящих на основе релизов, огромную важность несет скорость выхода обновлений, связанных с безопасностью ПО. Это тоже показывает уровень квалификации разработчиков дистрибутива. Серьезные дистрибутивы выпускают такие обновления оперативно, несерьезные берут исправления у серьезных :).
    Уровень модификации пакетов апстрим. Некоторые проекты, типа Archlinux, Gentoo, Slackware используют авторские пакеты без каких-либо серьезных модификаций. Другие проекты, типа Fedora и openSUSE обычно сильно патчат все свои пакеты. Иногда это сказывается на стабильности этих дистрибутивов, иногда нет... Ubuntu, например, также сильно модифицирует все пакеты, связанные с рабочим столом пользователя, потому что компания Canonical оплачивает труд профессиональных дизайнеров, которые и улучшают ее внешний вид. Это причина того, что в одних дистрибутивах интерфейс оконной среды сделан в стиле «разработано профессиональными программистами», а в других – любо-дорого посмотреть.
    Системные компоненты, включенные в дистрибутив по умолчанию. Также важна возможность предоставления вариантов этих компонентов и легкость их смены. Кто-то предоставляет эту возможность, кто-то нет. Например, в Fedora, начиная с 15-й версии, система инициализации systemd приколочена к системе намертво, а в OpenSUSE по-умолчанию используется старый добрый sysvinit, а systemd предоставляется как вариант. Еще один пример - во все дистрибутивы включается ядро Linux :). И во всех дистрибутивах перед разработчиками встают такие вопросы - нужно ли использовать какие-то дополнительные патчи для него, типа bfs, или нет? Нужно ли предоставлять пользователям несколько вариантов «вкуса» (flavours) ядра, как делают OpenSUSE, Ubuntu и Mandriva или стоит обойтись одним универсальным вариантом? Другие примеры – это возможность выбора различных вариантов сетевых служб, имеющих аналогичный функционал (например, sendmail/postfix), Java-сред по умолчанию, вариантов рабочего стола, офисного пакета (Openoffice.org или Libreoffice), оконной среды - KDE/GNOME/XFCE/Openbox/WindowMaker и т.п.
    Принципы построения сообщества вокруг дистрибутива. Обычно это вопросы иерархии тех, кто дистрибутив разрабатывает: кто будет принимать технические решения, кто будет обладать правом арбитра при решении споров и правом вето, как будут приниматься пожелания. Не менее важно - как построена обратная связь с пользователями дистрибутива - только через систему отслеживания ошибок или нечто подобное OpenFATE в openSUSE, brainstorm в Ubuntu и GLEP в Gentoo. Важны вопросы приема в проект новых участников, условия этого вступления. В нормальных и серьезных проектах такие вещи определяются политиками и руководящими документами. Легкость нахождения этих документов и их полнота - отличный показатель серьезности проекта.
    Доступность документации для конкретного дистрибутива. Все серьезные проекты имеют не менее серьезные wiki-страницы. По уровню wiki и ее проработанности лидирует, на мой взгляд, wiki.archlinux.org, неплохие страницы документации у Gentoo и Ubuntu. Для администраторов Red Hat кладезь информации - сайт docs.redhat.com.
    Еще один показатель качества дистрибутива - это наличие на сайте с документацией правил сборки пакетов для него с обязательными требованиями по качеству их сборки. У дистрибутивов, относящих себя к серьезным проектам, всегда есть в свободном доступе скрипты для выполнения такой проверки (deblint для Debian/Ubuntu, rpmlint в Fedora/OpenSUSE, sisyphus_check в ALT Linux). Эти скрипты используются в сборочной системе для контроля качества собранного пакета. Уровень серьезности таких проверок варьируется от дистрибутива к дистрибутиву, например, OBS проверяет исходный код на наличие утечек памяти, а в Debian в репозиторий не попадет пакет без man-страницы.
    Тяжелый вопрос для каждого из проектов - вопрос инфраструктуры. У серьезного дистрибутива должен быть свой web-сайт, на котором размещаются основные документы, касающиеся дистрибутива, приема новых участников команды, сайт с документацией, формы для приема пожеланий по его развитию, и, конечно же, форум для общения и обмена мнениям. Помимо этого - сборочный сервер, сервер с репозиторием дистрибутива и репозиториями отдельных разработчиков. Инфраструктура никак не может быть виртуальной и требует для своей работы определенного количества денег. Крупным проектам технику обычно дарят, а список дарителей висит на веб-странице проекта в явном виде.

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


Возможно ли на основе данной информации сделать какой-то выбор? Не знаю, если честно. Вопрос выбора дистрибутива – это как вопрос выбора автомобиля (если опустить финансовую сторону дела): человек может долго обсуждать технические аспекты вопроса, а потом выберет себе тот, где пепельница на удобном месте :).

Выбор дистрибутива можно делать примерно так:
Допустим, нам нужен дистрибутив с красивым десктопом из коробки, обладающий хорошей стабильностью и огромным количеством софта. Скорее всего, это будет Ubuntu LTS.Нужен дистрибутив под базу данных Oracle. Тут выбор маленький, и с вероятностью 95% ими будут Red Hat Enterprise Linux или SUSE.
Нужен дистрибутив под LAMP-сервер – хороший выбор тут Debian или Ubuntu Server.
Нужен дистрибутив под какой-нибудь маршрутизатор – скорее всего, это будет опять Debian из-за огромного количества поддерживаемых архитектур.
Если вы опытный пользователь, любите экспериментировать с системой, ставить несколько версий одного ПО «на потестить», цените огромную гибкость системы, любите, чтоб все было по-вашему и готовы платить за это своим временем, – однозначный выбор Gentoo.


Естественно, что это все приблизительно и приведено для примерных схем выбора, а не для очередного холивара :). Приведенная статья не может охватить все дистрибутивы Linux и сразу рассказать про них все (в ней тогда будет «многабукав» и читать ее мало кто рискнет :) ). Но если у меня получилось дать некую базу для дальнейшего гугления интересующей информации по сайтам конкретных проектов, думаю, что я достиг поставленной цели.

Автор: Антон Чернышов

Источник: TuxThePinguin
"Свободен лишь тот, кто потерял все, ради чего стоит жить." Э. Ремарк

Оффлайн Voltmeter

  • Moderator
  • Hero Member
  • *****
  • Сообщений: 3547
Дистрибутивы Linux
« Ответ #2 : Суббота 9 Июля 2011 03:52:19 »
Дистрибутивы Linux

04 Июль, 2011

virens начинающим

Вопрос, будоражащий пытливые умы сомневающихся пользователей Windows: что такое дистрибутив линукс? Чем один дистрибутив отличается от другого? Вон их сколько! Зачем же так много дистрибутивов Linux? Ответ на этот важный вопрос есть и будет дан в этом посте.


Windows одна, и всем хватает - а зачем Линуксов так много?
Короткий ответ: потому, что линуксы разные - один лучше для серверов, другой - для десктопов.

Долгий ответ: вообще Linux - это только ядро операционной системы, а для полной системы нужно много чего ещё: загрузчик, системные утилиты и куча прикладных программ, вроде плееров музыки и редакторов текста. Каждый Линукс - комбинация всех этих программ и способов их установки, версий ядра, лицензионной политики и нескучных обоев. Именно эта комбинация и отличает Debian от Slackware, Gentoo от Ubuntu, и openSuSe от RedHat.

    Вот эти-то комбинации разных программ, соединённые в одно единое взаимосвязанное целое, как раз и называют дистрибутивами Linux.

Что такое дистрибутив - выяснили, теперь ответ на вопрос:


Чем отличается один дистрибутив от другого?

    десктопным окруженим, предустановленными программами и обоями "из коробки";
    пакетным менеджером для управления программами;
    широтой репозиториев пакетов программ;
    лицензионной политикой;
    регулярностью и качеством релизов.

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


Десктопное окружение и внешний вид "из коробки"
Собственно, это самое главное для пользователя - как это чудо будет выглядеть сразу после установки. Более того, один и тот же дистрибутив можно заставить выглядеть по-разному:
Ничто не мешает снести одно десктопное окружение и поставить другое. Более того, в каждом десктопном окружении есть свои особенные программы: например, в KDE текстовый редактор - Kate, в GNOME - gedit, в XFce - Mousepad. Но ничто не мешает использовать программы одной среды в другой, потому, что девиз Linux - настраивается ВСЁ! Заблудились в обилии настроек KDE? Попробуйте лаконичный GNOME. Хочется быстрой, отзывчивой среды с минимумом свистулек - поставьте XFce. Заворожены красотами Enlightenment17 - без проблем. Даже в консоли можно найти аналоги привычных программ и прекрасно работать.

Но дистрибутивы отличаются не только десктопными средами и программами, установленными "из коробки" - одно из главных отличий в том, как эти программы устанавливаются, и тут мы встречаем


Пакетный менеджер для управления программами
В дистрибутивах Linux, в отличие от Windows, вы никогда не увидите файлов типа setup.exe, которые устанавливают какие-то непонятные файлики DLL чёрт знает куда и которые потом нужно очищать всякими костылями. В линуксах программы устанавливаются, удаляются и обновляются централизованно, и отвечает за это специальная программа, которая называется пакетный менеджер.

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

Почему же это тогда называется пакетный менеджер, а не программный, спросите вы?

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

Системы управления пакетами и программы-пакетные менеджеры бывают разные:

    RPM [Redhat Package Manager] создана для RedHat-основанных дистрибутивов Linux. Пакетный менеджер, например yum или zypper, используется в RedHat Linux, а так же в Fedora, SuSe и других.

    APT [Advanced Package Tool] создана для дистрибутивов Linux, основанных на Debian GNU/Linux. Пакетный менеджер, например aptitude или dpkg, используется собственно Debian, а так же Ubuntu, Knoppix, Mepis и другими.

    Portage package management system имеет много разновидностей, примером может служить дистрибутив Gentoo. Как вариант пакетного менеджера можно привести emerge.

Пакетные менеджеры не просто ищут желаемые вами программы по описаниям. Вот вы ткнули мышкой в программу и нажали кнопку установить, а она спрашивает вас про какие-то зависимости. Что это такое?


Зависимости в пакетах
В пакете содержится не только исполнимая программа, библиотека или обоина на рабочий стол, но также и требования того, какие программы или библиотеки (в Windows это называют DLL-файлы) нужны для её работы. Например, если вы работаете в десктопной среде GNOME и вам приглянулся текстовый редактор Kate из KDE, при попытке его установить пакетный менеджер попросит поставить кучу зависимостей - библиотек KDE. Это будет сделано за вас, автоматически, и никакого мусора в системе не будет - всё под контролем пакетного менеджера.

    А почему в линуксах всё так сложно, а в Windows этого нет и все живы? Потому, что в Windows каждая крупная программа ставит вместе с собой свои версии библиотек. Это спорное, если не сказать жёстче, решение. Так как в Windows менеджера пакетов нет, обновить программу получится только сносом старой и установкой новой версии. Обновить такую систему целиком без переустановки программ, понятное дело, не получается. Для пользователя оно вроде как проще - ткнул setup.exe и готово. Программистам из Микрософта тоже напрягаться не надо. Сложно будет потом, когда захочется обновиться до следующей версии Windows...

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

    Но если вам захочется, не трогая дистрибутив, поставить распоследнюю версию программы, могут возникнуть сложности. Например, в Debian версии 5.0 просмотрщик PDF это kpdf, и мне захотелось его обновить из следующей версии, Debian 6.0. Пакетный менеджер, просмотрев зависимости, радостно доложил: в новой версии kpdf нет, но есть okular, и он зависит от новых библиотек, и текущие нужно обновлять. Кроме того, старые программы с новыми библиотеками работать не будут, так что нужно обновлять и их. А вместе и другие программы. И графическую оболочку. Ну и загрузчик заодно. И всё из-за одного мелкого бубенчика...

Конечно, в 99% случаев всё кончится хорошо и программа (часто вместе с куском системы) обновится без осложнений. Просто обновлять много всего из-за мелкой программы не всегда есть время, желание и возможности.

Вся эта огромная куча пакетов с их ворохом зависимостей друг от друга, управляемая пакетным менеджером, как раз и составляет ваш дистрибутив Linux. Но это не просто куча мусора, а упорядоченная система, которая называется


Репозитории пакетов программ
Все программы в дистрибутивах Linux - отдельные проекты, развивающиеся сами по себе. Как вы уже поняли, прочитав про зависимости в пакетах, собрать все эти программы, с их зависящими друг от друга библиотеками вместе и чтобы всё работало - дело очень сложное.

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

    Собрать программу в пакет можно и самому, и это, при некотором понимании процесса, не очень сложное дело - если вы не пытаетесь собрать что-то большое, вроде KDE, GNOME или LibreOffice. Тем не менее, для этого потребуется использовать компилятор и иметь хотя бы отдалённое понятие о программировании.

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

    Репозиторий это все файлы пакетов, принадлежащие одному дистрибутиву (например, Debian) одной его версии (например 5.0).

ISO-файлы образов для пропаливания на болванку содержат как раз репозитории пакетов со всеми зависимостями и менеджером пакетов плюс установочную программу, которая разметит жёсткий диск, всё поставит и приготовит вам десктоп (или сервер, или что попросите).

    ВАЖНО! Пожалуйста, не поддавайтесь искушению ставить программы в Linux в обход менеджера пакетов, простой компиляцией. Работать они будут, но пакетный менеджер ничего о них не будет знать. При обновлении системы или программ вы рискуете получить больше проблем на свою голову, чем представляете. Устанавливайте программы ТОЛЬКО в виде пакетов.

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


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

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

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

    Сравнение с автомобилем: проприетарное программное обеспечение
    Чтобы представить себе проприетарщину в полный рост, вообразите, что некая корпорация МикроАвто, выдавив нечестной конкуретной борьбой всех соперников, является монополистом на рынке автомобилей. Купить машину можно только марки МикроАвто, и заправки в городе только МикроАвто - рецепт топлива держится в секрете.
    При этом, когда вы покупаете автомобиль, вас просят подписать лицензионное соглашение, в котором на автомобиль не даётся никаких гарантий вообще. То есть они не гарантируют, что тормоза работают, двигатель не взорвётся, а руль не отвалится. При этом вам запрещено открывать капот, давать покататься на машине другому человеку и перевозить более 1 пассажира (хотя мест 5).

Долгое время альтернатив не было - попробуйте построить заправку для автомобиля, если состав топлива неизвестен, а за попытку это выяснить можно оказаться в суде!

Именно из-за подобной зверской лицензионной политики и появилось движение за Свободное Программное обеспечение. Были созданы другие лицензии, например, GNU GPL, которые позволяют копировать, распространять и изменять открытые программы. В свободном программном обеспечении:

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

Некоторые дистрибутивы, например Debian GNU/Linux, очень тщательно следят за тем, какие программы включаются в состав дистрибутива - они не хотят иметь дело с несвободными программами во избежание лицензионных проблем. Поэтому в Debian, например, будет Iceweasel а не Mozilla Firefox, LibreOffice а не OpenOffice.

Когда все лицензионные вопросы утрясутся, репозитории будет более или менее готовы - разработчики соберут дистрибутив, налепят на него версию, обзовут как-нибудь по-хитрому (типа Ubuntu "Свободомыслящий Сурикат"), и выложат для скачивания и обновлений. И это долгожданное событие называется


Релиз!
Ещё одно отличие дистрибутивов - способ релизов. Релизы бывают фиксированные (с определённой периодичностью, как в Ubuntu, или "когда будет готово", как в Debian) и скользящие (rolling-release, обновляется постепенно - когда обновите систему, тогда для вас релиз и произойдёт). Каждый вид релизов имеет свои сильные стороны:

    Дистрибутивы со скользящим релизом (rolling release), например Arch и Gentoo. В таких дистрибутивах программы попадают в репозиторий обычно после короткого периода тестирования, поэтому главное преимущество здесь - свежесть программ. Это важно, так как изменения в программах под Linux могут происходить очень быстро, и буквально за полгода программа может обрасти нужными вам функциями. Недостаток - как правило, меньшая подогнанность программ друг к другу и наличие ошибок из-за малого тестирования.
    Дистрибутивы с фиксированным релизом, например Debian и Ubuntu. Программы, предназначающиеся для релиза, проходят долгий путь тестирования, обкатки и вылавливания ошибок. Главное преимущество поэтому - высокая стабильность, надёжность и подогнанность программ друг к другу. Естественно, что программы в таких дистрибутивах не могут быть самыми свежими, поэтому и недостаток - программы довольно старые, особенно по меркам скользящих релизов.

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


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

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

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

Удачи!

Источник: MyDebianBlog
"Свободен лишь тот, кто потерял все, ради чего стоит жить." Э. Ремарк

Оффлайн torvaldus

  • Sr. Member
  • ****
  • Сообщений: 301
Re: Из чего состоят дистрибутивы Linux
« Ответ #3 : Суббота 16 Июля 2011 01:35:01 »
Огромное спасибо Вольтметру и Бибуху!

Остался только непонятным вопрос, что тут делает бездельник Фокс?
Нафиг тут маркетологи и менеджеры по продажам?
 :dirol:

 

Rating@Mail.ru
Portal Management Extension PortaMx v0.980 | PortaMx © 2008-2010 by PortaMx corp.
Яндекс.Метрика