Федорчук Алексей Викторович

Священные войны мира FOSS

Священные войны мира FOSS

Алексей Федорчук aka alv

Предисловие

Священные войны, они же holy wars – непременный атрибут жизни FOSS-мира. И потому в этой книжке будут собраны все мои статьи и заметки, посвящённые сравнению систем, дистрибутивов и интегрированных сред. Они сочинялись на протяжении десятилетия и составили содержание рубрик Holy wars и Сравнение мужей нашего Блогосайта. Это всё – материалы для истории, и потому включены в книжку почти as is, с минимальной стилистической правкой, исправлением мелких ошибок и отдельными дополнениями «для связки». Так что при чтении их предлагается, во избежание недоразумений, обращать внимание на дату написания самих материалов и номера версий описываемых объектов.

Своего рода итог разновозрастным заметкам подводит центральный (и, в силу исторических причин, заключительный) материал, включённый в книжку. Он сочинялся сейчас, в декабре 2013 года, и посвящён Большому Сравнению трёх дистрибутивов из числа самых популярных ныне: Fedora, openSUSE, Ubuntu. Или, по крайней мере, наиболее обсуждаемых. Предварительный вариант этого Сравнения также был размещён на Блогосайте. Здесь вы увидите несколько отредактированную его версию.

Сравнение мужей. Общее введение

Февраль 10, 2012

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

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

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

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

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

Ныне костры эмоций отгорели, и автор полагает себя в силах рассматривать современные «сравнения мужей» в сфере Open Source и Free Software глазами этнографа-любителя без гнева и пристрастья, как завещал великий Тацит. Хотя, конечно, это получается не всегда...

Войны систем

В этом разделе собраны заметки о сравнении операционных систем и их дистрибутивов.

Мой роман с леди Free

2002, весна

Чудо-женщина жила (Господи, прости ей!), Не добра и не мила, Но краса ее влекла Джентльменов без числа Дьявольской стихией.

Джентльменов бел числа От Дувра до Холъспая, Африкой она была, Южной Африкой была, Нашей Африкой была, Африкой без края.

Редьярд Киплинг

Это глава из книжки «FreeBSD. Установка, настройка, использование», изданной в 2002 году издательством BHV – Санкт — Петербург. Она может служить преамбулой к последующим статьям на тему «Linux vs FreeBSD». В ней я попытаюсь рассказать, почему я люблю эту систему – возможно, мои мотивы покажутся читателю убедительными.

Прежде чем начинать рассказ о системе, не худо бы убедить читателя в том, что система эта лично ему нужна и полезна. Я же даром убеждения не обладаю – иначе подался бы в религиозные пророки или комсомольские секретари. И потому, вместо обоснования несравненных достоинств FreeBSD, просто попробую рассказать, почему и за что я ее люблю. Хотя, когда речь идет о любви, понятия «почему» и «за что» кажутся неуместными. Или, по крайней мере, рациональному истолкованию не поддающимися. Так что для начала – преамбула личного характера.

Мое шапочное знакомство с FreeBSD началось лет пять (на момент сочинения данного текста) назад – на этапе первичного приобщения к миру свободного софта. Рыская по книжным магазинам в поисках дистрибутивов Linux, только что появившихся в широкой продаже, я то и дело натыкался на коробки с изображением чертика с вилами и надписью – FreeBSD. Чем-то они неосознанно привлекали меня – возможно, загадочностью: об этой системе в русскоязычной литературе имелись только отрывочные упоминания. Тем не менее опробовать эту систему я не рискнул – это тогда казалось мне, старому пользователю DOS, избалованному годами работы в Windows, непосильным.

Непосредственное же общение с FreeBSD пришлось на последние дни ушедшего тысячелетия. К тому времени я, безжалостно истребив на своей машине известное произведение Самой Великой Софтверной Компании, уже более или менее освоился с Linux, и даже научился выполнять в нем все жизненно важные для меня задачи. Скажу больше – Linux как настольная система меня вполне устраивал.

Казалось бы, чего еще желать? Однако неискоренимое любопытство требовало знакомства с чем-то новым. И напрашивающееся решение для удовлетворения любопытства – установить FreeBSD. Что я и не замедлил проделать...

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

Помнится, по первости я немало затратил времени, чтобы отыскать в консоли FreeBSD средство для пролистывания экранов – там в этом качестве выступали клавиши PgUp/PgDown при включенном Scroll Lock, а отнюдь не комбинация Shift+PgUp/PgDown, как в Linux-консоли.

Относительно же командных сред достаточно сказать, что по умолчанию таковой во FreeBSD выступал некий /bin/sh – как потом выяснилось, точный римейк традиционно-архаичного Shell'а Борна, средства интерактивной работы в котором не идут ни в какое сравнение с bash или zsh. И с непривычки производит он впечатление если не убожества, то уж предельного аскетизма – точно.

Совершенно иной подход к процессу установки... Идеологически иной подход к локализации... Даже X, который как бы и в Африке – X, также выглядел и настраивался несколько иначе. Короче говоря, не знаешь, за что хвататься в первую очередь – за настройку ли среды, консоли, установку русских буковок или что другое...

И еще: особенностью FreeBSD казалось почти полное отсутствие средств автоматизации настройки – хотя бы типа аналогов linuxconf. Далеко не сразу понял я, что программа sysinstall, используемая при установке – вместе с тем и почти универсальный инструмент конфигурирования. Поначалу все требовало ручной правки конфигурационных файлов в текстовом редакторе. В качестве коего в базовом наборе предлагались либо vi в его классической ипостаси, либо ee – редактор хоть и простой (местами – даже очень простой, как реклама незабвенной фирмы «Сэлден»), но непривычный.

Благо, как ни странно, FreeBSD оказалась очень хорошо документирована, в том числе – и на русском языке. Количественно, конечно, русскоязычные источники информации по этой системе очень уступали таковым для того же Linux. Но зато качественно – то, что имелось, было на высоте. И, главное, можно было быть уверенным, что все они относились к одной и той же системе. Тогда как для Linux – в ряде случаев было трудно понять, к какому конкретному дистрибутиву относится данный FAQ или еще какой HOW TO. Правда, и тут не обошлось без ложки дегтя – изрядная часть этой документации относилась к версиям FreeBSD весьма преклонного возраста.

Главное же – в этой документации очень много говорилось о системном администрировании, и почти ничего – об использовании в мирных (то есть настольных) целях. Что подкреплялось высказыванием одного из моих корреспондентов, что держать FreeBSD на десктопе – сродни извращению...

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

В итоге через некоторое время я начал понимать логику установки и конфигурирования FreeBSD, строгую красоту ее настроек. Конечно, работа в ней требует существенно большей дисциплины мысли и действий, чем работа в т.н. user-ориентированных дистрибутивах Linux (не говоря уже о Windows). Однако чисто эмпирические алгоритмы действий в стандартных (и даже не очень стандартных) ситуациях нарабатывались достаточно быстро. И я прочно, казалось бы, записал FreeBSD в свой рабочий арсенал...

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

И потому я с вожделением ожидал очередного периода всенародного рождественского запоя в ночь с 24 декабря на 14 января. Это – время, когда на мою службу запрещается доступ, я остаюсь в своей заснеженной деревне без связи с внешним миром и волен заниматься чем угодно. В этот раз перспектива на ближайшие три недели была ясна – я возвращаюсь к моей леди Free.

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

Так что жребий был брошен, Рубикон перейден, CD-диск вставлен в привод, Reset нажат... Начинался процесс очередной инсталляции. И тут я наконец понял причину своей, чисто инстинктивной, симпатии к этой системе. FreeBSD – это женщина, более того – леди. Да, леди весьма суровая и не склонная к сантиментам. Она, подобно киплинговской Африке, не добра и не мила для случайных пришельцев. Но своим преданным поклонникам – всегда ответит взаимностью. По крайней мере, я на такую взаимность надеялся твердо.

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

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

Linux или FreeBSD? Без гнева и пристрастия

27 августа 2004

Эта статья была написана почти 10 лет назад – во времена, когда казалось, что Linux и FreeBSD могут выступать на десктопном поле в одной категории. Дальнейшее развитие этой темы мы увидим в статье следующей.

Вступление post factum

Первая версия этой статьи была некогда опубликована на всенародно известном Хоботе (ixbt.com), и вызвала довольно бурное обсуждение как там, так и на более ином форуме. Со многими высказанными замечаниями и соображениями я согласен. И поначалу хотел внести в материал некоторые коррективы. Однако потом отказался – это потребовало бы существенной переделки статьи, а она отражает мое представление о вопросе на текущий (тогда) момент времени. И пересказывать высказывания с форума мне показалось нецелесообразным. А потому в заключение заметки я приведу только свое резюме развернувшегося обсуждения.

Лишь одна оговорка: ниже по тексту все высказывания типа «в Linux возникают проблемы» и им подобные следует контекстно заменить на «могут возникать» – действительно, бывает и такое (хотя, как показывают высказывания, отнюдь не обязательно).

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

Пара отмазок

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

И еще: далее ни слова не будет говорится о применении Linux или FreeBSD в качестве серверов, узлов локальной сети и тому подобных сисадминских материях. А исключительно – о пользовательских, сиречь десктопных, их качествах. Предвидя реакцию некоторой категории читателей, последнюю фразу готов повторить дважды и трижды.

Субъективное введение

Скоро стукнет четыре года, как FreeBSD и Linux чередуются на моих машинах (домашних и служебных) с некоторой, не вполне определенной, периодичностью. Или – мирно уживаются в одном, отдельно взятом системном блоке. И за это время я заметил интересную закономерность.

В периоды, когда на моей машине живет одна FreeBSD, рабочее время мое распределяется примерно так: 90% – практическая работа (абсолютно не важно, какой характер она носит в данный момент), и 10% – более или менее нездоровые эксперименты над системой. Стоит же угнездиться в уголке винчестера какому-никакому Linux'у – и временная доля экспериментов сразу подскакивает до 50%. А в периоды, когда я занимался сборкой Linux'а с нуля, экспериментальный режим фактически становился перманентным.

И я задал себе вопрос – почему? И – для себя же – ответил: FreeBSD – цельная и стройная система, в которой, после комплекса начальных настроек не возникает желания ни прибавить чего, ни убавить. Не случайно же движение from Scratch, время от времени охватывающее широкие слои Linux-пользователей, в мире FreeBSD фактически не получило развития: известное сочинение Йенса Швайкхардта «FreeBSD from Scratch» – это скорее описание автоматизированной альтернативы sysinstall, нежели ручного построения собственной системы с нуля.

Linux же такой внутренней стройностью похвастаться не может. И потому желание что-то изменить в уже установленной системе, усовершенствовать, добавить, почистить – а то и просто пересобрать все заново, – возникает постоянно, и преодолевается только дефицитом времени.

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

Однако, повторяю, все это – сугубо субъективно, ведь далеко не все занимаются сочинением околокомпьютерных заметок. И потому попробую провести более объективное сравнение.

Первая попытка объективизма: «железо». Что требуется большинству пользователей от операционной системы как таковой? Во-первых, конечно же, поддержка «железа», которое на настольных персоналках, как известно, однообразием не страдает.

Бытует мнение, что Linux поддерживает более широкий спектр оборудования, нежели FreeBSD. Действительно, для последней мы не найдем, скажем, принтерных драйверов от производителя, полноценная поддержка современных видеокарт реализована только в том случае, если они – от NVIDIA (да и то, по отзывам, существенно худшая, нежели для Linux'а). Вероятно, возникнет в этой ОС напряженка и с т.н. win-модемами. Это – с одной стороны.

А с другой: всем счастливым обладателям контроллеров ATA RAID и Serial ATA в Linux до недавнего времени приходилось прибегать ко всякого рода ухищрениям. К тому же – не всегда удачным, особенно если присобаченные к таким контроллерам диски предполагалось использовать в качестве загрузочных устройств. Собственно, ситуацию можно считать нормализовавшейся только в последних ядрах ветки 2.6.X...

Во FreeBSD же 5-й ветки более или менее параллельно, на каком контроллере IDE-семейства сидит жесткий диск: благодаря CAM (Common Access Method) как-то работать с ним можно будет в любом случае, а если он еще и корректно опознан – то не будет препятствий и для загрузки с него. Да и в 4-й ветке – я ни разу не сталкивался с проблемами для «одновозрастных» контроллеров ATA RAID.

Другой пример – звуковые карты. Все те из них, что основаны на более-менее распространенных чипах, работали во FreeBSD без малейшего напряжения (рук или мысли). То же можно сказать и о «чипсетном» звуке. В Linux'е же аналогичные устройства часто требовали не вполне тривиальных манипуляций с ALSA-драйверами, благо ныне они встроены в ядро. Однако даже и в последнем случае без кое-каких настроечных действий не обойтись. Но это уже – предмет второй попытки объективизма.

А итог «железного» объективизма я сформулировал бы так: может быть, Linux поддерживает более широкий круг всяческого оборудования (в том числе и кое-какой экзотики), но все «железо», что поддерживается FreeBSD (а это – практически все стандартное и распространенное «железо»), использовать, в большинстве случаев, проще. И тут мы плавно переходим ко второму волнительному для юзера, особенно начинающего (а не начинающие давно сделали свой выбор) моменту, имя которому -

Настройка

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

Начнем с установки. Инсталляция FreeBSD штатными средствами (с помощью утилиты sysinstall выполняется за полчаса, не требует непременного доступа к Сети (хотя таковой лишним не будет) и дает в итоге полностью работоспособную систему с кириллической консолью, функционирующим dial-up (или, по ситуации, включением в локалку), запускаемыми Иксами и необходимым для начала практической деятельности минимумом пакетов (из прекомпилированных бинарников). Все настройки – и общесистемные, и для прикладных пакетов, – разумны (пусть и не идеальны с точки зрения конкретного юзера).

Конечно, установка FreeBSD требует некоторых предварительно полученных познаний. Каковые сводятся к а) представлению о разметке диска в BSD-стиле, принятой здесь номенклатуре накопителей и стратегии создания файловых систем. Не потому, что эти моменты так уж сложны – просто именно они сильно отличаются от всего, что пользователь мог знать ранее (по опыту общения с DOS/Windows или Linux). И к тому же разметка диска и файловые системы на них – это единственное, что пользователь не в силах изменить после инсталляции (без тотальной переустановки, естественно). Однако и это не столь страшно: предлагаемая в sysinstall схема разметки и файловых систем по умолчанию вполне походит для настольной персоналки, хотя и не идеальна в ряде специальных случаев.

Большинство известных мне инсталляторов из разных дистрибутивов Linux отличаются от Free'шного sysinstall в две противоположные стороны:

• есть установщики более простые – хотя, ИМХО, это та самая простота, которая хуже... ну сами знаете чего;

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

Наравне с Free'шным sysinstall я поставил бы (из всех мне известных) только установщик из Archlinux. Написанный, как свидетельствует его разработчик, под влиянием первого, он обеспечивает почти такое сочетание простоты и гибкости.

Однако (и это уже – специфика Linux как системной целостности) даже в этом случае законченной работоспособной системы на выходе не получается. Без ручной доводки (пусть не рашпилем, но надфилем) обойтись не удастся.

Конечно, постинсталляционная доводка не возбраняется и во FreeBSD. Однако здесь она направлена на достижение идеала, а не обеспечение базовой функциональности. Что я проиллюстрировал бы серией примеров.

Начнем с той же русификации. Сразу же после установки FreeBSD пользователь, при желании, получает полностью кириллизованную консоль. Правда – в одном-единственном варианте, с внутренней кодировкой kOI8-R, вводом в ней же и экранным выводом в кодировке DOS, да еще и с не вполне идеальными шрифтами. Но – никаких дальнейших действий по базовой русификации от него в обязательном порядке не требуется. А привести раскладки и шрифты в соответствие со своим идеалом он может и позднее. В дистрибутивах же Linux, не очень напирающих на дружественность пользователю, ручной правки пары конфигов пожалуй что не избежать. На причинах этого останавливаться не буду (для тех, кто представляет разницу между консолью в Linux и FreeBSD, они очевидны).

Конечно, в user-ориентированных дистрибутивах Linux отечественного происхождения пользователь получает стопроцентно русифицированную консоль «из коробки». Однако – выполненную в соответствии с представлениями разработчиков. Каковые отнюдь не обязаны совпадать с представлениями (и, главное, потребностями) данного конкретного пользователя. И уж в этом случае на коррекцию ему придется затратить существенно больше сил, нежели при русификации с нуля какого-либо дистрибутива из числа Source Based. В подтверждение чему – вспомним многочисленные статьи, посвященные откату в Red Hat (и Fedore'ном Core) с «прогрессивной» кодировки UTF на KOI8, пусть «бомжовскую», но вполне устраивающую многих и многих...

Русификация консоли вообще тесно связана со стилем инициационных файлов, принятых в данной системе. И тут линейный BSD-стиль с позиций пользователя выглядит много более простым, нежели принятая в Linux инициация в стиле System V, основанная на понятии runlevels, перевод которого как «уровни выполнения» способен окончательно сбить с понталыку начинающего пользователя.

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

Не случайна тенденция многих современных дистрибутивов Linux – использовать BSD-стиль загрузки, примерами чему, кроме классической Slackware, и CRUX, и Gentoo. А в Archlinux понятие runlevels вообще утрачивает значение – хотя соответствующие слова в файле /etc/inittab найти можно, на практике уровни выполнения при старте системы никак не играют. А вот попыток внедрить в BSD-системы «прогрессивный» стиль System V что-то не наблюдается – не считать же таковым группировку скриптов различных служб в едином подкаталоге в /etc во FreeBSD 5-й ветки.

Что же до русификации Иксов – X, как известно, он и в Африке X. И действия по вписыванию путей к файлам с кириллическими шрифтами, коррекция клавиатурной раскладки и установка переключателя с латиницы на кириллицу окажутся неизбежными, поверх какой операционки Иксы бы ни стояли.

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

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

В Linux: начинаем с того, что то же самое чипсетное аудио (а с постепенным вымиранием карт типа SB AWE128 оно становится предпочтительным для всех пользователей без претензий на меломанию или композиторство) непременно требует драйверов ALSA. благо ныне они встроены в ядро и в большинстве дистрибутивов включены в умолчальные ядра в качестве модулей. Если нет – перекомпиляция ядра большого труда не составит.

Однако перекомпиляцией ядра дело не ограничивается. Нужно еще поставить соответствующий ALSA-инструментарий (да еще, как правило, средства совместимости ее со старой звуковой системой OSS), активизировать соответствующего демона и с помощью не вполне очевидных средств обеспечить его «самовосстановление». И после всего этого опять столкнуться с неожиданностями. Например, с нежеланием мирного сосуществования ALSA и arts (звуковой системы KDE). Конечно, мне могут возразить, что это – проблемы KDE, однако во FreeBSD их не возникает вовсе.

Кстати, о доустановке инструментария (и прочих программ – для этого ведь необходима

Система управления пакетами

Здесь до недавнего времени первенство безусловно принадлежало FreeBSD: система портов ее обеспечивала несравненное сочетание простоты и гибкости, всегда оставляя возможность выбора – собирать ли пакеты из исходников, или устанавливать их из бинарников. Не возбраняя и комбинацию этих методов. Из всего Linux'ового богачества по этой части с портами мог сравниться только Debian'овский apt, ассимилированный в недрах многих rpm-based дистрибутивов. Однако, хотя apt и предполагает возможность сборки собственных пакетов, основным методом при нем является использование прекомпилированных бинарников, собранных в соответствие с представлениями майнтайнера о зависимостях оных.

Ныне положение изменилось – и в Source Based дистрибутивах Linux широко используются портообразные системы, развившиеся под сильным влиянием своего FreeBSD-прототипа: портежи Gentoo, Sorcery из Sorcerer'а, порты CRUX, Archlinux Building System из одноименного дистрибутива. Они подчас превосходят своего прародителя по универсальности, гибкости, глобализации настроке или прозрачности устройства, использования и модернизации. К тому же за десятилетие своего развития порты FreeBSD стали весьма громоздким и труднообозримым сооружением, поддержание которого в актуальном состоянии представляет собой отдельную задачу. Далеко не всегда решаемую с помощью дополнительных средств типа portupgrade (которая сама по себе является уже частью не базовой системы, но системы портов).

И тут уместно сказать пару слов еще об одной широко распространенной легенде – будто бы сборка из исходников посредством портообразных управляющих комплексов всегда приводит к более «чистой» (то есть свободной от лишних компонентов) системе. Это далеко не всегда так.

Во первых, в самой природе портов (и их клонов) часто заложена некоторая избыточность устанавливаемых компонентов. Хрестоматийный пример – cvs-up, требующий для актуализации как базовой системы, так и портов FreeBSD: в бинарном виде это легкий компактный пакет, не обременяющий даже пользователя с модемным подключением. При сборке же через порты он тянет за собой дистрибутив modula (поскольку на нем написан), который дальнейшем не пригодится никому, кроме приверженцев этого языка программирования.

Что меня всегда удивляло в портах FreeBSD – ситуация со сборкой моего любимого редактора joe. Каковой в качестве зависимости непременно требовал GNU make версии 3.80, хотя собственный make входит в состав FreeBSD Distributions – и собрать с его посредством joe руками – не составляет никаких проблем.

А вообще «чистота» установки пакета очень зависит от конкретной реализации порта. Давеча вот обнаружил я где-то в новостях сообщение о новом оконном менеджере под названием edo – небольшом, как говорилось, компактном и быстром. Обнаружился он и в портах FreeBSD, откуда я решил его собрать. В итоге этот маленький:-) WM потянул за собой (как зависимость зависимости) не что иное, как MySQL...

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

Каждый, кому доводилось собирать Linux from Scratch, знает, что некоторые версии пакетов Base Linux имеют обыкновение собираться только с определенными (отнюдь не обязательно – самыми свежими) версиями таких утилит, как autoconf и automake, категорически отказываясь делать это с другими их версиями (пусть даже более свежими и прогрессивными).

Разработчики Source Based дистрибутивов Linux подчас обходят эту сложность тем, что принудительно вносят в список зависимостей таких «склизких» пакетов autoconf и automake «прошлогоднего» розлива – при том, что сам по себе базовый комплект включает уже текущие на данный момент их версии. В результате чего, например, в Gentoo при выполнении бутстраппинга или emerge system можно с удивлением наблюдать, как система лезет в Интернет за бородатым, как Карл Маркс, autoconf – хотя свежая его версия только что была развернута из тарбалла stage1. А если вспомнить, что многие полагают, будто по настоящему стабильное ядро Linux может быть собрано только с gcc версии 2.9.X, результатом чего оказывается присутствие в системе двух компиляторов, – о какой «чистоте» сборки можно еще говорить?

Впрочем, достижение разумного баланса между развертыванием прекомпилированных пакетов, установкой их из портообразной системы и самостоятельной «штучной» сборкой – тема совершенно отдельного разговора. А пока рискну сформулировать еще пару «объективок»:

• FreeBSD, вопреки устоявшемуся мнению, существенно проще в настройке и локальном администрировании – даже без учета того факта, что она одна, а Linux'ов – много;

• напротив, система портов FreeBSD в настоящее время (в отличие от недавнего прошлого), не имеет значимых преимуществ перед аналогичными инструментами из Source Based дистрибутивов Linux.

Если тщательно подсчитать приведенные выше плюсы и минусы обеих операционок, можно прийти к выводу, что счет между ними – равный. Возможно, с незначительным позиционным преимуществом FreeBSD, но столь незначительным, что вполне резонно согласиться на ничью. Однако каждая ОС устанавливается, настраивается и наращивается приложениями не ради себя самой, а для практического использования. И потому следует рассмотреть в сравнении их

Пользовательские качества

Здесь для начала рискну высказать крамольное, с точки зрения фанатиков любой из обсуждаемых систем, мнение (впрочем, фанатики любое мнение, не совпадающее с их собственным, сочтут крамольным). А именно:

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

Ибо такой пользователь большую часть времени проводит в Иксах, и ему абсолютно без разницы, поверх какой операционки эти самые Иксы крутятся. Ему только кажется, что он работает в Linux или FreeBSD (NetBSD, OpenBSD – рискну расширить я этот список). На самом же деле работает он в KDE (Gnome, XFce, WindowMaker – нужное дописать). И если бы ему не пришлось предварительно устанавливать и настраивать свою операционку, он имел бы шанс никогда не узнать, в какой именно из POSIX-совместимых систем он работает: перед ним будут одни и те же интерфейсные элементы, одни и те же средства настройки, одни и те же приложения.

Так что в сравнительном аспекте речь может идти только о работе в консольном режиме с использованием системных и пользовательских утилит базового комплекта.

И тут я не могу не произнести оду текстовой консоли FreeBSD и средствам управления ею. Каковые включают в себя всего две команды – vidcontrol и kbdcontrol, – назначение которых однозначно вытекает из названий. И которые позволяют настроить в консоли абсолютно все – от плотности символов на экране (т.н. разрешения) до цвета бордюров, своих для каждого виртуального терминала.

Пользователь Linux для начала вынужден разбираться с тем, какой из двух пакетов управления консолью – kbd или console-tools – применяется в его дистрибутиве. Конечно, ныне они практически идентичны по своим возможностям, но каждый имеет свой набор команд с несколько различающимся синтаксисом. А кое-какие настройки (например, цвета текста и фона) требуют от него использования команд, не входящих ни в один из пакетов. А кое-что (например, те же цвета бордюров) все равно останутся для него недоступными.

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

Конечно, и Linux располагает тем же самым набором классических Unix-утилит (точнее, как и FreeBSD, их аналогами). Однако это – именно разобщенные пакеты, разрабатывавшиеся в рамках проекта GNU, в сущности, независимо от операционной системы. И уже в силу этого не столь тесно интегрированные с ней и между собой.

Так что же – в консольном режиме первенство остается за FreeBSD. По моему мнению – безусловно. Но – только если речь идет именно о чисто текстовой консоли. Если же обратить свой взгляд на т.н. графическую консоль (реализуемую посредством Frame Buffer) – все видится несколько иначе.

Начать с того, что графическая консоль FreeBSD (т.н. Raster Mode) ограничена одним-единственным разрешением – 800x600 (тут речь идет именно о настоящем пиксельном разрешении, а не плотности символов). Да и то – на некоторых чипах этот режим не работает вообще, на других же – имеет вид вполне скверный. Собственно, нормального результата в Raster Mode мне не удавалось добиться ни на одной из имевшихся в моем распоряжении видеокарт.

В Linux же графическая консоль просто радует взгляд. Даже при поддержке Frame Buffer для абстрактных VESA-совместимых карт на всегда ней можно варьировать разрешения от 640x480 до 1280x1024, с изменением глубины цвета в стандартном диапазоне. Что обеспечивает не только комфортный просмотр изображений, но и весьма приличное (на мой взгляд – более чем приличное) воспроизведение видео. Для карт же, имеющих хорошо реализованные собственные драйвера в ядре Linux (Matrox, ATI, чипсетное видео от Intel) – к этому добавляется возможность установки нестандартных разрешений экрана.

Конечно, никто не использует консоль для работы с изображениями, и очень немногие – для просмотра видео. Почему же я придаю графической консоли такое значение? Да потому, что незаметно, на тоненьких пока ножках, но наступает эра жидкокристаллических дисплеев, знаменующая собой смерть чисто текстового режима (но не консольного режима как такового). Почему – легко поймут те, кто видел стандартный текстовый режим 80x25 символов на 18-дюймовом LCD-мониторе с физическим разрешением матрицы 1280x1024. А как это смотрелось бы на экране с соотношением сторон 16:9 – я боюсь себе даже представить...

Наконец, остается еще один вопрос, важный для пользователя -

О производительности

Представление о большем быстродействии FreeBSD по сравнению с Linux'ом – столь же традиционно, как и мнение о большей сложности ее настройки. Однако так ли все однозначно?

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

Во-вторых, даже если считать скорость загрузки одним из критериев быстродействия, – превосходство перед Linux'ом обнаруживает только FreeBSD 4-й ветки. Пятая ветка грузится ровно столько же, сколько и любой дистрибутив Linux, задействующий файловую систему устройств devfs. Конечно, в благородном Linux-семействе можно подобрать таких представителей, которые грузятся еще дольше – но это очень дружественные к юзеру системы, отягощенные... нет, не вином и едой, но изобилием стартовых сервисов (в частности, автоопределителем оборудования kudzu).

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

Очевидно, что на производительность файловых операций каждой ОС влияют два фактора – реализация взаимодействия с дисковой подсистемой (для десктопа – конкретно с интерфейсом ATA) и организация поддерживаемой файловой системы (систем). И вот тут-то FreeBSD оказывается в невыгодном по сравнению с Linux положении.

Выше упоминалось, что за счет CAM во FreeBSD (речь идет о 5-й ветке) достигается универсализм в работе с дисковыми контроллерами – у меня создалось впечатление, что ей вообще безразлично, на каком конкретно контроллере сидит диск (лишь бы он опознавался BIOS'ом – но и это необходимо только для загрузки с него ядра). Однако за универсализм приходится платить. И похоже, что в данном случае расплата наступает в виде снижения быстродействия дисковых операций – хотя достоверной информации по данному вопросу я не нашел, исходя из общих соображений, это выглядит похожим на правду.

Такова первая сторона вопроса. Вторая – файловая система FreeBSD, каковыми являются UFS и (по умолчанию в 5-й ветке) ее усовершенствованная модернизация UFS2. Традиционно в этой ОС обе используются в частично синхронном режиме (noasync mode), когда изменения метаданных файлов записываются на диск немедленно, а изменения блоков данных – кэшируются в оперативной памяти.

В Linux принята другая модель работы с ATA-дисками: разные типы контроллеров имеют (или не имеют) собственную поддержку в ядре. Что исключает использование явно не поддерживаемых устройств, зато для поддерживаемых, судя по всему, обеспечивает большее быстродействие. Файловые же системы (а Linux поддерживает в качестве нативных несколько их разновидностей) по умолчанию все (кроме, возможно, JFS) используются в полностью асинхронном режиме (async mode), когда и данные, и метаданные кэшируются в оперативной памяти.

В результате сочетания указанных факторов файловые операции осуществляются в Linux существенно быстрее, нежели во FreeBSD. Собственно, я всегда это подозревал, но только серия измерений показало, насколько отставание FreeBSD 5-й ветки в этом плане существенно – положение не спасает даже механизм SoftUpdates, призванный повысить и надежность, и производительность манипуляций над файлами. К слову сказать – во FreeBSD 4-й ветки такого отставания ранее не наблюдалось, что косвенно подтверждает негативное влияние работы с дисковой подсистемой (усугубляющее деградацию именно синхронных операций) – в ней модель CAM не используется (по крайней мере, не использовалась, когда я ею пользовался). А вот в Linux с его исключительно асинхронным использованием файловых систем, по моим наблюдениям, зависимости скорости работы с файлами от производительности дискового железа почти нет.

Второе из обещанных исключений относится к операциям своппинга. Каковые в Linux и FreeBSD выполняются существенно по разному. Для установления чего достаточно посмотреть на вывод команды top в той и другой ОС при среднепользовательской нагрузке. В Linux можно видеть, что при достаточном количестве оперативной памяти процент использования swap-пространства стремится к нулю. Например, на моем ноутбуке с Linux (512 Мбайт памяти) в момент сочинения этих строк, при загруженном KDE, html-редакторе Quanta, konsole, двух экземплярах konqueror и работающем mplayer (воспроизводство mpeg и RealAudio), swap не задействован вообще. На десктопе же с FreeBSD (1 Гбайт памяти) при той же нагрузке задействованная область подкачки меньше 10% почти не опускается.

Это связано с тем, что Linux прибегает к своппингу только при переполнении оперативной памяти, во FreeBSD же на диск в любом случае (даже при избытке RAM) выгружаются страницы памяти, к которым не было обращений в течении некоего промежутка времени. В сущности, оперативная память в этой ОС выступает в качестве своего рода кэша для области подкачки (точнее, для виртуальной памяти вообще). Что эффективно при ограниченном ее объеме и было оправдано в стародавние времена, когда процессоры были медленными, а памяти – мало. Ныне же такая модель использования своппинга в некоторых ситуациях приводит к замедлению работы. Пример – в KDE с большим количеством рабочих столов и периодическим переключением между ними, где такое замедление видно невооруженным глазом.

Все это обуславливает большее объективное (устанавливаемое тестами) и особенно субъективное быстродействие Linux по сравнению с FreeBSD. Хотя должен опять подчеркнуть – речь идет именно о десктопной сфере: на сильно загруженном сервере механизм кэширования FreeBSD может проявить свои сильные стороны, и скоростные соотношения между этими системами, возможно, в ряде случаев окажутся прямо противоположными.

Подведем итоги

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

Чем подкупает FreeBSD – так это а) простотой установки, б) логичностью настройки и в) легкостью администрирования в локальном масштабе. Однако те же особенности (по крайней мере, большая их часть) характерны ныне и для лучших (по моему мнению) современных представителей Linux-семейства (CRUX и Archlinux, в какой-то степени – Gentoo). Хотя ожидать от них внутренней стройности и целостности FreeBSD, по понятным причинам, в ближайшее время не приходится.

В то же время я отдаю себе отчет в архаичности файловой системы FreeBSD, особенно отчетливо проступающей в сравнении с современными реализациями ReiserFS и XFS для Linux. Ну и почти месячная эксплуатация FreeBSD-десктопа и Linux-ноутбука – машин с практически равным номинальным быстродействием, – что называется, лицом к лицу, убеждает меня в большем быстродействии последней. а вот что имеет больший вес для пользователя – это каждый должен решать для себя. Хотя, как это ни прискорбно, Linux в настоящий момент кажется лучшим выбором для настольного применения.

Однако подчеркну – в настоящий момент, ведь выход версии FreeBSD 5.3 может существенно изменить ситуацию. Однако, что бы ни случилось, будущее хотелось бы видеть как взаимовлияние обеих операционных систем, взаимной ассимиляции всех плюсов и изживании минусов. Почему я и закончил бы свое затянувшееся повествование лозунгом в духе советских времен:

Демон с пингвином – братья навек!

Заключение post factum

В результате развернувшегося обсуждения должен признать: заметка получилась у меня если и без гнева, но не совсем без пристрастия – ну люблю я FreeBSD, что поделать? Хотя и против Linux'а ничего не имею и даже им пользуюсь.

Основное замечание, прошедшее во многих форумных постах, справедливо – признаю. Я действительно давно не имел дела с пакетными юзер-ориентированными дистрибутивами Linux, и малость подзабыл, как они выглядят. Тем не менее, подчеркну еще раз: одно из существенных преимуществ FreeBSD перед любым дистрибутивом Linux – в том, что он (Free то бишь) одна, а Linux'ов – множество.

