Менеджеры пакетов в Linux

Установка ПО (или пакетов) в дистрибутивах Linux происходит «централизованно», что удобно, но часто вызывает вопросы у новичков. И так, максимально доходчиво я постараюсь объяснить, почему всё не так как в Windows и зачем знать базовые команды консольного менеджера пакетов, если в любом современном дистрибутиве есть графический интерфейс.Если вы интересуетесь темой Linux, то знаете о существовании множества дистрибутивов и о том, что нередко они несовместимы между собой. Точнее, готовые пакеты одного дистрибутива несовместимы с другими дистрибутивами, особенно если это не производные друг от друг дистрибутивы. Поэтому у каждого дистрибутива есть свои репозитории готовых пакетов, собранных исключительно под конкретный дистрибутив. Из этих репозиториев пакетный менеджер и берёт пакеты. Но это не единственная и далеко не основная причина того, что пакеты для Linux систем распространяются таким образом. При установке той или иной программы через пакетный менеджер видно, что вместе с пакетом самой программы, в систему устанавливается ещё куча всяких пакетов. Чем сложнее программа и чем «чище» ваша система, тем больше пакетов устанавливается в качестве «зависимостей». Зависимости – это системные библиотеки, а иногда и другие программы, необходимые для работы устанавливаемой программы. Каждый пакет в репозитории содержит файл-манифест, в котором указаны все зависимости. В Windows также, некоторые упакованные программы требуют наличия определённых компонентов в системе. Например, для игр необходимо наличие библиотек DirectX в каталоге «system32» и так далее. Это те же зависимости. Установщик программы видит их наличие и сообщит вам о их отсутствии, если не найдёт соответствующую запись в реестре. На самом деле, в Windows программы часто просто не запускаются или вылетают с ошибкой, но причина именно в отсутствии того или иного компонента. В Linux же пакет просто не будет установлен, если нет возможности соблюсти все зависимости. Разбором зависимостей и занимается пакетный менеджер. В идеале в репозиториях дистрибутива есть всё необходимое для соблюдения всех зависимостей всех пакетов. В этом заключается опасность использования сторонних репозиториев. Если информация о зависимостях в них устарела, или содержит ошибки, то использование пакетов из таких репозиториев может вызвать проблемы той или иной сложности. Имена пакетов, системных библиотек и их версии в разных дистрибутивах отличаются. Поэтому невозможно без плясок с бубном взять пакет из Ubuntu и установить его в OpenSUSE. Теоретически это можно сделать, пересобрав пакет и установив нужные зависимости, но такой пакет не будет обновляться, даже если не вызовет других проблем. Всегда нужно устанавливать пакеты именно для вашего дистрибутива и к другим способам прибегать только в случае крайней необходимости. Если ваш дистрибутив не содержит всего того, что вам нужно, то это серьёзный повод для смены дистрибутива. Существует несколько пакетных менеджеров со своими плюсами и минусами, а также сам подход к зависимостям у большинства дистрибутив отличается. Кроме пакетов с ПО, существуют так называемые «мета-пакеты», которые содержат только инструкции по зависимостям. Мета-пакеты используются для установки комплексных решений в один клик. Например, мета-пакеты рабочих столов, когда установкой одного мета-пакета можно установить окружение рабочего стола и кучу прикладного ПО. Та же ситуация и с удалением. Рано или поздно вы захотите удалить неиспользуемое ПО, входящее в состав дистрибутива. И, в зависимости от дистрибутива, можете обнаружить, что удаление почтовой программы удаляет также мета-пакет рабочего стола, что помечает половину пакетов в вашей системе как «ненужные». Пакеты, установленные как зависимости, могут быть безболезненно удалены как в процессе удаления основного пакета, так и после. Беда в том, что мета-пакет рабочего стола был указан как жёсткая зависимость почтовой программы. Имеется в виду, что без рабочего стола она работать не будет. Но не учитывается, что рабочий стол без почтовой программы может работать без каких-либо проблем. В итоге, после невнимательного удаления чего-либо действительно ненужного, можно обнаружить, что система стала легче гигабайт на 5, но при этом загружается в чёрный экран и командную строку. Такой подход к зависимостям свойственен, например, Ubuntu, тогда как пакетный менеджер в Arch Linux помечает подобные зависимости как «необязательные», что избавляет пользователя от проблем, приведённых в пример выше, но требует от него определённых знаний. То есть, если утрировать, то рабочий стол без почтовой программы работает, но кому-то может понадобиться её функционал. Таким образом, пользователь должен знать какие необязательные зависимости ему нужны, а какие нет. Большинство же дистрибутивов решают это за пользователя, имея в зависимостях того или иного пакета максимальный набор компонентов «на все случаи жизни». Другими словами, чем меньше знаний требуется для использования дистрибутива, тем больше в нём «мусора». И чем больше опыта у пользователя, тем сложнее его «настольный» дистрибутив. По той же причине в мире существует огромное количество различных дистрибутивов, ориентированных на различную аудиторию. Но не всегда широта возможностей прямо пропорциональна сложности. Исторически так сложилось, что большая часть пакетов в Linux зависит от наличия системных библиотек. По аналогии с директорией «system32» в Windows, в Linux есть директория «lib». Такой подход экономит место, когда одна и та же системная библиотека используется множеством программ, но он же делает пакеты одного дистрибутива непригодным для установки в другой. Кроме имён системных библиотек отличаются так же их версии, в зависимости от дистрибутива. Во многих пакетах в качестве зависимостей указаны не только сами библиотеки, но и их версии. По той же причине многие дистрибутивы не обновляют версии ПО в пределах жизненного цикла версии дистрибутива. Например, в Debian вы будете получать обновления безопасности, но версии практически всего ПО останутся неизменными. Таким образом ряд дистрибутивов поддерживает стабильность. Тот же подход можно видеть в корпоративных версиях Windows, когда весь функционал заморожен в пределах одной версии, и обновления содержат только исправления и патчи безопасности. Но в Windows это касается только компонентов ОС, тогда как всё остальное устанавливается и обновляется отдельно. В Linux же всё прикладное ПО распространяется централизованно, как и компоненты ОС. Теоретически новая версия определённой программы будет работать с текущей версией определённой системной библиотеки, так же, как и текущая версия программы с более новой библиотекой, но это не тестировалось на пререлизных стадиях дистрибутива. Всегда есть шанс, что что-то пойдёт не так. Поэтому в ряде дистрибутивов есть стадия так называемой «заморозки», когда перед релизом все версии ПО замораживаются и остаются неизменными на протяжении всего жизненного цикла версии дистрибутива. Такой подход даёт свои результаты. Если не использовать сомнительные сторонние репозитории в Debian, то она гораздо стабильнее даже корпоративных версий Windows. Некоторые дистрибутивы могут сочетать в себе стабильность и инновации. То есть, они устанавливают рань между новизной ПО и его стабильностью на более приемлемой для широкого круга пользователей позиции. Роллинг-дистрибутивы так же могут быть стабильными, если разработчики и тестировщики приложили к этому достаточно усилий.Понятно, что «пакетно-зависимый» подход не всегда оправдывает себя. Попытки унификации пакетов ПО для Linux были всегда. Две самые удачные и современные системы – это Snap от Canonical и Flatpak, которая разрабатывается сообществом. Обе системы не идеальны, но позволяют решить две самые основные задачи: унификация и интеграция. В отличии от более ранних реализаций, установленное таким образом ПО смотрится нативно и интегрировано в систему (ОС знает, что оно установлено, присутствуют все привычные меню, ярлыки и прочее). Основным плюсом является то, что подобный пакет содержит все необходимые зависимости и работает на любом дистрибутиве, способом работать с этой системой пакетов. Разработчикам не нужно разбирать зависимости каждого дистрибутива при создании пакета. Нужно лишь учитывать специфику самой системы Snap или Flatpak. А то, как система в целом работает в дистрибутиве – это дело разработчиков дистрибутива. Как уже было сказано, Snap и Flatpak не идеальны. По ряду причин ПО не всегда выглядит нативно и не всегда учитывается всё возможное. Это зависит как от самих этих систем, так и от интеграции системы на стороне дистрибутива. Но обе системы развиваются и, на мой взгляд, это шаг в правильном направлении, хотя обе системы часто критикуются. В основном критика относится к проприетарной природе серверной части Snap и тому факту, что в Ubuntu, при установке ПО через графический интерфейс, приоритет отдаётся пакетам Snap. Так же критикуется «Windows-подход» при распространении ПО подобным способом. Последнее относится, в основном, к размеру и нагрузке. Размер этих пакетов значительно выше традиционных пакетов, так как каждый пакет содержит все необходимые зависимости локально, и их наличие или отсутствие в системе во внимание не берётся. Но при объёмах современных носителей информации лишний десяток гигабайт менее важен, чем унификация пакетов в Linux.Для управления пакетами Snap и Flatpak используются их собственные пакетные менеджеры, но многие «традиционные» пакетные менеджеры имеют плагины для работы с этими пакетами. И так, если с зависимостями и различиями в дистрибутивах всё более или менее ясно, то при чём тут командная строка? Дело всё в той же централизованной системе. При обновлении пакетов, в системе часто обновляются и компоненты рабочего стола, и сам пакетный менеджер. Чем меньше компонентов задействовано в процессе обновления, тем меньше шансов на то, что что-то пойдёт не так. Графический интерфейс для всех пакетных менеджеров – это всего лишь «надстройка». Если установка и удаление пакетов обычно проходит гладко, то при использовании консоли у вас больше возможностей решить ту, или иную проблему, возникшую во время обновления. Особенно это актуально в роллинг-дистрибутивах, где со временем обновляется не только само ПО, но и список его зависимостей. Графический интерфейс может повиснуть при обновлении его компонентов, консоль же менее зависит от окружения рабочего стола, даже если является его частью. Не важно как вы обновляете Snap-пакеты или Flatpak-пакеты, так как они не затрагивают систему, но в остальных случаях обновляться через консоль безопаснее. В Сети часто можно найти инструкции по сборке того или иного из исходного кода и последующей установке (команда make install), но это плохая идея в пакетных дистрибутивах, где пакетный менеджер – основной и часто единственный инструмент контроля и управления программным обеспечением. Даже в Gentoo, где всё собирается из исходников, есть свои инструменты контроля. В пакетных же дистрибутивах правильным будет собрать пакет и установить его с помощью пакетного менеджера. Исключение можно сделать для чего-то локального, установленного в один отдельный каталог с правами пользователя. Ручное «размазывание» библиотек по системным разделам – плохая идея, так как рано или поздно возникнут проблемы.И так, резюмируя всё вышесказанное… Пакетные менеджеры в Linux существуют не только для удобства. Они ведут учёт ПО и обеспечивают правильность его установки, от чего зависит стабильность работы как самого ПО, так и операционной системы в целом. Установка ПО другими способами возможна, но с рядом оговорок. На самом деле, подобный подход кажется странным только тем, кто много лет просидел на Windows. В Windows так же есть эксперименты с пакетными менеджерами, но проприетарная модель как самой ОС, так и большей части программ под неё, не позволяет добиться той же слаженности, что мы видим в операционных системах на ядре Linux.