Относительно поддержки видеокарт – также согласен, упущение. Потому что в игры не играю и фирменные драйверы никогда не ставлю – для 2D достаточно штатной Иксовой поддержки. Да и про Linux Compatible во FreeBSD – каюсь, просто забыл.

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

А вот касаемо быстродействия – спектр высказанных мнений только подтверждает мое: в отношении номинального быстродействия (если не брать пресловутые файловые операции в массовом масштабе) ни одна из систем сама по себе ощутимого преимущества не имеет. Всё это больше зависит от индивидуальной настройки, задействованных сервисов и т.д.

А вообще, конечно, сравнение Linux с FreeBSD можно резюмировать очень тривиальным образом: лучше та система, которую лучше знаешь.

Linux vs FreeBSD: продолжим “Священные войны”?

4 декабря 2008 г

Давным-давно написал я статью «Linux или FreeBSD? Без гнева и пристрастия». Много воды с тех пор утекло, немало сменилось ядер Linux'а и веток FreeBSD, менялись файловые системы, менялось «железо», мир десктопов заполнился 64-битными и многоядерными машинами. И настало время вернуться к этому вопросу на новом витке развития ОСестроения и аппаратных средств.

Вступление

Благо, для возвращения к вопросу подвернулся и повод: статья morbo «Сравнение FreeBSD и Linux (Debian)», сопровождавшаяся обсуждением как непосредственно в блоге, так и на форуме POSIX.ru. Впрочем, всё это послужило только катализатором для кристаллизации давно созревавшего замысла.

Конечно, сравнительные достоинства различных Unix-подобных систем, в том числе и Linux vs FreeBSD, обсуждались бессчётное количество раз — на уровне идеологическом и технологическом, эмоционально или с попытками бесстрастия. И ныне затрагивать эту тему на полном серьёзе невозможно. Так что и всё сказанное ниже чересчур уж серьёзно воспринимать не надо. Но и не след забывать, что в каждой шутке есть лишь её доля. Не понимающим этого — просьба воздержаться от дальнейшего чтения во избежание отрицательных эмоций.

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

Так что давайте начнём с того, что отделим мух от котлет, а котлеты — от гарнира, то есть разграничим сферы применения. Ныне сфер таких можно назвать три:

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

• серверный сегмент, охватывающий управление сетями и службами коллективного применения — своего рода войска тылового обеспечения для первой группы задач;

• сегмент встраиваемых устройств — очертить его словами довольно трудно, но смысл, думаю, интуитивно понятен.

Разумеется, у каждого есть свои предпочтения, что из перечисленного считать мухами, что — котлетами, а что — гарниром. Это, во-первых. Во-вторых, и это — следствие первого, непреодолимой границы между выделенными сегментами нет: как было резонно отмечено в обсуждении на POSIX.ru, одно и то же устройство может выступать в любой из указанных ролей. А в-третьих, напротив, граница между мухами, котлетами и гарниром с течением времени становится всё более резкой. Что хорошо видно на примере эволюции мультимедии разного рода. Играя роль котлеты для их разработчиков, они, по мере превращения в привычный гарнир для своих пользователей, всё больше оказываются в амплуа мух для тех чудаков, кто по прежнему использует компьютер традиционным способом, то есть для работы.

Нечто аналогичное на наших глазах происходит со встраиваемыми устройствами, что демонстрирует в своём «Железном марше» Сергей Голубев. Типичный пример — сетевые накопители. Оснащенные винчестерами, подчас объединёнными в RAID-массивы, такого объема, которому ещё недавно позавидовал бы data-центр средней руки, они нынче, казалось бы, прочно переместились в пользовательский сегмент. Однако не будем спешить: уверен, что очень скоро эти агрегаты будут продаваться с «предустановленными» видео- и аудиозаписями, коллекциями изображений и подборками материалов «только для взрослых». После чего прочно окучат сектор бытовых устройств.

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

Теперь про области сравнения. Традиционно Linux и FreeBSD сравниваются с точки зрения:

• поддержки аппаратных платформ;

• поддержки дополнительного оборудования внутри одной архитектуры;

• поддержки хранилищ данных, таких, как логические тома и файловые системы;

• внутреннего устройства системы и средств поддержки её целостности;

• средств управления дополнительным программным обеспечением;

• наконец, производительности.

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

Поддержка аппаратных платформ

Итак, поддержка аппаратных платформ. Да, Linux поддерживает их существенно больше, нежели FreeBSD (хотя до уровня Net- и даже OpenBSD существенно не дотягивает).

Актуально ли это для сферы десктопного применения? Увы, отнюдь нет. На протяжении многих лет я не устаю вспоминать статью в журнале PC Mafazine, опубликованную лет пятнадцать назад под названием (по памяти) «Через 10 лет все платформы, кроме IBM PC, уйдут в небытие».

Ныне в пользовательском сегменте это можно считать свершившимся фактом: единственной настольной платформой сейчас является x86_64 (она же AMD64), чистый i386 скоро можно будет найти только у старьёвщиков и торговцев антиквариатом. Платформа PowerPC прекратила своё существование с переходом Macintosh'ей на Intel. Платформа Cell в универсально-настольной своей ипостаси, не смотря на возлагавшиеся на неё надежды, похоже, умерла ещё на стадии зачатия. О доле Sparc'ов, Alpha. Power и прочих Itanium'ов в настольных системах можно не говорить, верно?

Так что возникает вопрос: зачем нужна многоплатформенность на столе? Для поддержки старого железа? Старые Alpha или Sparc благополучно доживают свой век со своими родными старыми же операционками. Конечно, в истории известны случаи гальванизации старых Sun'овских станций путём установки Linux'а, вместо морально самортизированной предустановленной версии Solaris — пример такой процедуры описан в известной книге Владимира Водолазкого. Но проводился его эксперимент в уж больно специфической обстановке первой половины 90-х годов. А чем только не занимались в то время пролетарии умственного труда, вроде нас с вами...

Так может быть, версии Linux или FreeBSD для указанных выше аппаратных платформ могут рассматриваться как альтернатива родным ОС? С трудом верится, что те, кто затратил изрядные, даже по ненашим масштабам, деньги на приобретение соответствующих комплексов, будут сносить предустановленные, оплаченные, тщательно заточенные под «родное железо» системы, да ещё подчас со столь же предустановленными и оплаченными, специализированными приложениями, ради сомнительного удовольствия устанавливать на них свободную ОС и столь же свободные (но далеко не всегда столь же функциональные) приложения?

На моей памяти был случай... не скажу массового, но по крайней мере организованного применения Linux'а на платформе, отличной от i386 – на DEC'овских Alpha. Но об этом рассказ пойдёт в книжке Мир FOSS. Вопросы истории (готовится к размещению).

Итак, поддержка многочисленных платформ в настольном сегменте похвальна с точки зрения общих соображений, но не особенно востребована на практике. Более того, самое смешное, что она ударными темпами теряет актуальность и в сегменте серверном — с тех самых пор, как появились дешёвые многопроцессорные системы на Opteron'ах. Да, амортизация серверов происходит медленно, и дорогие сервера на не-Intel'овских платформах будут крутиться ещё очень долго. Однако, по аналогии с рабочими станциями, трудно представить себе, что в процессе промышленной эксплуатации их родные операционки будут заменяться на что бы то ни было свободное.

Вообще-то говоря, я могу понять мотивы портирования Linux на архитектуры, отличные от x86. Главный из них, как мне кажется, — просто наличие соответствующей техники у разработчиков и спортивный азарт при адаптации любимой ОС для прикручивания к оной. Опять-таки, мотив веский с точки зрения just for fun, но вряд ли способствующий «концентрации сил и средств на решающем направлении».

Сложнее понять растущую тягу к многоплатформенности среди разработчиков FreeBSD — системы, изначально ориентированной на самую демократичную платформу всех времён и народов. Единственное объяснение, которое я вижу — это отработка поддержки 64-битных архитектур вообще: обратим внимание, что таковыми были все поддерживаемые FreeBSD не-Intel'овские платформы, причём поддержка эта появилась ещё до широкого распространения x86_64.

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

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

Более того, перебрав 64-битные варианты нескольких дистрибутивов Linux, я обнаружил падение производительности в задачах, связанных с интенсивными дисковыми и файловыми операциями, что, в принципе, и следовало бы ожидать. Так что единственное, что реально даёт пользователю Linux'а поддержка 64-битной архитектуры — это возможность использования памяти более трёх с копейками гигабайт, если таковая имеется в наличии.

Впрочем, того же результата можно добиться и косметическими мерами — пересборкой ядра с поддержкой PAE. При этом сама по себе система остаётся не только полнофункциональной, но и 32-битной, то есть на ней можно использовать, например, фирменные драйвера для видеокарт от Nvidia или ATI/AMD, 64-битные версии которых или отстают во времени, или просто отсутствуют как класс.

Во FreeBSD с поддержкой PAE дело обстоит гораздо хуже. Конечно, и её ядро можно перекомпилировать с включением соответствующих опций, но при этом накладывается столько ограничений на многие другие подсистемы ядра, что сама по себе ОС становится практически не пригодной к использованию в мирных (то есть десктопных) целях.

Однако это более чем с лихвой окупается тем, что собственно 64-битный вариант FreeBSD функционирует более чем исправно, и на машинах с соответствующими процессорами (то есть AMD64, Intel Core 2 и более высокими) прирост производительности можно заметить даже при обычной работе, а не только на тестах. Замедление же файловых операций, вероятно, имеющее место при работе с файловой системой UFS2 (которая и сама по себе достаточно задумчива) компенсируется тем, что именно на мощных 64-битных машинах с большим количеством реальной и полностью адресуемой памяти во всём блеске начинает играть ZFS, родной поддержки которой в Linux'е в ближайшее время не предвидится.

Ныне процессор менее чем с двумя ядрами найти не проще, нежели без 64-битных инструкций. И потому поддержка многопроцессорности и параллельных вычислений видится не менее важной — правда, опять-таки в основном по причине жадности, раз деньги за второе, третье или четвертое ядро всё равно уплочены. И тут можно констатировать, что и в Linux'е, и во FreeBSD многопроцессорность в настольном сегменте играет только на одном его поле — при компиляции программ, и там, и там обеспечивая примерно одинаковый прирост производительности. Но, поскольку пользователю FreeBSD заниматься сборкой программ в среднем приходится чаще, нежели линуксоиду, то он может греть свою душу мыслью о не совсем зря потраченных деньгах.

От поддержки платформ мы плавно перекидываем сразу два мостика: один — к поддержке дополнительного оборудования, другой — к поддержке хранилищ данных. Трудно сказать, что более (или менее) важно для пользователя. И потому — просто в порядке упоминания. Итак, первым меня угораздило упомянуть вот это:

Поддержка дополнительного оборудования

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

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

Для начала следует заметить, что сами по себе ОС Linux и FreeBSD поддерживают все карты, соответствующие стандарту VESA, то есть практически все, существующие ныне в природе. Причём собственными силами делают это как в текстовом режиме, так и графическом консольном, именуемом режимом frame buffer в Linux или pixel mode во FreeBSD.

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

Так что, когда речь заходит о поддержке видеосистемы, явным или не явным образом подразумевается её поддержка в оконной системе X (или, в просторечии, в Иксах). И тут надо сказать, что Иксы, практически единственной современной реализацией которых является Xorg, абсолютно одни и те же и в Linux'е, и во FreeBSD, и во всех прочих свободных Unix-подобных системах, вплоть до Solaris'а. И собственными, то есть свободными, видеодрайверами Иксов все существующие видеокарты, точнее, чипы, на которых они основаны (а их и осталось-то практически всего три ряда — от Intel, Nvidia и ATI/AMD) поддерживаются абсолютно одинаково. То есть — хорошо в отношении 2D графики и никак — в отношении графики трёхмерной.

Так что относительно различий в поддержке видеокарт в Linux'е и FreeBSD можно говорить только применительно к 3D-функциям, обеспечиваемым фирменными драйверами, и только для видеокарт от Nvidia и ATI/AMD. И тут — да, Linux обходит FreeBSD на несколько корпусов: под него существуют драйвера от обеих фирм в 32-битных вариантах, а от Nvidia — также и в 64-битном. Тогда как для FreeBSD имеются только 32-битные фирменные «дрова» Nvidia, да и то, по отзывам, качество их реализации оставляет желать лучшего.

Однако зададимся вопросом — а насколько это практически востребовано, если отвлечься от той же естественной жадности? Ведь 3D-функции необходимы только для двух вещей — игр и трёхмерных эффектов в графических средах. Важность чего с точки зрения работы равна нулю (а то и отрицательной величине). Если же говорить о трёхмерной графике профессиональной — то она требует и других видеокарт (ценовой диапазон которых испокон века начинался от тысячи условных не-рублей), и другого софта, да, пожалуй что, и совсем другой аппаратуры вообще.

Поддержка звуковых карт, как сама по себе, так и механизм её реализации во FreeBSD, давно уже стала притчей во языцех. Только давайте посмотрим, а есть ли предмет разговора? Ведь фактически весь ныне существующий их ассортимент сводится к паре-тройке встроенных аудиокодеков типа AC'97 и одной-двум текущим «крутым» моделям от Creative. Относительно вторых ничего сказать не могу, ибо со времен SB AWE128 не испытывал в них ни малейшей потребности. А вот со встроенными кодеками во FreeBSD всё обстоит более чем нормально. Причём ещё с тех времён, когда их настройка в Linux'е представляла собой не вполне тривиальную задачу, во FreeBSD она обеспечивалась одной-тремя строками в конфиге ядра или загрузчика.

Предвижу возражение, что в Linux'е с тех пор звуковая система развилась до невозможных пределов, а во Free всё осталось по прежнему. Да, но так ли уж это плохо? Ведь всем известно, что если солнце всходит на востоке, заходит на западе и так — каждый день, может быть, лучше ничего не менять в этом процессе?

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

Поддержка хранилищ данных

А вот поддержка средств хранения данных — вопрос для пользователя очень важный, если, конечно, его личные данные не сводятся к набору порнухи, скачанной из Интернета. И тут, казалось бы, мы видим явное лидерство Linux'а, ядро которого поддерживает массу файловых систем как нативных (а в ближайшее время число таковых обещает чуть не удвоиться), обеспечивает эффективные средства работы с программными RAID'ами и логическими томами (LVM). Чем до недавнего времени FreeBSD могла противопоставить только архаичную, не смотря на все усовершенствования, файловую систему UFS и несколько способов организации программных RAID-массивов, причём без возможности задействовать их простыми средствами.

Ныне положение изменилось, и портирование на FreeBSD системы ZFS, обеспечивающей функции как менеджера логических томов, так и собственно файловой системы, действительно ставит последнюю точку в развитии средств хранения данных на современном этапе. Ибо ни по функционалу, ни по простоте использования, ни по быстродействию ни одно из аналогичных средств Linux'а с ней состязаться не может даже в комплексе. Да, надёжность ZFS ещё не проверена временем и не вполне достаточна для использования в промышленных серверах. Но это — дело наживное (и, как показывает практика, интенсивно наживаемое). А для настольных применений ZFS более чем достаточна даже в существующем виде.

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

В Linux'е поддержки ZFS в нативном виде нет и, по юридическим причинам, не предвидится, а реализация её на пользовательском уровне — не совсем то, что надо. Конечно, нельзя исключить того, что кто-либо из энтузиастов возьмется за разработку сторонних патчей поддержки ZFS к ядру Linux'а, однако доведение их до ума, как показывает пример FreeBSD, потребует немалого времени, а шансов на получение ими официального статуса почти нет.

Отступление: не могу не констатировать с удовольствием, что ныне с поддержкой ZFS в Linux с технической точки зрения всё нормально (проект ZFS on Linux). Не смотря на препоны и рогатки, чинимые статусом – по прежнему далёким от официального.

И вообще, специфика разработки Linux'а в отношении файловых систем выливается в то, что энтузиасты, желающие (и могущие) этим заниматься, с большим удовольствием создают собственные велосипеды, типа BTRFS или TuxFS, нежели доводят до ума велосипеды существующие, чему примером служит печальная судьба AdvFS. Само по себе это не хорошо и не плохо — это медицинский факт. Однако именно в области файловых систем он играет роль не самую положительную...

Внутреннее устройство системы и обеспечение её целостности

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

Конечно, и то, и другое — в идеале. На практике и в любом дистрибутиве Linux можно выделить базовый комплекс, состоящий из примерно одного набора системных и пользовательских утилит, необходимых для старта системы и её минимальной функциональности. А FreeBSD Distributions, напротив, включает в базовый набор, с одной стороны, компоненты, вовсе не являющиеся жизненно необходимыми (типичный и наиболее часто поминаемый пример — sendmail). С другой стороны, base FreeBSD нельзя считать и полностью самодостаточным — трудно представить себе её, например, без Perl'а...

Различие, скорее, в модели разработки. Базовый комплект FreeBSD, за некоторыми (хотя и принципиально важными) исключениями, разрабатывается в рамках единого проекта. И в результате каждое изменение функциональности ядра тут же находит своё отражение в инструментах, эту функциональность реализующую. В Linux'е ядро и базовый комплект развиваются в серии независимых проектов, и отнюдь не всегда согласовано.

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

Средства пакетного менеджмента

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

Сравнивать Linux и FreeBSD в этом отношении напрямую невозможно: каждый из «основополагающих» дистрибутивов Linux'а имеет собственную систему пакетного менеджмента или сборки приложений, которые дают их пользователям не меньшие основания для гордости. А, скажем, верные последователи Патрика Фолькердинга испытывают чувство глубокого удовлетворения от фактического отсутствия в их дистрибутиве штатных инструментов для управления пакетами.

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

Приведу простой пример из собственной недавней практики. В ходе обсуждения данной темы на POSIX.ru неожиданно был затронут вопрос о формате rpm и его истории, позднее выделенный в отдельное производство. С rpm based системами я не имел дела много лет, и потому решил во FreeBSD поставить rpm из порта — дабы хотя бы почитать, что о нём говорит тётя Маня.

Сказано — сделано: перехожу в каталог /usr/ports/archivers/rpm4/ и, не мудрствуя лукаво, набираю

# make install clean

после чего продолжаю заниматься своими делами. Через некоторое время решил поглядеть, что там у меня делается с установкой — и с удивлением обнаружил, что она всё ещё продолжается: скачиваются и собираются в качестве зависимостей TeX, Qt и ещё что-то...

Разумеется, такую ситуацию можно было бы предотвратить внимательным изучением Make-файла или списка зависимостей, например, на Freshports. Сказанным же хочу только подчеркнуть, что системы портов, как и пакетный менеджмент в стиле apt, сами по себе гарантии от неё не дают, наиболее эффективно работая в том случае, когда пользователь знает, что делает. А вот отсутствие в Slackware развитых средств управления пакетами просто заставляет относиться к их установке вдумчиво.

О сравнении производительности

Это ещё более сакральный вопрос. И ответить на него можно только в том случае, если ясно определиться, производительность чего именно сравнивается. В двух словах же я сказал бы так: на современных машинах, выполняющих набор обычных пользовательских приложений в окружении распространённых ныне графических сред, разница в производительности между Linux'ом и FreeBSD не фиксируется. Точка. Исключение — массовые файловые операции. Если до недавнего времени FreeBSD, за счёт особенностей работы с PATA-контроллерами и задумчивости своей файловой системы, однозначно (и местами весьма значительно) проигрывала Linux'у, то ныне распространение SATA-винтов выровняло ситуацию, а портирование ZFS сместило чашу весов в её пользу.

Разумеется, только на мощных машинах. Как-то, эксперимента ради, я поставил FreeBSD с ZFS на ноутбук с Sempron'ом (одним из первых), медленным, даже по ноутбучным меркам, винчестером и 512 Мбайт памяти. Зрелище было душераздирающее. Так что, пожалуй, для реанимации относительно старого «железа» лучше подойдёт какой-либо из «легких» дистрибутивов Linux. Хотя для «железа суперстарого», в силу особенностей обращения с памятью, FreeBSD опять окажется предпочтительной — правда, также в одной из старых своих ипостасей, например, 4-й ветки.

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

Ubuntu vs Fedora

Апрель, 2012

Эта серия заметок в наименьшей степени претендует на соответствие завету Тацита, поскольку была написана на злобу дня – и злоба эта продолжается по сей день. Или, напротив, день этой злобы ещё не кончился. Однако однако эмоции несколько отгорели, и итоговая статья, написанная уже непосредственно для этой книжки, надеюсь, будет более сдержанной (см. Большое Сравнение: Fedora, openSUSE, Ubuntu).

Вступление

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

Кто доблестней, Кох или Вагнер? Пускай без бряцания шпор.

До недавнего времени мне не хотелось влезать в эту тему, и я ограничивался участием в вялотекущих перепалках на Юниксфоруме и в Джуйке. Однако в конце концов нервы мои не выдержали – и в результате вниманию читателей предлагается данное сочинение.

Завязкой сюжета послужила информация об отчёте Linux Foundation, посвящённая вопросу вклада в ядро Linux, сделанному различными фирмами, организациями и лицами в 2011 году. На русском языке она прозвучала, например, на OpenNet'е. Одновременно её интерпретацию озвучил Пётр Леменков в заметке «Кто разрабатывал ядро Linux в 2011 году?»

Пересказывать содержание отчёта и тем более его возможных (и/или сделанных) интерпретаций не буду. Чисто фактографически же это выглядит так: наибольший вклад в разработку ядра Linux (далее – LK), если не считать собирательного образа в лице Большого Бухарца Сообщества, внесли сотрудники Red Hat (которые по совместительству являются и основными разработчиками дистрибутива Fedora). Это – по количеству внесённых (и принятых) патчей. По числу же патчеодобрятелей Red Hat оставил позади даже всё сообщество, вместе взятое.

Отдельной строкой был отмечен вклад компании Microsoft, занявшей 17-е место по числу патчей. Правда, все они касаются только поддержки Linux как гостевой ОС в их собственной системе виртуализации Hyper-V. Да и объём кода невелик. Однако он разбивается на много патчей, что позволило компании войти в двадцатку сильнейших.

В сети же по следам этого отчёта «отдельно, с большим наслажденьем» комментировался вклад фирмы Canonical в развитие LK. Точнее, видимая незначительность этого вклада: в отличие от Microsoft, Canonical по числу не сподобилась причислению к «великолепной двадцатке». Дело дошло до обвинений в том, что в Ubuntu вообще не сочиняют код, а только передвигают кнопки справа налево и перекрашивают обои. Впрочем, такие мелкие «дружеские» подначки в адрес Ubuntu и Canonical последнее время стали любимым развлечением пользователей некоторых более иных дистрибутивов.

Разумеется, «ответ Чемберлену» ждать себя не замедлил. Марк Шаттлворт выступил с объяснениями, почему основанная им компания не участвует в разработке ядра. И ответ его можно свести к двум «апрельским» тезисам:

1. для Canonical приоритетным является развитие Ubuntu как цельной системы, направленной на благо пользователя, кем бы он ни был (домохозяйкой или админом огромной сети);

2. развитием LK и без неё занимается много сильных компаний и команд, так что Canonical вмешивается в это дело лишь постольку, поскольку оно требуется для развития собственного бузинеса.

И итоговый отчёт, и ответ Марка вызвали бурную полемику как Рунете, так и в мировом масштабе. За некоторыми обсуждениями я следил и даже по мере сил в них участвовал (пока не надоело). Они и составили этнографическое основание для настоящих заметок.

Важно заметить, что все эти обсуждения протекают на фоне других разговоров, касающихся новшеств, продвигаемых в дистрибутиве Fedora, что косвенно затрагивает также и Red Hat (то есть RHEL). И если острота дискуссий по поводу GNOME 3 или pulseaudio отошла в прошлое, то страсти вокруг systemd прямо так и кипят. Усугубляясь смежными темами, как то: слиянием проектов systend и udev, введением новой системы записи log'ов или предложением переноса в сферу компетенции systemd части функций интегрированных сред (KDE, GNOME, XFce).

Однако, помимо этого сиюминутного фона, есть и более широкая историческая ретроспектива сегодняшних дискуссий. И это – историческая составляющая моих заметок. Так что с истории я и начну.

Но сначала оговорю свою личную позицию. Ни к Fedora, ни к Ubuntu я не питаю ни гнева, ни пристрастия. На протяжении нескольких лет я был пользователем и того, и другого дистрибутива – то есть, если во временной последовательности, сначала другого, потом того. В настоящее же время (на момент сочинения заметок) не применяю ни один из них. Так что ни малейшей личной заинтересованности в них не испытываю, и потому попытаюсь вести обсуждение более или менее объективно – насколько это возможно при обсуждении дистрибутивов.

Ретроспектива

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

Как известно, дистрибутив Red Hat не был первым дистрибутивом Linux. А одноимённая компания не была первой на поприще бизнеса FOSS related – похоже, что здесь первенство за S.u.S.E., двадцатилетие развития которой мы скоро будем праздновать. Не исключено, что были и другие фирмы, пытавшиеся заработать на распространении и поддержке дистрибутивов Linux и свободного софта вообще – но до наших дней они не дожили, и память о них затёрлась.

Но фирма Red Hat безусловно была

• первой FOSS-компанией на Американском континенте (повторяю, за исключением вымерших гипотетических участников), и

• первой успешной компанией, подвизавшейся на ниве свободного софта.

И, к слову сказать, пока она оказывается и последней: ни одной компании, основывающей свой бизнес на распространении и поддержке свободного софтае повторить успех Red Hat до сих пор не удалось. Даже упомянутой выше S.u.S.E., имевшей, казалось бы, фору почти в два года.

Почему? Рискну предположить, что одной из причин было как раз американское происхождение компании. И, как следствие, потенциальная возможность выхода на существенно более широкий рыночный простор, чем могла открыть перед S.u.S.E. Германия или даже вся Европа.

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

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

Так или иначе, но последние годы прошлого тысячелетия Red Hat стал самым распространённым дистрибутивом в мире, и не только в корпоративной сфере: само имя его прочно ассоциировалось среди немногочисленных ещё тогда «простых» пользователей прочно ассоциировалось с именем ОС Linux, хотя особым дружелюбием к пользователю он, по нынешним меркам, и не блистал. Да и внимания им при разработке дистрибутива уделялось постольку, поскольку...

Первенство Red Hat не поколебало ни возникновение столь же корпоративного Caldera Linux, ни создание первого «юзерофильного» дистрибутива – Mandrake (и продолжателей тенденции – StormLinux и Corel Linux), ни поднявшаяся в начале нулевых годов волна интереса к дистрибутивам Source Based (Rock Linux, Gentoo, первоначально CRUX и Archlinux), ни появившиеся тогда же системы быстрого равёртывания, ориентированные, как и Mandriva, на конечного пользователя (Vector Linux, Mepis). S.u.S.E., она же SUSE и Suse, уверенно удерживала второе место в тройке корпоративных участников, но с очень большим отрывом.

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

В результате в Red Hat, видимо, почувствовали себя королями корпоративной горы и окончательно сосредоточили свои усилия в этой области, полностью свернув десктопную линию. Причиной чему, видимо, была откровенная неудача первых юзерофильных дистрибутивов: из неё на плаву остался лишь Mandrake, преобразованный в Mandriva, да и та была скорее уделом хоть и десктопных, но всё-таки энтузиастов. Прочие же либо сгинули в безвестности, либо так и не получили сколько-нибудь широкого распространения.

В Red Hat же десктопное направление было выделено в отдельное производство – в развиваемый сообществом, при поддержке фирмы, дистрибутив Fedora. Каковой первоначально рассматривался в основном как испытательный стенд для апробации всяких новшеств, которые потом включались (или не включались) в коммерческую линию дистрибутивов RHEL.

Это с одной стороны. С другой же, Fedora выступала в роли Red Hat для бедных – пользователей-индивидуалов, не желающих оплачивать техническую поддержку RHEL или в ней не нуждающихся. Но желающих, тем не менее, приобщиться к величию «редхатианской мысли».

С ролью RHEL'овского полигона Fedora справлялась вполне успешно – и неудивительно, ведь многие её основные разработчики по совместительству были и сотрудниками Red Hat. И они имели здесь возможность порезвиться, не будучи скованными узами «партийной дисциплины». Именно отсюда и берёт начало традиция, развивающаяся по сей день: изрядная часть новшеств в LK берёт своё начало из проекта Fedora. На втором же месте неизменно держится Suse, принявшая, после попадания в объятия Novell, ту же модель разработки – расщепление на коммерческую ветку SLE и свободную openSUSE.

А вот в амплуа собственно десктопа Fedora поначалу показала себя не лучшим образом. Первые релизы Fedora Core носили настолько экспериментальный характер, что даже установить или не установить их на вполне стандартное «железо» можно было почти с той же вероятностью, что встретить или не встретить динозавра на улице Москвы. Ну а чтобы система ещё и беспроблемно работала после установки – об этом могли мечтать только те, кому динозавра всё-таки встретить удавалось.

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

В общем, на исходе первой половины нулевых годов сложилась вполне благостная картина:

• сотрудники Red Hat и Novell развивают свои коммерческие продукты, а в свободное от этого время экспериментируют в своих песочницах, при участии сложившихся вокруг них сообществ волонтёров;

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

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

• Mandriva балансирует между банкротством и получением немыслимых правительственных контрактов (или всё-таки субсидий?);

• пользователи Gentoo, набравшись опыта, задумываются, а куда бы им переползти, но пока стойко продолжают перекомпилировать систему по будням, отдыхая по праздникам;

• разнообразные нишевые дистрибутивы и дистрибутивы второго эшелона... да кто же уследит, что происходит в их мирках; разве что некоторым, как Archlinux, удаётся попасть в запас эшелона первого.

В общем, идёт нормальная цивилизованная жизнь, разговоры о Linux'е на каждом десктопе и скором виндовом апокалипсисе ведутся чисто по привычке. И ничто, казалось бы, не в силах нарушить этого благолепия. Пока в него не вторгается второй протагонист (или антагонист?) нашей мелодрамы.

Появление второго протагониста

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

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

Надо сказать, что «действующие» пользователи Linux встретили появление Ubuntu... да никак они его не встретили. Ибо помнили ещё и «год великого перелома» – 1999-й, обещавший приход Linux'а на каждый пользовательский десктоп. И первую волну юзерофильных дистрибутивов, каждый из которых представлялся как «Linux с человеческим лицом» (можно подумать, что до этого у Linux'а было не лицо, а... ещё одна спина). И то, как эти человеколицые дистрибутивы меняли имена, исчезали или влачили жалкое существование, не нужные никому, даже своим создателям.

Кстати, впервые выражение «Linux с человеческим лицом» я услышал (точнее, прочитал) применительно к Corel Linux, типичному представителю юзерофильных дистрибутивов первой волны. И, столь же кстати, бывшего в этой волне первым «барашком» – если оставить за чертой Mandrake, который был всё-таки дистрибутивом всамделишним, и под именем Mandriva остаётся им до сих пор. Так вот, Corel Linux, возникнув в недрах одноимённой фирмы (да-да, той самой, которая Corel Draw – она тоже оскоромилась на ниве Linux'а, но это совсем другая история) в 1999 году и удостоенный кучи хвалебных отзывов в околокомпьютерных СМИ, в том числе того самого, про лицо (что невольно вызывало вопрос: если это его лицо, то какова же его, да простят меня читающие это дамы, жопа)...

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

Так что те самые действующие пользователи, интересующиеся новыми дистрибутивами, поначалу пророчили и Ubuntu ту же судьбу. Должен сознаться, среди них, наряду со многими, был и автор этих строк. Наиболее определённо о первой версии Ubuntu высказался мой старый товарищ, возможно, памятный посетителям Юниксфорума и форума Позикса по нику DW. Установив Ubuntu одним из первых в нашем кругу, он сказал примерно так:

Очень интересный дистрибутив. Но для своей задачи – ознакомления совсем ньюбов – совершенно не пригоден: слишком много надо допиливать.

И в первой версии (04.10) так оно и было. Что опять-таки не способствовало оптимистической оценке Ubuntu. Так что я выкинул его из головы.

Однако это был один из тех нередких случаев, когда провидцы и ясновидцы, даже будучи очевидцами, оказались не правы (повторяю, это и ко мне относится). Ибо не учли личности организатора всего этого безнадёжного предприятия. А меры, предпринятые Марком Шаттлвортом для продвижения своего произведения, были дезординарными, с одной стороны, и вполне тривиальными – с другой.

Самой дезординарной мерой была организация заказов на компакты дистрибутива безвозмездно, то есть даром – с бесплатной же почтовой доставкой по всему миру, в том числе по России. И это действительно работало – даже в самых удалённых городах и весях нашей необъятной родины.

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

Это была одна из причин почти мгновенного роста популярности Ubuntu. Вторая же, как я говорил – вполне тривиальна: интенсивная «работа над ошибками», и не только своими. Ubuntu изначально позиционировался как очередной Linux с человеческим лицом, с одной стороны, и концентратор самого свежего софта – с другой. В плане первого вопроса были учтены все ошибки прежних попыток «очеловечивания» Linux'а. И в итоге разработчикам удалось если не найти оптимум между «настройкой с паяльником и осциллографом» и «молчаливыми визардами для полных идиотов», то вплотную к нему приблизиться.

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

В результате осенью 2005 года, когда, подстрекаемый лавинообразным нарастанием сетевых публикаций об Ubuntu (что само по себе было показателем популярности), я серьёзно заинтересовался этим дистрибутивом, то обнаружил вполне зрелую систему, пригодную к применению «искаропки» пользователем любого уровня. Разумеется, не без некоторых шероховатостей, касавшихся в первую очередь локально-зависимых вещей, но это было вполне естественно: обеспечить равную поддержку всех языков, от зулусского до русского, за столь короткий срок физически невозможно. Да и лечилось всё это достаточно просто – руками самих утопающих... то есть, пардон, нативных носителей языка.

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

Не менее, чем количество, показателен состав пользователей Ubuntu в сравнении с более иными дистрибутивами. Для начала, в многочисленных опросах о первом дистрибутиве Linux на протяжении первой половины нулевых годов неизменно, и с большим отрывом, одерживала победу Mandrake, она же в замужестве Mandriva. Но те же опросы о текущем дистрибутиве показывали, что после успешного старта с Mandriva изрядное число пользователей перетекало на другие системы.

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

В то же время немало оказалось и действующих пользователей Ubuntu, для которых этот дистрибутив был не первым, и не вторым, тех, кто прошли и ручную настройку Slackware, и тотальную компиляцию Gentoo, и роман «Ядро и мир» от FreeBSD, а возможно, и сборку LFS. И чьё сердце успокоилось в казённом доме тихой и уютной Ubuntu.

В своё время Марк в интервью журналу Linuxformant (тогда ещё английской версии), сказал о двух категориях потенциальных пользователей Ubuntu. Первая:

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

И вторая категория, в которую

...входят люди, которые действительно любят свободное программное обеспечение за его качество и техническое превосходство – то есть те, кто является по-настоящему предан идее open source.

Иначе говоря, Ubuntu ориентирован, с одной стороны, на тех, кто сам все знает и умеет, с другой – на тех, кто ничего о компьютерах не знает, знать не хочет, но готов положиться на знающих.

В этом аспекте интересно, что среди пользователей Ubuntu высок процент тех, кто не имеет к компьютерам ни малейшего отношения – ни по долгу службы, ни по велению души. А разве что по жизни вынужден ими пользоваться. Тогда как среди пользователей иных дистрибутивов процент этот исчезающе мал. Более того, среди моих личных, реальных и виртуальных, знакомых (а круг и тех, и особенно других у меня весьма широк) вообще нет людей, не работающих в околокомпьютерных сферах или просто не интересующихся компьютерами как хобби, которые использовали бы какой-либо дистрибутив Linux'а. Разумеется, если этот Linux – не Ubuntu.

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

Буквально за пару лет Марку Шаттлворту, фирме Canonical, примкнувшим к ним независимым разработчикам и, не в последнюю очередь, активным пользователям – создателям сайтов и авторам блогов убунтийской тематики, удалось превратить, казалось бы, рядовую «человеко-мордастую» поделку в самый популярный и распространённый дистрибутив планеты.

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

Последствия

Предыдущую заметку я закончил на том, что Ubuntu понадобилось всего года два для того, чтобы добиться если не доминирования среди Linux-десктопов, то явного преобладания. То есть той популярности среди узкого круга широких народных масс, к которой на протяжении полутора десятков лет стремились и Red Hat в свою ещё и десктопную пору, и Debian во время своих самых широких имперских притязаний, и Mandrake с Mandriva при всей своей перманентной юзерофильности.

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

Первым и, пожалуй, самым заметным, следствием был параллельный рост популярности GNOME. Да-да, дорогие мои читатели – поклонники этой рабочей среды: своей популярностью она обязана не команде разработчиков, не своим несравненным достоинствам (каковые в разное время трактовались диаметрально противоположным образом), и даже не усилиям Red Hat, продвигавшей её со дня появления. А исключительно широкому распространению Ubuntu, где она выступала в качестве основного – а для начинающих пользователей и единственного десктопа.

Напомню, что первоначально в качестве объектов бесплатной рассылки выступали собственно Ubuntu и её «образовательный» вариант – Eduduntu, обе – с GNOME в качестве рабочего окружения. Kubuntu с KDE включилась в этот процесс существенно позднее, и участвовала в нём не очень долго.

В сочетании с шоковым действием, оказанным на старых KDE'шников первыми версиями 4-й ветки этой среды, это привело к тому, что GNOME по популярности с ней почти сравнялся.

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

А вот второе следствие было более общим: лавинообразный рост источников информации о Linux'е. Ибо к середине нулевых годов писательский пыл линуксоидов первого призыва подыссяк. И причины того понятны. Ибо проблемы, которые волновали поколения пользователей, начинавших свой путь в Linux ещё в прошлом тысячелетии, и бывшие поводом для сочинения всякого рода FAQ'ов, How-to'ёв, Tips'ов и Hint'ов, ушли в прошлое.

К моменту массового распротсранения Ubuntu ни в одном из «больших» дистрибутивов уже почти не требовалось ни ручной правки Иксовых конфигов, ни построения программых RAID'ов и систем LVM «с нуля», ни прикручивания файловых систем, отличных от умолчальной ext2, ни, в наших условиях, кириллизации. Все эти вопросы решались «искаропки», требуя в худшем случае небольшой косметической доводки. И в результате из прежних линуксописателей на вахте остались только те, для кого, как для автора этих строк, это занятие стало чем-то вроде профессии.

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

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

– Вот вы тут сидите и не знаете, а пиписька-то х...м называется!

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

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

Ещё одно частное, но очень важное для конечного пользователя следствие распространения Ubuntu – появление в Иксах качественных шрифтов. Точнее, не столько даже самих шрифтов, сколько механизмов их экранного воспроизведения. Если раньше

• для практической работы широко применялись пиксельные шрифты,

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

• а умельцы вручную патчили freetype для включения поддержки интерпретации байткодов и субпиксельного хинтинга,

то в Ubuntu качественный рендеринг шрифтов обеспечивался из всё той же тумбочки коробки.

И ещё очень важный момент: Ubuntu, развивая традиции систем быстрого развёртывания, начинавшейся со сгинувшего StormLinux и продолженная в таких дистрибутивах, как Vector Linux, MEPIS, Zenwalk, довела до логического завершения безальтернативную «установку в пять кликов», милую сердцу начинающего пользователя. И в то же время сохранила идущую от Debian'а альтернативную текстовую инсталляцию, допускающую широкое ручное вмешательство со стороны пользователя, знающего, что он делает.

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

Нововведения Ubuntu привели к повышению планки «юзерофильности» в хорошем смысле слова; или, если угодно, к понижению порога вхождения для начинающего пользователя.

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

Но, так или иначе, с появлением Ubuntu мир Linux изменился, и это – очередной медицинский факт, с которым отныне должны были считаться все дистростроители. Так что давайте посмотрим, как отреагировали на это строители нашего первого протагониста.

Ещё немного ретроспективы

Итак, прошлая заметка заканчивалась тем, что Ubuntu явочным порядком (и самим фактом своего существования) изменяла мир Linux'а: если раньше пользователь в основном приспосабливался к этому миру, то ныне мир стал приспосабливаться к нему. А что поделывали в это время Fedora и стоящий за ней Red Hat?

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

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

В общем, продолжалась та самая нормальная цивилизованная жизнь, о которой я написал в одной из предыдущих заметок. И никак не было заметно по Fedora, что с появлением Ubuntu эта жизнь изменилась, и мерки цивилизованности стали другими.

Так продолжалось до того момента, пока в Ubuntu не замахнулись на святое – на серверы. Не то чтобы Ubuntu Server вдруг в одночасье стал прямым конкурентом для серверов на RHEL. Более того, отношение к Ubuntu в амплуа сервера было ещё более скептическим, чем поначалу – к Ubuntu в роли пользовательского десктопа. По крайней мере, на Linux-ресурсах было хорошим тоном иронизировать по этому поводу. Кстати сказать, это положение не изменилось и по сей день.

Но в Red Hat сидят люди серьёзные, и им было не до иронии. Может быть, потому, что они вспомнили историю, начавшуюся в 1995 году. Поскольку я тоже её помню, и меня ещё не замочили («Братва и кольцо»), расскажу её для тех, кому не довелось жить в то интереснейшее время.

Всё началось с того, что была выкована супер-мега-ОСь выпущена Windows 95. К которой, как и к Ubuntu, поначалу никто не относился серьёзно: она воспринималась как платформа для запуска игрушек. Даже для всамделишней офисной работы резонные люди консервативного склада отдавали предпочтение старой, не очень доброй, но досконально известной Windows 3.1/WfW 3.11. Прогрессисты же склонялись к OS/2 3 Warp, затем 4 Merlin. Что же до серверов на Windows 95 – такое могло привидеться в кошмарном сне с большого перепоя.

Нет, у Microsoft была в загашнике и самая настоящая ОСь – Windows NT, от которой по прямой линии происходят все варианты всех современных Windows. Но как серверная платформа и даже платформа для рабочих станций она и близко не могла конкурировать не только с UNIX-машинами – в те времена ещё и несоизмеримыми по мощности с любыми компьютерами на x86, но даже с рассчитанной на последние OS/2. А на десктопах применение NT тормозилось интерфейсом, унаследованным от Windows 3.1, который в считанные месяцы после выхода 95-ой стал казаться старомодным.

Однако именно тогда, на исходе 1995 года, в одной из колонок Георгия Кузнецова (в то время – главного редактора «Компьютерры») проскользнула пророческая фраза (воспроизвожу по памяти):

Пользователи притащат Windows 95 на службу, и нам, профессионалам, придётся с ней разбираться).

Так оно и случилось, хотя и не сразу. Но постепенно Windows 95 утвердилась на рабочих местах различных контор. Я хорошо помню, как у нас на службе она постепенно вытесняла не только старушку три-первую, но и недавно установленного «Кривого Мерлина».

А затем... затем Microsoft в очередной раз всех напарила, выпустив Windows NT 4 с интерфейсом в стиле modern, то есть a la Windows 95. И именно с неё началось распространение NT-серверов и рабочих станций.

В результате в 1997 году – а кто не помнит, это был год рождения массового российского Интернета, – некоторые московские провайдеры впервые стали предлагать хостинг не на UNIX-машинах, а на NT-серверах. Причём последний стоил дороже. На вопрос – почему? – один из таких провайдеров дал характерный ответ:

Потому что веб-мастер может управлять своим сайтом с помощью привычного интерфейса.

Судя по тому, что означенная услуга пользовалась спросом, аргумент действовал.

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

Видимо, вспомнили эту историю и в Red Hat – ведь Ubuntu тоже начала свой путь с оккупации пользовательских десктопов. В том числе десктопов школьников и студентов. А поскольку, как я уже говорил, пользователи Ubuntu, в отличие от Mandriva, уже показали завидное постоянство своих привязанностей, резонно было ожидать, что со временем эти самые школьники и студенты принесут её и на рабочие места. Так что пора было принимать меры по десктопизации если не RHEL, то Fedora. Какие? Скоро увидим.

Федорины меры

Я пропустил момент, когда начали приниматся меры по десктопизации Fedora. Да, скорее всего, его и уловить было невозможно, поскольку поначалу проводились они за кулисами. Так что остаётся только попытаться реконструировать события.

Рискну предположить, что за этими самыми кулисами процесс пошёл примерно во время выхода 7-го релиза в мае 2007 года, когда Fedora утратила Core'мычное дополнение к своему имени. Поскольку частица Core некоторым образом ассоциируется с ядром (или, скорее, сердцевиной), она символизировала тот факт, что разработчики дистрибутива заняты серьёзными делами, типа усовершенствования ядра и системных сервисов, а не мелкими поделками из разряда десктопных приблуд.

Однако, как я уже говорил, времена изменились, изменилась и система приоритетов федорианцев. И намёки на ядерную зацикленность показались неуместными. Однако, учитывая полугодичный релиз-цикл дистрибутива, можно предположить, что решение об изменении ориентации было принято ещё осенью 2006 года. А толчком для него послужил выход Ubuntu 6.06 LTS – первой «долгоиграющей» версии этого дистрибутива. То есть – откровенно нацеленной на применение, в том числе, и на серверах.

Как бы то ни было, когда я плотно засел на Fedora, а было это летом 2009 года, вскоре после выхода релиза 11, десктопизация этого дистрибутива шла полным ходом. И мне выпала возможность наблюдать её на протяжении четырёх релиз-циклов – вплоть до 14-го релиза включительно. Почему не далее? Этот вопрос имеет прямое отношение к теме настоящих заметок, и со временем я вернусь к нему.

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

Первое, что бросается в глаза при знакомстве с дистрибутивом – это его визуальное быстродействие или, по выражению Александра Иванова aka Hrafn, отзывчивость в отношении пользовательских приложений. Понятно, что это – лишь побочное следствие оптимизации ядра (и, в частности, планировщика), которая проводилась в рамках подготовки корпоративного полуфабриката, но конечному пользователю от этого хуже не становилось.

Второй момент, весьма значимый для пользователя – объединение всех пакетов, не имеющих официальной поддержки, но развиваемых примкнувшими майнтайнерами, в единый репозиторий – RPM Fusion. В полной мере я оценил это после знакомства с openSUSE, где такие пакеты раскиданы по куче отдельных, часто мелких (буквально на один пакет) хранилищам.

Третьим деянием на пути к массовой десктопизации Fedora был отказ от «скользящей» модели обновления дистрибутива (так называемой rolling release). Каковое, конечно, очень блаародно и греет душу Linux-энтузиаста, всегда имеющего самые свежие версии ядра, Иксов и прочих основных компонентов системы. Однако, при неудачном стечении обстоятельств (от которых не застрахован никто и нигде), способно доставить несколько неприятных минут пользователю массовому, занимающемуся выполнением практических задач без оглядки на версии программ, это делающих.

И последнее – исправление тех самых мелких, но раздражающих багофич, о которых я говорил ранее, и добавлении различных полезных мелочей на стадии Firstboot (типа активизации sudo).

Впрочем, в отношении последнего пункта очень велика была роль проекта Russian Fedora, возникшего осенью 2008 года, и с тех пор выпускавшего собственные сборки дистрибутива (RFRemix) одновременно с выходом оригинального релиза. Именно в нём и были реализованы впервые столь важные для пользователя мелочи. К коим следует добавить и сборку библиотек шрифтовой поддержки с опциями интерпретации байткодов (что по истечении срока действия соответствующего патента попало и в оригинальную Fedora) и субпиксельного рендеринга.

Важным моментом для конечного пользователя было не только существование RFRemix самого по себе – системы, собранной с учётом локальной специфики, но и наличие поддержки на языке родных осин. Таковая осуществлялась, во-первых, на форуме проекта, во-вторых – с помощью постоянно пополняемой русскоязычной документации, в первую очередь вполне оригинальной Wiki.

При этом RFRemix продолжала сохранять полную совместимость с оригинальной Fedora: одну сборку в другую можно было превратить легким движением руки – и в любом направлении. Что было немаловажно для отечественного пользователя, часто испытывающего недоверие к отечественной же продукции – иногда законное, но в данном случае абсолютно неоправданное. Так что, убедившись в последнем после установки оригинального дистрибутива, пользователь мог безболезненно перейти на русскую сборку.

В общем, пресловутая «готовность к десктопу», о которой последнее время говорят не меньше, чем о «человеческом лице» Linux'а – в недалёком прошлом, возрастала и в оригинальной Fedora, и, особенно, в RFRemix от версии к версии. И достигла своего апогея в релизе 14 (ноябрь 2010 года).

Предшествующие версии RFRemix (по крайней мере с 11 по 13, которые я, что называется, «щупал рукаами»), можно было рекомендовать начинающим пользователям – но с рядом оговорок. Впрочем, число их от релиза к релизу всё сокращалось. И 14-й релиз я взял на себя смелость рекомендовать уже безусловно и всем пользователям, вне зависимости от задач и начальной подготовки. В общем, как сказал мой коллега Сергей Голубев в одном из своих обзоров:

... еще один Linux пошел в народные массы.

Увы, сказал он это задним числом – потому что с выходом 15-го релиза, имевшим место быть в марте 2011, выяснилось, что предпосылки к обретению статуса образцового дистрибутива оказались похеренными.

Как это случилось – будет рассказано в следующей заметке. А на вопрос почему? я постараюсь дать предположительный ответ несколько позже.

Fedora 15: переломный релиз

Так что же трагического для десктопных пользователей случилось с выходом 15-го релиза Fedora? Такого, что дало основание сказать Сергею Голубеву (в упомянутом ранее обзоре), что

... все рухнуло в одночасье.

Давайте посмотрим, попытавшись заодно оценить меру «рушения».

Собственно, тревожные симптомы можно было уловить ещё до выхода релиза – по сообщениям в новостях, а затем и по тестовым версиям.

Первой ласточкой (или, скорее, воробушком) было переименование сетевых интерфейсов. Вместо традиционных для Linux и давно привычных имён типа eth# в Fedora явочным порядком вводились различные наименования для встроенных сетевых чипов и карт для PCI-слотов. Мотивировалось это проблемами, возникающими при подключению к компьютеру нескольких сетевых устройств, когда нумерация одноимённых интерфейсов могла измениться.

В обоснованность этих опасений вдаваться не будем. Тем более, что как раз десктопных пользователей это не особенно волновало – мало у кого из них в машине имелось более двух сетевых устройств, а большинство так вообще обходилось одним. Просто запомним этот маленький фактик – со временем он найдёт себе место в общей картине.

А вот вторая ласточка была куды жирней, и для десктопного пользователя тянула уже на приличную курицу. Это было внедрение в качестве рабочей среды по умолчанию пресловутого (или знаменитого) GNOME 3 с его GNOMEShell'ом. О его весьма спорных достоинствах и бесспорных недостатках уже написано без счёта постов на форумах и в блогах. Немало говорено и о том, как превратить его в почти нормальный GNOME 2 – кажется, 90% всех форумных постов, так или иначе касавшихся Fedora 15 и GNOME 3, были посвящены этому вопросу.

Так что просто «кратко резюмирую вчерашний уж базар», не вдаваясь, повторяю, в материи, столь любимые некогда Великим Советским Поэтом:

GNOME 3 – откровенно нишевое решение, ориентированное на устройства, управляемые пальцами и яйцами стилами. Которое столь же откровенно (и весьма агрессивно) продвигается как решение универсально-десктопное.

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

В рамках же текущего момента остановимся на возражениях против высказанного резюме. Даже не самого резюме – возражения против него я встречал только от двух категорий.

Во-первых, со стороны лиц, связанных с проектом Fedora и Russian Fedora. Ну им как бы по долгу службы положено, это я понимаю. Хотя от главного сборщика RFRemix, Аркадия Шейна aka Tigro, дифирамбов в адрес «третьегнома» я тоже не слышал.

Ну а во-вторых, радетелями за GNOME 3 в основном выступают пользователи, для которых Linux-машина является не рабочим инструментом, а объектом развлекательного плана. Это типа такое этнографическое наблюдение.

Но я хотел коснуться возражений против следствия из резюме – что GNOME 3 оказался на текущий момент сдерживающим фактором десктопизации Fedora. Они тоже стандартны, и сводятся к старому детскому анекдоту:

– Мама, я не люблю дедушку... – Не нравится – не ещь!

А конкретней – это предложения:

• оставаться на GNOME 2;

• использовать GNOME 3 в режиме «второгномоподобия»;

• применять более иные рабочие среды.

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

Но на самом деле всё оказывается не так просто. «Второгном» с выходом «третьегнома» можно смело зачислять в разряд того, что в биологии называют «живыми окаменелостями», вроде рыбы латимерии. Конечно, сам по себе он будет каким-то образом поддерживаться – хотя бы потому, что корпоративные клиенты Red Hat будут использовать его ещё многие годы. Будут существовать и форки – но опыт Trinity уже показал, что этот путь большого энтузиазма в массах не вызывает. Что же до режима «второгномподобия» – то его откровенная ущербность, вроде бы, сомнений ни у кого не вызвала.

А вот с более иными рабочими средами интересней. Казалось, бы – да, не тюрьма народов, «средь мира дольного для сердца вольного» есть и KDE, и XFce, и LXDE. Но это очередной случай того, что в реальности тоже не совсем так, как на самом деле. GNOME 2 в исполнении Fedora был привлекателен для начинающих пользователей и терпим для старых его нелюбителей (типа автора этих строк) своей доведённостью и интегрированностью с системными службами этого дистрибутива. А вот последнего заведомо и близко не лежало у LXDE, с этим были заметные напряги у XFce... ну разве что KDE более или менее, судя по отзывам, в этом отношении допилили.

И в итоге получается, что у Fedora, начиная с 15-го релиза, из колоды, на глазах весьма значительной категории пользователей, выпал весьма сильный козырь. А туз в прикупе, то есть GNOME 3, при ближайшем рассмотрении оказался даже не третьей дамой, а четвёртым валетом, играющим только при единственном раскладе у вистующих.

Что же, дядя Лёша, спросите вы меня, ты что, дяденек из Red Hat'а совсем уж за лохов держишь, которые ферзя от туза не отличают? Отнюдь – отвечу я вам. Дяди эти фишку просекают чётко, и мы скоро в этом убедимся. Но сначала нам надо рассмотреть ещё одно агрессивно продвигаемое новшество Fedora – не менее пресловутую, чем «третьегном»: systemd и связанные с ней материи.

Предстрастие к systemd

«Гномомстрасти», описанные в прошлой заметке, в основном уже отгорели. Хотя и поныне чуть ли не каждую неделю на Distrowatch'е можно видеть дистрибутивы (как правило, клоны Debian'а или Ubuntu) с GNOME 2 или вариациями на его темы в качестве десктопа по умолчанию. А вот страсти по очередной новинке, впервые увидевшей свет в составе Fedora, systemd, только разгораются. И причину их опять надо поискать в истории.

Как известно, исторически сложилось так, что Linux ассимилировал систему инциализации в стиле SysV, с главным процессом init и уровнями запуска (Runlevel) – наборами сценариев на разные случаи жизни. Замечу тут в скобках, что BSD-подобный стиль инициализации некоторых дистрибутивов Linux (Slackware, Gentoo, Arch, CRUX) – своего рода эвфемизм: от присутствия главного сценария инциализации и его конфига уровни запуска в них (свойственные Linux и отсутствующие в BSD-системах) никуда не исчезают.

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

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

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

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

Коллеги, мы же профессионалы. Давайте просто расстегнём штаны и померяем.

Так и время загрузки есть объект для сравнительного измерения при форумных дискуссиях. Практический смысл его сокращения стремится к нулю. Ибо при стационаром использовании в рабочем (не развлекательном!) режиме для персонального компьютера норма – одна загрузка в сутки, а то и реже. И кустарём-надомником это время тратится на совершение утреннего туалета, а офисным работником – на обмен приветствиями с коллегами, первую рабочую сигарету etc. А старт любой более-менее современной машины, пусть и перегруженной сервисами по самые... уши, всё равно пройдёт быстрее, чем эти увлекательные занятия.

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

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

В настоящее же время понятие скорости загрузки вообще утрачивает физический смысл. Это связано с постепенным распространением SDD-накопителей, по крайней мере, в качестве носителей для системы и приложений. Скорость чтения с них на порядок превышает таковую для традиционных HDD. И на этом фоне время запуска стартовых служб становится исчезающе малым.

Сужу по своему опыту. Через мои руки прошло два SSD Corsair с интерфейсами SATA II и SATA III, и выполненный в виде платы PCI-E OCZ Revo Drive. Все дистрибутивы, которые у меня были в то же время (Fedora, PCLinuxOS, openSUSE) грузились с любого из них примерно за 20 секунд – из них всё мало-мальски уловимое время уходило на поиск DNS-сервера и синхронизацию по NTP, а собственно процесс инициализации, вне зависимости от схемы её (классический init, upstart или systemd, о которых скоро зайдёт речь) занимал какие-то мгновения.

Скажу больше: нынче и с традиционного HDD система подчас грузится за меньшее время, нежели уходит на процедуру POST при включении машины – особенно на «навороченных» материнских платах. После таких наблюдений любые разговоры о «проблеме скорости загрузки» могут восприниматься только в юмористическом ключе.

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

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

Не случайно, когда несколько лет назад проблема ускорения загрузки вдруг стала актуальной (или показалось, что стала таковой), практически одновременно было разработано несколько «параллельных» альтернатив классическому init'у: runit, daemontools, initng. Была даже попытка портировать на Linux систему инициализации MacOS X – launchd. Правда, некоторую известность из них приобрёл, пожалуй, только initng. Однако и он, насколько я знаю, не прижился даже в родном дистрибутиве – в Gentoo.

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

Примерно в том же ключе init'оподобия была оформлена и система upstart. Она разрабатывалась в рамках проекта Ubuntu на достаточно ранних стадиях его жизни (upstart 0.1.0 – сентябрь 2006 года). И сначала за пределами родного дистрибутива не использовалась. Однако весной 2008 года система upstart, как прогрессивная, была включена... куда? Разумеется, в самый фронтирный дистрибутив своего времени, в Fedora 9-го релиза.

Казалось бы, поддержка со стороны двух самых «крутых» носителей прогресса в Linux-мире предвещает триумфальное по нему шествие советской власти этой системе. Но:

Судьба играется с пакетом Пакеты же клепает человек

И, как мы скоро увидим, человек такой нашёлся.

Страсти по systemd

Итак, фронтирнейший дистрибутив Fedora включает в себя вполне такую фронтирную систему инициализации upstart, что вроде бы обрекает последнюю на светлое будущее во всех дистрибутивах. И действительно, в виде опции она появляется в тестовой ветке консервативнейшего Debian'а, поговаривают о включении её в openSUSE (и вроде бы она промелькнула в какой-то из тестовых версий 10-го релиза).

Но что это за фронтирный дистрибутив, который довольствуется новшествами, написанными в дистрибутиве ином? Непорядок, который срочно должен быть исправлен. И весной 2010 года Леннарт Поттеринг, сотрудник Red Hat, ранее прославленный созданием аудиосервера PulseAudio, выступает с новой прогрессивной инициативой – системой инициализации по имени systemd.

Сначала она имеет статус прототипа, к лету того же года обретает права 1-го релиза, а уже весной 2011 года оказывается в составе Fedora 15 – одновременно с GNOME 3, о котором говорилось ранее.

Коренных отличий systemd от upstart – два. Первое – ещё большее распараллеливание процедуры запуска стартовых служб за счёт полного отказа от их последовательного осуществления: сначала создаётся канал связи между зависящими друг от друга сервисами, а затем уже происходит их запуск.

И второе – большинство сервисов штатно запускается не shell-скриптами, а скомпилированными Си-программами. Хотя пока, в целях совместимости, не возбраняется и запуск сценариев, в том числе и самописных.

Чем это чревато для пользователя? Двумя обещаниями: во-первых, фантастического роста скорости загрузки системы, во-вторых, возможности гибкого управления уже запущенными сервисами. Здорово, правда? А давайте посмотрим, насколько здорово.

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

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

Я не поленился, и провёл эксперимент. Благо, дистрибутив openSUSE, вслед за Fedora внедривший новую прогрессивную инициализацию, сохранил (в релизе 12.1 и в тестируемой версии будущего релиза 12.2) возможность лёгкого, безболезненного и обратимого отката с умолчального Systemd на SysVinit. Так вот, на ноутбуке с медленным HDD (5400 об./мин.) скорость загрузки при возврате sysvinit не только не увеличилась, но даже уменьшилась на 9 (девять!) секунд (46 против 55 секунд, соответственно). Иными словами, systemd проиграл старику-традиционалисту вчистую (подробнее об этом – в следующем «сравнении мужей»).

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

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

А вот как раз с этим-то и может возникнуть напряжонка. Конечно, пока ещё при инциализации в стиле systemd использование стартовых сценариев допускается. Но надолго ли хватит такого либерализма? В одном из своих сетевых заявлений Поттеринг обещал подготовить полностью shell-loss систему – и, возможно, уже выполнил это обещание.

У сторонников systemd есть два, как им представляется, неубиенных аргумента в её защиту (кроме, разумеется, утверждения, что это система новая и потому уже хорошая по определению):

1. докажи мне, что systemd плох (более мягкий вариант – покажи, в чём именно он плох);

2. сначала изучи systemd как следует, а потом говори о его недостатках.

Первый аргумент демонстрирует некоторую напряжёнку с логикой у его авторов. Не могу отказать себе в удовольствии процитировать высказывание Goodvin'а в одном из обсуждений на Юниксфоруме:

Согласно логике, бремя доказательства ложится на того, кто утверждает, что та или иная вещь или явление существуют, а не на том, кто в этом сомневается.

И далее вполне к месту упоминается знаменитый чайник Рассела.

В данном случае бременем доказательства сторонники systemd себя не отягощают – более того, на все возражения типа того, что никакого профита пользователю он не даёт, следует повторение того же тезиса: докажи, что это плохо.

Хотя с точки зрения той же логики очевидно, что если что-то новое, мягко говоря, не лучше старого (а мы недавно видели, что, совсем мягко говоря, это так и есть) – то оно плохо уже этим. Ибо требует переучивания без адекватной отдачи.

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

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

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

Некогда я затратил немало времени на ковыряние с файловой системой устройств в Linux (devfs) и HAL'ом в нём же. Последний, кстати, даже прикручивал, и вполне успешно, к FreeBSD. О потраченном времени не жалею – но возникает вопрос: и где теперь эти devfs и HAL? Брошены и погребены в одной могиле. И рядом с ней, возможно, заготовлено место и для upstart.

С ней я, кстати, каюсь – тоже не разбирался. Ибо пока собирался это сделать – оказалось, что это никакой не последний писк прогресса, а сплошной ретроградный консерватизм (отстой, по простому). А все прогрессисты должны срочно кидаться на systemd.

Вообще, стереотип поведения чукчи-хирурга, полосующего внутренности больного большим хирургическим скальпелем со словами

– Опять ничего не получилось!

весьма характерен для многих проектов Open Source, особенно связанных с Linux'ом: не доведя до ума имеющегося, всё бросать и создавать новый клон, форк, подсистему etc. Мир BSD этим грешит меньше: в частности, devfs, выскобленная и выглаженная, безотказно служит во FreeBSD по сей день.

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

Послестрастие к systemd

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

Собственно, начало этого процесса мы уже наблюдаем. Так, с systemd оказывается связанным journald – демон ведения системных журналов, продвигаемый как замена традиционному syslog... кем бы вы думали? Леннартом Поттерингом и Кеем Сиверсом, одним из основных разработчиков подсистемы udev – скоро мы и до неё доберёмся. Однако связь между ними – не только в именах разработчиков: поскольку journald представляет собой один из стартовых сервисов, он неизбежно должен укладываться в общую канву системы инициализации.

Впрочем, системный журнал – не та штука, которая больше всего интересует конечного пользователя (в отличие от системного администратора). Но дальше – больше: вслед за этим упомянутый только что Кей Сиверс объявляет о слиянии подсистемы udev и systemd в единую кодовую базу. А вот это для пользователя уже важнее: ведь udev отвечает и за настройку Иксов, и за монтирование сменных носителей, и вообще за работу всех устройств. То есть выполняет все функции именованных в прошлой заметке покойников – devfs и HAL.

Правда, в заявлении Кея специально подчёркивается, что udev может использоваться и помимо systemd, и вообще

совместимость udev из состава systemd с другими системами инициализации будет сохранена на протяжении длительного времени.

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

Таким образом, длинные руки systemd протянулись уже и в сторону Xorg, очень сильно зависящего от подсистемы udev. Но это ещё не всё: буквально через считанные дни после заявления Сиверса Auke Kok (транскрибировать не берусь), один из разработчиков системы Tizen (ОС для смартфонов и прочих гаджетов, базирующаяся на Linux) и Lunar Linux (одного из Source Based дистрибутивов второй волны), выступил совсем уж с неожиданным «рабочим почином».

Суть его «встречного плана» – в переносе функциональности, обеспечиваемой ныне дисплейными менеджерами (такими, как KDM и GDM), системами запуска рабочих сред и управления сеансами, из состава этих сред (то есть из KDE, GNOME, Xfce, LXDE)... куда? Правильно, разумеется, в systemd.

Правда, о реакции разработчиков соответствующих десктопов на столь смелую инициативу до сих пор ничего неизвестно. Можно только гадать, в каком восторге от такой перспективы пребывают ныне разработчики KDE, XFce и особенно LXDE.

А вот реакция разработчиков GNOME вполне предсказуема: они сделают так, как будет приказано. Собственно, уже сейчас, по выходе версии 3.2, systemd включён в число его зависимостей. Что, как на шести пиках в преферансе, фактически обязывает майнтайнеров всех дистрибутивов, использующих «третьегном» в своих сборках, обеспечивать поддержку новой системы инициализации, хотя бы опционально.

Впрочем, и без этого systemd расползается по дистрибутивам, по крайней мере, наиболее известным и распространённым. В openSUSE он был внедрён в релизе 12.1 в качестве системы инициализации по умолчанию (хотя, как я уже говорил, возможность «отката» на SysVinit здесь пока сохраняется).

Mandriva перешла на systemd, начиная с прошлогоднего релиза (2011). Разрабатываемый независимым сообществом форк её, Mageia, будет иметь это удовольствие во 2-й своей версии, выход которой должен случиться в ближайший месяц-два.

Чисто «сообщнические» дистрибутивы – Debian, Gentoo, Archlinux, верные своему принципу не забыть никого и ничего – уже опционально включили systemd в свои тестовые ветки.

Очевидно, что инспирировавший всё это Red Hat сменит классово чуждый upstart на родной systemd, как только волонтёры из Fedora вытящат из огня все каштаны отловят основную массу багов. И за ним, естественно, потянутся его клоны в скобках сателлиты, такие, как Scientific Linux и CentOS.

Фактически из популярных дистрибутивов совсем вне сферы systemd'изации пока остаются:

• Slackware, традиционно отстранённая от всяких «политических разборок»,

• PCLinuxOS, отличающийся здоровым консерватизмом,

• серия user-friendly дистрибутивов, типа Vector Linux и MEPIS, которые погоды не делают.

И, разумеется Ubuntu со всеми своими вариантами и клонами. Но тут я уже перехожу к выводам и прогнозам, о которых – позднее.

Отборочные соображения

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

Однако полностью отвлечься от темы в этот промежуток времени мне не удалось. Ибо страсти вокруг systemd и сопряжённых материй и не думали утихать. Разгорелись с новой силой они вокруг очередного отчёта Леннарта Поттеринга, посвящённого очередному же витку развития systemd.

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

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

Для начала резюмируем основные точки пересечения дистрибутивов Ubuntu и Fedora. Первая начинала как сугубо десктопный дистрибутив, ориентированный на конечного пользователя, и очень быстро преуспела на этом поприще. Fedora же первоначально была экспериментальной площадкой для обкатки будущих промышленных решений, реализация которых осуществлялась уже «головной организацией», то есть фирмой Red Hat.

Однако тихо и незаметно Ubuntu расширяет сферу своей деятельности в двух противоположных от десктопа направлениях. Первое – это серверные решения, реализуемые в виде периодически выходящих «долгоиграющих» (LTS) версий. Здесь конкурировать с Red Hat она в настоящее время не может и близко – но намерения обозначены. А учитывая базу десктопных пользователей (своего рода подразделения запаса), претворение этих намерений в действительность – вопрос техники и времени. Кроме того, кое-где они даже начали претворяться – но об этом чуть позже.

Второе же направление – прямо противоположное: разного рода гаджеты. И если в серверной сфере Ubuntu тащилась в хвосте не только за Red Hat и SUSE, но даже за прародительским Debian'ом, то здесь она оказалась в числе передовиков производства.

Это выразилось, во-первых, в виде сборок для нетбуков (NBR – NetBook Remix) – а ведь нетбуки, по крайней мере по первоначальной задумке, были куда ближе к гаджетам, нежели к персоналкам. Сам по NBR не получил распространения среди производителей нетбуков и не снискал (вполне заслуженно) популярности среди пользователей. Да и сами нетбуки быстро эволюционировали в сторону «недобуков для бедных», и эта ниша оказалось закрытой.

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