Go to Source
Author: Tatyana

Linux

Данный материал ориентирован на тех, кто ничего не знает о Linux, но заинтересовался этой темой. Я постараюсь максимально доходчиво объяснить некоторые нюансы, ответить на самые распространённые вопросы и развенчать некоторые мифы, связанные с Linux. Первое, что нужно знать любому, кто заинтересовался этой темой: Linux – это не операционная система. Это ядро. Операционная система – это готовая платформа, набор компонентов, позволяющий включить компьютер и тут же начать им пользоваться. Windows – операционная система. Для определённых задач вам понадобится определённое ПО, но ОС уже знает как его установить, как интерпретировать запросы, в ней уже есть всё необходимое. Ядро же – это что-то вроде основы. Все основные компоненты ОС взаимодействуют с ядром. Драйверы, интерпретаторы и всё то, о чём обычный пользователь мог и не слышать – всё это взаимодействует с ядром любой операционной системы. Скорее всего вы уже пользовались Linux и делали это чаще, чем вам кажется. Большинство периферийных устройств давно работают на Linux. Навигатор в вашей машине, роутер у вас дома, смартфон на Android у вас в кармане – всё это Linux, в подавляющем большинстве случаев. То, что Linux можно обнаружить на самых различных устройствах, связано, в первую очередь с тем, что Linux распространяется под свободной лицензией. У меня уже был материал, посвящённый разнице между «свободным» и «несвободным» ПО, поэтому сейчас мы эту тему развивать не будем. Первую версию Linux в 1991-ом году опубликовал финский разработчик Линус Торвальдс. Возникновение Linux в том или ином виде, было продиктовано временем. Компьютерные технологии развивались стремительно, но существующие проприетарные решения не могли удовлетворить все потребности. Рынком владели корпорации. По словам самого автора, он хотел написать свободную альтернативу Unix для личного использования. Но идея создания свободной операционной системы, которую каждый бы мог использовать без каких-либо значимых ограничений и финансовых затрат, со временем взяла верх. В то время, если разработчик хотел написать программу под определённую ОС, ему нужно было купить лицензию и/или оплатить доступ к API, что было проблемой. Не каждая программа способна окупить себя в будущем, да и цели такие перед собой ставят не все разработчики. В случае с проприетарным ПО и по сей день ситуация изменилась не сильно. Например, если некто хочет написать простенькое приложение под Xbox, то в самой консоли необходимо активировать «режим разработчика», что обойдётся в двадцать баксов. Не заоблачно, но, видимо, в Microsoft рассудили, что при жёсткой конкуренции и «с паршивой овцы хоть шерсти клок». Написание полноценной операционной системы – задача, мягко говоря, амбициозная. Особенно для одиночки. Но Линус Торвальдс был не одинок в своём стремлении создать открытую ОС. Поколение хиппи дало миру не только Стива Джобса с его ненавистью к IBM. На заре эры ПК были и более бородатые дяди, с более радикальными взглядами. Одного из них звали Ричард Столман. На момент выхода первой версии Linux, анархисты из проекта GNU уже имели множество прикладного ПО, но у них не было ядра. GNU и Linux дополнили друг друга. В том же 1991-ом году стали появляться первые дистрибутивы «GNU/Linux», включающие в себя ядро Linux и прикладное ПО из проекта GNU. «Дистрибутив» в данном случае – это ОС. Не все программы в современных дистрибутивах относятся к проекту GNU, но когда речь идёт именно о десктопной операционной системе, то правильно называть её «GNU/Linux». Операционные системы на ядре Linux (или дистрибутивы Linux) разрабатываются как компаниями (Ubuntu, Red Hat Enterprise Linux и так далее), так и сообществом энтузиастов (Debian, Arch Linux и прочие), но все они публикуют исходный код. Любой может внести свои изменения и если они будут приняты лидирующими разработчиками, то появятся в последующих релизах. Нередко от одних дистрибутивов ответвляются другие. Такие «форки» часто привносят что-то своё и ориентированы несколько на другую аудиторию, нежели их прародители. На сегодня существует множество различных дистрибутивов, нацеленных на разную аудиторию и придерживающихся определённых принципов. Часть из них продвигает свободное ПО как идею, другие же стремятся предоставить пользователю максимально широкий перечень возможностей. Есть также дистрибутивы для определённых целей, делающие упор на что-то одно. Например, дистрибутивы для работы с мультимедиа, дистрибутивы для диагностики, или дистрибутивы, ставящие во главу угла анонимность. При выборе дистрибутива, в первую очередь нужно руководствоваться причиной. Самая распространённая ошибка, это когда пользователь сам не знает, что он хочет. Просидел некто 20 лет на Windows и ищет тот же Windows, но чтобы это был Linux. Некоторые дистрибутивы позиционируют себя как «дружественные для новичков», переходящих с Windows. На самом деле, это плохая идея. Они с первого же момента знакомства пользователя с Linux, вводят его в заблуждение. Если пользователю нужен Windows, то идеальным для него вариантом будет Windows, а не Linux, внешне очень похожий на Windows. Чтобы быть дружественным к пользователю, не нужно что-то копировать. Достаточно просто иметь широкие возможности, хорошую документацию и дружелюбное сообщество. Когда пользователь, не знакомый с Linux, получает нечто, выглядящее как Windows, то он и ждёт от этого дистрибутива того же, к чему привык в Windows. Кроме внешнего вида, в такие дистрибутивы обычно вшит Wine (свободная реализация Win32 API) и они даже умеют запускать простенькие Windows-приложения «из коробки». Но Wine – это не Windows. Из-за проприетарной природы Win32 API, в Wine реализовано только то, что задокументировано Microsoft и то, что можно было воспроизвести путём обратного инжиниринга, не нарушая патентов и законов об авторском праве. Если программа использует не задокументированные свойства Win32 API, то она либо вообще не будет работать под Wine, либо будет работать с серьёзными ошибками. Другими словами, Linux – это не Windows. И ждать от ОС на ядре Linux полной совместимости с программами под Windows не следует. Это то же самое, что жаловаться в Microsoft на то, что в Windows не работают программы, написанные под Mac. Хотя, если последнее невозможно в принципе, то при определённых навыках можно играть во многие современные Windows игры на компьютерах с GNU/Linux. Но всё же, это абсолютно разные операционные системы. У Linux гораздо больше общего с MacOS, чем с Windows, так как и Linux и MacOS – это «юниксоподобные» операционные системы. Но даже при похожей структуре, нельзя запустить программу из Linux на Mac и наоборот. Мало того, не всегда просто запустить приложение для одного дистрибутива на другом. Но в Linux можно добиться внешнего вида как Windows, так и MacOS (на скриншотах в этом абзаце дистрибутивы Linux, а не другие операционные системы). На что и ведутся те, кто ждут от Linux чудес. В Википедии есть забавная картинка, иллюстрирующая «генеалогическое древо» всех дистрибутивов, и она оставляет неизгладимое впечатление на тех, кто пытается выбрать свой первый дистрибутив. Но на самом деле, кардинально друг от друга отличаются лишь узко направленные дистрибутивы или дистрибутивы для различных устройств. Например, нельзя без эмуляции на Ubuntu запустить приложение из Google Play, хотя и в Android и в Ubuntu используется ядро Linux. Так же стоит понимать, что львиная доля дистрибутивов – форки от общего предка. Например, Ubuntu – форк от Debian, Linux Mint – форк от Ubuntu и так далее. «Корневых», ныне живущих дистрибутивов не так много. Это Slackware, Red Hat Enterprise Linux, S.U.S.E, Debian, Arch Linux, Gentoo. Это дистрибутивы, от которых произошли все настольные дистрибутивы широкого профиля, и разобравшись в предке, вы сможете разобраться в производных. Также, если вы освоите качественный форк, то разобраться в материнском дистрибутиве тоже будет легко, за редкими исключениями. Например, знания в Android вам вряд ли помогут при работе с Gentoo, но умение обращаться с Linux Mint сильно облегчит работу с серверной Debian. Теперь о самых распространённых мифах. «Linux нестабилен и часто глючит». Это не так. Более 90% всего Интернета работает на Linux. От серверов гигантов типа Google, до домашних роутеров. Интернет был бы невозможен без стабильности решений на Linux. Интернет многим был бы не по карману без свободного ПО в целом, львиная доля из которого – решения на Linux. Но действительно, существует много косых дистрибутив. Глючит, как правило, плохо отлаженное прикладное ПО в таких дистрибутивах. Это всевозможные «как Windows» дистрибутивы и дистрибутивы «одного разработчика», которые «глюк в глюк» повторяют родительский дистрибутив, но при этом нагружены неотлаженным прикладным ПО. Если правильно подобрать дистрибутив, то стабильность будет выше, чем в любой существующей проприетарной ОС. Глюки в проприетарной ОС исправляют годами (Windows 10 вам в пример). Если вы пользуетесь хорошо поддерживаемым дистрибутивом, то исправления придут практически сразу, как наличие проблемы будет подтверждено, что происходит быстро из-за большого числа вовлеченных в разработку людей. «Под Linux мало программ». Это тоже не так. Их не меньше, чем под Windows, но они часто доступнее. Нередко бывает так, что аналог в Windows стоит несколько сотен долларов, а в Linux такая программа бесплатна. Хотя абсолютной халявы нет нигде. Например, Google Chrome под Linux и под Windows выпускает одна компания. Естественно, что пользователь этого браузера одинаково комфортно будет себя чувствовать как в Windows, так и в Linux. Но Adobe не выпускает Photoshop под Linux, и пользователю придётся искать аналог. Ближайший аналог, в данном случае – Gimp. И он попьёт немало крови, если подойти к нему с уверенностью, что он должен быть клоном Photoshop. Это две разные программы, предназначенные для решения схожих задач. Для Linux существует множество как бесплатных, так и платных программ, но немалая их часть не знакома пользователям других ОС. «В Linux всё нужно делать с командной строкой». Это было актуально 30 лет назад, когда в Linux не было графического интерфейса. После появления X.Org, в 2004-ом году, программы стали обрастать графическими интерфейсами, и Linux дистрибутивы стали выглядеть как любая другая настольная ОС. Вы можете выучить пару базовых команд и обходиться ими, а можете обойтись вообще без консоли. Во всех современных дистрибутивах широкого профиля консоль – инструмент опциональный. Но умение пользоваться консолью значительно облегчает жизнь при отладке и решении рутинных задач, таких как обновление, редактирование системных файлов и так далее. Тоже самое касается любой другой ОС. В Windows тоже командная строка – мощный и быстрый инструмент с более широкими возможностями, чем любой графический интерфейс, если грамотно ею пользоваться. «В Linux почти нет игр, а те, что есть, выглядят как из прошлого века». На сегодня это утверждение близко к истине, но не в том плане, в каком многие привыкли считать. Игры – сугубо развлекательное ПО. Производство качественной игры стоит больших денег, а аудитория Linux достаточно мала. Абсолютное большинство коммерческих игр на Linux – это порты с других платформ. Качественное портирование игры также требует большой работы и финансовых затрат. Это окупается при портировании игр с консолей на Windows, но не оправдывает себя в случае с Linux. Даже самый качественный порт под один дистрибутив, может странно вести себя на другом. Эту проблему пытается решить компания Valve, но с переменным успехом. На сегодня в Steam доступно огромное количество игр под Linux. Несоизмеримо больше, чем лет десять назад, но часть из них не работает на Linux нативно. Связано это с тем, что традиционно пакеты ПО в Linux не содержат всё необходимое для работы. Часть библиотек находится в системе. К ним и обращаются программы. Если игра старая, то версии системных библиотек, прописанных в игре как зависимости, давно устарели. Либо вообще заменены на другие на стороне дистрибутива. И речь не идёт о десятках лет. ПО в Linux безнадёжно устаревает за пару лет. В Steam под Linux есть набор универсальных библиотек (Steam Runtime), но из-за серьёзных различий в некоторых дистрибутивах, работает это не всегда. Система Proton (пропатченный Wine) позволяет запускать достаточно много игр в Linux, написанных под Windows, но большая их часть поддерживается неофициально, а значит никто не даст вам гарантию, что завтра оно не перестанет работать. То есть, проблема не в Linux ( под Android существует великое множество игр), проблема в разнообразии дистрибутивов. А так же в замкнутом круге, где корпорации не вкладывают деньги в нативные игры под Linux, объясняя это низким спросом. От этого спрос ещё ниже, так как многих именно игры держат на Windows. Нередко на ПК используется двойная загрузка, когда Windows используется исключительно для игр, а для всего остального пользователь перезагружается в Linux. Такая ситуация устраивает всех, кроме пользователей. Другими словами, если вам нужна игровая ОС, то это Windows. Либо можно использовать двойную загрузку. Либо приготовьтесь к тесному знакомству с Wine, что требует терпения и ментальной стабильности в стрессовых ситуациях, но не гарантирует вам запуск всей вашей библиотеки игр. Другими словами, игр в Linux великое множество, но мало качественных нативных игр. Эмуляция в Linux потребляет меньше ресурсов и при правильной настройке работает быстрее, чем в Windows. То есть, старые игры под DOS и консоли поколений 8 – 128 bit будут работать лучше, чем в Windows. Wine же поможет запустить многие игры, написанные под Windows. Нередко с более высокой производительностью. Например, на моём старом ПК с AMD FX8350 ремейк Resident Evil 2 работает идеально под Linux, но периодически сваливается в 20-30 fps под Windows. И так, чем нужно руководствоваться при выборе дистрибутива в первую очередь? Если вам нужна настольная ОС «на каждый день», то многие советуют начать с чего-нибудь «попроще» и с того, где вам проще получить помощь. Есть Ubuntu – один из самых популярных дистрибутивов. Он имеет огромную базу совместимого ПО, и большая часть инструкций в Интернете посвящена именно Ubuntu, или её производным. Я же рискну с этим поспорить. Популярность в мире Linux – понятие относительное. Никто не скажет вам сколько именно пользователей того или иного дистрибутива в мире, так как почти никто не продаёт на них лицензии. Относительно точное количество пользователей Windows можно посчитать по количеству активации, в Linux же даже user-agent браузера очень редко показывает имя дистрибутива. Никто не спорит с тем, что Ubuntu и производные занимают значительную часть всех Linux дистрибутив, но стабильность – это более сложная тема. Пакеты в Ubuntu попадают из нестабильного репозитория Debian. И называется он «нестабильным» не просто так. Отладка и тестирование пакетов требует огромной работы. К сожалению, в Ubuntu вся отладка часто происходит после релиза. Видимо это проклятие всех корпораций, независимо от продукта. И текущий дистрибутив Ubuntu становится стабильным ближе к сроку выхода следующего. Именно поэтому у Ubuntu так много форков. Каждый позиционирует себя более стабильным, чем родитель. Однако нередко они баг в баг повторяют Ubuntu, когда это касается внутренних процессов. Не всё так плохо с Ubuntu и часто дистрибутив стабилен, но до тех пор, пока вы не попытались что-либо в нем переделать. Для решения определённых задач нередко приходится подключать сторонние репозитории, что-то удалять и что-то устанавливать. И нередко после манипуляций с ядром, его модулями, или с рабочим столом, Ubuntu перестаёт загружаться. И такое можно сказать о многих дистрибутивах. Вместо того, чтобы навязывать тот или иной дистрибутив, я попробую объяснить нюансы работы некоторых. Я буду брать в пример «материнские» дистрибутивы, перечисленные выше, так как все их производные работают по тому же принципу. Все популярные дистрибутивы – пакетные, кроме Gentoo. Что это значит? ПО в них устанавливается в виде готовых пакетов. Пакет – это, по сути, zip-архив со скомпилированной именно под ваш дистрибутив программой. Пакеты хранятся в так называемых репозиториях. То есть для установки того или иного пакета вам нужно либо ввести специальную команду в терминал, либо воспользоваться графическим интерфейсом. Выглядит это как установка приложений в Android. Вы ищите нужную программу, кликаете кнопку «установить», и она устанавливается со всеми другими, необходимыми для её работы пакетами. Этим занимается «пакетный менеджер», который в современных дистрибутивах имеет графический интерфейс, работающий поверх консольной программы. С его же помощью происходит и удаление программ. Кроме основных репозиториев, существуют также «сторонние». Их часто создают разработчики того, или иного ПО. Например, для установки Google Chrome в Ubuntu нужно добавить отдельный репозиторий, так как в основных репозиториях практически всех дистрибутив нет проприетарных программ. Звучит сложно, но происходит всё в один клик. Так же, с помощью пакетного менеджера происходит обновление установленного ПО. Централизованно, в один клик, или одну команду в терминале. Упомянутый выше Gentoo – худший вариант для новичка. Даже если у вас получится его установить, то работа с ним покажется адом не только пользователям Windows, но даже адептам Ubuntu. Установка ПО в нём происходит путём сборки каждого компонента из исходного кода. Вам нужно не только уметь собирать бинарники из исходного кода, но и знать, что от чего зависит. Это тоже не так ужасно, как звучит, так как в Gentoo есть инструменты для облегчения и частичной автоматизации процесса, но для новичка в Linux, задача непосильная. Плюсом подхода Gentoo является низкое потребление ресурсов. Программы собираются не только под ваш дистрибутив, но непосредственно под ваш ПК и под ваши нужды. Например, если у вас CPU и GPU от Intel, то поддержки nVidia и AMD не будет даже на уровне ядра, что значительно сократит размер установленного ПО и увеличит скорость его работы, путём удаления бесполезного для вашей машины кода. Что в свою очередь выльется в целую эпопею, если вы решите модифицировать или обновить свой ПК. Так же есть мнение, что если вы освоили Gentoo, то, не краснея, можете называть себя специалистом в Linux. Справедливости ради надо заметить, что пакетные дистрибутивы просто удобнее, а сборку персонального ядра и прикладного ПО можно освоить и в них. Кроме того, можно освоить сборку пакетов под ваш дистрибутив и стать участником проекта по его поддержке, если процесс вас зацепит. Кроме «странной», для пользователей Windows, системы управления пакетами, в дистрибутивах отличается цикл их разработки. Например, новая версия Debian выходит каждые два года. С тем же циклом Canonical выпускает «стабильные» версии Ubuntu. Так называемые «версии с долгосрочной поддержкой» или TLS. Такие версии поддерживаются на протяжении пяти лет и в конце своего срока становятся действительно стабильными, в полном смысле этого слова. «Стандартные» версии Ubuntu выходят каждые 6 месяцев и тоже позиционируются как стабильные, но по сути, это пререлизные бета-версии того, что потом станет TLS-релизом. Срок жизни таких версий 9 месяцев. По истечении этого срока дистрибутив перестаёт получать обновления, даже критические. Стоит иметь ввиду, что обновление старой версии дистрибутива на новую – это всегда геморрой. Разница лишь в степени, что зависит от дистрибутива и того, на сколько и как вы изменили его состав за время использования. Возможно вам удастся обновить одну TLS-версию Ubuntu на следующую (но не через одну), если вы вообще никак не трогали его системные компоненты в процессе использования, и только устанавливали критические обновления. Но чаще всего предпринятые усилия не стоят конечного результата. Самым простым способом обновления является переустановка дистрибутива. Если вы установили его правильно (систему в один раздел накопителя, а пользовательскую часть «home» в другой), то сможете даже сохранить все данные и настройки программ. Это займёт меньше времени, чем обновление с одной версии дистрибутива на другую и последующие попытки победить глюки, которые неизбежно появятся в большинстве дистрибутивов. Также при выборе дистрибутива стоит учесть, что во многих «цикличных» дистрибутивах версия пакетов замораживается ещё на пререлизной стадии. Особенно это заметно в Debian. Исключение делается только для некоторых пакетов. То есть, в большинстве случаев вы не просто не получите новый функционал в рамках одной версии дистрибутива, но и минорные версии прикладного ПО будут те же, что были во время релиза. В Debian приходят только критические исправления. Вы можете ожидать исправления багов и закрытия дыр безопасности, но не новых возможностей, доступных в более поздних версиях ПО. В той или иной степени такой подход практикуется во всех дистрибутивах с подобным циклом разработки. Это часто можно обойти путём использования сторонних репозиториев. Чем популярнее дистрибутив, тем больше у вас будет возможностей касательно прикладного ПО. Но использование сторонних репозиториев критического для системы ПО влечёт за собой ряд рисков. Риски безопасности и стабильности в первую очередь. Нужно доверять владельцам репозитория. Однако, в мире свободного ПО, если кто-то попытается вшить вам в пакет какую-нибудь бяку, об этом быстро станет известно. Но это не повод подключать первые, попавшиеся на глаза репозитории, так как криворукость является не меньшей бедой, чем злой умысел. Также некоторые дистрибутивы придерживаются «rolling» цикла разработки. Такой цикл подразумевает «бесконечное» обновление дистрибутива по мере выхода новых версий ПО. Роллинг-версии могут быть и у «цикличных» дистрибутивов. Например, S.U.S.E имеет две версии дистрибутива, среди которых одна версия – роллинг. Недавно Red Hat объявила о том, что CentOS отныне будет придерживаться роллинг-модели. Когда дистрибутив имеет роллинг-версию, это как правило говорит о том, что это тестовая версия их основного дистрибутива. Как бы они его не называли, но часто за модным именем скрывается публичная альфа-версия. Но есть дистрибутивы, для которых роллинг-модель является основной и единственной. Например, Arch Linux. У него вообще нет версий. Она всегда последняя и всегда называется Arch Linux. И это не значит, что Arch – мешок неотлаженного ПО, упаковано в дистрибутив. Как и у любого другого дистрибутива, у Arch Linux есть нестабильные репозитории для разработчиков, тестовые для тестировщиков и стабильные репозитории для обычных пользователей. Чистый Arch Linux сложен для новичка, но у него много форков, которые позиционируют себя как «дружественные для новичков». Например, Manjaro для новичка не сложнее Ubuntu, но вы получите всегда свежее ПО и всю мощь Arch Linux. Дистрибутивы как Manjaro, являются «semi-rolling» дистрибутивами. Они не обновляются постепенно и бесконечно, но периодически выпускаю «пачку» обновлений практически на всё. В случае с Manjaro, обновления выходят пару раз в месяц. Разработчики Manjaro берут стабильные версии пакетов из Arch Linux и помещают их в «нестабильную» ветку своих репозиториев. И далее всё так же, как у всех: отладка, тестирование и стабильный релиз. Таким образом пакеты в Manjaro выходят, примерно, с двухнедельной задержкой, по сравнению с Arch Linux, но позиционируются как более стабильные. Это как если бы полугодичные версии Ubuntu выходили пару раз в месяц, обновлялись без переустановок и по стабильности не уступали TLS-версиям на третьем году жизни. Каждый тип цикла разработки имеет свои плюсы и минусы, но всё зависит от разработчиков. И роллинг релизы могут быть стабильными, если цель разработчиков именно стабильность, а не тестирование новых возможностей для своего основного дистрибутива. Из личного опыта скажу, что предпочитаю semi-rolling модель. Но всё зависит от потребностей и интенсивности использования. Следующее, на что следует обратить внимание при выборе дистрибутива – на сколько он популярен, и на сколько вменяемое у него сообщество. Популярность – показатель того, как быстро вы получите помощь в случае проблем. От сообщества же зависит, на сколько качественной будет эта помощь, и на сколько само сообщество толерантно к новичкам. Например, когда читаешь форумы Arch Linux, складывается впечатление, что абсолютное большинство отвечающих свято верит в непролазную тупость обратившегося с вопросом, равно как в свою врождённую гениальность. Даже официальная Wiki подразумевает, что читатель далеко не новичок не просто в Linux, но именно в Arch Linux. Темы же по Ubuntu часто изобилуют слабоумием «экспертов». И если слепо следовать их советам, то система рухнет быстрее, чем при самостоятельных экспериментах в неизвестных областях. При этом официальная документация похожа на Wiki Arch Linux, хотя и содержит больше законченных практических примеров. Так же при выборе дистрибутива стоит знать, что в отличии от Windows и Mac, в мире Linux несколько рабочих столов. Имеется ввиду не набор ярлыков с обоями, а сама среда. Это файловый менеджер, всевозможные настройки и прикладное ПО. На пример, в Windows, если не брать во внимание весь мусор, поставляемый с Десяткой, рабочий стол – это всё окружение, которое вы получаете при первом запуске. Текстовой редактор для открытия текстовых файлов, медиа плеер для воспроизведения аудио и видео, программы для открытия изображений, архивов и так далее. Весь графический интерфейс, позволяющий вам взаимодействовать с операционной системой. Без рабочего стола это будет чёрный экран и командная строка. Учитывая тот факт, что многие программы в Linux (особенно программы из проекта GNU) содержат графический интерфейс как компонент (могут работать и без него), то система без рабочего стола будет вполне функциональна. Но для новичка, даже видевшего голый DOS, функциональность будет чисто теоретической. В Linux существует множество рабочих столов, но, как и в случае с дистрибутивами, большинство из них являются форками или написаны на основе более ранних. Два основных и самых распространённых – Gnome и KDE. Для новичка основным показателем является внешний вид, а об удобстве использования впечатления складывается позже. Если утрировать, то Gnome больше похож на Mac, KDE на Windows, и не только внешне. Если подойти к вопросу более детально, то Gnome, к сожалению, с каждым новым крупным релизом всё ближе к философии «мы лучше знаем, что вам нужно». Ситуация может измениться в четвёртой версии, но я не питаю по этому поводу излишних иллюзий. При этом Gnome достаточно элегантен и функционален, особенно в тех дистрибутивах, где не оставили всё по умолчанию, как в Debian. KDE даёт гораздо больше возможностей в персонализации. Практически любой каприз можно исполнить через командную строку и правку конфигурационных файлов, но многое доступно и через настройки в графическом интерфейсе. KDE потребляет немного больше ресурсов в сравнении с Gnome, но это заметно лишь на реально слабых или очень старых машинах. KDE так же легко уронить, если бездумно лезть во все настройки. Оба рабочих стола полнофункциональны и современны. Форки часто возникали из-за неприятия курса развития рабочего стола. Так рабочий стол Mate изначально являлся форком Gnome. Третья линейка Gnome так сильно отличалась от второй почти во всём, что это вызвало бунт среди пользователей и в кратчайшие сроки возник форк. Теперь же, это полнофункциональный, современный рабочий стол, но внешне похожий на Gnome 2. Производные от KDE или Gnome рабочие столы, часто преследуют конкретные цели. Есть минималистические рабочие столы, потребляющие минимальное количество ресурсов. Есть рабочие столы, где главное – это элегантность, даже если это идёт в ущерб производительности или функциональности. И так далее… Рабочий стол является одной из главных составляющих при выборе дистрибутива. Если вам неудобно в окружении вашего рабочего стола, или его внешний вид вводит в уныние, то удовольствия от работы в нём вы не получите. А удобный и красивый рабочий стол иногда позволяет закрыть глаза на минорные баги самого дистрибутива. И так, резюмируя всё вышесказанное, на что нужно опираться при выборе дистрибутива? На наличие в нём возможностей удовлетворить все ваши требования к нему, а уже потом на его популярность и прочее. Если вы много лет просидели на Windows, то нужно понимать, что его клонов не существует. Любая другая ОС – это всегда новый опыт и неизбежные вопросы. Рассмотрите возможность двойной загрузки, пока не поймёте, что освоили всё, что вам нужно и вас всё устраивает. Если единственное, для чего вы используете компьютер – это игры, то даже «игровые» дистрибутивы не заменят вам Windows, по крайней мере на сегодня. Если же вы вообще новичок в компьютерах, то правильно подобранный, современный дистрибутив, окажется не сложнее любой другой ОС, существующей сегодня на рынке. Также стоит иметь ввиду, что какой бы дистрибутив вы не выбрали, он вряд ли станет последним. Рано или поздно вам станет тесно в его возможностях, либо просто захочется нового опыта. Дистрибутивы появляются и исчезают. Даже самый лучший на сегодня дистрибутив, через пару лет может перестать отвечать как вашим личным требованиям, так и требованиям времени. Но в мире Open Source любую опустевшую нишу всегда заменит кто-то другой. Вы всегда сможете найти что-то, что будет отвечать вашим требованиям.

Go to Source
Author: Tatyana