А во-вторых (и это тесно связано с «во-первых»), именно Ubuntu одной из первых всерьёз занялась адаптацией самой себя для альтернативных процессоров – ARM'ов всякого рода. Причём как организованно, так и частным порядком. Первое направление представлено официальными образами для ARM-архитектуры в основной ветке дистрибутива, причём как в десктопном, так и (sic!) серверном вариантах.

Индивидуальная инициатива выразилась в том, что пользователи Ubuntu прикручивали её ко всякого рода недобукам на ARM-процессорах с обвязкой типа Tegra. И хотя широкого распространения, опять-таки, не получили ни устройства, ни то, что к ним было прикручено, это дало положительный опыт: для других дистрибутивов решений, хотя бы условно работоспособных, просто не появилось.

Разумеется, в Red Hat и на вершинной части его айсберга, представленной Fedora, сложа руки не сидели. В заметке про Федорины меры я уже говорил об интенсивной и весьма успешной десктопизации этого дистрибутива – до поры, до времени.

Оболочка GNOME Shell вышла практически одновременно с Unity – и, как и последняя, пыталась перенести «гаджетную парадигму» на рабочий стол. Правда, сама по себе «гаджетная» система на базе Fedora до сих пор в проекте – в грядущем релизе 18, но можно быть уверенным – за ней дело не заржавеет.

Выходим в полуфинал

И тем не менее, Red Hat (говорим Red Hat – подразумеваем и Fedora) впервые за всю историю существования дистрибутивов Linux оказался не в роли законодателя мод, в выступил в амплуа второго любовника. На десктопном поприще Fedora, по степени «юзерофильности» едва сравнявшись с Ubuntu в своей 14-й ветке, оказалась отброшенной назад с переходом на GNOME 3.

Нет, Unity из одновозрастной Ubuntu была ничуть не лучше GNOME Shell'а (хотя и не хуже, потому что, ИМХО, хуже некуда). Но, имея чуть более длинную предысторию, обладала хоть каким-то средствами настройки. Тогда как GNOME 3 сразу приходилось твикать сторонними твикерами – такого позорища, кажется, не было даже в KDE 4.0.

Но самое главное не в этом. А в том, что Unity вызвала меньшее отторжение среди пользователей Ubuntu, нежели GNOME Shell – среди пользователей Fedora. И причина очевидна: за счёт интенсивной популяризации среди убунтийцев процент совсем начинающих пользователей, которые, кроме Unity, ничего больше толком увидеть не успели, был неизмеримо выше, чем среди пользователей Fedora.

Впрочем, и Unity, и GNOME Shell вызвали, во-первых, возрождение популярности KDE – тем более, что эта среда к тому времени по своей стабильности, функциональности и конфигурабельности стала вполне похожей на настоящую (то есть на KDE 3.5.X). А во-вторых, спровоцировали всплеск интереса к XFce и LXDE.

И здесь опять Ubuntu оказалась более «продвинутой». Её варианты Kubuntu, Xubuntu, а затем и Lubuntu давно развивались как тесно интегрированные с «генеральной линией партии», но самостоятельные проекты. И хотя Джонатан Риддел, главный майнтайнер Kubuntu, недавно был снят Canonical'ом с довольствия, на проекте это как будто не сказалось. Во всяком случае, до сих пор отсутствие дотаций от фирмы-матери не мешало успешно развиваться ни Xubuntu, ни Lubuntu.

В Fedora же XFce и LXDE ютились на задворках великой империи GNOME: официальные сборки дистрибутива с этими средами впервые появляются в тестовой версии 17-го релиза, до этого они имели место быть только в RFRemix. То есть бедные американцы, не владеющие русским языком, были ранее вынуждены устанавливать соответствующие метапакеты с DVD или по сети.

Интеграция XFce и особенно LXDE с общедистрибутивными системными службами оставляла желать лучшего. Про улёт кириллических раскладок я уже упоминал – он касался только ретроградствующих обскурантов вроде меня, которые упорно не желают менять устаревший вариант раскладки typewriter на прогрессивный winkeys. Но постоянно возникали проблемы с автомонтированием сменных носителей и вообще с выполнением операций, требующих ввода рутового пароля.

Справедливости ради надо сказать, что с интеграцией KDE в Fedora, по отзывам, дело обстояло получше. А в бете 17-го релиза стало совсем хорошо (это уже по собственному впечатлению). Однако сборка с KDE явно не является флагманским продуктом в славной семье двигателей унутреннего изгоранияремиксов и респинов Fedora.

Так что в десктопной сфере разрыв между Ubuntu и Fedora в посткритический период (то есть после выхода гипермодернистких графических оболочек), скорее всего, даже увеличился. А про сферу «гаджетную» и говорить нечего. Точнее, уже всё сказано ранее: в то время, как сборки Ubuntu для ARM-архитектур существуют уже около двух лет, для Fedora они только в проекте.

Кстати, тут можно фиксировать отставание Fedore, а, следовательно, по завершении периода релаксации, и Red Hat, в коронной для последнего области – серверной: среди убутианских ARM-сборок есть и предназначенные для серверов на этом процессоре. А ныне, в связи с борьбой за энергосбережение, они приобретают актуальность.

Ну а о том, что Ubuntu вырвалась вперёд на таком новомодном направлении, как «облачные вычисления», не говорил ещё разве что совсем ленивый. И не говорите мне, что could computing – это нечто... эээ... не очень определённое, я это и сам знаю. Однако он предназначен для корпоратива и ынтырпрайза, а там, где начинается корпоративный охмурёж – мсье Здравый Смысл может спокойно покурить в тенёчке. И кому это не знать, как ветерану Linux-корпоративного движения.

Империя наносит удар

Я могу представить себе чувство обиды, испытываемое ветераном движения в данной ситуации. Ведь на протяжении 20 лет Red Hat сначала самолично, к лице одноимённого дистрибутива, а затем под псевдонимом Fedora был основным источником инноваций в мире Linux'а. Или, по крайней мере, очень многими воспринимался в этом качестве.

И вдруг в одночасье он оказывается вторым номером и на десктопой стометровке, и на гаджетном беге с препятствиями. И даже первенство его в корпоративном марафоне стало выглядеть не столь однозначным.

Разумеется, реально в серверной сфере Rad Hat'у ничего не угрожает: легион его корпоративных клиентов не будет менять коней не то что на переправе – а просто в дороге. Так что рискну предположить, что в большей мере чувство обиды возникало от того, что скорохват-Ubuntu стал в массовом сознании близнецом-братом Linux'а:

Говорим Linux – подразумеваем Ubuntu, Говорим Ubuntu – подразумеваем Linux.

Наверное, это можно сравнить только с чувствами, испытываемыми Столлманом сотоварищи, которые после многих лет работы над мега-ОСью GNU вдруг обнаружили, что ОСь эта не только называется Linux'ом, но таковым и является. И не только в массовом сознании, но и в действительности.

Однако, если Столлман пошёл по пути борьбы терминологической – за словосочетание GNU/Linux, и фонетической – за акцентирование первого слова, то Red Hat принял кардинальное решение: отрешиться от старого мира путём отряхивания всего праха мира прежнего – от парадигмы пользовательского интерфейса до системы инициализации, призванной в недалёком грядущем пропитать все прочие подсистемы не только Linux'а, но и некогда кросс-платформенных решений – Иксов и графических сред.

В одной из предыдущих заметок я говорил о своём нежелании знакомиться с systemd. А ещё ранее, и неоднократно (уже не упомню, когда и где) – о нежелании тратить силы на освоение GNOME 3. Мотивируя это тем, что это мне не нужно.

И это действительно так – но лишь отчасти. Главная же причина в том, что ни GNOME 3, ни systemd, что бы ни говорили о их технических достоинствах (вне зависимости от их наличия или отсутствия), ни малейшего отношения к технологии дела не имеют.

То, что что мы видим сегодня – это всего лишь бизнес. И политика, вокруг этого бизнеса намешанная. Со всеми атрибутами политических игрищ, в том числе с агитацией и пропагандой, достойной лучших последователей товарища Ульянова в скобках Ленина. Когда всё наше заранее объявляется прогрессивным, а всё не наше – устаревшим и маргинальным. Это не мои слова – это звучит между строк ранее упоминавшегося поста Поттеринга, почти явно – в посте Мартина Лангхоффа на эту тему. И уж совсем открытым текстом говорится их последователями, в том числе и на русскоязычных ресурсах. Короче, большевистский лозунг

Кто не с нами – тот против нас!

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

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

Ну а уж что до мелких подъ...ок (да простят меня читающие это дамы, но никакое иное слово здесь не подходит по смыслу) касаемо перекрашивания обоев или перетаскивания кнопок управления окном справа налево – то это просто смешно. Особенно на фоне таких шоу, как демократический выбор имени следующего релиза дистрибутива. Не говоря уж о том, что стратегия «перекрашивания обоев и перетаскивания кнопок» (употребляю это очень фигурально) за несколько лет дала Ubuntu больше пользователей, чем Red Hat'у – самые передовые патчи ядра за двадцать лет.

Короче говоря, мы видим нынче не какую-то техническую дискуссию, а очередной акт вековой драмы, имя которой – Борьба Бабла и Зла. Другое дело, что от исхода этой борьбы зависит направление технического развития систем, которые до сих пор назывались Свободными. И потому пользователей их, вне зависимости от ОСеисповедания и дистрибутиво-ориентации, не может не интересовать ответ на вопрос: чьё же Бабло в борьбе обретёт право стоять во главе борьбы со Вселенским Злом.

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

В преддверии финала

Не исключено, что мы являемся сейчас свидетелями одного из судьбоносных моментов в истории и FOSS, и UNIX-подобных операционных систем, сравнимых по значимости с такими явлениями, как отщепление Берклианской ветки от древа первозданного UNIX'а и возникновения Linux.

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

Вариант первый – осуществление программы-максимум разработчиков systemd: во-первых, её внедрение, по крайней мере, в дистрибутивах «первой десятки», во-вторых, инфильтрация её, при участии udev, практически во все подсистемы Linux, надстраивающих его Иксов и интегрированных сред. Это, подобно зубцу Логовенко из известного произведения классиков, делит мир Linux на две части: майнстримную и маргинальную.

Представители первой группы находятся, как кажется на первый взгляд, в режиме наибольшего благоприятствования. Для них пишутся новые, systemd-ориентированные патчи к ядру, для них, с оглядкой на всё на тот же systemd, развивается Xorg и интегрированные десктопы. Да и приложения со временем начинают писать не под абстрактный UNIX, абстрактные Иксы, Qt и Gtk, и даже не под их адаптации для Linux как таковой: их пишут под Linux, повязанный подсистемами systemd и её метастазами.

Оборотная сторона медали – все представители первой группы со временем превращаются в сателлитов Red Hat. И будут либо подхватывать объедки с барского стола, подобно нынешним CentOS и Scientific Linux, либо расширят «песочницу» Red Hat, ныне представленную одной Fedora, до масштабов изрядной части Linux-сообщества.

Маргинальная группа влачит жалкое существование, которое ей и предрекают Поттеринг и Лангхофф. Они вынуждены довольствоваться старыми версиями ядра, замороженными субсистемами типа udev, застывшими в своём развитии Xorg, рабочими средами и их существующими приложениями, а также обходиться без приложений, которые будут написаны в будущем. И представителям второй группы останется только или тихо помереть, или продастся общественным работникам упасть таки в объятия systemd'щиков.

Поскольку systemd и udev – подсистемы сугубо Linux'овые, в положении маргиналов автоматически оказываются все операционки BSD-семейства. Что ставит окончательный крест на их развитии как десктопных систем. Возможно, об этом не так уж и пожалеют – доля BSD на десктопах нынче исчезающе мала. Но это ставит под сомнение продолжение их развития вообще – ведь все обновления вообще будут сочиняться уже с учётом специфики связки Linux и systemd/udev.

Вспоминается в этой связи высказывание Тео де Раадта в момент распада Иксов на XFree86 и Xorg – о несовместимости новой лицензии первой с идеалами свободы и открытости. Интересно, а как бы ему понравился Xorg, несовместимый с его собственной операционкой? Или абстрактные идеалы для него важнее собственного детища?

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

Очередное этнографическое подтверждение того, что отмирание десктопного Linux'а предвижу не только я – в оттоке от Linux'а юниксоидов старого закала. Правда, не на Windows, а на Macintosh, но зато оттоке массовом – насколько можно говорить о массе применительно к этой немногочисленной группе.

Вероятен ли такой поворот сюжета? Вполне. Во-первых, за ним стоит крупнейшая Linux-компания мира. И, как мы видели ранее, единственная по настоящему успешная, не так давно отпраздновавшая десятый миллиард своего дохода.

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

И, пожалуй, нигде более, чем в крупных Linux-проектах (а все крупные FOSS-проекты последних двух десятилетий в существенной мере завязаны именно на Linux) не проявляется две черты, сформировавшиеся ещё в период, когда их разработка осуществлялась в рамках Just for Fun:

1. синдром чукчи-хирурга, о котором я уже говорил, и

2. стремление к созданию собственного велосипеда.

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

Тем не менее, каждый новый велосипед, особенно с колёсами в форме ромбододекаэдра, вызывает волну пламенного энтузиазма. Без чего, как и без поддержки волонтёров, в мире FOSS невозможен успех ни одного проекта. Правда, часто этот энтузиазм, как в нашем случае, оказывается инспирированным некими закадровыми силами – но энтузиастам это не всегда очевидно.

Разумеется, за исключением энтузиастов штатных, типа Поттеринга, – они-то всё знают, всё понимают, и даже не считают нужным своё понимание скрывать. Прикрывая его фиговыми листочками разговоров о свободе выбора. Ибо для них период Just for Fun в далёком прошлом – они участвуют в бизнес-играх.

Наконец, в-третьих, не исключено, что такой поворот событий будет поначалу приветствоваться не только энтузиастами, но и разработчиками пользовательских приложений. Ибо распадение UNIX-мира в его FOSS-ипостаси может избавить их от головной боли – обеспечивать совместимость своих программ с неким абстрактным UNIX'ом (или, шире, POSIX-совместимыми системами): достаточно будет работоспособности в новообразованном Linux'е.

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

А будет ли финал?

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

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

Правда, в истории мира FOSS я затрудняюсь вспомнить такие случаи: обычно новое принималось «на ура», а потом долго и мучительно доводилось до функционала старого. Чему типичным примером – KDE 4, но его судьба будет предметом специального сравнения мужей.

Во-вторых, возможен выход на сцену нового чукчи-хирурга с большим, чем у Поттеринга, скальпелем, которым он искромсает systemd и udev, а из обрезков сделает что-нибудь новое, возможно, напластав туда же, для совместимости, чего-то от SysVinit и (или) Upstart. И это менее маловероятно – по крайней мере, именно так произошло в своё время с devfs и HAL.

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

Кстати, всё забываю обратиться к коллегам, также относящимся к systemd без должного (то есть пламенного) энтузиазма: не надо демонизировать Леннарта Поттеринга. И призывать к физической расправе над его кодом (и тем более над ним самим). Потому что если бы Поттеринга не было – его следовало бы создать. Он носил бы другое имя, и иначе называлась бы сочинённая им система. Но велосипед такого назначения всё равно был бы изобретён. Потому что, как говаривал Марк Порций Катон Старший, Карфаген должен быть разрушен.

А в-третьих и главных – мы забыли про второго нашего протагониста, Ubuntu. Ведь со всеобщей systemd'изацией она окажется среди маргиналов – и более того, в первых их рядах. А это уже совсем другой коленкор.

Во-первых, в десктопной сфере Ubuntu, вместе с сателлитами типа Kubuntu сотоварищи, по числу пользователей наверняка превосходит все прочие дистрибутивы Linux, вместе взятые, а с учётом клонов, вроде Mint'а, перевес будет ещё большим.

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

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

И причина тому ясна: многочисленные пользователи Ubuntu выдвинули из своей среды столь же многочисленных, в долевом отношении, убунтописателей. Которые, с одной стороны, ещё не растеряли запала неофитов, с другой же – за минувшие годы усовершенствовались в сочинительском ремесле (а это – в том числе и ремесло, которому нужно учиться).

Кроме того, не следует списывать в тираж тех, также упоминавшихся мной ранее, пользователей Ubuntu, которые перед тем прошли огонь, воду и медные трубы Slackware, FreeBSD, Gentoo. И в которых временами взыгрывает ретивое на предмет вклада в копилку источников информации.

В-четвёртых, производители пользовательского оборудования, те из них, кто не брезгует поддержкой Linux'а, в своих драйверах «искаропки» рассчитывают в первую очередь на Ubuntu.

Возникает резонный вопрос: кого при таком раскладе следует считать плывущим в майнстриме, а кого – сидящим на обочине культурного процесса? И ответ на него отнюдь не очевиден.

Наконец, последнее. В свете возможного расщепления Linux'а на две неравные части, большая из которых форсированно и навсегда порвёт с вековыми традициями UNIX – не будет ли это стимулом для разработчиков BSD-систем оживить их десктопное направление, а для пользователей, по крайней мере некоторых, применять их разработки в этом качестве?

Так что надеюсь, что Линупокалипсис на ближайшее время откладывается. А как будут развиваться события на самом деле – мы узнаем достаточно скоро: или во время осеннего урожая релизов, или, в крайнем случае, весной, индо взопреют релизы весенние. Но хочется верить, что заколдобиться, понюхав их портянку, в отличие от старика Ромуальдыча, нам не придётся.

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

Upstart vs systemd

Несколько отдельных заметок, написанных в разное время по поводу противостояния систем инициализации, в том числе и измерительного содержания.

Леннарт Поттеринг об upstart и systemd

Апрель 25, 2012, оригинал 24.04.2012

От переводчика: это запись из блога Леннарта Поттеринга (названия в оригинале нет), с которой я внимательно ознакомился по наводке Vascom'а. Ну и заодно решил её перевести и сопроводить комментарием (см. следующую заметку). Курсивом в скобках – мои вставки, сделанные исключительно ради гладкости русского текста.

Многие люди просят меня в нескольких словах прокомментировать решение Canonical не включать systemd (в состав своей системы). В нескольких словах и скажу:

Я слышал очень много закулисных разговоров о контроле. Они (Canonical) контролируют Upstart (и как майнтайнеры, и как обладатели авторских прав), и полагают, что не контролируют systemd. Однако свободное программное обеспечение никогда не было (полностью) подконтрольным (кому бы то ни было), и, когда вам что-то не нравится – у вас есть возможность создать собственный форк. [Кроме того, во время Git легко поддерживать и собственный набор патчей]. Пример таких компаний, как Sun (которая боялась отказаться от контроля над Java), стремление к контролю вызывает грусть, и никогда не идёт на пользу (любому) проекту.

Я думаю, что такое решение не подходит для экосистемы Linux. Ubuntu стала островом, который становится все более и более отдаляется от всех прочих больших коммерческих дистрибутивов Linux. Поскольку они не приняли systemd, они будут продолжать развивать и поддерживать направления, официально заброшенные разработчиками и майнтайнерами (например, ConsoleKit, независимый udev). Они погрязли в полуустаревшем стеке, который уже не будет развиваться. Конечно, Canonical может сделать инвестиции в большие работы по его развитию для своей платформы, но это, несомненно, станет первым опытом для них, и я серьезно сомневаюсь, что у них достаточно знающих инженеров для этого. Canonical почти ничего не внесла в проектирование Linux, так же как они держатся подальше от (разработки) ядра. Теперь перед ними открывается две возможности: а) остаться навсегда с наполовину устаревшей кучей, или б) много работать, чтобы развивать свой стек исключительно своими силами, чтобы оставаться конкурентоспособными с нами.

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

Всё это выражает мнение Марка, что cloud и focus (его любимые модные словечки) полностью сделают Upstart частью программного обеспечения будущего...

Это печальный день для экосистемы Linux. Но нам это облегчает жизнь, поскольку мы можем отказаться от любых действий по «облегчению», и сохранить свое место в открытом мире с systemd.

Комментарий к заметке Леннарта Поттеринга об upstrat и systemd

Апрель 25, 2012

С предыдущим текстом я ознакомился по ссылке, присланной в личном сообщении Vascom'ом, за что ему весьма признателен – сам бы я до блога Поттеринга не добрался. По прочтении я решил разместить здесь её перевод, сделанный в меру моих скромных сил и возможностей в этой области. А поскольку заметка хорошо укладывается в сюжет очередного Сравнения мужей (Ubuntu vs Fedora), то заодно и сопроводил её комментариями.

Для начала надо сказать, что Vascom прислал мне эту ссылку по недоразумению (что не уменьшает меры моей ему благодарности). Вероятно, полагая, что я являюсь приверженцем upstart'а и ненавистником systemd. Должен откреститься от такой трактовки моей позиции: обе системы инициализации мне, как простому советскому юзеру, глубоко до лампочки. И обе, с точки зрения того же пользователя, я полагаю лишними в равной степени – по причинам, изложенным в одном из частей сравнения (Ubuntu vs Fedora).

Однако, тем не менее, разница между ними есть. Точнее, разница в политике их продвижения. Upstart никогда особо не навязывался разработчиками Ubuntu окружающему миру – они полагали его своим личным делом. И то, что он был инкорпорирован, например, в Fedora – проявление доброй воли её разработчиков и их тяги к прогрессу. Кроме того, по большому счёту Upstart не так уж сильно отличается от канонического SysVinit – что, возможно, большой минус с точки зрения гипермодернистов, но не меньший плюс для простых пользователей.

Разработчики же systemd активно (я бы даже сказал, агрессивно) продвигают своё детище уже не просто как систему инициализации, а как всеобъемлющую систему управления всего и вся – вплоть до старта Иксов и рабочих сред. Агрессия же выражается, в том числе, и в том, что прочие системы инициализации уже заранее объявлены устаревшими (что красной нитью проходит и через заметку Поттеринга), хотя systemd пока ничем не доказала своего превосходства над ними.

Умиляют крокодиловы слёзы Леннарта над грядущей горькой судьбой Ubuntu, которая останется как изолированный остров в дивном новом мире со своим полуустаревшим стеком (мне очень хотелось перевести его stack как кучу... ну вы сами понимаете, чего, но я удержался). Однако, учитывая, что «настольных» пользователей Ubuntu, даже без учёта прямых клонов, типа Mint'а, наверное, больше, чем пользователей всех остальных дистрибутивов, вместе взятых, вопрос о том, что тут остров, а что – матёрая земля, становится не вполне однозначным. Как и вопрос о том, кто из антагонистов стремится к всеобщему (учёту и) контролю.

Да, в корпоративном секторе расклад другой, и в ближайшее время он не изменится. Однако примеры того, как системы с пользовательских десктопов инфильтровались в «корпоратив», мы видели в статье Ubuntu vs Fedora. А вот обратных, пожалуй, и не припомнить. По крайней мере, их не явили нам ни OS/2 встарь, ни OpenSolaris – в недалёком прошлом. И ни один коммерческий UNIX – тоже. А ведь в середине 90-х такие попытки предпринимались со стороны и HP UX, и True64 UNIX, и той же Solaris (правда, вкупе с их же аппаратными платформами, что, в немалой степени, было причиной претерпения ими фетяски).

Что же до стиля Поттеринга... Да, он неслабый пропагандист и агитатор. Прекрасно владеющий любимым приёмом всех гипермодернистов и революционеров – наклеиванием ярлыков на оппонента, типа:

Ах, какой он пошляк, Ах, как он неразвит! Современности вовсе не видно! А.К.Толстой

А уж дальше пусть оппонент, подобно пану Гималайскому, сам отыскивает справочку, что он не верблюд.

О пузометрии

Ноябрь 19, 2012

С самого появления менеджера инициализации, именуемого systemd, он был окружён множеством легенд.  Из которых самая известная – легенда о фантастической скорости загрузки машины, которую он обеспечивает. Она же – самая устойчивая: похоже, развеять её ничуть не проще, нежели Чёрную легенду о Ричарде Третьем...

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

Так что для начала пара цитат из постов serzh-z'а. Первая из них:

15 лет назад речь не шла о 2-х (двух) секундах, с момента передачи управления ядру и отображения менеджера GUI

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

Однако  serzh-z с этим не согласен:

Системе инициализации на bash и с initrd – 2 секунды не светят.

В ответ на что я предположил, что при отключении сети на моей системе получится нечто подобное – с давних пор изрядное время при загрузке у меня уходит на поиск DHCP сервера и синхронизацию времени с сервером NTP.

Я, конечно, ничего не понимаю в  и прочих systemd'овых штуковинах. Но привык доверять своим глазам и своему секундомеру. Да и измерить время загрузки  своей машины вполне в состоянии, руки пока не отваливаются. Тем более, что применяемая мной openSUSE (пока) даёт возможность прямого сравнения времени загрузки при использовании той или иной схемы инциализации.

Ранее я уже проводил такого рода измерения. И не откажу в удовольствии процитировать себя любимого:

измерения скорости загрузки с секундомером вообще показали интересную картину: при использовании systemd  openSUSE грузилась 55 секунд (это почти втрое дольше, чем Fedora 14 ещё без оного). А вот если переключиться на SysVinit — то время загрузки…падает до 46 секунд.

Предвижу возражение: те измерения проводились на ноутбуке с его медленным и отсталым традиционным винчестером. Да и systemd тогда, в феврале месяце текущего года, была ещё не той системы. А вот  на мощной системе с современным SSD накопителем современная же systemd покажет себя во всей красе.

Принимаю вызов. Благо openSUSE, позволяющая сравнение скорости загрузки, стоит у меня как раз на современных SSD накопителях, принадлежащих к числу самых быстрых из ныне имеющихся.

Итак, традиционно меряю время от выбора нужного пункта  в меню GRUB до появления приглашения к авторизации в KDM. Сначала при моём обычном наборе стартовых сервисов (то есть с network и всеми с ним сопряжёнными). Получаем:

• при systemd – 10 секунд;

• при SysV... 10 секунд.

Отключаю все сетевые службы и повторяю процедуру. Получаю:

• при systemd – 10 секунд;

• при SysV... 8 секунд.

Признаю, загнул в азарте, и при SysV двух секунд на загрузку действительно не светит. Но ведь их не засветило и при использовании systemd. Более того, если при SysV отключение «лишних» служб ведёт к сокращению времени загрузки (пусть и на жалкие 2 секунды), то sysyemd на это просто не реагирует.

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

То есть получается, что systemd ведёт себя подобно Windows, которая сначала являет своему пользователю графический интерфейс, а потом втихаря подгружает всякие, в том числе и сетевые, службы. В преферансе за такое бьют канделябром...

А не ты ли, Лёха, скажете вы мне, всегда утверждал, что время загрузки – это такая мелочь, о которой смешно говорить?  И что к скорости реальной работы она не имеет никакого отношения. Признаю, утверждал, утверждаю и буду утверждать, пока не заделаюсь коммивояжером по продаже дамских корсетов. Но ведь скоростью загрузки, в числе прочих достоинств, козыряют как раз разработчики systemd. И если их утверждения относительно такой вещи, которую легко измерить и проверить, мягко говоря, не очень соответствуют действительности – какие у меня основания верить во все прочие несравненные достоинства systemd?

Правда, убедить в чём-то приверженцев этого менеджера инициализации ничуть не легче, чем читателя Шекспира – в том, что Ричард Третий...

... был славный малый. Храбрец, рубака, умер и истлел.

А вот причины этого явления заслуживают отдельного этнографического исследования.

О пузометрии: спустя почти полгода

Апрель 29, 2013

Когда речь заходит о systemd, сторонники этого менеджера инициализации говорят о массе его преимуществ по сравнению и с древним sysvinit, и с upstart, разработанным для Ubuntu.

Многие из этих преимуществ выглядят субъективными. Например, логичность внутреннего устройства системы: логика, как известно, бывает разная, как минимум, аристотелева, неаристотелева и женская. Другие, скажем, контроль над выполнением фоновых процессов, обычно не могут быть оценены конечным пользователем (да и не очень его волнуют). Третьи же, такие, как управление службами, в systemd если и имеют преимущества по сравнению с аналогами из sysvinit и upstart, то только в «многобуквии» (см., например, ) и более ином синтаксисе. В чём следует видеть неустанную заботу о пользователе, дабы он не разучился читать (новую документацию) и писать (точнее, набирать на клавиатуре).

Так что фактически остаётся единственный момент для сравнения, поддающийся количественной оценке – скорость загрузки системы. Все резонные люди понимают, что

1. момент этот несущественный (нормальная UNIX-машина загружается много если раз в сутки), и

2. не имеет никакого отношения к скорости выполнения реальных задач.

Тем не менее, сторонники systemd постоянно козыряют этим преимуществом. Провоцируя своих оппонентов на очередные фаллометрические тесты.

Отдал дань фаллометрическому движению и автор этих строк, сначала в виде отрывочных наблюдений за скоростью загрузки, а затем и целенарправленного сравнения оной в дистрибутиве openSUSE, благо он вплоть до версии 12.2 включительно перед инициализацией системы. Результаты оказались, мягко говоря, несколько не соответствующими заявлениям о бесспорном преимуществе systemd над sysvinit (столь многочисленным, что от ссылок воздержусь и предлагаю воспользоваться поиском).

По установке Ubuntu появилось желание продолжить фаллометрические состязания – уже в сравнении systemd с upstart, в качестве одного из преимуществ которой также декларируется несравненная скорость загрузки. С этой целью были использованы два идентичных накопителя SSD SanDisk Extreme 120 GB. На первом была установлена openSUSE 12.3 с systemd (в этой версии возможность простого переключения на sysvinit ликвидирована), на втором – Ubuntu 13.04 с upstart. В обоих случаях использовалась файловая система ext4. Никаких оптимизаций загрузки ни в той, ни в другой системах не проводилось – загружались службы, предусмотренные при первичной инсталляции.

Усреднённые результаты по десяти замерам времени от нажатия Enter в меню GRUB до приглашения к авторизации (в KDM и LightDM для openSUSE и Ubuntu, соответственно) для каждой из систем следующие:

• openSUSE с systemd – 7 секунд;

• Ubuntu с upstart – 8 секунд.

В процентном отношении выигрыш systemd по отноешнию к upstart cсоставляет внушительные 14%. Однако не будем забывать, во-первых, о том, что в абсолютных цифрах речь идёт об 1 (одной!) секунде. Во-вторых, процедура POST на моей машине занимает 18 секунд, на фоне которых та самая секунда выигрыша просто теряется.

Самое же главное – в-третьих: после авторизации и последующей загрузки среды Ubuntu полностью готова к работе. На примере Xubuntu, где штатно предусмотрено сохранение сеанса (в Ubuntu это надо прикручивать, чего я ещё не сделал), можно видеть, что внешний винчестер с USB-интерфейсом смонтирован, а в браузере открыты все интернет-страницы из прошлого сеанса. В openSUSE же для монтирования внешнего винта требуется щёлчок на его имени в файловом менеджере (хотя опция автоматического монтирования сменных накопителей установлена). А браузер даёт ошибку загрузки страниц.

То есть скорость загрузки системы при использовании systemd – кажущаяся: приглашение к авторизации появлятся до старта всех используемых служб, подобно тому, как это делается в Windows. Казалось бы, ничего страшного? Однако на практике это выливается в ряд мелких, но очень раздражающих неудобств: необходимости повторной загрузки документов, открытых с внешнего винчестера в текстовом редакторе, ручном восставновлении torrent-сессии, обновлении страниц в браузере, а иногда и его перезапуске. Вероятно, systemd как-то можно настроить, чтобы избежать такого безобразия, но upstart ни в какой настройке не нуждается (как, к слову сказать, и sysvinit). Да и абсолютное время загрузки при этом, видимо, будет иным...

Любопытства ради я померял и время загрузки Xubuntu, которая установлена у меня на традиционном винчестере (Seagate Barracuda, 500 ГБ, 7200 об./мин.). Оно составило 11 секунд, то есть примерно в полтора раза больше, чем старт системы с SSD, вне зависимости от схемы инициализации. То есть основной выигрыш в скорости загрузки обеспечивается вовсе не последней, а исключительно «железом». Что, собственно, было ясно из общих соображений (товарищ майор, поздравляем вас с присвоением очередного звания).

Apt vs yum

Февраль 13, 2012

В дистрибутивах, использующих формат пакетов rpm, применяется ряд систем для управления оными. Из них наиболее известны (в исторической последовательности) apt-rpm, yum, urpmi, zypper. Последние два – дистрибутив-специфические, и применяются, насколько я знаю, только в Mandriva и openSUSE, соответственно. Два других же, apt-rpm и yum, используются в нескольких дистрбутивах, в том числе в некоторых (Fedora, PCLinuxOS) могут применяться параллельно, или, скорее, альтернативно. И потому сравнение их представляется не лишённым смысла. Чем мы и займёмся в настоящей заметке.

Для начала надо отметить, что сравнение apt vs. yum никогда не было предметом ожесточённых сетевых баталий, и поэтому здесь я вполне могу следовать завету Корнелия Тацита, то есть писать «без гнева и пристрастья». Но для начала – маленький исторический очерк, для расстановки приоритетов.

Первые годы своего существования Rad Hat и его прямые клоны и порты, такие, как Caldera, Mandrake и Yellow Dog, обходились без системы управления пакетами, довольствуясь средством их установки – утилитой rpm. Впрочем, систем управления пакетами тогда не было ни в одном дистрибутиве Linux – вплоть до того момента, когда в 1999 году в Debian'е не появилась система apt. Которая была быстро окучена бразильской компанием Conectiva и приспособлена к работе с rpm-пакетами.

Система, получившая название apt-rpm, оказалась очень удачной, и была немедленно задействована в российском дистрибутиве Altlinux, как раз в это время (2001 год) отделившемся от Mandrake. Началось и ползучее её внедрение в праотеческий Red Hat, а затем, после покупки фирмой MandrakeSoft бразильской Conectiva – и в объединённом дистрибутиве Mandriva. Однако, в отличие от Altlinux, использующего её до сих пор, ни там, ни там apt-rpm не прижился. В Mandriva она была заменена собственной системой urpmi, а Red Hat взял на вооружение систему yum.

Прототипом системы yum послужила система yup, разработанная для дистрибутива Yellow Dog – порта Red Hat на платформу PowerPC. К 2002 году она, уже под своим современным именем, была адаптирована для самого Red Hat'а и сразу же взята на вооружение российским же дистрибутивом Asplinux. В Red Hat'е же она боролась с apt-rpm за почётное звание ударника пакетного менеджмента до осени 2003 года. Когда была принята в качестве штатного средства управления пакетами в только что образовавшемся дистрибутиве Fedora Core. В котором, тем не менее, реликтовая поддержка apt-rpm сохранилась до сих пор.

Ещё один дистрибутив, в котором apt-rpm прочно утвердился в роли менеджера пакетов – PCLinuxOS. И до недавнего времени он был там единственным исполнителем этой роли (вместе со своей графической оболочкой – Synaptic'ом). Ныне ведутся работы по включению в этот дистрибутив и yum'а – также с его графическим фронт-эндом yumex. В настоящее время оба они доступны для тестирования в 32-битной сборке PCLInuxOS (хотя в 64-битной и yum, и yumex пока отсутствуют).

За всё время пользования Fedora я использовал только yum (и PackageKit, а недавно опробовал yumex), необходимости обращаться к apt-rpm не возникало. В PCLinuxOS же, напротив, я ограничивался исключительно apt'ом – за отсутствием, как уже сказал, yum' в 64-битной сборке. Тем не менее, на уровне субъективных ощущений вполне могу сравнить оба пакетных менеджера.

Первым впечатлением от apt-get в PCLinuxOS было ощущение быстроты. То есть я всегда знал, что yum – система довольно медленная, так как требует скачивания больших объёмов метаинформации. Но что она медленней настолько – для меня было неожиданностью. Аналогично и с графическими фронт-эндами: Synaptic работал ощутимо быстрее, нежели yumex (сравнивать его с PackageKit было бы некорректно, так как последний, в сущности, может быть назван пакетным метаменеджером).

С другой стороны, yum синтаксически проще: если использование apt'а требует двух команд – apt-cache для получения информации о пакетах и apt-get – для выполнения действий над ними, каждая со своим набором субкоманд, то в yum присутствует только единственная одноимённая команда, сопровождаемая субкомандами.

Кроме того, yum показался мне несколько более богатым функциями: в этом отношении его можно скорее сравнить с aptitude в командном режиме (реализации которой для работы с rpm-пакетами не существует). Кроме того, функциональность yum'а расширяется за счёт многочисленных плагинов. А при использовании в качестве пользовательской командной оболочки (login shell) zsh он хорошо интегрируется с нею, повышая удобство работы.

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

В общем, данное сравнение мужей завершается вничью – миром и дружбой. Я так и не смог решить, кто же доблестней – Кох или Вагнер apt или yum. И для себя решил пользовать оба – каждый в своём родном дистрибутиве: yum – в Fedora, apt – в PCLinuxOS.

Войны десктопов

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

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

Не вполне свободен от эмоций и автор этих строк. И потому боюсь, что завету Тацита смогу следовать не всегда.

KDE: обсуждение выбора

Осень 2004 г

Эта заметка может рассматриваться как вступление ко всей последующей истории священных войн на десктопах. В ней я сразу обозначаю меру моей пристрастности на многие годы – и назад, и вперёд. Хотя ныне мои пристрастия существенно изменились.

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

Итак, наш десантник ответил: когда я прыгаю, у меня есть два выхода – или парашют раскроется, или не раскроется. Если раскроется – все хорошо, а если не раскроется, остается два выхода: или я останусь жив, или разобьюсь насмерть. Если я останусь жив – все хорошо, если разобьюсь – остается два выхода: или я попаду в рай, или я попаду в ад. Если я попаду в рай – все хорошо, а если я попаду в ад, остается два выхода: или чёрт меня не съест, или чёрт меня съест. Если чёрт меня не съест – все хорошо, а если чёрт меня съест – ну один-то выход у меня все равно остается!

Это объяснение каждый начинающий POSIX'ивист должен запомнить, как молитву: в любом затруднительном положении у него есть как минимум два варианта решения своей проблемы. И если ему покажется, что выхода нет – хоть один вариант решения проблемы по зрелом размышлении найдется обязательно.

Так что проблема выбора графического интерфейса начинается с определения того, что же нужно пользователю – просто оконный менеджер или действительно интегрированная среда (graphic environment), называемая также просто десктопом (desktop). Различия между ними очевидны: первый класс программ предоставляет пользователю возможность управления окнами – их открытия, закрытия, масштабирования, сворачивания, перемещения, переключения между открытыми окнами.

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

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

Интегрированный десктоп, разумеется, включает в себя средства управления окнами – собственные, как в KDE, или привлеченные из дружественных (то есть совместимых) оконных менеджеров, как в GNOME (понятно, что без управления окнами работа в оконной среде X попросту невозможна). Но тут уже виртуальные десктопы, средства запуска программ и навигации по ним – всякого рода панели, стартовые и контекстные меню, пиктограммы, наборы тем и прочие красивости становятся непременными атрибутами. Плюс – более или менее обширный набор интегрированных в десктоп приложений (почему он и называется интегрированной средой), как минимум – терминал, редактор, файловый менеджер. Ну и обязательным компонентом десктопа (без чего он не заслуживал бы этого наименования) – средства сквозного конфигурирования его самого и его приложений.

Маленькое отступление. Среди старых (не по возрасту, а по стажу) пользователей POSIX-систем широко распространено мнение, что любые программы, выполненные в направлении Unix Way (или, резче, True Unix Way) должны настраиваться правкой конфигов в текстовом редакторе (а паче того, их созданием «с нуля»), все же остальное – от лукавого.

С этим трудно не согласиться. Да, истинный POSIX'ивист всегда должен иметь возможность вмешаться руками в процесс настройки. Однако если речь идет о правке многих десятков конфигов (а в случае с KDE, как станет ясным из дальнейшего, именно так и есть), не проще ли в общем и целом положиться на собственный конфигуратор, а к ручной правке прибегать только в критических ситуациях? Ибо если GUI не может сам себя настроить своими же GUI'евыми средствами – то какой он к чертям собачьим GUI?

И уж вообще нелепо, если с помощью GUI'евой конфигурялки можно настроить массу очень сложных параметров, а для какого-либо элементарного действия – например, изменения шрифта меню, – требуется ручное редактирование rc-файла...

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

А вот при выборе интегрированного десктопа перед пользователем два выхода. Первый – это строить такой десктоп самостоятельно, на основе более или менее простого оконного менеджера и тех приложений, которые он использует постоянно. Благо многие из оконных менеджеров позволяют превратить себя в полноценную интегрированную среду (хотя и весьма индивидуальную) если не легким движением руки, то несложным редактированием своих конфигов. Здесь показателен пример fluxbox'а – благодаря механизму закладок (tabs) совместно используемые приложения (например, терминал, текстовый редактор, браузер) легко объединяются в группы «по интересам». Так что если пользователь сделает такой выбор, все хорошо: остается только затратить должное количество времени на редактирование файла X-ресурсов, пользовательского ~/.xinitrc, конфигурационных файлов оконного менеджера и отдельных приложений. Если же это почему либо не устраивает – остается второй выход: использование уже готового десктопа.

Каковых также не так и мало. Из мне известных графических интерфейсов в этом качестве позиционируются CDE, XFce, GNOME и KDE. Однако первая – продукт коммерческий, и, насколько я знаю, не входит в состав ни одного дистрибутива Linux или свободной BSD-системы. А XFce, при всех своих несомненных (и многочисленных) достоинствах, в современном своем виде на роль интегрированной среды никак не тянет: это скорее наиболее развитый (по сравнению с прочими оконными менеджерами) конструктор для собственноручного построения таковой. Так что на самом деле и тут остается только два выхода: GNOME или KDE.

Если пользователь решится на первый выбор – для него (надеюсь) все будет хорошо. Однако здесь я ему не советчик. Потому что GNOME – один из немногих представителей класса графических интерфейсов, который мне активно не нравится. Я вполне разделяю чувства поклонников элегантности преемников NextStep (Afterstep, WindowMaker) или строгой простоты семейства *box'ов (Blackbox, Openbox, Fluxbox – к слову, ничуть не менее элегантных, а последний еще и уникально функционален). Тем паче, что сам долгое время был в их числе (а периодически пользуюсь WindowMaker или Fluxbox и по сей день). Я готов понять любителей IceWM, сочетающего в себе простоту настройки с ее гибкостью. Я осознаю несравненную настраиваемость FVWM2 – хотя и чисто теоретически. Мне, столь же платонически, очень нравятся идеи, заложенные в XFce, являющего близкий к идеальному баланс между минимализмом оконного менеджера и функциональностью полноценного десктопа. Наконец, я некоторых случая мне представляется вполне приемлемым предельный аскетизм FLVM, которому, приложив чуть-чуть усилий, можно еще и придать некоторую элегантность.

Но, разгрызи меня гром, за все свои попытки общения с GNOME я не обнаружил в нем никаких привлекательных (для себя) черт. Начать с того, что это – также не вполне интегрированная среда. Что, конечно, становится особенно понятным при сравнении с KDE, однако... Большая часть того, что интегрировано в GNOME и заслуживает всяческого использования – создавалась до него, вне него, и независимо от него. Тут вспоминаем GIMP – ведь именно для его разработки была придумана библиотека Gtk (что так и расшифровывается – GIMP Toolkit), послужившая базой для множества приложений, изначально с GNOME никак не связанных – от сугубо кросс-платформенного AbiWord до векторного графического редактора Sodipodi, автор которого озаботился столь же легкой интеграцией своего произведения в KDE.

Далее. Если KDE с каждой новой версией становится все быстрее, то GNOME – все задумчивее. Ну и наконец, просто идеология: разработчики GNOME все больше и больше тяготеют к воспроизведению особенностей Самой Великой ОС всех времен и народов. Известное высказывание, что последние версии GNOME представляют собой большую Windows, чем сама Windows, говорит само за себя.

Единственным основанием к использованию GNOME я вижу нежелание (или невозможность) плодить большое количество библиотек – так как без GIMP при мало-мальски существенной доле работы с графикой обойтись все равно не удастся, а он основан на той же библиотеке Gtk, что и GNOME. Хотя строго говоря, как раз наоборот – Gtk создавалась специально для GIMP, а ко GNOME ее прикрутили за отсутствием выбора, если исключить Qt. Впрочем (ИМХО) и тут XFce (основанная на той же Gtk) была бы более предпочтительна.

Впрочем, ругательных материалов о GNOME, особенно в современных его ипостасях, в Сети можно найти ничуть не меньше, чем хвалительных. Как уже было сказано, мне лично хвалить GNOME не за что, а ругать его не возьмусь за слабым знанием. Ограничившись одним-единственным (но для меня очень весомым) аргументом, также анекдотического происхождения. Помните, как один мужик в церкви жаловался Господу, что дела у него идут из рук вон плохо, не смотря на его хорошее, с точки зрения христианских понятий, поведение, и в отчаянии вопрошал: «Ну почему, о Боже?» – «Ну не нравишься ты мне» – донесся до него Глас Божий. Вот и про GNOME могу сказать – не нравится он мне, да и все.

Так что пользователь должен сделать свой выбор, опираясь на субъективные впечатления и (квази) объективные оценки из источников. Однако, если выбор его будет не в пользу GNOME, то еще один выход у него найдется. И выход этот – использование KDE.

Итак, KDE – единственный (ИМХО) по настоящему интегрированный десктоп в мире Open Sources. Правда, в принадлежности последнему ему долгое время отказывали, так как базируется он на библиотеке Qt, имеющей (в том числе и) коммерческий статус. Однако ныне лицензионные споры относительно свободы/несвободы ее отшумели, и лицензия, под которой Qt распространяется для некоммерческого использования, признана вполне GPL-совместимой. Так что у всех адептов Open Sources «юридических» оснований не использовать KDE не осталось.

Другое дело, что многие не любят KDE за его масштабность, переходящую в монстроидальность. Действительно, эта среда предъявляет довольно высокие требования к аппаратуре, особенно – объему памяти: мало-мальски комфортная работа в современных версиях KDE возможна, начиная с RAM 128 Мбайт (лучше – больше, хотя, начиная с 512 Мбайт, разницы уже не чувствуется). Однако столь ли страшны такие требования для современных машин? Не мало места занимают компоненты этой среды и на винчестере: моя обычная установка KDE (вместе с обязательной библиотекой Qt) тянет почти на 500 Мбайт. Но и это при современных винчестерах не столь критично. Наконец, удовольствие от работы в KDE можно получить при разрешении экрана, начиная с 1024x768 и глубине цвета от 16 бит. Но ведь и это – не проблема для современных видеокарт и мониторов.

Можно видеть, что при мало-мальски современной аппаратуре системные требования KDE не выглядят чем-то сверхъестественным. Другое дело, что это – не лучший выбор для реанимации старого «железа». Однако и GNOME этой цели не послужит: его требования к памяти и дисковому пространству ничуть не ниже (если не выше). Так что пользователям безнадежно состарившихся (морально, не обязательно физически) машин придется обратиться в выбору между «легкими» оконными менеджерами.

Далее, среди пользователей бытует легенда о какой-то особо выдающейся «тормознутости» KDE. Однако этот вопрос тесно связан с предыдущим: резкое падение быстродействия в этой среде фиксируется при малом объеме памяти. Хотя и процессор желательно иметь помощнее Pentium-166, но любого из современных – хватит за глаза.

Впечатление некоторой «задумчивости» при общении с KDE может дать старт самой среды и первый в сеансе запуск какого-либо приложения. Действительно, поскольку любое KDE-приложение задействует множество библиотечных функций, запуск его по определению не может быть быстрым. Однако столь ли это критично? Ведь сама среда и постоянно используемые ее компоненты запускаются один раз в день (а на служебной машине, возможно, вообще загружены круглосуточно). А на тех программах, которые открываются и закрываются перманентно (например, терминальные окна), замедление не сказывается: повторный запуск любого KDE-приложения осуществляется на порядок быстрее, чем первый (оно и понятно – нужные библиотечные функции уже в памяти). Кроме того, в Linux, например, существует метод радикального ускорения старта KDE-приложений (и не только их) – так называемое предварительное связывание (prelinking). А в DragonFlyBSD аналогичная функция поддерживается на уровне ядра.

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

Наконец, KDE – одна из немногих программ в мировой истории софтостроения, которая с каждой новой версией становится не только функциональней, но и быстрее. И это не слова, а реальность, которую не могли не заметить все пользователи, перешедшие в недавнее время с версий 3.2.X на 3.3.X.

И последнее из широко распространенных предубеждений против KDE – его интерфейс с точки зрения визуального впечатления. Действительно, «умолчальный» вид KDE а) не являет собой предел эстетического совершенства, и б) вызывает неприятные для приверженцев True Unix GUI ассоциации с внешностью Самой Известной ОС. Однако а) с каждой новой версией KDE движется в сторону элегантности, и б) для него существует (и постоянно пополняется) большой набор тем, в том числе и весьма симпатичных. Ну а родимые пятна Windows-подобия легко выводятся несложными настроечными действиями.

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

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

Во-первых, функциональностью собственно оконного менеджера – средства управления окнами многочисленны и разнообразны. Во-вторых, полным ассортиментом средств запуска – от пиктограмм рабочего стола до строки минитерминала, сохраняющей историю команд, от стартового меню в стиле Windows (K-меню) до трея главной управляющей панели, не говоря уж о традиционном для Иксовых интерфейсов контекстных меню рабочего стола. В третьих, удобством средств навигации между виртуальными рабочими столами (а оных может быть аж 20 штук) и окнами открытых приложений, разнообразием способов «поднятия» и фокусировки окон.

Конечно, всем этим богачеством современного пользователя удивить трудно – перечисленные средства в том или ином сочетании есть в любом развитом оконном менеджере. Однако, во-первых, лишь в редких из них можно найти полный их набор. А во-вторых, многие из означенных возможностей впервые появились именно в KDE – например, минитерминал с историей команд (т.н. mini-cli).

Однако KDE имеет и уникальные возможности. И здесь в первую голову стоит помянуть сквозное средство глобального конфигурирования среды обитания – Центр управления (KCC – KDE Control Center). С помощью KCC конфигурируется 99 процентов того, что вообще может возникнуть желание сконфигурировать у самого привередливого пользователя. Тот же оставшийся процент настроек, не поддающихся средствам KCC, легко изменяется редактированием конфигов.

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

Изобилие штатных приложений – вторая особенность KDE: не покидая этой среды, можно найти и прекрасный эмулятор терминала, и полнофункциональный текстовый редактор, и файловый менеджер с браузером, и почтовый и ftp-клиенты, и множество графических и мультимедийных приложений, не говоря уже о мощном (и, что характерно, пригодном к использованию) наборе общесистемных утилит и средств разработки программ и web-материалов. «А чего не хватит в доме – сколько хочешь в гастрономе»: число программ от сторонних разработчиков, ориентированных на работу в среде KDE, наверное, учету не поддается, и охватывает абсолютно все области, для которых только существуют разработки Open Source вообще. Кроме того, ряд программ, специфических библиотек не использующие, имеют front end'ы (в просторечии – «морды»), основанные на библиотечных элементах Qt/KDE – здесь можно вспомнить не только KDE-ипостась mplaeyr'а, известного, но и сборки на базе KDE офисного пакета OpenOffice и недавно появившуюся возможность прикрутить KDE'шную морду к движку Gekko – базе проприетарного Netscape, свободных Mozilla и Galeon. Все разработанные для KDE программы, включая front end'ы, имеют стандартизированный интерфейс, который, как уже было сказано, может быть настроен глобально, вместе с параметрами самой среды (что не исключает индивидуального конфигурирования – но и об этом я уже упоминал).

В целом KDE выглядит даже перегруженным штатными приложениями – и это нередко отмечается как очередной недостаток данной среды. Да уж, что есть, то есть: кое-какие программы редко кем используются (ввиду наличия более продвинутых аналогов), иные же явно дублируют друг друга, и подчас дублирующие варианта, мягко говоря, далеки от совершенства – чтобы в этом убедиться, достаточно просмотреть пункты Графика и Мультимедиа «умолчального» K-меню. Однако, во-первых, вовсе не все компоненты полного набора KDE обязательны к установке, и нет препятствий к запуску из этой среды программ, основанных на других библиотеках. А главное, многие программы штатного комплекта принадлежат к числу лучших в своем классе (для примера – текстовый редактор Kate, звонилка Kppp, почтовый клиент KMail) или просто держат пальму первенства в своей области (как тут не вспомнить konqueror – лучший файловый менеджер всех времен и народов).

Из первых двух особенностей KDE вытекает третья, и главная – ее самодостаточность. Которая, собственно, и позволяет назвать эту среду по настоящему интегрированной. Подавляющее большинство своих задач пользователь может выполнить, не покидая KDE-десктопа – вплоть до интерактивного редактирования общесистемных скриптов инициализации (что, впрочем, не значит, что это нужно делать – но возможность этого вы имеет). А в грядущих версиях, по агентурным данным, KDE будет способно обходиться даже без Иксов – правда, подробности в настоящее время пока не известны, и не ясно, как это будет выглядеть: то ли в KDE будет встроен собственный X-сервер, то ли система обретет возможность воспроизведения графики через frame buffer. Впрочем, даже в современном виде KDE просматривается тенденция обходиться без обще-Иксовых ресурсов – например, в нем имеются собственные системы управления шрифтами и клавиатурными раскладками.

И четвертое выгодное качество KDE – это стабильно поступательное, уже на протяжении многих лет, развитие. Я имел удовольствие наблюдать эту систему с самых первых версий (где-то с 1998 г.) и свидетельствую: от ветки к ветки она не только обрастала новыми функциями (это – дело обычное), но становилась все стабильнее и (sic!) быстрее. Совершенствуя при том свой интерфейс визуально – а эстетический момент отнюдь не последний в деле выбора среды обитания, по крайней мере для меня.

Конечно, KDE еще не достигла состояния идеального десктопа, и не свободна от некоторых недостатков. Однако выше я попытался показать, что они не критичны, и более-менее легко преодолимы. Что позволяет рассматривать эту систему в качестве оптимального выбора при необходимости именно в интегрированной среде обитания.

KDE vs GNOME: первый размышлизм на заданную тему

15 августа 2006 г

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

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

С теми, кто интегрированные среды не использует, все ясно: в их распоряжении изобилие менеджеров окон, имя которому – легион. А вот у приверженцев интеграции выбор совсем невелик. И до недавнего времени он вообще сводился к альтернативе, вынесенной в заголовок. Правда, можно ожидать, что скоро к KDE и GNOME добавится XFce, обретающий постепенно качества истинно интегрированного десктопа, однако пока он до этого звания еще не дотягивает.

Полноты картины ради отмечу, что есть еще несколько программ, претендующих на звание интегрированной среды. Однако это либо а) самосборные среды на базе менеджера окон и разнородных приложений (FVWM-Crystal), либо б) сугубо экспериментальные разработки (3D-Desktop или UDE), либо в) либо «недо-десктопы», крутящиеся вокруг одно приложения (как ROX – в сущности, просто файловый менеджер, хотя и удобный).

Для начала – пара слов о том, чем десктопы отличаются от менеджеров окон. Главной задачей последних, как явствует из их названия, является управление поведением окон – открытием и закрытием, перемещением, масштабированием, передачей фокуса и переключением между окнами. И есть немало оконных менеджеров, функциональность которых этим и ограничивается. – не от бедности, а, так сказать, от жадности (точнее, экономного отношения к наличным ресурсам). Однако большинство широко используемых оконных менеджеров предоставляет и дополнительные функции – как минимум, средства для запуска приложений и навигации по ним. Кроме того, в них часто включаются собственные конфигураторы, средства управления внешним видом окон, а также мелкие утилиты типа часов, системных мониторов и тому подобных облегчающих жизнь мелочей.

Интегрированные среды могут иметь собственные менеджеры окон, как KDE и XFce. Но это для них как раз не обязательный компонент – в частности, GNOME собственного WM не содержит, а может пользоваться возможностями ряда совместимых оконных менеджеров. Главными же компонентами десктопов оказываются а) средства собственного конфигурирования и б) базовый набор приложений, объединяемых сквозным интерфейсом. Единство интерфейса обеспечивается использованием определенных наборов библиотек, которые, таким образом, оказываются неотъемлемой частью десктопа.

Идея интегрированных сред пришла в мир Open Source из проприетарных Unix-систем, где с давних пор развивался декстоп под названием CDE, основанный на библиотеке Motif. Ни сама CDE, ни ее базовая библиотека не были свободными программами, и, следовательно, их использование в Linux или BSD оказывалось невозможным. И потому во второй половине 90-х годов начали развиваться проекты по созданию свободных интегрированных сред.

И тут дело в первую очередь упиралось в разработки собственных библиотек – единственная полнофункциональная графическая библиотека, Motif, как я уже говорил, в те годы не была свободной. А ее свободный клон, Lesstif, использовавшийся во многих менеджерах окон, по своей функциональности сильно не дотягивал до прототипа. И тут помощь пришла со стороны: в 1996 году началась разработка растрового графического редактора Gimp, под который была создана библиотека Gtk (GIMP ToolKit). Именно она и легла в основу первого свободного десктопа – GNOME, который довольно быстро стал рабочей средой по умолчанию в ряде популярных дистрибутивов (в частности, Red Hat).

Вторым путем к созданию интегрированной среды – оказалась возможность использования кросс-платформенной библиотеки Qt, созданной норвежской фирмой Trolltech (на ней основывалась и основывается известный барузер Opera). Сама по себе эта библиотека не была свободной, но ее лицензия допускала бесплатное использование в некоммерческих проектах, в том числе и проектах Open Source. Она-то и легла в основу второй интегрированной среды – KDE. Правда, вследствие коммерческого характера базовой библиотеки отношение к ней было сначала очень сдержанное. И первым дистрибутивом, в который KDE была включена как десктоп по умолчанию, стал Mandrake (1998 год).

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

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

Развитие же KDE было скучным, плоским, даже линейным. Версии первой его ветки, которые мне довелось увидеть в 1998-1999 годах, не поражали воображение ни дизайнерскими изысками, ни какими-то сверхъестественными фичами. Навевая ассоциации с унылым индустриальным пейзажем, видным из окон микрорайона современного мегаполиса. Но они отличались одной особенностью – все в них работало, работало стабильно и, по сравнению с GNOME, относительно быстро.

Вторая ветка KDE привнесла в эту среду оригинальность с точки зрения функционала: именно в ней убогий IE-подобный kfmanager сменяется покорителем файловых пространств konqueror'ом, а место удручающих kedit и kwrite занял kate. Впрочем, во всей красе они развернулись только в третьей ветке, каковая и является на данный момент текущей. И которая подарила миру десктопов функции, ранее обеспечивавшиеся только X-серверами – в частности, управление шрифтами и клавиатурой. Кстати, и с эстетической стороны KDE претерпело разительные изменения от первой до третьей ветки. Правда, следы «индустриального» происхождения можно видеть в ней и по сию пору.

С первых же дней сосуществования GNOME и KDE между приверженцами этих сред развернулись чуть ли не религиозные войны, усугубившиеся идеологическими соображениями. К настоящему времени идеологическая составляющая этого противостояния оказалась исчерпанной. Библиотека Qt, кроме сугубо коммерческой лицензии, распространяется также (для некоммерческого использования) и под открытой лицензией QPL, совместимость которой с GPL не ставится под сомнение даже самыми строгими пуристами от свободного софта. Однако технологическая сторона противостояния GNOME vs KDE не только не сгладилась, но даже несколько обострилась. Правда, в основном со стороны их пользователей. Майнтайнеры универсальных дистрибутивов ныне включают оба десктопа в штатные свои комплекты, как правило, предоставляя выбор между ними на стадии инсталляции. А разработчики сторонних программ, вне зависимости от используемых базовых библиотек, все чаще предусматривают интеграцию своих продуктов в обе среды.

Эта заметка – еще один вклад в священную войну десктопов. Сразу оговорюсь – в ней я даже не пытался быть беспристрастным. Потому как использую KDE с самых первых ее версий (тех, что были в Mandrake 5.1 и 6.0/RE), правда, с перерывами, вызванными увлечением WindowMaker и всяческими box'ами. И полагаю эту среду вполне подходящей как для начинающих пользователей, так и для тех, кому надоели работы по сборке собственного десктопа.

Что же до GNOME... начиная с того же 1998-го, неоднократно ставил его, пытаясь проникнуться величием этого десктопа – и каждый раз безуспешно. И все многочисленные обсуждения этого вопроса не изменило моего мнения. Так что можете считать эту заметку апологией KDE. Буду рад, если она подвигнет кого-либо на сочинение, продемонстрирующее, наконец, несравненные достоинства GNOME и, особенно, его приложений.

Итак, по каким критериям можно сравнивать десктопы? Во-первых, по удобству выполнения элементарных действий – запуска программ, манипуляции окнами и запущенным приложениями, и так далее.

Во-вторых, по богатству и удобству средств собственного конфигурирования.

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

Начнем с так называемого удобства. Так называемого – потому что понятие это весьма субъективное, и во многом зависит просто от сложившихся привычек. Кроме того, вид и поведение интерфейсных элементов обеих сред могут быть модифицированы в очень широких пределах. Не говоря уже о том, что они во многом определяются текущим менеджером окон – а и в GNOME (своего менеджера окон, как мы помним, не имеющего), и в KDE заменить их можно достаточно легко.

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

Так что любые сравнительные оценки удобства использования KDE и Gnome носят абсолютно субъективный характер. Так что позволю себе и я высказать свое сугубо субъективное мнение: KDE существенно удобнее в использовании, чем Gnome. Правда, не в умолчальном своем состоянии, а после некоторых настроек, как то:

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

2. уменьшения размера пиктограмм;

3. сокращения длины панели до 90% от ширины экрана (зачем скоро станет ясным);

4. выноса на панель наиболее часто используемых приложений и командной строки минитерминала;

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

6. увеличения количества рабочих столов по потребностям.

А потребность в рабочих столах диктуется стилем работы – оконным (каждое приложение открыто в окне, занимающем часть одного или двух рабочих столов – стиль, унаследованный от Windows) или полноэкранным. Я – приверженец второго, и вот за этим мне и потребовалось сократить длину главной панели – чтобы всегда иметь доступ к конеткстным меню, осуществляющим как запуск программ, так и переключение между рабочими столами и запущенными приложениями.

Таким образом, для полного комфорта работы в KDE (подозреваю, что и в Gnome тоже) необходимо выполнить кое-какие настроечные действия. И тут мы плавно переходим ко второму критерию сравнения десктопов – собственным средствам конфигурирования.

На первый взгляд, в этой сфере однозначно выигрывает Gnome: большинство тривиальных действий по настройке окружающей среды в нем выполняются в два-три клика мышью. Однако настройки не тривиальные оказываются либо запрятанными где-то глубоко, либо вообще недоступны. По удачному замечанию одного из участников вышеупомянутого форума, Gnome специально сделан так, чтобы пользователь работал, а не занимался всякими «финтифлюшками». Идея, конечно, не лишенная резона – однако что делать, если именно некторые из этих «финтифлюшек» оказываются необходимыми для создания комфорта на рабочем месте?

В упрек KDE можно поставить разбросанность настроек в KCC (KDE Control Ctenter) и некоторую нелогичность их группировки. Так, нелегко догадаться, что настройка «горячих клавиш», например, для переключения между рабочими столами, скрывается за пиктограммой Региональные и специальные возможности. Однако, если освоиться внутри системы конфигурирования KDE, то с ее помощью можно настроить абсолютно все. Конечно, времени это займет несколько больше, чем аналогичные манипуляции Gnome. Но временные затраты компенсируются много большей гибкостью настроек. Да и заниматься этим делом приходится лишь однажды – далее потребуются лишь мелкие коррективы при обновлении версий.

Теперь обратимся к основному критерию сравнения – набору штатных приложений. Из коих главными мне (и, думаю, со мной согласится каждый действующий линуксоид) представляются следующие:

• терминальная программа;

• файловый менеджер;

• текстовый редактор;

• почтовая программа;

• браузер;

• средство резервного копирования;

• офисный пакет; точнее, ворд-процессор, как средство, по выражению Владимира Игнатова, прогнуться под испорченный мир.

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

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

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

Итак, переходим к сравнению, начав, согласно приведенному выше списку, с терминальной программы. Таковыми в KDE и Gnome выступают konsole и Gnome terminal, соответственно. Набор базовых возможностей у них примерно одинаков: поддерживаются закладки (Tabs), имитирующие множество терминальных окон «в одном флаконе», «горячие клавиши» для переключения между ними, настройку шрифта, цветовой схемы и типа терминала, смену кодировок вывода «на лету» (незаменимая возможность для поиска текстовых фрагментов в файлах с разными исторически кодировками). Однако незаменимая функция konsole – возможность сохранения так называемых профилей сеансов, позволяющая индивидуально задать свойства каждой закладки и сохранить их для дальнейшего использования.

Файловые менеджеры из KDE и Gnome – Konqueror и Nautilus, соответственно, – сравнивать напрямую не очень легко. Хотя бы потому, что первый выступает также и как браузер, тогда как Nautilus – только и исключительно файловый менеджер, внешне подобный MS Explorer. Однако даже чисто в ипостаси файлового менеджера Konqueror демонстрирует массу уникальных свойств. Во-первых, внешний его вид может быть настроен буквально как угодно – от типично древовидного представления файловой иерархии до двухпанельного вида, подобного незабвенному командиру Нортону и его многочисленным детям.

Главная же особенность Konqueror'а – интеграция файлового менеджера с терминальным окном, представляющим собой ту же самую konsole, свойства которой могут быть настроены независимо. И действия в которой можно синхронизировать с окнами визуального представления файловой системы.

Стандартным текстовым редактором в KDE выступает kate (при унаследованном от прошлых версий kwrite), в Gnome – Gedit. Здесь все просто: второй супротив первого – что плотник супротив столяра, это программы просто разной весовой категории. Gedit – простенький редактор с минимумом обычных ныне функций, включающих контекстный поиск и замену, подсветку синтаксиса. Однако лишенный таких развитых средств, как поиск с использованием регулярных выражений и управление проектами, а также возможности простого создания макросов.

С другой стороны, Kate обладает всеми атрибутами редактора «тяжелой» весовой категории, в том числе поддержкой вкладок (Tabs) и меток в тексте, очень развитыми средствами управления проектами и поиска/замены. Ему также свойственна особенность, уникальная, насколько мне известно, среди текстовых редакторов – интеграция с файловым навигатором и терминальным окном, функции которого выполняет все та же вездесущая konsole. Конечно, Kate обладает одним существенным и, похоже, неискоренимым недостатком: отсутствием простых средств для создания пользовательских макросов (подобных таковым в NEdit, например). Но ведь его нет и в Gedit'е...

В отношении почтовых программ сравнивать KDE и Gnome несколько сложно. Потому что функционально Evolution, обеспечивающий прием и отправку почты в последнем, далеко выходит за рамки почтового клиента, являясь также персональным помощником (PIM) и обеспечивая интеграцию с Microsoft Exchange. Однако, если в этих функциях нет необходимости – можно признать, что Kmail из KDE с обязанностями почтового клиента справляется отлично. А PIM в KDE есть и отдельный.

Теперь браузер. В KDE с ним все просто – эту роль исполняет Konqueror в соответствующей ипостаси. Его относят обычно к категории легких, или «неполноценных» браузеров. Что, однако, было верно только для второй ветки. В ветке же третьей Konqueror-браузер, сохранив легкость, превратился в полноценное средство web-серфинга. Фирменная его особенность – очень развитые и удобные средства управления закладками, ничуть не уступающие таковым из Opera, породившей идею Tab'ов. К недостаткам Konqueror'а можно отнести неправильное воспроизведение многих сайтов. Что ж, это – плата за нежелание потсупиться принципами в отношении следования спецификациям W3C (Konqueror – один из самых жестких браузеров в этом отношении). Так что недостаток ли это – вопрос спорный. По меткому замечанию Сергея Голубева, он по крайней мере позволяет сразу выявлять фирмы, сэкономившие на зарплате web-мастера.

В Gnome с браузером посложнее. Насколько я слышал, на эту штатную единицу там предназначен Galeon. Слышть слышал, а вот видеть не приходилось. Потому что в дистрибутивах, использующих Gnome в качестве декстопа по умолчанию (например, Ubuntu) никаких следов Galeon'а в исходной установке не обнаруживается. Стыдятся его майнтайнеры, что ли? Неужто Galeon так плох? И в результате в большинстве случаев дежурным браузером оказывается FireFox. Хорошая, конечно, программа (хотя мне и не нравится), но какое отношение она имеет к Gnome?

Напоминать о необходимости резервного копирования, думаю, не нужно – она очевидна всем. Столь же очевидно, что чем удобнее инструмент для выполнения этой операции (а ныне она, фактически, сводится к записи на CD/DVD), тем с большей регулярность пользователь будет ее выполнять. Конечно, в его распоряжении консольная пара mkisofs и cdrecord, и при массовой записи дисков с ними не сравнится никто. Однако единичные диски часто проще записать с помощью графических front-end'ов. И такой в KDE имеется (хотя и не ходит пока в набор основных пакетов) – программа k3b, простая в освоении и использовании, имеющая все необходимые функции. Ничего аналогичного Gnome, насколько мне известно, предложить не может. Разве что Gaveman – очень простую в обращении оболочку, вроде бы умеющую делать все, что обычно нужно (по крайней мере, мне). Но и это – строго говоря, не Gnome, а просто Gtk-приложение...

И, наконец, ворд-процессор, представленный KWord в KDE и AbiWord в Gnome, составные части KOffice и Gnome Office, соответственно. Сразу скажу, что для всамделишних офисных задач ни тот, ни другой не годятся – тут уже без OpenOffice.org не обойтись. В частности, оба они не умеют работать с мультиверсионными документами MS Word. Хотя KWord делает это, если так можно выразиться, менее плохо: он хотя бы помещает версионные вставки в общий текст, и хотя никак их не помечает, при крайней необходимости разобраться можно. Тогда как AbiWord их просто игнорирует.

А вот в чем KOffice оказывается вне конкуренции – это в экспорте в формат HTML. Будучи единственным из известных мне ворд-процессоров, позволяющим получить на выходе web-документ без всяких «паразитных» тэгов. Для чего только и нужно, что отметить в диалоге экспорта соответствующие опции. Правда, AbiWord тоже предлагает аналогичный диалог, но результаты его хладнокровно игнорирует: что бы вы там ни указали, результатом будет все тот же перегруженный «отсебятиной» файл (хотя и не столь страшный, как при экспорте из MS Word и даже OpenOffice.org).

Раз уж речь зашла об web-страницах, не могу не сказать пары слов об инструментах, в отличие от ворд-процессоров, специально предназначенных для создания оных. Тем более, что пакет kdewebdev входит в штатное расписание KDE. А включает он редактор html-кода Quanta Plus, среди функций которого – средства управления проектом, возможность закачки изменений на сервер и прямой онлайновой правки web-страниц, визуальное представление и редактирование кода, и многое другое. А чего не поддерживается непосредственно редактором – обеспечивается дополнительными компонентами пакета, обеспечивающими построение Image Maps, проверку целостности ссылок, как внутренних, так и внешних, глобальную замену текста в пределах проекта. Кстати, для Quanta Plus характерна та же интеграция со средствами файловой навигации и терминальным окном, что и для Kate. В противовес этому Gnome может вдвинуть два html-редактора – Bluefish и Screem. Правда, ни тот, ни другой не входят в уполчальный комплект, а суммарный их функционал дай Бог потянет на половину от одной Quanta.

О сравнении мультимедийных и графических программ говорить особенно не буду: первое – очень субъективно, в отношении же графики сравнивать особо нечего. Ибо векторная графика в обеих средах находится в зачаточном состоянии, в графике растровой Gimp конкуренции себе не имеет. Растровый редактор из KDE, Krita, представляет из себя еще весьма сырую и неустойчивую конструкцию. Правда, Gimp тоже не составляющая Gnome, скорее уж, Gnome – это интерфейс для запуска Gimp'а.

Пора подводить итог. Не боюсь показаться пристрастным, ибо, с моей точки зрения, он таков:

• KDE – это целостная конструкция, все составляющие которой развиваются во взаимосвязи;

• Gnome – эклектическая мозаика различных по происхождению программ, причесанных под один интерфейс лишь благодаря общим библиотекам;

• среди приложений, составляющих ядро KDE, ряд программ, безусловно, принадлежит к числу лучших в своем классе, а некоторые – просто уникальны по своим возможностям;

• все Gnome-приложения, составляющие неотъемлемую часть этого десктопа, в лучшем случае имеют средний рейтинг в своих категориях;

• все действительно первоклассные программы, включаемые в состав среды Gnome, не являются неотъемлемыми его компонентами.

При обсуждении KDE и Gnome обычно большое внимание уделяется их сравнительному быстродействию. Я об этом скажу лишь вкратце. До недавнего времени KDE по визуальном быстродействию однозначно выигрывала – Gnome подчас казался мне средой, специально предназначенной для того, чтобы swap-раздел не простаивал без дела. Ныне положение изменилось, и по такому параметру, как скорость собственной загрузки и запуска приложений, Gnome безусловно (и ощутимо) вырвался вперед. Но: скорость запуска отнюдь не равна быстроте выполнения реальных операций. Как скажется различие сред и лежащих в их основе библиотек на, скажем, создании огромного архива или образа DVD-диска? Подозреваю, никак: на современных машинах разница вряд ли будет заметна, а для старых и слабых машин ни KDE, ни Gnome не предназначены; хотя, может быть, последний не предназначен несколько менее...

Конечный мой вывод, думаю, ясен: если нужно выбирать из интегрированных десктопов, мои симпатии всецело на стороне KDE. Если мои соображения кажутся излишне категоричными – что ж, в силах оппонентов написать апологию несравненных достоинств Gnome.

GNOME: сдержанная апология

Август 6, 2009

Ровно три года назад я написал статью под названием «KDE vs GNOME: первый размышлизм на заданную тему» (см. предыдущий материал). Каковая являла собой откровенную и неприкрытую апологию первой из указанных в заглавии интегрированных сред. Написал в тайной надежде, что кто-нибудь из приверженцев GNOME в порыве возмущения сочинит нечто подобное о несравненных достоинствах своего любимого десктопа.

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

Первое событие, излечившее меня от категоричности, к самому GNOME не имело никакого отношения: это был выход KDE4, которого столь долго ожидали давние пользователи этой среды. И которое для многих из них послужило источником разочарования. Можно сколько угодно рассуждать о прогрессивности заложенных в новый десктоп идей, но факт остаётся фактом: это была резкая смена парадигмы его развития. Каковая, опять же с точки зрения тех самых, давнишних, пользователей выглядела не вполне оправданной.

Сразу оговорюсь – вопросы устойчивости первых релизов KDE4 или отсутствия в них многих привычных приложений я обсуждать не буду. В конце концов, недоработки только что вышедшей версии любой программы – штука вполне естественная и лечится временем. Но вот отказ от поступательного развития, характерного для KDE с самой первой его версии, не мог не настораживать.

И это мнение не только моё: KDE с выходом 4-й версии растеряло многих своих прежних приверженцев. Чтобы убедиться в этом, можно посмотреть на результаты опроса на Unixforum.org, начавшегося 1 октября 2008 года и по недосмотру администрации не закрытого по сей день. Конечно, благодаря этому он стал напоминать среднюю температуру по больнице. Однако его пролонгированность отражает тенденцию: даже с учётом наплыва новых пользователей Linux'а за последние пару лет – тех, кто, возможно, KDE3 и в глаза уже не видел, доля последней по прежнему превосходит младшую сестричку. И это на фоне роста числа пользователей GNOME и Xfce. О росте популярности тайловых оконных менеджеров или возрождения интереса к разнообразным box'ам я уже не говорю.

Разумеется, у стойких приверженцев KDE 3-й ветки был выход – продолжать использовать любимый некогда десктоп. Однако очевидно – это не более чем временное решение: с самого начала было ясно, что поддержка её в скорости прекратится, форка не предвидится, и через пару лет эта среда станет анахронизмом, какими бы достоинствами она ни обладала. Подобно тому, как ныне выглядят анахронизмами блестящий WindowMaker или скромно-элегантный Blackbox. Так что забота о будущем требовала поиска запасных аэродромов.

Для тех, кто не готов отказываться от сквозных настроек среды и при этом не испытывал симпатии к GNOME, выбор был однозначный – Xfce. С KDE её роднит концептуальная целостность. Но, в отличие от последней, в Xfce нет (и пока не предвидится) всеохватного набора собственных приложений – это не хорошо и не плохо, это просто медицинский факт. Так что недостающие в штатном комплекте программы приходится тащить из посторонних для этой среды источников. И тут оказывается, что, ввиду общности большей части библиотек, эти программы оказываются теми же самыми, что и в GNOME. А потому возникает резонный вопрос – а почему бы не попробовать его самого?

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

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

И ни разу у меня с GNOME не срасталось – возможно, потому, что после стройного здания KDE, воздвигнутого в едином стиле (пусть и в стиле «эпохи архитектурных излишеств»), он производил впечатление эклектичной мозаики разновозрастных и разнохарактерных компонентов. Да ещё и сознательно ограниченной в настройках.

Перелом в моём отношении к GNOME наступил в те недолгие месяцы, что мне довелось поработать в OpenSolaris. Поскольку эта ОС не предоставляла никакого выбора среды обитания, пришлось обитать там, где обиталось. То есть в GNOME. К тому моменту отказ от KDE стал для меня свершившимся фактом, и за спиной был уже некоторый стаж жизни в Xfce. Так что первое, что мне понравилось в GNOME – это то, что внешне превратить его в Xfce-подобие оказалось делом нескольких минут.

Ну а когда я занялся Fedora, познакомиться с GNOME поближе сам Бог велел – уж больно органично они сочетаются друг с другом. И тут уже совсем выяснилось, что не так страшен GNOME, как его малюют. Чтобы убедиться в этом, достаточно осознать следующий факт:

GNOME – это не интегрированная среда в собственном смысле слова, в отличие от KDE и даже Xfce.

Возможно, это покажется крамолой, поэтому попробую обосновать.

На том, что GNOME не имеет собственного менеджера окон, я зацикливать внимание не буду: времена, когда он мог менять WM'ы «как, терьям-терьям, перчатки», кажется, забылись (хотя в свете грядущего рано или поздно GNOME 3 о них и придётся вспомнить в связи с заменой Metacity на Mutter). Тем не менее, остаётся фактом, что интерфейс GNOME обеспечивается сочетанием оконного менеджера, механизма панелей и набора плагинов и апплетов.

Далее, GNOME, как ни странно, в сущности не имеет сквозных средств настройки – эти функции выполняются набором утилит общесистемного конфигурирования и представления пользовательского окружения. Да, они объединены рамкой Центра управления полетами, но, в отличие от KCC, системного единства не представляют. Да и самого Центра управления может не быть – точнее, он может быть по умолчанию скрыт в невидимом пункте системного меню.

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

И, наконец, штатные приложения GNOME. Существует мнение, что их бессчётное количество. Однако, если вдуматься, то неотъемлемых приложения в GNOME всего три – эмулятор терминала (Gnome terminal), файловый менеджер (Nautilus) и текстовый редактор (Gedit). Все остальные – либо меняются от версии к версии среды, либо благополучно существуют вне GNOME и помимо него, будучи объединены с ним только привязкой к тем же библиотекам Gtk.

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

После осознания факта, что GNOME – не интегрированная среда, а лишь её заготовка, жизнь в нём становится простой и лёгкой. Не понравившееся приложение из сборки данного дистрибутива без труда меняется на функционально аналогичное (например, Totem и Rhythmobox замещаются Gnome-mplayer'ом, Deluge – Transmission'ом, и так далее), приложения заведомо ненужные – удаляются (даже Evolution, казалось бы, так прочно интегрированный в среду), недостающие компоненты – доустанавливаются (например, Geany – при недостаточности возможностей Gedit'а; хотя, надо заметить, и последний оказывается не столь убогим, каким выглядит на первый взгляд). Что же касается «внесредовых приложений», типа Firefox'а или Openoffice.org, то они в GNOME выглядят более чем органично.

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

А вот по поводу визуального быстродействия – нельзя не признать, что GNOME сделал большой шаг вперёд. Впрочем, это было заметно ещё три с лишним года назад, когда я глядел на него изнутри инсталляции Ubuntu – с одновозрастной KDE из Kubuntu он конкурировал не просто на равных, а с существенным опережением. А ведь это было ещё во времена расцвета KDE 3-й ветки – что же говорить о ветке 4-й.

Сравнение с Xfce не столь однозначно. Можно лишь утверждать, что последняя не выказывает подавляющего превосходства. И вообще, тут дело скорее зависит от конкретной сборки. Во всяком случае, GNOME в Fedora 11 по «реактивности» ничуть не уступает Xfce из Zenwalk'а 6.0, несколько превосходя её же из Xubuntu 9.04.

Итог же этой заметки таков: жизнь есть везде, даже в подземельях Мории. То есть в среде GNOME.

GNOME Shell: оценка юзерофильности

Октябрь 12, 2009

Едва в предшествующей заметке, «GNOME: сдержанная апология», я успел пропеть хвалебную драпу GNOME... впрочем, нет, скорее, флокк... Как разработчики этой среды вспомнили, видимо, что любая хвалебная песнь требует адекватного отдарка в виде золотых обручьев, драгоценного оружия, а то и цельного драккара (см. «Исландские саги» в любом издании). И решили не давать ни малейшего повода себя хвалить, выпустивши GNOME 3 с его GNOME Shell'ом. О котором далее и пойдёт речь. Правда, ещё о пре-релизной версии, в которой GNOME Shell' ещё не развернулся во всей красе. И которая вызывала надежду на исправление очевидных огрехов – увы, не оправдавшуюся.

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

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

Марья Петровна, кто кого... эээ... любит, я Вас или Вы меня?

Для начала – о революционности. Она заключается в наличии двух принципиально разных режимов:

• оверлейного, из которого можно только запускать приложения или открывать файлы, и

• «рабочего», в котором можно работать с файлами уже открытыми.

Это действительно совсем разные режимы: в оверлейном ничего нельзя делать практически, кроме как открывать и закрывать, в «рабочем» – можно почти только работать. Запускать программы и открывать файлы (вне запущенных приложений) тоже можно – но фактически только через командную строку минитерминала. Меня лично это не напрягает – но объекту любви, пресловутому сферическому юзеру в вакууме, может и не понравится.

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

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

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

А вот что мне очень не понравилось – так это сочетание фона и текста в сайдбаре при оверлейном режиме. Шрифт, во-первых, очень маленький для моих глаз. Во-вторых, по моему глубокому убеждению, выворотка (то есть светлый текст на тёмном фоне) вообще приемлем только при использовании полужирного шрифтоначертания. Так что разглядеть что-либо на сайдбаре можно только с большим трудом.

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

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

Однако таким образом вызывается обычный Центр управления GNOME, позволяющий настроить вид окон и приложений, но не оказывающий ни малейшего влияния на сайдбар оверлейного режима:

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

Хочется верить, что невозможность настроек оверлейного режима – явление временное, и будет ликвидирована к моменту обретения GNOME Shell'ом статуса релиза. А пока он находится в состоянии активной разработки, и при каждом плановом обновлении системы в нём что-нибудь, да меняется.

В заключение коснусь двух моментов, вызывающих обоснованные опасения. Первый касается быстродействия. Так вот, тут бояться нечего – даже на моей хилой (с точки зрения 3D) видеоподсистеме (интегрированный Intel) ни малейшего торможения при переключении режимов и рабочих мест, сопровождающемся эффектом «разворачивания» (не знаю, как это назвать более наукообразно – но тот, кто видел, поймёт) не наблюдается. Нет его, торможения, и нигде вообще.

А вот второй момент – о революционности нового интерфейса, о которой столь много говорят разработчики. Хвала Аллаху, они сильно преувеличивают – ничего ультраааа-революционного в нем я не углядел, все действия выполняются достаточно просто и привычно. За что им отдельное спасибо.

В общем, подведу итог: даже в современном своём виде GNOME Shell пригодится линуксоиду не только для того, чтобы погубить красивую вендузяднецу, но и для выполнения самой простой и обычной работы. Так что пользователя новый интерфейс любит в меру...

KDE vs GNOME. Часть 1

Февраль 11, 2012

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

Поучаствовал в тех клавиатурных баталиях и ваш покорный слуга. Причём тогда он был и гневен, и пристрастен. Почему гневен – скажу чуть позже. А пристрастен – потому что использовал KDE на протяжении десяти лет, почти с момента его появления (точнее, с появления на нашем горизонте дистрибутива Mandrake, распространявшегося IPLabs Linux Team, будущим Altlinux, в сопровождении пакетов русификации), и до выхода KDE 4.0.

Не то чтобы без перерывов – на машине, где основная работа происходит в консоли, а Иксы служат исключительно для запуска GIMP или OpenOffice, интегрированная среда выглядит как седло на корове. Так что я перепробовал я и массу оконных менеджеров, от суперминималистического FLWM до изобильных функционалом IceWM и WindowMaker. Но везде, где интегрированный десктоп был уместен, я устанавливал KDE.

Пытаясь быть объективным, я не один раз за этот период пытался и приобщиться GNOME. И каждый раз оставался в недоумении: как этим вообще можно пользоваться? Системой с убогим функционалом, являющей собой эклектику разнородных компонентов, слепленных на живую нитку, да ещё раз в три-четыре года с завидной регулярностью меняющей вектор своего развития. Фактически лишённой собственных приложений, и подбирающей их с миру по нитке. Да ещё, поначалу, и тормозной донельзя. Помнится, первые версии GNOME хорошо справлялись только с одной задачей – свопированием на диск его самого. Поневоле приходила в голову мысль о тех самых мышах, что грызли кактус. Потому что всем этим пользовались. И мало того, что пользовались – активно пропагандировали как величайшее достижение научно-технической мысли для истинно свободного мира.

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

1. обильным функционалом в отношении управления окнами и приложениями;

2. абсолютной настраиваемостью всего и вся;

3. набором штатных приложений и приложений от примкнувших сторонних разработчиков.

Функциональность KDE передать словами довольно сложно. Но достаточно было поработать подряд за KDE- и GNOME-машиной, как у матросов не становилось вопросов. Если, конечно, матросы не были уже заражены большевистской пропагандой фанатиков GNOME.

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

Маленькое отступление. С первых дней работы в Linux'е я открыл для себя истину: любой мало-мальски сложный GUI должен в штатных случаях настраиваться штатными же GUI'выми средствами. Перефразируя слова маршала Ланна, можно сказать, что

GUI,который сам себя не может настроить, – не GUI, а дерьмо.

Это в простых случаях можно обойтись правкой конфигов: например, настройка таким образом FLVM – дело очень милое и приятное. Но вот конфигурирование FVWM2 – адова работа: по богатству настроек он ничуть не уступает KDE (а может, даже и превосходит), но единственное средство реализации этого богатства – текстовый редактор. Один мой знакомый, затратив немало времени на вылизывание FVWM2 и доведя его до собственного идеала, говорил, что второй раз не взялся бы за это дело под дулом автомата.

Так вот, KDE, после понимания логики его конфигурирования (а она там, признаю, была явно не Аристотелева), настраивался легко и непринуждённо, щелчками мыши. Правда, весьма многочисленными – но и настроечных параметров в этом десктопе было немеряно.

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

К этому следует добавить, что сообщество KDE никогда не отличалось такой агрессией, как приверженцы GNOME. Конечно, в пылу форумных дискуссий эпитеты типа гномосеки или кедерасты, постились с обеих сторон. Но это, как я уже говорил во Введении, неотъемлемый атрибут древнего ритуала сравнения мужей. А амбиций в плане изменить мир в сообществе KDE никогда не наблюдалось, в отличие от GNOME Community.

Отступление. Про изменить мир я не шучу. Жена моего старого товарища, ныне пребывающего на ПМЖ в Калифорнии, будучи уволенной из NASA чуть ли не по подозрению в шпионаже (в пользу русской мафии, надо полагать) в поисках работы обратилась в том числе и в GNOME Foundation. Где на собеседовании её спросили: хотите ли вы участвовать в изменении мира? Она не выдержала и рассмеялась. В результате в этот самый фонд её не взяли. Пришлось идти на работу в маленькую заштатную конторку, каковой в то время был Google. И после капитализации которого пришлось стать очень богатой женщиной. Так что политика GNOME подчас благотворно отражается на судьбах людей, с ней соприкоснувшихся.

В силу перечисленных факторов первой половине нулевых годов вокруг KDE сплотилось сообщество пользователей-прагматиков, нуждавшихся в качественном софте для решения своих задач в среде, поддающейся стопроцентной индивидуальной настройке. В том числе и пользователей, никакого отношения к компьютерам не имеющих – юристов, переводчиков и прочих гуманитариев. Нельзя сказать, что таких не было среди пользователей GNOME – однако в этом сообществе до некоторого момента всё-таки доминировали компьютерные гики, вынашивающие планы изменения мира. Не случайно все опросы, касающиеся используемого десктопа, приносили чистую победу KDE – и с большим, подчас двухкратным, перевесом (интересующиеся могут убедиться в этом по опросам на Unixforum'е, носившем в те годы название Linuxforum'а.

Началом коренного перелома стал конец 2004 года, когда в мировом масштабе развернулось распространение дистрибутива Ubuntu, в качестве рабочей среды по умолчанию использовавшей GNOME. Однако предпосылки коренного перелома закладывались году в 2002, в то время, когда Марк Шаттлворт только приступал к реализации своего проекта. И когда он принял судьбоносное решение – использовать в новом дистрибутиве не KDE, а GNOME.

Сам Марк объясняет это тем, что в то время в KDE были «одни рюшечки и менюшечки», а GNOME был простым и функциональным десктопом. Однако тут он несколько лукавит: по функциональности KDE в то время на голову превосходил GNOME. А вот на счёт простоты – да, что было, то было. Настройка KDE усложнялась от версии к версии (пропорционально росту функционала), тогда как GNOME как раз в это время резко сменил вектор развития: если раньше его девизом было: крутейший десктоп от крутейших программеров, то теперь было решено сделать простейший десктоп, который может настроить и кухарка. А поскольку Ubuntu ориентировался (в том числе и на эту) категорию пользователей, выбор был вполне логичен.

Главным же фактором для предпочтения GNOME, мне кажется, было стремление выделиться из ряда развивавшихся тогда (и не без успеха) deb based Систем Быстрого Равёртывания (СБР), таких, как MEPIS, Xandros, Lindows: все они в качестве десктопа использовали KDE.

Так или иначе, но вследствие сочетания обоих факторов – массовой бесплатной рассылки дисков с Ubuntu и «упрощения» GNOME – началось широкое распространение последнего. Причём первый фактор был, безусловно, более весом: в ряды линуксоидов влилось свежее пополнение, которое ничего, кроме Ubuntu и GNOME, в глаза не видело, и для них эти понятия стали, по крайней мере по первости, тождественны понятию Linux. Однако и второй фактор нельзя сбрасывать со счетов: если бы GNOME показался неофитам слишком сложным, диски с Ubuntu были бы выброшены ими на помойку без всякого сожаления, ибо халява. Так что расчёт Марка оказался точным.

Здесь надо отметить, что с момента зарождения GNOME его интенсивно внедряла самая мощная Linux-компания – Red Hat. Однако, при несомненных её успехах в корпоративном секторе, на пользовательских десктопах результаты этого внедрения были мало заметны. Так что авантюрный шаг Шаттлворта для популярности GNOME оказался куда более эффективным, о чём нынче GNOME-фаны предпочитают не вспоминать. А возможно, даже и не задумываются над тем, что эта самая популярность в значительной мере обусловлена вовсе не несравненными достоинствами их любимого десктопа...

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

KDE vs GNOME. Часть 2

Февраль 13, 2012

Судьбоносное событие, изменившее ситуацию в распределении пользователей по десктопам (или десктопов по пользователям?) произошло в начале 2008 года. Это был выход KDE 4.0.

Эта версия KDE разрабатывалась примерно столько же времени, сколько хватило, чтобы смениться KDE 1, KDE 2 и KDE 3. И в анонсах её поначалу обещались если и не золотые горы, то по крайней мере серебряные. В частности, в ранних анонсах содержались толстые намёки на то, что KDE 4 будет обходиться без Иксов (правда, каким образом – не уточнялось). Со временем анонсы становились всё скромнее (в частности, из них исчезло упоминание об отказе от X-сервера), но по прежнему оставались многообещающими.

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

А с этою плазмой Дойдёш до маразма, И это довольно почётно.

На счёт почёта не знаю, а вот про маразм – очень даже соответствовало первым впечатлениям от 4-й версии.

Надо сказать, что разработчики KDE 4.0 честно предупреждали, что эта версия предназначена ещё не для практического применения, а лишь для ознакомления с новыми возможностями и их тестирования. Но делали они это достаточно невнятно, и майнтайнеры дистрибутивов дружно бросились включать её в свои новые релизы (обычно, правда, параллельно с предыдущей, 3.5.X). А пользователи, приняв всё это за чистую монету, столь же дружно стали её устанавливать.

Результат вполне предсказуем. Поскольку было вполне очевидно, что дни 3-й ветки сочтены, начался массовый отток пользователей KDE на запасные аэродромы. Для кого им стал XFce, кто вернулся ко временам информационной юности – на менеджеры окон. Но немало бывших пользователей KDE попросило политического убежища в стане GNOME.

Тут выяснилось, что в GNOME 2008-2009 годов жить можно. Конечно, огорчал подход к конфигурированию среды, когда в интерактивном режиме был доступен лишь самый минимум, необходимый, по мнению разработчиков, «простому» пользователю, а для реализации более сложных (по их же представлениям) опций следовало лезть в нечто вроде реестра, ещё менее интуитивно понятного, чем опции настройки KDE, и гораздо более бедного. Видимо, разработчики GNOME руководствовались старым советским принципом:

Что позволено парторгу – не позволено бичу.

Поначалу удручало убожество убожество штатных приложений – например, Gedit'а в сравнении с Kate или Nautilus'а – в сравнении с Konqueror'ом, настроенным должным образом. Однако в этом оказались и свои плюсы: в GNOME органично интегрировались любые сторонние приложения, основанные на Gtk. И Gedit для всамделишней работы легко заменялся Geany, а Nautilus – дополнялся PCManFM'ом.

Кроме того, GNOME оказался тесно интегрированным с такими ОС, как OpenSolaris и такими Linux-дистрибутивами, как Fedora. Тем более, что нормальных альтернатив в первой и не предлагалось. И, хотя при ближайшем рассмотрении OpenSolaris для практической работы оказалась непригодным, именно эта ОС и примирила меня с GNOME. В составе Fedora он мне даже стал немного нравиться – ведь и там в качестве альтернатив выступали или отвергнутая KDE, или XFce, сама по себе прекрасная но как раз имевшая напряги по части интеграции с системными службами дистрибутива – напряги мелкие и поправимые, но раздражающие.

Так что на рубеже десятилетий между KDE и GNOME был достигнут примерный паритет. Хотя KDE и сохранял некоторое преимущество – за счёт а) стойких его приверженцев и б) энтузиастов новаторства. Тем более, что на месте эта среда не стояла, а постепенно допиливалась до юзабельного состояния, сама по себе, во-первых, и портированием на 4-ю ветку сторонних «трёшечных» приложений – во-вторых. Я, утратив в то время всякий интерес к KDE, не следил за этим процессом. Но, говорят, что к версии 4.4 KDE стал вполне похожим на настоящий как сам по себе, так и в отношении своих приложений.

Отступление. Сейчас, по прошествии нескольких лет, я понимаю, что разработчики KDE почти всё сделали правильно. Допустив лишь одну тактическую ошибку: обозвав релизом достаточно сырую тестовую версию. И никакие объяснения, что это не совсем таки настоящий релиз, не в силах были преодолеть магию Слова. Хотя, с другой стороны, не пойди KDE'шики на такой отчаянный шаг, разбудивший здоровую рабочую злость и пользователей-тестировщиков, и сторонних разработчиков – кто знает, может быть, 4-я версия KDE отлаживалась и по сей день в тестовом режиме.

Тем не менее, отток пользователей от KDE казался необратимым, и GNOME утвердился с ним на одной ступеньке пьедестала почёта, может быть, ну на полступеньки ниже. Повторяю, заслуги самого по себе GNOME в приближении к вершине пьедестала были минимальны, ибо главные роли в этом спектакле сыграли уже упомянутые факторы – массовое распространение Ubuntu и ошибки команды KDE в продвижении новой версии своей среды. К этому надо добавить неожиданный рост популярности дистрибутива Fedora, тесно интегрированного с GNOME. Причём рост этот начался не благодаря GNOME, а скорее вопреки ему: многие пользователи готовы были смириться с этой средой ради достоинство самой системы.

Это что касается распространения GNOME в мировом масштабе. А в нашей стране дело усугубилось успехом проекта Russian Fedora, деятельность которого воплощена была в сборках RFRemix, кардинально улучшавшихся от версии к версии, вплоть до RFRemix 14 – апофеоза отечественного дистростроения.

Но, как поётся в песенке

Недолго музыка играла, Недолго фраер танцевал.

Ибо свежий ветер перемен затронул и GNOME, да так, что мало не показалось. Потому что принёс он с собой GNOME 3 с его GNOME Shell. Если и раньше, во времена GNOME 2, среда эта не утомляла своего пользователя изобилием настроек, даже в собственном реестре, то с переходом к 3-й ветке настройки практически исчезли как класс – или, позднее, в очень ограниченном количестве стали доступны благодаря сторонним утилитам. Что же до интерфейса – от него, казалось бы, не осталось просто ничего.

Однако большинство нового – это хорошо испорченное старое. Так, оверлейный режим GNOME Shell'а вызывает в памяти времена FVWM и FVWM95. Времена, когда не было ещё фиксированных множественных рабочих столов, но был зато единый рабочий стол с виртуальным разрешением в два и более раз выше физического. А вертикальный ряд пиктограмм вдоль левого края экрана кажутся репликой Window Maker'а, который, в свою очередь унаследовал эту идею от NeXTSTEP'а, чего разработчики «делателя окон» никогда не скрывали.

Не знаю, позаимствовали разработчики GNOME Shell'а эти идеи у предшественников, или изобрели свои велосипеды независимо от них. Но в любом случае – ничего ультра-революционного в плане интерфейса эта среда не содержит. Разве что слияние виртуального рабочего стола с вертикальными пиктограммами. В результате чего получилось вполне удачное нишевое решение – например для планшетов и прочих устройств с сенсорным экраном. И мало пригодное для использование на обычном десктопе или ноутбуке. По крайней мере, для тех, кто на десктопе или ноуте преимущественно работает, а не развлекается.

Однако разработчики GNOME Shell'а с этим не согласились. И пытаются представить своё нишевое решение как универсальное. Причём с такой агрессивностью, с какой я не сталкивался за полтора десятка лет соприкосновения с миром Open Source. На любую критику в адрес своей среды у её фанатиков (не фэнов, не фанатов, а самых натуральных фанатиков) существует универсальный ответ: всё это гениально и прогрессивно, а кто того не понимает –- ретроград и обскурант.

Существует среди пользователей GNOME и другое течение – страстотерпцев. Не будучи приверженцами модерна, но сохраняя приверженность GNOME, они полагают, что надо смириться и привыкать к новомодному GNOME Shell'у. Пот принципу: Стерпится – слюбится.

Наконец, третье течение – консерваторов от GNOME. Понимая, что слова

Мене, текел, упарсин

для 2-го GNOME уже написаны, они занимаются превращением внешнего вида GNOME 3-го в некое подобие левой руки предшественника. И, надо сказать, не без успеха. Однако при этом затрачивается столько усилий, что поневоле вспоминаются слова Ильфа и Петрова о создании трудностей для того, чтобы их героически преодолевать.

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

Именно это я и попробовал проделать, когда установил PCLinuxOS – в его текущей версии представлена KDE 4.6.5. И должен со всей ответственностью заявить: «четвёрку» KDE действительно допилили. Ныне это полнофункциональная, стабильная, гибкая, абсолютно настраиваемая (хотя по прежнему и не вполне очевидными способами) рабочая среда. К тому же – на более-менее современных машинах весьма быстрая, и не предъявляющая столь специфических требований к системе, как GNOME 3 с его Shell'ом.

Но... за годы, прошедшие со дня выхода KDE 4.0, его приложения растеряли большинство своих преимуществ перед аналогами. Не то что они стали хуже. Но в то время, когда большая часть сил KDE-сообщества уходила на допиливание среды, сторонние разработчики приложений на Gtk (не обязательно под GNOME – почти все они прекрасно работают и вне этой среды) не сидели сложа руки и активно развивали свои софтины.

В результате ныне Geany безусловно превосходит Kate по своей функциональности, AbiWord приобрёл все атрибуты настоящего текстового процессора, включая нормальные средства коллективного редактирования, Gnumiric остаётся вне конкуренции в плане инженерных расчётов и технической графики – по сравнению с соответствующими компонетами не только KOffice (который так и не нашёл своего пользователя), но и OOo/LibreOffice. И подобных примеров можно привести ещё много.

Показательна в этом плане ситуация с Konqueror'ом. Будучи изначально прекрасным файловым менеджером с дополнительными функциями браузера, он в 4-й ветке стал посредственным браузером с функциями файлового менеджера, задействование которых требует некоторых усилий. То есть сам по себе Konqueror в ипостаси браузера не плох. Но для работы со всякого рода онлайновыми службами, в том числе платёжными, мало пригоден. Ибо разработчики последних едва усвоили, что кроме IE существует ещё и FireFox, так что ожидать от их продукции совместимости с Konqueror'ом, доля которого при заходах даже на сайты тематики UNIX/Linux не достигает и процента, было бы опрометчиво.

Роль же файлового менеджера в 4-й ветке была возложена на Dolphin – поначалу жалкое Explorer-подобное поделие, лишь недавно достигшее функционала старого Konqueror'а. Конечно, вы можете возразить, что последний по прежнему можно использовать как файловый менеджер по умолчанию. Однако тогда возникает вопрос – а зачем нам два генеральных секретаря файловых менеджера?

В результате я обнаружил лишь несколько KDE-утилит, сохранивших безусловное первенство, например, Ksnapshot для снятия экранных снимков и Krename – средство массового переименования файлов. Да комплект Kdewebdev, включающий web-редактор Quanta, остаётся вне конкуренции, но его развитие практически прекратилось: много ли кому нынче, в век многочисленных типовых движков, требуется создание с нуля и сложное редактирование HTML-кода?

Возникает вопрос: так зачем устанавливать среду KDE, пусть даже в минимальном объёме, если из неё реально необходимо лишь несколько пакетов? Не проще ли использовать лёгкий DE или даже менеджер окон, дополняя их нужными KDE-, QT- и Gtk-приложениями? Которые, разумеется, потянут за собой в качестве зависимостей соответствующие библиотеки, но, тем не менее, количество балласта в система ощутимо сократится.

Кстати, всё сказанное относится и к GNOME. С той только разницей, что сам по себе этот десктоп не содержит никаких выдающихся приложений.

Большое сравнение: Fedora, openSUSE, Ubuntu

Так уж исторически склалось, что последние полгода я занимался в основном Ubuntu и её сородичами, в первую очередь Mint'ом. Это естественным образом привело меня к порождённому им Cinnamon'у. Который привёл меня в восхищение, бывшее бы полным, если бы некоторые мелкие детали, весьма для меня важные детали, мешавшие полноте этого чувства. Отсюда появилось желание поглядеть на этот десктоп в более иных дистрибутивах. Что я и не замедлил проделать на примере тех, которые больше всего применял в течении последних лет – Fedora и openSUSE. В результате чего активизировалась давнишняя задумка провести сравнение этих трёх систем. Результаты её реализации и предлагаются на последующих страницах.

Введение

Перед вами очередное «сравнение мужей», которое, как и все сочинения данного жанра, преследует в основном гуманитарные цели – этнографические или, если угодно, этологические. Однако, прежде чем добраться до гуманитарной составляющей, придётся пройти сквозь некоторые технические детали устройства объектов сравнения. А в качестве таковых выбраны Fedora, openSUSE и Ubuntu .

Отбор участников

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

Отбор участников – вполне волюнтаристический, ибо, как сказано выше, был спровоцирован обстоятельствами. Тем не менее, он не совсем произвольный: мысль сравнить именно эти три дистрибутива была у меня давно. Общее между претендентами то, что все три

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

• все три декларируют свою любовь к конечному пользователю, хотя и каждый по своему;

• за каждым из этих дистрибутивов стоит тыловое прикрытие (или даже «крыша») в виде коммерческой фирмы.

Все три дистрибутива имеют близкий релиз-цикл (6-9 месяцев). И как раз недавно вышли их свежие стабильные версии. То есть в данном случае речь идёт о срезах современного их состояния.

По хорошему в число сравниваемых систем надо было бы включить ещё и Mandriva, как дистрибутив, подходящий по всем статьям. И к тому же в лице первозданного Mandrake бывший прародителем всей современной юзерофилии вообще. Однако нынче этот дистрибутив разделился на несколько линий с не вполне понятными взаимоотношениями. И не ясно, которого из них надо привлекать к ответственности по нашему делу. К тому же об одном из представителей этого семейства, дистрибутиве ROSA, часто и подробно пишет мой товарищ и коллега Сергей Голубев. Так что пробелы в данном сравнении читатель легко может восполнить.

Я не ставлю себе целью возвеличивание ни одного из рассматриваемых здесь дистрибутивов, не собираюсь убеждать читателей в том, что один из них – единственный и несравненный. И порядок их перечисления в титуле страниц – не попытка выстроить из них иерархию снизу вверх, сверху вниз, или даже в сторону. Оно отражает последовательность моего обращения к этим системам в отрезок с 2009 года и по настоящее время. Впрочем, его можно считать и алфавитным.

В дальнейшем порядок будет описания соответствующих особенностей дистрибутивов будет определяться скорее литературными соображениями и удобством собственно сравнения.

Критерии сравнения

С точки зрения применителя дистрибутивы могут сравниваться по технологическим особенностям  и в гуманитарном аспекте. Весь этот цикл написан ради последнего, и к нему мы обратимся пол занавес. А пока – о технологических критериях. Среди них главными мне представляются следующие:

• программа установки;

• состав репозиториев и их структура;

• поддержка различных рабочих сред;

• политика обновления дистрибутива и/или его частей;

• средства управления пакетами и репозиториями;

• штатные средства настройки.

Конечно, при этом местами мы вступаем в пограничную область сравнения дистрибутивов и используемых в них рабочий сред. Ибо один и тот же дистрибутив со средой KDE будет похож на любой другой KDE-ориентированный дистрибутив, нежели на самого себя с GNOME или Xfce. Однако это – тоже показательный момент при сравнении. Потому что все три участника нашего соревнования, с одной стороны, имеют свою коронку в виде рабочей среды, поддерживаемой «по первому разряду»: GNOME 3 для Fedora, KDE для openSUSE, Unity для Ubuntu. А с другой стороны, все «коронные» десктопы любого из них поддерживаются остальными участниками или непосредственно, или силами окружающего сообщества. Исключение тут, понятное дело, Unity – но и как мы увидим в конце концов, весьма показательно.

Объяснения и отмазки

Данное Сравнение основано на практическом применении всех его объектов на протяжении ряда лет, хотя местами и с перерывами: Ubuntu – начиная с 05.10 Breezy Badger‭, Fedora – c лета 2009 года и 11-го релиза, openSUSE – с февраля 2012 года и версии 12.1.

Все описываемые особенности дистрибутивов были актуализированы по текущим их версиям: (в порядке выхода «в свет») Ubuntu 13.10 Saucy Salamander (вместе с представителями её семейства того же поколения, стабильный релиз от 17.10.2013), openSUSE 13.1 (стабильный релиз от 19.11.2013), Fedora вместе с RFRemix 20-го релиза).

Так что всё сказанное далее основано исключительно на личном опыте практического применения сравниваемых дистрибутивов. Степень же моего знакомства ними разная. И потому не исключаю, что в своём сравнении я упустил какие-то важные особенности того или другого дистрибутива. Буду признателен за соответствующие замечания.

Сфера применения мной Linux'а довольно специфична, и потому может показаться, что я, с одной стороны, уделяю слишком много внимания некоторым деталям. А со стороны же другой, вследствие той же ограниченности личного опыта, очень может быть, что я таки забыл какие-то очень важные для применителя критерии сравнения дистрибутивов и их особенности: как говаривал Козьма Прутков, нельзя объять необъятное.

Читатели предыдущей страницы наверняка заметили, что из числа критериев сравнения исключены так называемая «стабильность» и так называемое «быстродействие». Это сделано сознательно, и вот почему.

Широко распространено мнение, что одни дистрибутивы более стабильны, нежели другие. Правда, в качестве как «одних», так и «других» называются те же самые имена, и выяснение этого вопроса часто переходит в виртуальные побоища. Я этот вопрос обсуждать отказываюсь категорически. Во-первых, единицы количественного измерения пресловутой «стабильности» никто ещё не придумал. Во-вторых, за исключением некоторых дистрибутивов, криво собранных на коленке, все современные Linux'ы из числа распространённых – и в первую очередь объекты нашего сравнения – субъективно стабильны, и стабильны одинаково. Конечно, в каждом из них время от времени бывают неудачные версии – но огрехи их достаточно быстро исправляются в рабочем порядке.

Сказанное не в меньшей степени относится и к быстродействию. Хотя теоретически здесь и могли бы иметь место количественные тесты на скорость выполнения тех или иных задач, но это относится к задачам действительно тяжёлым и русурсоёмким, например, счётным. Практически же все разговоры на эту тему сводятся к глазомерной оценке субъективного (или визуального) быстродействия – так называемой «отзычивости». Каковая, во-первых, количественному измерению не поддается, а во-вторых, давно снивелирована современным «железом».

Сказано же всё это к тому, что любые претензии типа «дистр А падает», «дистр Б глючит», «дистр В тормозит», а «дистр Г летает», отметаются с негодованием. Как, разумеется, и глубокие теоретические обобщения, что «Fedora/openSUSE/Ubuntu отстой, а Ubuntu/Fedora/openSUSE рулезз». С этим, пожалуйста, к врачу-ЛОРингологу...

Ну а мы тем временем приступим к сравнению по намеченным критериям и в указанном порядке.

Реверансы и референсы

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

• Ирине Киттелль, известной в сети как Алиса Деева – она вдохновляла меня на труды сочинительские;

• Владимиру Попову, Владимиру Родионову и Сергею Голубеву – немало затронутых здесь вопросов мы обсуждали в реале и виртуале;

• моим товарищам по форуму POSIX.ru, Юниксфоруму и Джуйке – поимённое их перечисление исчерпало бы мою дисковую квоту.

Искренняя благодарность – участникам проекта Russian Fedora, русскоязычной секции openSUSE Forums и создателям ресурсов по Ubuntu, имя которым – легион. И, разумеется, разработчикам соответствующих дистрибутивов.

Установка

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

Вступление

С одной стороны, система инсталлируется один раз. И большинство ошибок при установке, кроме разметки диска и создания файловых систем, легко корректируются в последующем. Так что, казалось бы, придавать слишком большое значение особенностям программы установки не следует.

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

Исходя из сказанного, попробуем сравнить инсталляторы наших участников. Но сначала – несколько слов о типах инсталляторов. Традиционно установка системы осуществлялась путём выбора некоторых предопределённых наборов пакетов, с опциональной их коррекцией – добавлением нужных компонентов и удалением ненужных. Издревле также это дополнялось режимом чистого попакетного выбора. Но в любом случае пользователь имел некоторую альтернативу для индивидуализации системы. Именно так первоначально обстояло дело в Red Hat и SUSE – предшественниках современной Fedora и openSUSE, соответственно.

Однако на рубеже тысячелетий возникли первые Системы Быстрого Развёртывания. Они основывались на переносе содержимого установочного носителя (как правило, LiveCD) на носитель целевой «один в один». После чего применитель сразу получал в своё распоряжение систему с набором приложений, необходимых для начала практической работы. Выбор рабочей среды и приложений или не предполагался вообще, или осуществлялся до установки – путём подбора соответствующего варианта «живого» образа. Системы Быстрого развёртывания активно развивались в начале нулевых годов – и апофигеем этого развития стала Ubuntu.

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

А вот дистрибутивы с попакетным выбором эволюционировали (не без влияния Ubuntu, к слову сказать) в противоположном направлении – большинство из них обзавелись наборами LiveCD, с которых выполнялось быстрое безальтернативное развёртывание системы. Так что в Fedora и openSUSE оба способа можно рассматривать как равноправные. Но о генетическом происхождении инсталляторов нужно помнить при их сравнении.

Ubuntu

Ubuntu, как только что было сказано, изначально ориентировалась на быстрое развёртывание до более или менее работоспособного состояния. Она не была первой СБР в истории, но среди первых оказалась самой удачной и успешной. Хотя нынче уже не выглядит столь уникальной, как ещё несколько лет назад.

Будучи исходно клоном текстового Debian Installer'а, установочная программа Ubuntu быстро обзавелась графическим интерфейсом с пресловутой «установкой в пять кликов» с так называемых desktop-образов, представляющих собой LiveDVD. При которой, тем не менее, оставалось достаточно возможностей для ручного вмешательства на самых ответственных стадиях – дисковой разметки и создания файловых систем. Правда, в графическом режиме возможна только разметка диска в стиле MSDOS, однако прибегнуть к более иному стилю (читай – GPT) можно при так называемой установке альтернативной (см. ниже).

Выбор доступных файловых систем богат, включая все нативные для Linux (ext2/3/4, XFS, JFS, btrfs, до недавнего времени и ReiserFS) и всякие прочие, вроде FAT'ов и NTFS. Размещать файловые системы можно не только на разделах, но и на мультидисковых устройствах (softRAID и LVM). Правда, опций монтирования их можно задать не много, но все наиболее важные имеются, нет только специфичных для SSD.

Установка пакетов в графическом режиме безальтернативна, и определяется их набором на desktop-носителе: ни прибавить к нему, ни убавить на стадии инсталляции нельзя. Однако индивидуальный выбор пакетов возможен в режиме эксперта при поминавшейся выше альтернативной установке в текстовом режиме, которая сохранилась, во-первых, для дистрибутива Xubuntu, во-вторых – при сетевой инсталляции с MinimalCD.

Правда, в обоих случаях выбор пакетов осуществляется через интерактивный интерфейс утилиты aptitude, что, во-первых, не очень удобно для тех, кто с этим интерфейсом не знаком, во-вторых, в последних релизах Ubuntu работает весьма криво.

Но есть и другой способ установки индивидуализированного набора пакетов – выполнение из Live-режима процедуры debootstrap, при которой устанавливается так называемая core system, которую в дальнейшем можно нарастить с помощью apt-get. Тот же результат достигается при альтернативной установке выбором режима Command Line Only.

openSUSE

В openSUSE за инсталляцию отвечает соответствующий модуль системы её глобального конфигурирования YaST. Предусмотрено два варианта установки:

1. с DVD или NET-диска – по своим возможностям они идентичны, различаясь только источником для получения пакетов;

2. с LiveCD, точнее уже практически всегда LiveDVD – их штатно два, с KDE и GNOME в качестве десктопа.

В обоих случаях установка по умолчанию происходит в графическом режиме, однако в первом возможно и переключение на режим текстовый (с интерфейсом на базе ncurces). В отличие от Ubuntu, графический и текстовый режимы инсталлятора openSUSE по своему функционалу идентичны. А вот инсталляция с Live-носителя и с носителей чисто установочных, на первый взгляд, существенно различается.

Правда, в наиболее ответственной части установки – разметке диска и создания файловых систем, – возможности инсталлятора, запущенного с LiveCD и же с DVD/CD, в этом отношении одинаковы и богаты до чрезвычайности. В обоих случаях целевой носитель может быть размечен в любом из существующих стилей – практическое значение, как уже говорилось имеют MSDOS и GPT. Созданные разделы могут как непосредственно нести на себе файловые системы, так и объединяться в мультидисковые устройства – softRAID и LVM.

Из файловых систем, правда, поддерживаются не все нативные – нет JFS (не очень-то, впрочем, и хотелось), а в релизе 13.1 пропала ещё и ReiserFS. Что в какой-то мере компенсируется не просто поддержкой btrfs, а возможностью манипуляции её субтомами: как известно, btrfs – это ведь не просто ещё одна файловая система, а нечто с претензией на систему управления размещением данных вообще, подобно ZFS. Ещё одна особенность инсталлятора openSUSE – возможность монтирования файловой системы tmpfs в произвольные точки, разумеется, те, для которых это осмысленно. И, наконец, для всех создаваемых в ходе инсталляции файловых систем можно указать любые из возможных опций монтирования, в том числе и специфичные для SSD-накопителей.

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

С точки зрения выбора пакетов между режимами установки DVD/NET-диска и с LiveCD, казалось бы, существует очевидная разница. В первом случае можно выбрать один из предопределённых наборов – с рабочей средой KDE или GNOME, во-первых, с чистыми Иксами или «голой» консолью, во-вторых. А на следующем этапе обратиться к индивидуальному выбору пакетов для добавления нужных компонентов и удаления излишних, разумеется, с автоматическим разрешением зависимостей.

При установке openSUSE с Live-носителя по умолчанию создаётся точная его копия на диске. Однако, в отличие от Ubuntu, при этом происходит не попакетное развёртывание системы, а копирование её образа из «живой» корневой файловой системы, созданной в оперативной памяти. Что открывает уникальную возможность индивидуализации openSUSE – по крайней мере, ни в одном другом дистрибутиве я такой не видел. То есть в Live-режиме можно с помощью менеджера пакетов удалить все ненужные компоненты и доустановить нужные. Более того, можно даже выполнить необходимые пользовательские настройки – и все внесённые в Live-среду изменения будут сохранены на целевом носителе в инсталлированной системе.

В Live-режиме openSUSE есть и ещё одна возможность индивидуализации системы на стадии её установки. Она похожа на механизм debootstrap в Ubuntu и основывается на понятии шаблонов (patterns), о которых подробнее будет сказано в разделе о пакетном менеджменте. Суть её в монтировании в Live-среду того раздела целевого носителя, который будет в дальнейшем корнем инсталлированной системы, установке на него минимального набора пакетов – так называемого шаблона base (и, возможно, также шаблона enhanced_base), выполнения операции смены корня командой chroot и доустановке всех необходимых компонентов с помощью пакетного менеджера zypper уже в индивидуальном порядке.

Fedora

Установка Fedora осуществляется, как и в случае с openSUSE, либо со специальных установочных носителей (DVD или netinst), либо с одного из LiveDVD, различающихся используемыми рабочими средами. Как и в openSUSE, инсталляционная программа одна и та же для всех типов носителей. И различия в ходе её работы те же самые: с DVD/netinst можно установить как предопределённые наборы пакетов, так и заниматься их индивидуальным выбором – правда, только в отношении пополнения исходного набора (например, рабочий стол GNOME или KDE), корректировать его нельзя.

При инсталляции с LiveCD создаётся точная копия «живой» системы. В отличие от openSUSE, корректировать систему в Live-режиме с сохранением результатов после установки нельзя. Нет и простого механизма установки минимальной системы, подобного debootstrap в Ubuntu или шаблону base в openSUSE. По крайней мере, на поверхности он не валяется, хотя теоретически представить себе такую минимальную установку можно.

Отступление. Некогда в Red Hat применялся текстовый инсталлятор, считавшийся образцом дружелюбия к пользователю. На рубеже тысячелетий его сменил графический установщик Anaconda, верой и правдой прослуживший более десяти лет и заимствованный в ряде других дистрибутивов . Однако к началу второго десятилетия нынешнего века он стал казаться архаичным на фоне Ubuntu и недостаточно функциональным по сравнению с YaST'ом из openSUSE.  Поэтому, начиная с релиза 17, начались попытки его модернизации. Первые из них нельзя признать удачными. Но, как показывает бета-версия, к 20-му релизу (о котором здесь и идёт речь) «болезни роста» остались позади.

Особо надо сказать о разметке диска. В современном инсталляторе она упрощена до предела и сводится к

• выбору целевого носителя – если таковым выступает чистый диск, на нём будет автоматически создана разметка в стиле MSDOS; от принятой в прошлых версиях GPT-разметки нынче отказались;

• назначению его загрузочным устройством или, напротив, отказу от этой возможности; последнее зело полезно, если какой-либо настроенный загрузчик уже имеется;

• выбору так называемого типа устройства, каковых предусмотрено три – LVM (выбор по умолчанию), btrfs (выбор экспериментатора) и обычный раздел (выбор обычного применителя).

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

Итоги

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

Нет, графический инсталлятор Ubuntu хуже не стал. Но нынешний установщик Fedora по простоте существенно обогнал его, хотя и несколько уступил в функционале в отношении разметки диска. А вот инсталляционный модуль YaST'а из openSUSE, будучи в варианте DVD/NET не существенно сложнее Ubuntu'вского desktop, далеко превосходит его богатством возможностей. Более того, большинство этих возможностей (кроме выбора пакетов, конечно) доступны при установке в Live-режиме, которая уж точно ничуть не сложнее, чем desktop-инсталляция Ubuntu. Казалось бы, сохранение в последней реликтового текстового установщика могло бы уравнять шансы. Но нет: по функционалу alternate всё равно не дотягивал до YaST'а даже в свои лучшие годы, а нынче он к тому же и деградировал – индивидуальный выбор пакетов в нём стал почти невозможным. Конечно, в этом вина «поломанной» aptitude, но применителю от этого легче не становится.

Иными словами, в координатах простота/функциональность на противоположных полюсах можно поместить современный инсталлятор Fedora (наиболее простой и самый бедный) и модуль YaST'а из openSUSE (относительно сложный – но исключительно в том случае, если есть необходимость использовать его бесподобный функционал на всё катушку). Графический же установщик Ubuntu займёт близэкваториальную зону между ними.

В заключение раздела ещё раз подчеркну следующие моменты.

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

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

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

Репозитории

Отличительная черта настоящего дистрибутива нынче – собственный репозиторий пакетов: только его наличие даёт право на это гордое имя, в любом ином случае ты в лучшем случае ремикс дрожащая, а то и вообще жалкий респин. Шутка, конечно, ни в том, ни в другом нет ничего худого. Но дистрибутив, претендующий на всенародную любовь, или, хотя бы, широкую популярность (а все три наши героя на это претендуют), репозиторий быть обязан. Причём тем более всеобъемлющий, чем шире его претензии на популярность. И тем более понятный в использовании, чем больше претензий на любовь.

Вступление

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

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

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

Другая граница, пролегающая также внутри каждого репозитория – грань между полностью свободными в понимании GNU и FSF пакетами, и программами, на распространение которых могут накладываться те или иные ограничения. В суть последних вникать не будем – достаточно сказать, что они могут быть чисто юридическими, например, патентными для некоторых стран, или техническими – распространением только в бинарном виде, или каким-либо иными.

Казалось бы, в официальные репозитории дистрибутива свободной операционной системы могут входить только полностью свободные пакеты, а все пакеты «ограниченной свободы» должны поддерживаться сообществом. Однако на деле это не совсем так. И потому возникает сакраментальный вопрос – где кончается официоз, и где начинается сообщество? На который резонные одесситы давно уже дали исчерпывающий ответ: сообщество начинается именно там, где заканчивается официоз. Следуя их мудрым указаниям, майнтайнеры наших дистрибутивов определили для себя границу между официозом и сообществом каждый по своему.

Fedora

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

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

На некоторых зеркалах репозиториев Fedora (например, зеркале Yandex'а) репозитории os и rpmfusion можно видеть в едином дереве каталогов. Но это сделано исключительно для удобства нас с вами – то есть граждан одной из (многочисленных) стран, законы которых не признают ограничений свободы распространения программ по патентному, например, признаку. Официально же RPM Fusion – отдельный проект, и разработчики Fedora делают вид, что его репозиторий не имеет к ним ни малейшего отношения.

Кстати, на зеркале Yandex'а можно увидеть и ещё один репозиторий, имеющий к официальному os ещё меньше отношения, чем rpmfusion – russianfedora. Как нетрудно догадаться, он ведётся нашими соотечественниками и включает в себя в основном пакеты, учитывающие российскую специфику. К нему я ещё вернусь перед подведении итогов.

openSUSE

Репозитории openSUSE также разделяются на основную, официально поддерживаемую майнтайнерами, ветвь (distribution) и ветвь, развиваемую сообществом (repositories). Однако устройство их существенно отлично от аналогов для дистрибутива Fedora. Так, в состав официоза входят не только полностью свободные пакеты, но и некоторые пакеты ограниченного распространения. Правда, здесь эти части без всяких ссылок на свободу и несвободу, называются проще: oss (то есть OpenSuSe, что подчёркивает её неотчуждаемую принадлежность дистрибутиву) и non-oss (очевидно, что это пакеты, без которых дистрибутив может и перебиться).

А вот единого репозитория пакетов от сообщества, подобного rpmfusion в Fedora, в openSUSE нет и в помине. Вместо неё в ветви repositories есть множество отдельных тематических репозиториев, содержащих не только пакеты, дополняющие официоз (и даже не столько их), но в первую очередь сборки более свежих, относительно текущего релиза, крупных компонентов, таких, как ядро, Иксы, KDE, GNOME, а также шрифты и всё, что к ним относится. Эта часть ветви совершенно официально называется полуофициозом (Semi official repositories). Хотя структурно она никак не отделена от репозиториев для дополнительных пакетов, в том числе специализированных, которые тоже имеются в изобилии.

Тем не менее, большая часть дополнительных пакетов сконцентрирована в «домашних» репозиториях (repositories/home:/name). Это своего рода домашние каталоги пользователей – независимых разработчиков отдельных пакетов и их групп.

И тематические, и «домашние» репозитории охватываются понятием репозиториев OBS (Open Build Service). Как явствует из названия, это система сборки пакетов (причём не только для openSUSE, но и для некоторых более иных дистрибутивов), присоединиться к которой может любой «прохожий с улицы». Не вдаваясь в детали (описание которых потребовало бы половины нынешней книги), суть её в следующем: каждый желающий принять участи в развитии пакетной базы openSUSE регистрируется вв системе, получает там учётную запись и домашний каталог, как на локальной машине (например, у автора этих строк – repositories/home:/alv_fedorchuk/) и может резвиться там со сборкой нужных и интересных для него пакетов в полное своё удовольствие. Для чего ему, кроме домашнего каталога, представляется полный сборочный инструментарий (компилятор, необходимые библиотеки и утилиты), запускающийся удалённо в виртуальной машине на сервере OBS.

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

Репозитории OBS, как уже сказано, формально к официозу вроде не относятся, хотя, в силу специфики их сборки, тесно связаны с последним. Однако в openSUSE есть ещё менее официальные репозитории – так называемые внешние (external), которые включают в себя всякого рода мультимедию с не всегда определённым (в некоторых отдельно взятых странах) юридическим статусом, и фирменные драйвера, отличающиеся спецификой распространения.

Ubuntu

Наиболее широки рамки официоза в репозитории Ubuntu. Для начала в его составе можно выделить официоз первого сорта и, так сказать, второго, то есть поддерживаемые непосредственно фирмой Cannonical и неким сообществом. Это группы main и universe, соответственно: обе включают исключительно свободные программы. Первая дополняется группой restricted, вторая – группой multiverse: и в той, и в другой собраны программы с различными ограничениями. А различия между ними те же: первая официально поддерживается Canonical'ом, вторая... ну как бы не совсем официально.

Здесь очень важно подчеркнуть, что в Ubuntu все четыре группы главного репозитория с точки зрения применителя практически равноправны и могут быть задействованы при инсталляции – для этого достаточно отметить соответствующие опции для установки пакетов из restricted, universe и multiverse.

Однако этим специфика Ubuntu не исчерпывается: кроме основного репозитория, для неё существуют ещё и так называемые репозитории PPA (Personal Package Archive) и инструмент для работы с ними – Launchpad. Это нечто вроде аналогов OBS и её тематических и «домашних» репозиториев. То есть наоборот – приоритет здесь за Canonical (создание Launchpad – 2004 год, OBS, первоначально именовавшаяся OpenSUSE Build Service – 2006 год). Поддерживаются PPA-репозитории, как явствует из названия, сторонними разработчиками, то есть уже сообществом в полном смысле слова.

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

Отступление о стабильности

Считается, что пакеты из дополнительных репозиториев менее стабильны, нежели из репозиториев официальных, казалось бы, имеет некоторые основания: каждый из применителей Ubuntu, openSUSE, Fedora (как и любых других дистрибутивов) время от времени сталкивается со «сторонними» пакетами, которые не желают или устанавливаться, или запускаться после установки, или после запуска работают не так, как хотелось бы, или не работают вообще.

В кругах форумных активистов бытует мнение, что таких «кривых» пакетов больше всего в PPA-репозиториях Ubuntu, хотя многие готовы отдать пальму первенства в этом отношении OBS-пакетам openSUSE или пакетам из rpmfusion Fedora. Правда, в каждом случае уровень доказательности сводится к «у меня не встал» или «а у меня работает».

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

Хотя я готов согласиться с тем, что вероятность нарваться на «кривой» пакет из PPA-репозитория несколько выше, чем из OBS, и ощутимо выше, чем из rpmfusion. Но объяснение этому очень простое: в PPA пакетов немного больше, чем в OBS, и существенно больше, чем в rpmfusion.

Заключение о структуре

Как можно видеть из приведённого описания, главное различие в структуре репозиториев сравниваемых дистрибутивов – в границах их официально поддерживаемой части: наиболее широки они у Ubuntu, наиболее узки – у Fedora, openSUSE же занимает промежуточное положение, хотя и более близкое к последней. С точки зрения их применителей это обуславливает различие в доступе к пакетам, лежащим за пределами круга базовых.

Так, применители Ubuntu могут установить все необходимые компоненты, не совершая никаких «лишних» телодвижений, на стадии первичной инсталляции системы. В openSUSE, и в Fedora в штатном инсталляторе по умолчанию задействуются только пакеты из официоза. Пакеты ограниченного распространения придётся устанавливать уже позднее, что потребует поиска и подключения дополнительных репозиториев.

В Fedora, где вообще все «сторонние» пакеты собраны в репозитории rpmfusion, эта процедура несколько проще. К тому же при установке Fedora с образов проекта Russian Fedora библиотеки рендеринга шрифтов, использующие патентованные алгоритмы, мультимедийные кодеки, проприетарные драйвера и тому подобная музыка устанавливается «искаропки».

В openSUSE, с её разветвлённой структурой репозиториев OBS и внешних external-репозиториев, дело обстоит чуть сложнее. Что, однако нивелируется высокоуровневыми средствами пакетного менеджмента, о чём будет рассказано своевременно. Причём средства эти можно задействовать уже при установке openSUSE в Live-режиме, с их помощью подключить любые дополнительные репозитории и поиметь с них (в том числе и) необходимую мультимедию, о чём говорилось ранее.

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

Чисто теоретически самой логичной представляется структура репозиториев Fedora – за счёт чёткого отделения официоза от сообщака и агнцев свободы от козлищ проприетаризма. В Ubuntu обе границы проведены вполне волюнтаристически – и потому не всегда понятно, в какой из четырёх групп её главного репозитория следует искать нужный пакет, и не лежит ли он вообще в PPA-сообщаке. В openSUSE собственно официозная часть выделена очень чётко – однако за её пределами попадаешь в сложное переплетение полуофициоза, сообщака и экстернала. Хотя, раз в нём разобравшись, дальше в этих материях ориентируешься легко и непринуждённо. Впрочем, всё сказанное по поводу лёгкости и сложности – не более чем моё очень субъективное мнение.

Наполнение

Как я только что сказал, структура репозиториев применителя объектов нашего сравнения обычно не очень волнует – он отгорожен от неё системами пакетного менеджмента. А вот вопрос полноты репозиториев – волнует, и очень сильно. Настолько, что является предметом обсуждений и дискуссий, доходящих до Священных войн.

Хотя на самом деле и эта проблема во многом надумана. Если мы обратимся к официозу всех трёх сравниваемых дистрибутивов, то увидим практически полную их идентичность. Что и неудивительно – ведь входящие в них пакеты должны обеспечивать функционирование среднестатистической Linux-системы, Иксов, поддерживаемых рабочих сред и основных приложений. То есть компонентов, которые одни и те же во всём мире FOSS – что в Африке, что в Европе, что в Америке. Оговорок тут две: первая связана с более широким понимание официоза в Ubuntu, о чём уже была речь, вторая – с поддерживаемыми рабочими средами, про что будет сказано в следующем разделе.

В отношении полноты репозиториев дополнительных наши герои различаются – и весьма сильно. Относительная «камерность» разработки Fedora и её требования к «чистоте» софта приводят к тому, что rpmfusion по своей количественной полноте – бесспорный претендент на третью ступеньку пьедестала почёта (при трёх участниках).

С другой стороны, экосистема, сложившаяся вокруг Ubuntu, обеспечивает, во-первых, охват наиболее широкого круга дополнительных пакетов, во-вторых, самое активное его расширение. Так что распространённое мнение, что в PPA, как в Греции, всё есть, имеет под собой все основания. Как и то, что в наши дни большинство новых программ и их свежих версий появляется именно в сборках для Ubuntu. Более того, её Launcher может использоваться как своего рода путеводитель по новым пользовательским программам и их свежим версиям.

Ну а openSUSE в этом отношении занимает промежуточное положение. Хотя инфрастуруктура OBS позволила бы ей наступать на пятки лидеру. Однако её потенциал до сих пор не реализован в полной мере (но это уже проблема гуманитарная).

Завершу раздел о репозиториях небольшим патриотическим рассуждением. Если о богатстве или бедности абстрактных репозиториев можно спорить до посинения, то в отношении первенства во всём, что касается обеспечения работы в условиях нашего Отечества, торг неуместен: оно принадлежит репозиторию russianfedora (среди объектов настоящего сравнения, разумеется). И дело даже не в том, что он даёт возможность устанавливать мультимедийные кодеки или использовать патентованные методы рендеринга шрифтов «из коробки», хотя и это немаловажно. Главное, в рамках проекта Russian Fedora все баги, ущемляющие национальную гордость великороссов, выявляются мгновенно – и столь же мгновенно ликвидируются.

Конечно, такая же работа проводится и нашими соотечественниками – участниками проектов Ubuntu и openSUSE. Но она не координирована в рамках единых проектов, не сопровождается созданием специальных репозиториев, и результаты её далеко не всегда попадают в апстрим.

Итог

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

Так, с точки зрения простоты и логичности организации первое место безусловно заслуживает Fedora: её официозная часть структурирована безупречно (потому что состав её таков, что структурировать просто нечего), часть же сообщническая – разделена на достаточное количество структурных единиц – меньше некуда, больше не за чем.

А вот место второе я отдал бы openSUSE: официоз её, как и у победителя, в более дробной структуре не нуждается (если считать пару дюжин пакетов из non-oss просто довеском). А ветвь repositories, хотя и имеет запутанную структуру, но – имеет; и при желании в её логике на так сложно разобраться.

Ubuntu оказывается на последнем месте заслуженно: во-первых, за волюнтаризм, проявленный при разделении базовых пакетов, во-вторых – за полное отсутствие структуры репозиториев PPA, в которых без поллитры Launcher'а не разобраться.

С точки зрения доступности репозиториев картина прямо противоположная: первое место присуждается Ubuntu за возможность доступа к дополнительным пакетам при инсталляции системы. На втором месте – openSUSE, в которой при установке определённым образом дополнительные репозитории прикрутить можно. На третьем месте, по понятным причинам, Fedora (тот самый случай, когда принципы вступают в противоречие с практикой).

Впрочем, с учётом запасного игрока из клубной команды – репозитория russianfedora, картина опять повернётся другим боком, и Fedora вполне может потягаться с Ubuntu за первую ступеньку пьедестала почёта. А поскольку мы живём в этой стране, единственное основание его не учитывать – низкопоклонство перед Западом и укоренившееся недоверие ко всему отечественному. Так что при таком раскладе openSUSE остаются глубоко... на третьей ступени.

По части полноты репозиториев необходимости в спорах нет: первое место принадлежит Ubuntu, второе – openSUSE, третье, и с большим отрывом – Fedora (даже с учётом запасного игрока). Впрочем, если ограничиться только базовой частью системы, можно считать, что победила дружба.

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

Десктопы

Первое, что видит применитель после установки дистрибутива и первого запуска системы – это рабочая среда (или, по простому, десктоп). Та самая, которую он выбрал при инсталляции или ещё раньше, скачивая Live-носитель для оной. Да и в дальнейшем он будет работать не столько в Linux'е или каком-либо его дистрибутиве, а в KDE, GNOME, Unity и так далее. И потому очень важный критерий нашего сравнения – поддержка десктопов.

Вступление

Сравнение поддержки десктопов в дистрибутивах вообще сводится к ответу на два вопроса: какие рабочие среды они поддерживают – во-первых, и как именно они это делают – во-вторых.

Применительно к героям нашего сравнения на первый вопрос двумя словами ответить очень легко: в том или ином виде и Ubuntu, и openSUSE, и Fedora поддерживают все существующие в природе свободные рабочие среды. В репозиториях каждого, официозных или сообщнических, мы найдём и ветеранов-мастодонтов (не только по возрасту, но и мощи) KDE и GNOME, и их лёгкого ровесника Xfce, ныне животом не менее плечистого, и молодого (возможно, навсегда) LXDE, и совсем уж зелёную поросль Mate с Cinnamon'ом.

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

Открою страшную тайну: каждый из участников нашего сравнения поддерживает не только интегрированные рабочие среды, но и практически все хоть как-то развиваемые менеджеры окон. В официальных или дополнительных их репозиториях можно увидеть и IceWM (устанавливается в openSUSE по умолчанию при выборе конфигурации с минимальными Иксами), и Enlightenment (используется в одном из клонов Ubuntu – Bodhi Linux, устанавливается опционально в инсталляторе Fedora), и представителей семейства *box'ов, и обретшего не так давно вторую жизнь WindowMaker, и многие, многие другие. Но их я в настоящем сравнении рассматривать не буду.

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

openSUSE

Проще всего ответить на второй вопрос относительно openSUSE: в этом дистрибутиве совсем официально поддерживаются только KDE и GNOME. Под совсем официальной поддержкой я подразумеваю наличие соответствующих Live-носителей, во-первых, и возможность выбора одного из этих десктопов на первой ступени установки с DVD/NET-носителя – во вторых.

Однако в официозе openSUSE присутствуют также и такие рабочие среды, как Xfce и LXDE. И они доступны для выбора на первой ступени установки с DVD/NET-носителя. Более того, с недавних пор среди официальных Live-носителей openSUSE появился образ под названием Rescue – ни что иное, как «живой» диск со средой Xfce. Правда, по умолчанию он не предназначен для установки системы, но путём несложных манипуляций сделать это можно.

А вот таких относительно новых десктопов, как Razor-Qt, Mate и Cinnamon, мы в официозе openSUSE не найдём. Однако и они доступны для установки – достаточно обратиться к тематическим или домашним репозиториям OBS.

При установке openSUSE на стадии выбора десктопа по умолчанию отмечена KDE. И, следовательно, её можно считать самой поддерживаемой рабочей средой в openSUSE – ибо уж очень оказались тесно связаны их судьбы. Что находит практическое подтверждение: сборки KDE для openSUSE много лет пользуются заслуженной славной среди любителей этого десктопа. По многочисленным отзывам и отрывочным собственным впечатлениям, столь же хорошо поддерживается и GNOME – насколько это понятие к нему применимо... но тут я боюсь вступить на путь вкусовщины.

А вот Xfce поддерживается... не то что плохо, а просто недостаточно. Что и не удивительно: по агентурным данным, поддержкой этой среды в openSUSE занимается всего один человек.

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

И в заключение нужно сказать, что openSUSE – чуть ли не единственный из широко популярных дистрибутивов, в котором сохраняется поддержка KDE 3.5.11, до сих пор пользующейся популярностью, правда, во всё более узких кругах.

Fedora

В Fedora до недавнего времени дело обстояло ещё проще: в ней официально поддерживались только GNOME и KDE, отчасти Xfce. Причём Fedora была ещё более GNOME-ориентированной, нежели openSUSE – ориентированной на KDE: остальные десктопы поддерживались или похуже (KDE), или кое-как (Xfce). Ныне, однако, ситуация выравнялась: в официальном репозитории дистрибутива представлены все ныне развиваемые десктопы. А среди официальных Live-носителей имеются сборки с GNOME, KDE, Xfce, Mate. Есть они и в RFRemix. В сборках коего, кстати, при установке с DVD/NET-носителей имеется возможность выбора GNOME и KDE в минимальной комплектации.

Что же до качества поддержки – есть основание предполагать, что для GNOME оно осталось неизменно превосходным (с оговоркой на счёт предмета поддержки), для KDE – по слухам, достигло того же уровня, что и для «головного» десктопа. С Xfce всё по прежнему – это похоже на побочный продукт жизнедеятельности проекта. Относительно состояния дел с LXDE, Mate ничего сказать не могу. А вот что касается Cinnamon'а, то поддержкой это можно назвать чисто условно: не смотря на официальный статус, система с этим десктопом в русскоязычном окружении (и, подозреваю, в других не англоязычных) к использованию не приспособлена (надеюсь, что временно – пока до него не дотянутся длинные руки участников Russian Fedora).

Ubuntu

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

Однако Ubuntu – это не только одноимённый дистрибутив, но и целое их семейство, построенное на одной базе (то есть общих репозиториях main и restricted), но с различными компонентами из universe и multiverse, в первую очередь как раз с разными десктопами. И среди «законных» его отпрысков – Kubuntu, Xubuntu, Lubuntu и Ubuntu GNOME с рабочими средами KDE, Xfce, LXDE и GNOME 3, соответственно. И поскольку эти дистрибутивы развиваются сообществами любителей и энтузиастов перечисленных десктопов, каждый из них поддерживается «с искусством и любовью» – по крайней мере, про первые два могу утверждать на основе собственного опыта.

На этом список официально признанных десктопов заканчивается. Однако с течением времени вокруг Ubuntu образовалось изрядное количество «бастардов», самый известный из которых носит имя Mint. Он основан на тех же пакетах из базовых репозиториев родительской системы, надстраиваемых собственными сборками рабочих сред и их приложений. И исконными его десктопами являются Mate и Cinnamon. К поддержке которых слова Эрика Реймонда про искусство и любовь применимы не меньше – опять же про Cinnamon подтверждаю собственными впечатлениями.

К слову, заодно в Mint поддерживаются собственные сборки с KDE и Xfce. А его сборки Mate и Cinnamon'а можно безболезненно перетащить в Ubuntu – и это сделано посредством соответствующих PPA-репозиториев.

Итоги

Подведём итог. Для Fedora и openSUSE характерна блестящая поддержка «титульного» десктопа и произвольная, часто по остаточному принципу, всех остальных. Что я ни в коем случае не отнёс бы к недостаткам: лучше один хорошо заточенный десктоп, чем много недоделанных. Что мы, собственно, и видим в коммерческих линиях RHEL и SLE.

А в дистрибутивах семейства Ubuntu ситуация парадоксальная. Создаётся впечатление, что «побочные» десктопы в них поддерживаются лучше, чем «титульный». Вероятно, потому, что каждый из «бастардов» является «титульным» для своей системы. И некоторым образом «конкурирует» с одноимёнными рабочими средами, являющимися «титульными» для других дистрибутивов. А при этом может черпать улучшения и исправления апстрима соответствующего десктопа. Unity же в этом отношении варится в собственном соку – ну и тяжёлое наследие лежащего в её основе GNOME (причём с отставанием на одну, а то и две версии) тоже нельзя скидывать со счёта.

Поскольку выбор рабочего окружения – дело настолько личное, что его можно считать интимным, от выводов из сравнения наших дистрибутивов я воздержусь: каждый сможет сделать их для себя сам. Однако есть один аспект, в котором openSUSE безусловно превосходит своих сестёр-конкуренток. Это – обновление десктопов, что является составной частью сравнения по следующему критерию.

Политика обновления

Со времён незапамятных повелось, что раз установленная UNIX-система работала до полной физической амортизации целевой машины. Однако потом пришёл Linux с его бурей и натиском, и возникла настоятельная потребность в постоянном обновлении системы. Потому что чуть ли не каждый день появлялась то новая опция в ядре, но поддержка очередного видеочипа новой видеокарты, то новая фича в офисном пакете. И всё это новое действительно или расширяло функционал дистрибутивов, или повышало их usability. Потом буря и натиск закончились, а потребность обновляться осталась. Ибо вошла в привычку. И потому политика обновления дистрибутивов – наипервейшее дело при их сравнении.

Релиз-циклы

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

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

Релиз-цикл всех трёх наших героев колеблется вокруг 6 месяцев. Для Ubuntu он выдерживается очень строго: новая версия выходит дважды в год, в октябре и апреле. Единственная в истории этого дистрибутива задержка была связана с разработкой первого «долгоиграющего» релиза 6.06 LTS dapper и составила почти два месяца.

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

В openSUSE трепетного отношения к релиз-циклу вообще не наблюдается: последние годы он колебался от четырёх до девяти месяцев.

Ни строгое следование графику, ни, напротив, его нарушение сами по себе не являются ни плюсом, ни минусом. Первое даёт ощущение предсказуемости, второй же вселяет надежду на полное искоренение, как говаривал первый и последний президент Союза, багов. Стремление уложиться в прокрустово ложе релиз-цикла приводит либо к формальности выхода релиза, чисто «для галочки», либо к серьёзным ошибкам, либо, как мы недавно видели на примере Saucy Salamander, к тому и другому. С другой стороны, искоренение всех багов даже в масштабе отдельно взятого дистрибутива не более реально, чем воплощение в жизнь того самого горбачёвского указа. Так что всё сказанное об особенностях релиз-циклов надо просто помнить – и не более того.

Сравнивать политику наших дистрибутивов при смене релиза также особо не приходится. Давно прошли те времена, когда разработчики настоятельно советовали сбэкапить все данные и пользовательские настройки, после чего переустанавливать систему с нуля. Разумеется, в некоторых случаях этот совет имеет силу и поныне, но его настоятельность существенно снизилась. Потому что для почти всех современных развитых дистрибутивов отработаны схемы безболезненного обновления, дающие, при должной аккуратности, неизменно превосходный результат. По крайней мере, ко всем объектам нашего сравнения это относится в полной мере – проверено на своей шкуре неоднократно. Так что на сакраментальный гамлетовский вопрос «обновлять или переустанавливать» каждый отвечает в соответствие с условиями момента и собственных предпочтений. Я, например, время от времени люблю полностью «отречься от старого мира». А с другой стороны, нередко просто отказываюсь от обновления до новой версии ради самого факта: как было сказано в начале этого раздела, потребность в обновлении нынче часто дань привычки, а не необходимость.

В «межрелизье»

Гораздо интересней сравнить, как протекает жизнь наших героев в промежутках между релизами. Ведь в мире FOSS развитие каждого крупного внедистрибутивного или вообще кросс-платформенного проекта происходит по собственному графику. И появление принципиально новых (и, главное, востребованных) опций ядра, существенное улучшение поддержки видеокарт X-сервером или кардинальное усовершенствование вовсе не обязано совпадать с релиз-циклами даже самых популярных дистрибутивов.

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

В «межрелизье». Fedora

Начнём с Fedora, так как с ней проще всего. Ибо она предлагает всего два варианта: оставаться на стабильном релизе в течении всего его жизненного цикла, довольствуясь обновлениями, которые предложат майнтайнеры (а они предложат почти исключительно обновления безопасности), или переключаться на репозиторий релиза разрабатываемого, так называемый Rawhide.

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

В «межрелизье». Ubuntu

Больше вариантов выбора у применителей Ubuntu. Разумеется, они могут спокойно оставаться на стабильном релизе с его мелкими регулярными обновлениями (что, собственно, обычно и имеет смысл). Могут они, по примеру применителей «сыромятной» Fedora, и записаться в джигиты, установив одну из так называемых daily-сборок разрабатываемого релиза – они существуют для всех официальных представителей семейства.

Далее, при необходимости каких-либо важных компонентов системы можно обратиться и к PPA-репозиториям. Например, существует специальный репозиторий с пакетами ядра Linux версий, более старших, чем входят в текущий релиз дистрибутива. А если как следует покопаться в Launchpad'е, то можно найти свежие версии и различных десктопов (например, KDE, более позднюю, чем в текущей Kubuntu), и офисных пакетов (как LibreOffice, так и Apache OpenOffice), и многое другое. Правда, стабильность таких сборок не всегда гарантирована – но это касается любых дополнительных репозиториев всех без исключения дистрибутивов.

В «межрелизье». openSUSE

Однако больше всего возможностей для маневра в деле обновления системы – у применителей openSUSE. Во-первых и во-вторых, как и остальных, в их распоряжении стабильный релиз с его косметическими апдейтами и чисто тестовый Factory – репозиторий релиза разрабатываемого, со всеми «джигитскими» особенностями аналогов. В-третьих, имеется репозиторий Tumbleweed, регулярно обновляемый по модели rolling release и содержащий сборки всех пакетов дистрибутива в версиях, актуальных на данный момент времени. В отличие от Factory, он предназначен не только для опробования, но и для практической работы, и потому проходит тестирование именно как системная целостность. Хотя, конечно, по части стабильности может уступать текущему релизу.

В-четвёртых и, на мой взгляд главных, пора вспомнить о полуофициальных репозиториях. Как уже говорилось, в них содержатся сборки последних версий ключевых компонентов системы – ядра, KDE, GNOME и некоторых других. В отличие от Tumbleweed, их можно подключать независимо друг от друга, используя, таким образом, модель частичного роллинга только для тех пакетов, которые наиболее важны для данного применителя. Причём частичный роллинг может быть не перманентным, а задействованным на период активного развития интересующих подсистем. Например, во время кардинального совершенствования KDE, продолжавшегося с версии 4.6.X по 4.9.X, я подключал соответствующий полуофициальный репозиторий. А когда мне было интересно отслеживать изменения поддержки в ядре файловых систем (btrfs, f2fs), я задействовал репозиторий Kernel.

Наконец, в-пятых, самые свежие версии некоторых компонентов подчас можно отыскать в «домашней» части репозиториев OBS, подобно тому, как применители Ubuntu обращаются к PPA. Правда, в openSUSE, из-за наличия других моделей обновления, этот способ требует аккуратности: пакеты из home-репозиториев собираются под конкретные стабильные релизы, а также обычно под Tumbleweed и Factory. А вот с полуофициальными репозиториями они могут быть не согласованы по версиям.

Итог

Сказанного, думаю, достаточно, чтобы читатель составил себе представление о сравнительных возможностях обновления в Fedora, Ubuntu, openSUSE. А также – кому из них присудить переходящее красное знамя: ведь как раз на это я толсто намекал, отдавая предпочтение устройству репозиториев openSUSE. Именно их структуре этот дистрибутив обязан своей гибкой и контролируемой моделью частичного роллинга.

Таким образом, за безупречное следование политической линии обновлений, определяемых применителем, дистрибутив openSUSE награждается золотой медалью. А вот серебро и бронзу поделим поровну: Ubuntu за то, что допускает произвольное обновление из PPA-репозиториев, Fedora – за то, что не даёт возможности поломать систему, обновляя её в «межрелизье».

Пакетный менеджмент

Разговоры о репозиториях и политиках обновления повисают в воздухе без сравнения инструментария, обеспечивающего доступ к первым и реализацию вторых. Сравнением их мы сейчас и займёмся.

Вступление

Инструменты для работы с пакетами можно разделить на четыре группы:

• установщики пакетов;

• менеджеры пакетов;

• их графические фронт-энды;

• центры приложений.

С первой группой всё ясно – это низкоуровневые утилиты для работы с единичными пакетами, каковыми в нашем случае выступают самые обычные rpm для Fedora и openSUSE, и dpkg для Ubuntu. Сравнивать тут особенно нечего, по своим функциям они практически идентичны. Да и непосредственно применяются нынче редко – все обыденные манипуляции с пакетами обычно проще выполнять посредством менеджеров пакетов и их графических оболочек, которые и будут основным объектом дальнейшего сравнения.

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

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

Каждый из объектов нашего нынешнего сравнения имеет собственный менеджер пакетов, работающий из командной строки и выполняющий все необходимые функции по доступу к репозиториям и управлению пакетами. Правда, в Ubuntu и Fedora этот самый «главменеджер» имеет по альтернативе, однако в первом случае она нынче настоятельно не рекомендуется к использованию, а во втором, насколько я знаю, вышла из употребления явочным порядком. Так что речи о них здесь не будет.

Среди участников нашего сравнения в роли «главменеджера» выступают:

• в Ubuntu – комплекс утилит apt;

• в Fedora – утилита yum;

• в openSUSE – утилита zypper.

Список этот составлен в порядке «старшинства»: apt – древнейший из пакетных менеджеров вообще (начало разработки – 1998 год), yum создавался на несколько лет позже, в 2001-2002 годах, а zypper появляется в составе openSUSE в 2008 году. И это следует учитывать при сравнении функционала наших героев: более поздние пакетные менеджеры разрабатывались с учётом опыта предшественников.

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

Управление репозиториями включает в себя:

• получение списка включённых репозиториев,

• получение информации о репозитории,

• подключение нового репозитория и отключение ненужного,

• обновление локального кэша пакетов после изменения репозиториев.

И вот тут мы сталкиваемся с первым различием в функционале объектов сравнения: если yum и zypper прекрасно справляются с первыми двумя задачами, то в apt таких возможностей не предусмотрено. Подключение и отключение репозиториев – штатные функции и yum, и zypper (последний умеет также их переименовывать и модифицировать), тогда как в Ubuntu для этого требуется специальная утилита add-apt-repository (которая, кстати, появилась совсем недавно). Обновление локального кэша и в yum'е, и в zypper'е выполняется при каждом запуске (хотя это при необходимости можно отключить), apt-get же требует специальной субкоманды.

Основные действия с пакетами – это их поиск, получение информации, установка, удаление и обновление. И с этим вся наша троица справляется «на ура», хотя опять-таки кое у кого оно звучит громче, а у некоторых ещё и троекратней.

Начать с того, что для поиска и получения информации, с одной стороны, и непосредственно для действий с пакетами в Ubuntu требуется две отдельные команды – apt-cache и apt-get, соответственно, тогда как в Fedora и openSUSE достаточно одной, титульной. Далее, apt-cache search не способен отличать установленные и неустановленные пакеты, что по силам yum'у. А zypper, кроме того, имеет собственный фильтр, делающий ненужным обращение к команде grep для отделения «зёрен от плевел». Вообще по богатству извлекаемой информации zypper в ряду нашего сравнения – вне конкуренции.

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

Различно также обращение сравниваемых утилит с метапакетами – наиболее специфичным (и гибким) тут опять же выглядит zypper. Если метапакеты в Ubuntu и Fedora (задачи и группы, соответственно) представляют собой жёсткие списки пакетов, то шаблоны в openSUSE включают в себя обязательные, альтернативные и опциональные компоненты, определённые майнтайнерами. Но даже они могут быть скорректированы пользователем при установке. Все три типа метапакетов ныне могут быть принудительно «разубожены» – то есть после установки из них можно изъять, при соблюдении некоторых условий, ненужные компоненты. Делается это различным образом: «лобовым» удалением пакета в Fedora, изменением его статуса в Ubuntu, удалением включающего шаблона в openSUSE.

И, наконец, действия над системой в целом – это её обновление и очистка от «мусора». Тут глубоких различий между возможностями утилит из сравниваемых дистрибутивов я не вижу. Разве что опять-таки при использовании apt-get требуется отдельной командой предварительно обновить кэш, а yum и zypper сделают это автоматически. А так – все три системы предлагают два вида обновления: просто обновление установленных пакетов до последних доступных в репозитории версий и апгрейд дистрибутива, позволяющий смену его релиза. Правда, yum предлагает ещё несколько разновидностей обновлений системы, но каково их практическое значение, мне осталось не ясным.

Даже такое беглое сопоставление пакетных менеджеров наметить среди них явного лидера по функциональности и гибкости позволяет, и лидер этот – zypper. Однако немаловажно для программ этого назначения и удобство использования, во многом определяемое синтаксисом команд. Как обстоит дело с этим в нашей тройке по борьбе с басмачами пакетами?

Синтаксически наименее прозрачным и логичным мне представляются утилиты apt – хотя бы потому, что на каждый чих их требуется две (это не считая дополнительных команд типа add-apt-repository – да, Беня знает за автодополнение, но всё же...). Да и субкоманды к каждой длинноваты и не всегда смысл их очевиден. В этом отношении yum, ограничивающийся одноимённой командой, кажется гораздо более простым и лаконичным. Однако ряд функций его реализован за счёт внешних плагинов, которые не всегда устанавливаются по умолчанию, и с которыми тоже надо разбираться. А вот zypper с его логичным синтаксисом, допускающим использование сокращений в субкомандах, выглядит абсолютным чемпионом.

Подведу итог. Менеджеры пакетов – редкий случай в нашем сравнении, где я взялся бы определить лучшего из лучших. Ибо, повторяю, и остальные участники состязания выглядят достойно, вполне заслуживая свои места в тройке сильнейших – второе для yum и третье – для apt. Правда, эта тройка сильнейших из трёх участников – но что поделать, если aptitude и apt-rpm отсеялись ещё на предварительном этапе. А других участников у меня нет.

Графические фронт-энды

Так называемые графические менеджеры пакетов – в сущности, просто фронт-энды к текстовым утилитам, описанным на предыдущей странице. Должны оцениваться и сравниваться не сами по себе, а в двух аспектах: насколько полно они воспроизводят функционал своих бэк-эндов, и насколько удобны в употреблении. Фронт-энды («морды» по простому) привязаны не только к дистрибутиву, но и к рабочей среде, точнее, её библиотекам. И потому в одном дистрибутиве таких «морд» бывает больше одной.

В случае объектов нашего сравнения «морды» до недавнего времени были таков:

• в Ubuntu и всех Gtk-сородичах – Synaptic, и Muon, его функциональный аналог в Kubuntu;

• в Fedora – gnome-packagekit для одноимённого десктопа GNOME и apper для среды KDE;

• в openSUSE – модули универсальной системы YaST для управления пакетами и репозиториями.

И Synaptic, и Muon – графические надстройки над утилитами apt-get и apt-cache, добросовестно воспроизводящие их функционал в наглядном и интуитивно понятном виде. Более особо сказать о них нечего – но ведь и честного исполнения своего долга достаточно.

Ситуация с Fedora изменилась буквально пока верстался номер. В её 20-м релизе из набора gnome-packagekit исчез интегратор – gpk-application: ныне исполнение его супружеских обязанностей возложено на GNOME Software – но это представитель следующего класса программ.

А пока пару слов об уходящем gpk-application – не исключено, что он ещё появится.

Утилиты gnome-packagekit и apper – высокоуровневые надстройки над системой PackageKit. Последняя задумывалась как самое кросс-форматное, кросс-дистрибутивное и вообще самое-самое кросс-платформенное средство пакетного менеджмента – своего рода метапакетный менеджер. «Снизу» к ней теоретически можно подключить чуть не любые пакетные менеджеры – apt, zypper и, разумеется, yum. «Сверху» же PackageKit надстраивается консольной утилитой pkcon и уже именованными графическими «мордами».

Утилита pkcon подходит только на роль yum'а для нищих (духом), предлагая некоторое упрощение использования за счёт существенного ограничения функционала, по сравнению со своим бэк-эндом. И, видимо, поэтому ею никто не пользуется: для знающих yum она слишком убога, для ниасиливших интерфейс командной строки – излишне сложна.

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

Полноты картины для надо заметить, что в Fedora есть ещё одна графическая программа того же назначения – Yum Extender. Как явствует из названия, это «морда» к консольному yum'у – непосредственно, без прослойки PackageKit. По своим возможностям он примерно эквивалентен Synaptic'у, но по умолчанию не используется в основных базовых десктопах: мне он попался только при установке Fedora с Cinnamon'ом в качестве рабочей среды.

И, наконец, YaST из openSUSE. Это – универсальная система конфигурирования всего и вся, о которой будет подробно говориться в следующем разделе. Сейчас же нас интересуют только два её модуля – управления пакетами и репозиториями. Это опять-таки не более чем «морды» к zypper'у – но «морды», полностью задействующие возможности своего бэк-энда. А поскольку на прошлой странице последний был увенчан чемпионскими лаврами в своей весовой категории, то в категории графических фронт-эндов этот титул по праву принадлежит YaST'у.

Центры приложений

Под термином «центры приложений», нагло потибренным из понятийной базы Ubuntu, я понимаю средства, в которых интегрированы функции поиска пакетов в Сети, доступа к содержащим их репозиториям и собственно пакетный менеджмент. Таким образом они полностью отгораживают пользователя от всей инфраструктуры дистрибутива, позволяя устанавливать приложения, что называется, в один клик мышью. Относиться к ним можно по разному, но не нужно быть Нострадамусом, чтобы предвидеть в ближайшее время рост их популярности – собственно, это уже происходит на наших глазах.

Эпонимом для этой категории программ, как уже сказано, послужил Центр приложений Ubuntu. Он позволяет, введя в строке поиска фрагмент имени нужной программы или её описания (в том числе и на русском языке), получить список приложений, удовлетворяющих заданному условию, как установленных, так и не установленных. Выбрав из списка нужное приложение, его можно установить (в первом случае) или деинсталлировать (во втором). Разрешение зависимостей при этому будет выполняться автоматические. Ту же самую процедуру поиска приложений и их установки можно выполнить строке Dashboard'а, создавая ощущения некоторой магии.

На самом деле эту чуждую нам магию мы немедленно разоблачим. Ибо Центр приложений – ни что иное, как надстройка над комплектом утилит apt. И поиск осуществляется в его базе данных, то есть в подключённых репозиториях и источниках коммерческих программ – партнёров Canonical. То есть для поиска в PPA-репозиториях, что наиболее актуально для применителя, Центр приложений оказывается бесполезным. Эту функцию выполняет отдельное web-приложение – Launcher.

Центр приложений работает во всех дистрибутивах семейства Ubuntu, кроме Kubuntu: там имеется его аналог – Muon Discover. Нечто подобное, под названием Менеджер программ, существует и в Mint'е. Наконец, в сообществе разрабатываются несколько усовершенствованные производные Центра – например, App Grid.

Однако нашей целью является сравнение не убунтоидов, а трёх главных героев. Как с программами этого типа обстоит дело в них?

Если говорить о Fedora – то ответ до недавнего времени был прост: никак. Правда в GNOME версии 3.10, которая входит в состав 20-го релиза, был обещан некий GNOME Software –но в бета-версии его не было. Появился неожиданно в релизе. Что о неё сказать? Центр как центр, сделан по образу и подобию Центра приложений Ubuntu.  Не лучше и не хуже. За одним исключением. В Ubuntu после введения соответствующей приблуды Synaptic в системе сохранили – хотя и не по умолчанию. В Fedora же gpk-application подвергли обрезанию под корень.Слова доброго он, конечно, не стоил – но всё же жить с одним центром приложений – это тоже не правильно.

Кстати говоря, в openSUSE 13.1 сборка с GNOME (версии 3.10, однако) ни малейшего софтверного центра не содержит.

Но зато в openSUSE есть механизм, реализующий те же функции, что и Центр приложений (и даже лучше). Это так называемый 1 Click Install. Он не представляет собой отдельного приложения на локальной машине, но работает через любой браузер. И делает это так.

Если зайти на вот страницу http://software.opensuse.org/search (доступ к ней – также через Get it главной страницы сайта проекта) и ввести в строке имя пакета (или его часть – поиск инкрементный), то выведется весь список подходящих пакетов для всех поддерживаемых версий дистрибутива, вне зависимости от того, находятся ли они в подключённом или незадействованном репозитории. После чего достаточно выбрать нужную версию и архитектуру, щёлкнуть на ссылке, которая так и называется 1 Click Install – и начнётся процедура установки пакета. Для чего, если пакет находится в неподключённом репозитории, запускается сначала модуль управления репозиториями YaST, а затем и его модуль управления пакетами. То есть в первооснове всего механизма оказывается всё тот же zypper.

Разумеется, и тут нет никакого волшебства: затребованный пакет ищется не в каком-нибудь астральном пространстве, а в базе данных системы OBS. Но ведь именно это и нужно применителю, не так ли? Так что и в номинации центров приложений бесспорным победителем оказывается openSUSE. Именно интеграция YaST и репозиториев OBS – вторая причина, почему, подводя итоги сравнению репозиториев, я присудил пальму первенства openSUSE.

Итог

Подводя итоги конкурса средств обращения с пакетами, много говорить не придётся. Думаю, любой непредубеждённый читатель согласится со мной в том, что по этой части openSUSE равных себе не имеет, располагая самой совершенной системой пакетного менеджмента и наиболее гибким и функциональным графическим фронт-эндом к нему. И даже по части центров приложений – казалось бы, коронки Ubuntu сотоварищи – её простой, но эффективный 1 Click Install оставляет позади все «африканские страсти» на эту тему.

Столь же бесспорно второе место Ubuntu. Конечно, её apt несколько менее строен, чем yum, но вполне самодостаточен. А его фронт-энд, Synaptic, как бы ни обзывали его архаичным, всяко лучше PackageKit'овских «морд». И, конечно, Центр приложений ничуть не вредит: не смотря на «попсовость», он позволяет быстро поставить какую-нибудь софтину «на поглядеть». И столь же быстро её ликвидировать, если не глянулась. Так что в общем зачёте для Fedora не осталось другого места, кроме третьего. В том числе и за пудрение мозгов с GNOME Software.

Конфигурирование

С давних лет повелась традиция, что уважающий себя дистрибутив должен иметь не только собственный инсталлятор, но и собственный конфигуратор. И в основании её, между прочим, один из участников нашего сравнения – openSUSE, которая в далёком уже 1996 году первой в истории мироздания обзавелась сквозным средством настройки всего и вся. Потом эта традиция была продолжена в Mandrake с его DrakConf. Да и древний Red Hat, который был предшественником Fedora, в стороне от неё не остался – был в нём некогда свой управляющий центр, правда, удивительно похожий на таковой в той ОС, имя которой неприлично произносить при дамах. А Ubuntu тогда и в проекте не было...

С распространением интегрированных десктопов эта традиция стала понемногу отмирать: их центры конфигурирования (как бы они не назывались в разных рабочих средах) всё больше брали на себя функции выполнения глобальных настроек. И ныне, например, в Fedora всеобщего конфигуратора просто нет: в сборке с GNOME настройки выполняются посредством его Центра управления (и дополнительной приблуды... пардон, Дополнительных параметров системы), в сборке с KDE – с помощью её System Settings, в варианте с Xfce – через xfce4-settings... А уж как обходятся те, кто предпочитает менеджеры окон – даже и подумать боюсь. Не руками ли? Сначала правой, потом левой...

Так что один из участников нашего сравнения в данном виде состязаний сошёл с пробега ещё до его начала. А как остальные?

В дистрибутивах семейства Ubuntu ситуация в принципе та же самая, что и в Fedora: на какой-то единый конфигуратор нет и намёка. В результате Kubuntu настраивается своими средствами, Xubuntu и Lubuntu – своими, и так далее. Однако, как сказал некогда великий пролетарский поэт:

Мы говорим – Ubuntu, подразумеваем – Unity, мы говорим – Unity, подразумеваем — Ubuntu.

А раз

Unity и Ubuntu – близнецы-братья

то средства настройки этого десктопа можно считать дистрибутив-специфичными. Тем более, что Unity кроме, как в Ubuntu, более ни в одном дистрибутиве не используется.

Средствами конфигурирования Ubuntu богата. От GNOME она унаследовала центр управления – в супружестве Параметры системы, и первый к нему твикер – Ubuntu Tweak Tool, принявший фамилию жены. Поскольку охватить всё величие настроек Ubuntu они оказались не способны, в дополнение пришлось сочинять ещё и Ubuntu Tweak просто. Да и своеобычные редактор dconf и его gsettings оказываются при делах, как и менеджер настроек CompizConfig, который тоже никто не отменял.

Так что разработчики Ubuntu (подразумеваем Unity) воплотили в жизнь давнишее пророчество моего товарища и коллеги Владимира Попова о временах, когда количество утилит конфигурирования превысит число конфигурируемых параметров. А поскольку этот факт лежит далеко за гранью добра и зла, от его оценки в традиционных понятиях воздержусь.

Ибо пора вспомнить о самом универсальном конфигураторе, не зависящем от рабочих сред и тому подобных превходящих факторов – о YaST из openSUSE. Не совсем, конечно, не зависимом – есть его сборки на Qt, на Gtk и даже консольная – на ncurces. Функционально идентичных. Позволяющих настроить всё, что можно только настроить. И даже немножечко – то, что настроить, казалось бы, нельзя. И потому – несравненному.

Общий итог

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

Ведь перед каждым автором рано или поздно встаёт вопрос: для кого он пишет? Для sapiens'ов? Но ведь им и так sat. И они ведь и сами знают, почему блестящие технологические решения openSUSE обрели широкое признание только в очень узких кругах. Почему пламенный энтуазизм немногочисленных Fedora-применителей затянул в свои омуты экстремалов всех времён и народов. И почему, наконец, технически... эээ... довольно не самые совершенные решения Ubuntu снискали ей ту самую всенародную популярность, за которую бились поколения большевиков, меньшевиков и прочих героев народной воли.

Так что больше на эту тему мне писать лениво. Возможно, со временем я вернусь к теме сравнения дистрибутивов в гуманитарном аспекте, но пока сказал всё, что хотел.

Оглавление

Предисловие 1

Сравнение мужей. Общее введение 1

Войны систем 2

Мой роман с леди Free 2

Linux или FreeBSD? Без гнева и пристрастия 5

Linux vs FreeBSD: продолжим “Священные войны”? 15

Ubuntu vs Fedora 24

Upstart vs systemd 52

Apt vs yum 58

Войны десктопов 59

KDE: обсуждение выбора 60

KDE vs GNOME: первый размышлизм на заданную тему 66

GNOME: сдержанная апология 73

GNOME Shell: оценка юзерофильности 76

KDE vs GNOME. Часть 1 78

KDE vs GNOME. Часть 2 81

Большое сравнение: Fedora, openSUSE, Ubuntu 85

Введение 85

Установка 88

Репозитории 93

Десктопы 99

Политика обновления 102

Пакетный менеджмент 105

Конфигурирование 110

Общий итог 111

Content

Федорчук Алексей Викторович Священные войны мира FOSS

Предисловие

Сравнение мужей. Общее введение

Войны систем

Мой роман с леди Free

Linux или FreeBSD? Без гнева и пристрастия

Вступление post factum

Пара отмазок

Субъективное введение

Настройка

Система управления пакетами

Пользовательские качества

О производительности

Подведем итоги

Заключение post factum

Linux vs FreeBSD: продолжим “Священные войны”?

Вступление

Поддержка аппаратных платформ

Поддержка дополнительного оборудования

Поддержка хранилищ данных

Внутреннее устройство системы и обеспечение её целостности

Средства пакетного менеджмента

О сравнении производительности

Ubuntu vs Fedora

Вступление

Ретроспектива

Появление второго протагониста

Последствия

Ещё немного ретроспективы

Федорины меры

Fedora 15: переломный релиз

Предстрастие к systemd

Страсти по systemd

Послестрастие к systemd

Отборочные соображения

Выходим в полуфинал

Империя наносит удар

В преддверии финала

А будет ли финал?

Upstart vs systemd

Леннарт Поттеринг об upstart и systemd

Комментарий к заметке Леннарта Поттеринга об upstrat и systemd

О пузометрии

О пузометрии: спустя почти полгода

Apt vs yum

Войны десктопов

KDE: обсуждение выбора

KDE vs GNOME: первый размышлизм на заданную тему

GNOME: сдержанная апология

GNOME Shell: оценка юзерофильности

KDE vs GNOME. Часть 1

KDE vs GNOME. Часть 2

Большое сравнение: Fedora, openSUSE, Ubuntu

Введение

Отбор участников

Критерии сравнения

Объяснения и отмазки

Реверансы и референсы

Установка

Вступление

Ubuntu

openSUSE

Fedora

Итоги

Репозитории

Вступление

Fedora

openSUSE

Ubuntu

Отступление о стабильности

Заключение о структуре

Наполнение

Итог

Десктопы

Вступление

openSUSE

Fedora

Ubuntu

Итоги

Политика обновления

Релиз-циклы

В «межрелизье»

В «межрелизье». Fedora

В «межрелизье». Ubuntu

В «межрелизье». openSUSE

Итог

Пакетный менеджмент

Вступление

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

Графические фронт-энды

Центры приложений

Итог

Конфигурирование

Общий итог