Священные войны мира FOSS
Чудо-женщина жила (Господи, прости ей!), Не добра и не мила, Но краса ее влекла Джентльменов без числа Дьявольской стихией. Джентльменов бел числа От Дувра до Холъспая, Африкой она была, Южной Африкой была, Нашей Африкой была, Африкой без края.Это глава из книжки «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 в полной мере. Однако записал себя в число ее преданных поклонников. И пока не имел повода раскаиваться в своем решении... (обратно)Редьярд Киплинг
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 (а это – практически все стандартное и распространенное «железо»), использовать, в большинстве случаев, проще. И тут мы плавно переходим ко второму волнительному для юзера, особенно начинающего (а не начинающие давно сделали свой выбор) моменту, имя которому -
(обратно)
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 их не возникает вовсе.
Кстати, о доустановке инструментария (и прочих программ – для этого ведь необходима
(обратно)
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, но столь незначительным, что вполне резонно согласиться на ничью. Однако каждая ОС устанавливается, настраивается и наращивается приложениями не ради себя самой, а для практического использования. И потому следует рассмотреть в сравнении их
(обратно)
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 – я боюсь себе даже представить...
Наконец, остается еще один вопрос, важный для пользователя -
(обратно)
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 может проявить свои сильные стороны, и скоростные соотношения между этими системами, возможно, в ряде случаев окажутся прямо противоположными.
(обратно)
Демон с пингвином – братья навек!(обратно)
•
пользовательский сегмент — под ним мы будем понимать не столько пользователей домашних медиа-центров, сколько людей, занятых решением своих производственных задач на одной отдельно взятой машине;
•
серверный сегмент, охватывающий управление сетями и службами коллективного применения — своего рода войска тылового обеспечения для первой группы задач;
•
сегмент встраиваемых устройств — очертить его словами довольно трудно, но смысл, думаю, интуитивно понятен.
Разумеется, у каждого есть свои предпочтения, что из перечисленного считать мухами, что — котлетами, а что — гарниром. Это, во-первых. Во-вторых, и это — следствие первого, непреодолимой границы между выделенными сегментами нет: как было резонно отмечено в обсуждении на POSIX.ru, одно и то же устройство может выступать в любой из указанных ролей. А в-третьих, напротив, граница между мухами, котлетами и гарниром с течением времени становится всё более резкой. Что хорошо видно на примере эволюции мультимедии разного рода. Играя роль котлеты для их разработчиков, они, по мере превращения в привычный гарнир для своих пользователей, всё больше оказываются в амплуа мух для тех чудаков, кто по прежнему использует компьютер традиционным способом, то есть для работы.
Нечто аналогичное на наших глазах происходит со встраиваемыми устройствами, что демонстрирует в своём «Железном марше» Сергей Голубев. Типичный пример — сетевые накопители. Оснащенные винчестерами, подчас объединёнными в RAID-массивы, такого объема, которому ещё недавно позавидовал бы data-центр средней руки, они нынче, казалось бы, прочно переместились в пользовательский сегмент. Однако не будем спешить: уверен, что очень скоро эти агрегаты будут продаваться с «предустановленными» видео- и аудиозаписями, коллекциями изображений и подборками материалов «только для взрослых». После чего прочно окучат сектор бытовых устройств.
Так что для начала определюсь со своей личной системой приоритетов. Будучи ориентированным очень традиционно и банально, я рассматриваю компьютер в первую очередь как инструмент для работы. А поскольку работа моя не связана ни с настройкой серверов, ни с сопровождением сетей, в первую очередь меня интересуют пользовательские аспекты. Так что во всём дальнейшем банкете роль котлеты предназначена настольным системам, в качестве гарнира будут выступать серверные и сетевые средства — в той мере, в какой они способствуют поеданию котлет (то есть решению пользовательских задач), а встроенным системам достанется амплуа мух, роящихся где-то далеко на кухне. Критика этой позиции со стороны приверженцев иной системы приоритетов не принимается. А вот связное и последовательное изложение их позиции — напротив, приветствуется.
Теперь про области сравнения. Традиционно Linux и FreeBSD сравниваются с точки зрения:
•
поддержки аппаратных платформ;
•
поддержки дополнительного оборудования внутри одной архитектуры;
•
поддержки хранилищ данных, таких, как логические тома и файловые системы;
•
внутреннего устройства системы и средств поддержки её целостности;
•
средств управления дополнительным программным обеспечением;
•
наконец, производительности.
Не будем отступать от этой традиции и мы. Однако главной нашей задачей будет не столько собственно сравнение, сколько определение веса каждого из сравниваемых компонентов для указанной выше сферы применения — то есть десктопной котлеты, в сравнении с серверным гарниром; встраиваемых мух я вынужден оставить без внимания, так как с оными никогда не общался.
(обратно)
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-устройств и прочих дешёвых подделок) было бы просто скучно.
(обратно)
sendmail
). С другой стороны, base FreeBSD нельзя считать и полностью самодостаточным — трудно представить себе её, например, без Perl'а...
Различие, скорее, в модели разработки. Базовый комплект FreeBSD, за некоторыми (хотя и принципиально важными) исключениями, разрабатывается в рамках единого проекта. И в результате каждое изменение функциональности ядра тут же находит своё отражение в инструментах, эту функциональность реализующую. В Linux'е ядро и базовый комплект развиваются в серии независимых проектов, и отнюдь не всегда согласовано.
В результате FreeBSD имеет собственный механизм обновления и поддержания своей целостности — сакраментальные заклинания по сборке ядра и мира. В Linux'е эта задача возлагается на дистрибутив-специфические средства пакетного менеджмента, о которых речь пойдёт в следующем разделе.
(обратно)
rpm
и его истории, позднее выделенный в отдельное производство. С rpm based системами я не имел дела много лет, и потому решил во FreeBSD поставить rpm
из порта — дабы хотя бы почитать, что о нём говорит тётя Маня.
Сказано — сделано: перехожу в каталог /usr/ports/archivers/rpm4/
и, не мудрствуя лукаво, набираю
# make install clean
после чего продолжаю заниматься своими делами. Через некоторое время решил поглядеть, что там у меня делается с установкой — и с удивлением обнаружил, что она всё ещё продолжается: скачиваются и собираются в качестве зависимостей TeX, Qt и ещё что-то...
Разумеется, такую ситуацию можно было бы предотвратить внимательным изучением Make-файла или списка зависимостей, например, на Freshports. Сказанным же хочу только подчеркнуть, что системы портов, как и пакетный менеджмент в стиле apt
, сами по себе гарантии от неё не дают, наиболее эффективно работая в том случае, когда пользователь знает, что делает. А вот отсутствие в Slackware развитых средств управления пакетами просто заставляет относиться к их установке вдумчиво.
(обратно)
1. для Canonical приоритетным является развитие Ubuntu как цельной системы, направленной на благо пользователя, кем бы он ни был (домохозяйкой или админом огромной сети);
2. развитием LK и без неё занимается много сильных компаний и команд, так что Canonical вмешивается в это дело лишь постольку, поскольку оно требуется для развития собственного бузинеса.
И итоговый отчёт, и ответ Марка вызвали бурную полемику как Рунете, так и в мировом масштабе. За некоторыми обсуждениями я следил и даже по мере сил в них участвовал (пока не надоело). Они и составили этнографическое основание для настоящих заметок.
Важно заметить, что все эти обсуждения протекают на фоне других разговоров, касающихся новшеств, продвигаемых в дистрибутиве Fedora, что косвенно затрагивает также и Red Hat (то есть RHEL). И если острота дискуссий по поводу GNOME 3 или pulseaudio отошла в прошлое, то страсти вокруг systemd прямо так и кипят. Усугубляясь смежными темами, как то: слиянием проектов systend и udev, введением новой системы записи log'ов или предложением переноса в сферу компетенции systemd части функций интегрированных сред (KDE, GNOME, XFce).
Однако, помимо этого сиюминутного фона, есть и более широкая историческая ретроспектива сегодняшних дискуссий. И это – историческая составляющая моих заметок. Так что с истории я и начну.
Но сначала оговорю свою личную позицию. Ни к Fedora, ни к Ubuntu я не питаю ни гнева, ни пристрастия. На протяжении нескольких лет я был пользователем и того, и другого дистрибутива – то есть, если во временной последовательности, сначала другого, потом того. В настоящее же время (на момент сочинения заметок) не применяю ни один из них. Так что ни малейшей личной заинтересованности в них не испытываю, и потому попытаюсь вести обсуждение более или менее объективно – насколько это возможно при обсуждении дистрибутивов.
(обратно)
•
первой 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'е на каждом десктопе и скором виндовом апокалипсисе ведутся чисто по привычке. И ничто, казалось бы, не в силах нарушить этого благолепия. Пока в него не вторгается второй протагонист (или антагонист?) нашей мелодрамы.
(обратно)
Очень интересный дистрибутив. Но для своей задачи – ознакомления совсем ньюбов – совершенно не пригоден: слишком много надо допиливать.И в первой версии (04.10) так оно и было. Что опять-таки не способствовало оптимистической оценке Ubuntu. Так что я выкинул его из головы. Однако это был один из тех нередких случаев, когда провидцы и ясновидцы, даже будучи очевидцами, оказались не правы (повторяю, это и ко мне относится). Ибо не учли личности организатора всего этого безнадёжного предприятия. А меры, предпринятые Марком Шаттлвортом для продвижения своего произведения, были дезординарными, с одной стороны, и вполне тривиальными – с другой. Самой дезординарной мерой была организация заказов на компакты дистрибутива безвозмездно, то есть даром – с бесплатной же почтовой доставкой по всему миру, в том числе по России. И это действительно работало – даже в самых удалённых городах и весях нашей необъятной родины. Правда, по поводу этой акции скептики поначалу иронизировали: нынче каждый линуксоид имеет возможность бесплатно заказать себе подставку под пивную кружку. А ведь зря иронизировали: в результате о Linux'е узнала масса людей, прежде о его существовании и не подозревавших. И немало представителей этой массы дистрибутив хотя бы опробовали. А кое-кто из опробовавших так к нему и прикипел. Это была одна из причин почти мгновенного роста популярности Ubuntu. Вторая же, как я говорил – вполне тривиальна: интенсивная «работа над ошибками», и не только своими. Ubuntu изначально позиционировался как очередной Linux с человеческим лицом, с одной стороны, и концентратор самого свежего софта – с другой. В плане первого вопроса были учтены все ошибки прежних попыток «очеловечивания» Linux'а. И в итоге разработчикам удалось если не найти оптимум между «настройкой с паяльником и осциллографом» и «молчаливыми визардами для полных идиотов», то вплотную к нему приблизиться. Направление работ по второму вопросу очевидно: использование самых свежих версий софта всегда потенциально чревато ошибками в оном – и ошибки эти следовало исправлять. Или не допускать – путём сознательного ограничения «степени свежести» – ведь программы, в отличие от осетрины, бывают свежести весьма разной. И в итоге в Ubuntu не стало никакого особого гипермодерна – она основывалась на репозиториях Debian тестируемой ветки, пригодность к использованию которой в десктопных условиях общепризнана. В результате осенью 2005 года, когда, подстрекаемый лавинообразным нарастанием сетевых публикаций об Ubuntu (что само по себе было показателем популярности), я серьёзно заинтересовался этим дистрибутивом, то обнаружил вполне зрелую систему, пригодную к применению «искаропки» пользователем любого уровня. Разумеется, не без некоторых шероховатостей, касавшихся в первую очередь локально-зависимых вещей, но это было вполне естественно: обеспечить равную поддержку всех языков, от зулусского до русского, за столь короткий срок физически невозможно. Да и лечилось всё это достаточно просто – руками самих утопающих... то есть, пардон, нативных носителей языка. Всё сказанное выше было причиной того, что за год число пользователей Ubuntu достигло не просто высокого уровня – оно превзошло количество пользователей всех прочих дистрибутивов, вместе взятых. А с учётом появившихся вскоре многочисленных клонов и дериватов – пожалуй, что превышение их суммарного количества можно было мерить уже не разами. Не менее, чем количество, показателен состав пользователей Ubuntu в сравнении с более иными дистрибутивами. Для начала, в многочисленных опросах о первом дистрибутиве Linux на протяжении первой половины нулевых годов неизменно, и с большим отрывом, одерживала победу Mandrake, она же в замужестве Mandriva. Но те же опросы о текущем дистрибутиве показывали, что после успешного старта с Mandriva изрядное число пользователей перетекало на другие системы. Для второй же половины нулевых годов картина стала совершенно иной. Первое место в опросах о первом дистрибутиве прочно заняла Ubuntu. И в то же время процент пользователей, оставшихся верными этому выбору, был неизменно высок. В то же время немало оказалось и действующих пользователей Ubuntu, для которых этот дистрибутив был не первым, и не вторым, тех, кто прошли и ручную настройку Slackware, и тотальную компиляцию Gentoo, и роман «Ядро и мир» от FreeBSD, а возможно, и сборку LFS. И чьё сердце успокоилось в
Это люди, которые знают о компьютерах совсем немного и не хотят знать ничего сложного. На самом деле, они просто хотят использовать то, что нормально работает и сможет сделать все правильно, так как им нужно, – где они с легкостью смогут найти то, что им потребуется.И вторая категория, в которую
...входят люди, которые действительно любят свободное программное обеспечение за его качество и техническое превосходство – то есть те, кто является по-настоящему предан идее open source.Иначе говоря, Ubuntu ориентирован, с одной стороны, на тех, кто сам все знает и умеет, с другой – на тех, кто ничего о компьютерах не знает, знать не хочет, но готов положиться на знающих. В этом аспекте интересно, что среди пользователей Ubuntu высок процент тех, кто не имеет к компьютерам ни малейшего отношения – ни по долгу службы, ни по велению души. А разве что по жизни вынужден ими пользоваться. Тогда как среди пользователей иных дистрибутивов процент этот исчезающе мал. Более того, среди моих личных, реальных и виртуальных, знакомых (а круг и тех, и особенно других у меня весьма широк) вообще нет людей, не работающих в околокомпьютерных сферах или просто не интересующихся компьютерами как хобби, которые использовали бы какой-либо дистрибутив Linux'а. Разумеется, если этот Linux – не Ubuntu. Всё сказанное выше могу подтвердить личными впечатлениями и собственным опытом, но это далеко выйдет за рамки настоящей темы. Так что пока – предварительный итог: Буквально за пару лет Марку Шаттлворту, фирме Canonical, примкнувшим к ним независимым разработчикам и, не в последнюю очередь, активным пользователям – создателям сайтов и авторам блогов убунтийской тематики, удалось превратить, казалось бы, рядовую «человеко-мордастую» поделку в самый популярный и распространённый дистрибутив планеты. Не будем пока оценивать это в терминах великого советского поэта, автора знаменитой поэмы о «хорошо» и «плохо», а примем как медицинский факт. И посмотрим, что же из этого получилось. (обратно)
– Вот вы тут сидите и не знаете, а пиписька-то х...м называется!И ваш покорный слуга, в силу природной язвительности, отдал дань этому занятию. Однако факт остаётся фактом: время расставило всё по своим местам. Сайты и блоги совсем тривиального содержания канули в небытие, более иные же развились в полноценные ресурсы. И ныне решение любой проблемы, имеющей отношение к Linux'у вообще, скорее всего может быть найдено на ресурсах убунтийской тематики. Другое дело, что на таких ресурсах далеко не всегда делается различие между общелинуксовыми (и даже общеюниксовыми) решениями и решениями дистрибутив-специфическими. Но что поделать – это следствие всё той же популярности Ubuntu. Для многих пользователей которой понятия Linux, Ubuntu и, как уже было сказано чуть выше, GNOME оказались соединёнными символами тождественного равенства. Ещё одно частное, но очень важное для конечного пользователя следствие распространения Ubuntu – появление в Иксах качественных шрифтов. Точнее, не столько даже самих шрифтов, сколько механизмов их экранного воспроизведения. Если раньше
•
для практической работы широко применялись пиксельные шрифты,
•
для просмотра в браузерах и офисных пакетах приходилось прибегать к шрифтам от классового врага (причём, дабы соблюсти букву лицензии, следовало понимать толк в извращениях),
•
а умельцы вручную патчили freetype для включения поддержки интерпретации байткодов и субпиксельного хинтинга,
то в Ubuntu качественный рендеринг шрифтов обеспечивался из всё той же Пользователи притащат 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. Какие? Скоро увидим. (обратно)
sudo
).
Впрочем, в отношении последнего пункта очень велика была роль проекта Russian Fedora, возникшего осенью 2008 года, и с тех пор выпускавшего собственные сборки дистрибутива (RFRemix) одновременно с выходом оригинального релиза. Именно в нём и были реализованы впервые столь важные для пользователя мелочи. К коим следует добавить и сборку библиотек шрифтовой поддержки с опциями интерпретации байткодов (что по истечении срока действия соответствующего патента попало и в оригинальную Fedora) и субпиксельного рендеринга.
Важным моментом для конечного пользователя было не только существование RFRemix самого по себе – системы, собранной с учётом локальной специфики, но и наличие поддержки на языке родных осин. Таковая осуществлялась, во-первых, на форуме проекта, во-вторых – с помощью постоянно пополняемой русскоязычной документации, в первую очередь вполне оригинальной Wiki.
При этом RFRemix продолжала сохранять полную совместимость с оригинальной Fedora: одну сборку в другую можно было превратить легким движением руки – и в любом направлении. Что было немаловажно для отечественного пользователя, часто испытывающего недоверие к отечественной же продукции – иногда законное, но в данном случае абсолютно неоправданное. Так что, убедившись в последнем после установки оригинального дистрибутива, пользователь мог безболезненно перейти на русскую сборку.
В общем, пресловутая «готовность к десктопу», о которой последнее время говорят не меньше, чем о «человеческом лице» Linux'а – в недалёком прошлом, возрастала и в оригинальной Fedora, и, особенно, в RFRemix от версии к версии. И достигла своего апогея в релизе 14 (ноябрь 2010 года).
Предшествующие версии RFRemix (по крайней мере с 11 по 13, которые я, что называется, «щупал рукаами»), можно было рекомендовать начинающим пользователям – но с рядом оговорок. Впрочем, число их от релиза к релизу всё сокращалось. И 14-й релиз я взял на себя смелость рекомендовать уже безусловно и всем пользователям, вне зависимости от задач и начальной подготовки. В общем, как сказал мой коллега Сергей Голубев в одном из своих обзоров:
... еще один Linux пошел в народные массы.Увы, сказал он это задним числом – потому что с выходом 15-го релиза, имевшим место быть в марте 2011, выяснилось, что предпосылки к обретению статуса образцового дистрибутива оказались похеренными. Как это случилось – будет рассказано в следующей заметке. А на вопрос почему? я постараюсь дать предположительный ответ несколько позже. (обратно)
... все рухнуло в одночасье.Давайте посмотрим, попытавшись заодно оценить меру «рушения». Собственно, тревожные симптомы можно было уловить ещё до выхода релиза – по сообщениям в новостях, а затем и по тестовым версиям. Первой ласточкой (или, скорее, воробушком) было переименование сетевых интерфейсов. Вместо традиционных для Linux и давно привычных имён типа eth# в Fedora явочным порядком вводились различные наименования для встроенных сетевых чипов и карт для PCI-слотов. Мотивировалось это проблемами, возникающими при подключению к компьютеру нескольких сетевых устройств, когда нумерация одноимённых интерфейсов могла измениться. В обоснованность этих опасений вдаваться не будем. Тем более, что как раз десктопных пользователей это не особенно волновало – мало у кого из них в машине имелось более двух сетевых устройств, а большинство так вообще обходилось одним. Просто запомним этот маленький фактик – со временем он найдёт себе место в общей картине. А вот вторая ласточка была куды жирней, и для десктопного пользователя тянула уже на приличную курицу. Это было внедрение в качестве рабочей среды по умолчанию пресловутого (или знаменитого) GNOME 3 с его GNOMEShell'ом. О его весьма спорных достоинствах и бесспорных недостатках уже написано без счёта постов на форумах и в блогах. Немало говорено и о том, как превратить его в почти нормальный GNOME 2 – кажется, 90% всех форумных постов, так или иначе касавшихся Fedora 15 и GNOME 3, были посвящены этому вопросу. Так что просто «кратко резюмирую вчерашний уж базар», не вдаваясь, повторяю, в материи, столь любимые некогда Великим Советским Поэтом: GNOME 3 – откровенно нишевое решение, ориентированное на устройства, управляемые пальцами и
– Мама, я не люблю дедушку... – Не нравится – не ещь!А конкретней – это предложения:
•
оставаться на 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
, только разгораются. И причину их опять надо поискать в истории.
Как известно, исторически сложилось так, что 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-мире предвещает триумфальное по нему шествие upstart
, что вроде бы обрекает последнюю на светлое будущее во всех дистрибутивах. И действительно, в виде опции она появляется в тестовой ветке консервативнейшего Debian'а, поговаривают о включении её в openSUSE (и вроде бы она промелькнула в какой-то из тестовых версий 10-го релиза).
Но что это за фронтирный дистрибутив, который довольствуется новшествами, написанными в дистрибутиве ином? Непорядок, который срочно должен быть исправлен. И весной 2010 года Леннарт Поттеринг, сотрудник Red Hat, ранее прославленный созданием аудиосервера PulseAudio, выступает с новой прогрессивной инициативой – системой инициализации по имени systemd
.
Сначала она имеет статус прототипа, к лету того же года обретает права 1-го релиза, а уже весной 2011 года оказывается в составе Fedora 15 – одновременно с GNOME 3, о котором говорилось ранее.
Коренных отличий systemd
от upstart
– два. Первое – ещё большее распараллеливание процедуры запуска стартовых служб за счёт полного отказа от их последовательного осуществления: сначала создаётся канал связи между зависящими друг от друга сервисами, а затем уже происходит их запуск.
И второе – большинство сервисов штатно запускается не shell-скриптами, а скомпилированными Си-программами. Хотя пока, в целях совместимости, не возбраняется и запуск сценариев, в том числе и самописных.
Чем это чревато для пользователя? Двумя обещаниями: во-первых, фантастического роста скорости загрузки системы, во-вторых, возможности гибкого управления уже запущенными сервисами. Здорово, правда? А давайте посмотрим, насколько здорово.
О том, насколько «важна» для пользователя ныне скорость загрузки системы – я уже говорил в прошлой заметке. Как и о том, что распространение SSD-накопителей вообще снивелирует разницу между любыми схемами инциализации, какие только хватит фантазии придумать.
Но предположим, что для нашего пользователя метрологические соображения (в данном случае не у кого 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
оказывается связанным 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 •
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, но можно быть уверенным – за ней дело не заржавеет.
(обратно)
systemd
. А ещё ранее, и неоднократно (уже не упомню, когда и где) – о нежелании тратить силы на освоение GNOME 3. Мотивируя это тем, что это мне не нужно.
И это действительно так – но лишь отчасти. Главная же причина в том, что ни GNOME 3, ни systemd
, что бы ни говорили о их технических достоинствах (вне зависимости от их наличия или отсутствия), ни малейшего отношения к технологии дела не имеют.
То, что что мы видим сегодня – это всего лишь бизнес. И политика, вокруг этого бизнеса намешанная. Со всеми атрибутами политических игрищ, в том числе с агитацией и пропагандой, достойной лучших последователей товарища Ульянова в скобках Ленина. Когда всё наше заранее объявляется прогрессивным, а всё не наше – устаревшим и маргинальным. Это не мои слова – это звучит между строк ранее упоминавшегося поста Поттеринга, почти явно – в посте Мартина Лангхоффа на эту тему. И уж совсем открытым текстом говорится их последователями, в том числе и на русскоязычных ресурсах. Короче, большевистский лозунг
Кто не с нами – тот против нас!неожиданно прозвучал в исполнении тех, кого недавно считали оплотом свободы. И, что характерно, тех, кто таковым считает себя и сейчас, вдаваясь в рассуждения о свободе выбора, создании форков и тому подобные разговоры в пользу бедных. Не обходится и без прямых уколов «врага» нынешнего, дескать, недостаточно внимания уделяющего разработке ядра и вообще системных компонентов Linux. И ну никак без дифирамбов в адрес «врага» недавнего (как известно, в бизнесе нет постоянных врагов и постоянных друзей, есть только постоянные интересы). Хотя вклад этого самого «друга-врага» (отвлечёмся от методики его подсчёта) не нужен никому, кроме его самого. Ну а уж что до мелких подъ...ок (да простят меня читающие это дамы, но никакое иное слово здесь не подходит по смыслу) касаемо перекрашивания обоев или перетаскивания кнопок управления окном справа налево – то это просто смешно. Особенно на фоне таких шоу, как демократический выбор имени следующего релиза дистрибутива. Не говоря уж о том, что стратегия «перекрашивания обоев и перетаскивания кнопок» (употребляю это очень фигурально) за несколько лет дала Ubuntu больше пользователей, чем Red Hat'у – самые передовые патчи ядра за двадцать лет. Короче говоря, мы видим нынче не какую-то техническую дискуссию, а очередной акт вековой драмы, имя которой – Борьба Бабла и Зла. Другое дело, что от исхода этой борьбы зависит направление технического развития систем, которые до сих пор назывались Свободными. И потому пользователей их, вне зависимости от ОСеисповедания и дистрибутиво-ориентации, не может не интересовать ответ на вопрос: чьё же Бабло в борьбе обретёт право стоять во главе борьбы со Вселенским Злом. Попытка ответа на него приведёт нас с не очень устойчивого грунта косвенных реконструкций на совсем уж зыбкую почву футуристических прогнозов. Тем не менее, попробую на заключительной странице рассмотреть возможные продолжения сюжета нашей драмы. (обратно)
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'а окажется никому не нужной – это сейчас выглядит туманной перспективой.
(обратно)
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-систем оживить их десктопное направление, а для пользователей, по крайней мере некоторых, применять их разработки в этом качестве?
Так что надеюсь, что Линупокалипсис на ближайшее время откладывается. А как будут развиваться события на самом деле – мы узнаем достаточно скоро: или во время осеннего урожая релизов, или, в крайнем случае, весной, индо взопреют релизы весенние. Но хочется верить, что заколдобиться, понюхав их портянку, в отличие от старика Ромуальдыча, нам не придётся.
На этой оптимистической ноте позвольте закончить очередное, сильно затянувшееся, этнографическое исследование. В дискуссию по поводу которого я более не вступаю. Ибо сказал по данной теме всё, что мог и хотел.
(обратно)
(обратно)
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?
Правда, убедить в чём-то приверженцев этого менеджера инициализации ничуть не легче, чем читателя Шекспира – в том, что Ричард Третий...
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, вне зависимости от схемы инициализации. То есть основной выигрыш в скорости загрузки обеспечивается вовсе не последней, а исключительно «железом». Что, собственно, было ясно из общих соображений (товарищ майор, поздравляем вас с присвоением очередного звания).
(обратно)
(обратно)
~/.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 еще не достигла состояния идеального десктопа, и не свободна от некоторых недостатков. Однако выше я попытался показать, что они не критичны, и более-менее легко преодолимы. Что позволяет рассматривать эту систему в качестве оптимального выбора при необходимости именно в интегрированной среде обитания.
(обратно)
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 – это не интегрированная среда в собственном смысле слова, в отличие от 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 и двухрежимным интерфейсом GNOME Shell я не заметил. А вот на маленьких дисплеях нетбуков второй, за счёт отказа от перманентно присутствующих панелей может быть удобнее: в этом случае каждое приложение можно запускать на собственном рабочем месте в полноэкранном отображении.
Впрочем, нетбука у меня в тот момент не имелось, так что это было чисто теоретическое рассуждение. Не прошедшее испытания временем.
А вот что мне очень не понравилось – так это сочетание фона и текста в сайдбаре при оверлейном режиме. Шрифт, во-первых, очень маленький для моих глаз. Во-вторых, по моему глубокому убеждению, выворотка (то есть светлый текст на тёмном фоне) вообще приемлем только при использовании полужирного шрифтоначертания. Так что разглядеть что-либо на сайдбаре можно только с большим трудом.
Это было бы полбеды, если бы имелись хоть какие-нибудь средства настройки внешнего вида в оверлейном режиме. Однако таковых я не обнаружил – ни методом научного тыка, ни в документации (кстати, достаточно скудной).
Вообще-то, доступ к настройкам можно получить из «рабочего» режима шелла – через меню, вызываемое щелчком на имени пользователя верхней панели.
Однако таким образом вызывается обычный Центр управления GNOME, позволяющий настроить вид окон и приложений, но не оказывающий ни малейшего влияния на сайдбар оверлейного режима:
Правда, через то же меню сайдбар можно вывести и в «рабочем» режиме в виде почти обычного окна. Однако по сравнению с сайдбаром оверлейного режима он, во-первых, урезанный, во-вторых, урезает «полноэкранность» рабочих мест, а в-третьих, точно также не может быть настроен. Хотя по умолчанию воспринимается несколько лучше:
Хочется верить, что невозможность настроек оверлейного режима – явление временное, и будет ликвидирована к моменту обретения GNOME Shell'ом статуса релиза. А пока он находится в состоянии активной разработки, и при каждом плановом обновлении системы в нём что-нибудь, да меняется.
В заключение коснусь двух моментов, вызывающих обоснованные опасения. Первый касается быстродействия. Так вот, тут бояться нечего – даже на моей хилой (с точки зрения 3D) видеоподсистеме (интегрированный Intel) ни малейшего торможения при переключении режимов и рабочих мест, сопровождающемся эффектом «разворачивания» (не знаю, как это назвать более наукообразно – но тот, кто видел, поймёт) не наблюдается. Нет его, торможения, и нигде вообще.
А вот второй момент – о революционности нового интерфейса, о которой столь много говорят разработчики. Хвала Аллаху, они сильно преувеличивают – ничего ультраааа-революционного в нем я не углядел, все действия выполняются достаточно просто и привычно. За что им отдельное спасибо.
В общем, подведу итог: даже в современном своём виде GNOME Shell пригодится линуксоиду не только для того, чтобы погубить красивую вендузяднецу, но и для выполнения самой простой и обычной работы. Так что пользователя новый интерфейс любит в меру...
(обратно)
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, но ещё далеко с ним не сравнялся. Чтобы пропорции несколько выровнялись, потребовалось ещё одно событие, в котором также не было ни малейшей заслуги разработчиков этой среды. Но об этом мы поговорим во второй части. (обратно)
Что позволено парторгу – не позволено бичу.Поначалу удручало убожество убожество штатных приложений – например, 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 – апофеоза отечественного дистростроения. Но, как поётся в песенке
Мене, текел, упарсиндля 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'а. Конечно, вы можете возразить, что последний по прежнему можно использовать как файловый менеджер по умолчанию. Однако тогда возникает вопрос – а зачем нам два
•
в числе наиболее известных и популярных (в статистику вдаваться не будем, ибо она от глюкавого);
•
все три декларируют свою любовь к конечному пользователю, хотя и каждый по своему;
•
за каждым из этих дистрибутивов стоит тыловое прикрытие (или даже «крыша») в виде коммерческой фирмы.
Все три дистрибутива имеют близкий релиз-цикл (6-9 месяцев). И как раз недавно вышли их свежие стабильные версии. То есть в данном случае речь идёт о срезах современного их состояния.
По хорошему в число сравниваемых систем надо было бы включить ещё и Mandriva, как дистрибутив, подходящий по всем статьям. И к тому же в лице первозданного Mandrake бывший прародителем всей современной юзерофилии вообще. Однако нынче этот дистрибутив разделился на несколько линий с не вполне понятными взаимоотношениями. И не ясно, которого из них надо привлекать к ответственности по нашему делу. К тому же об одном из представителей этого семейства, дистрибутиве ROSA, часто и подробно пишет мой товарищ и коллега Сергей Голубев. Так что пробелы в данном сравнении читатель легко может восполнить.
Я не ставлю себе целью возвеличивание ни одного из рассматриваемых здесь дистрибутивов, не собираюсь убеждать читателей в том, что один из них – единственный и несравненный. И порядок их перечисления в титуле страниц – не попытка выстроить из них иерархию снизу вверх, сверху вниз, или даже в сторону. Оно отражает последовательность моего обращения к этим системам в отрезок с 2009 года и по настоящее время. Впрочем, его можно считать и алфавитным.
В дальнейшем порядок будет описания соответствующих особенностей дистрибутивов будет определяться скорее литературными соображениями и удобством собственно сравнения.
(обратно)
•
программа установки;
•
состав репозиториев и их структура;
•
поддержка различных рабочих сред;
•
политика обновления дистрибутива и/или его частей;
•
средства управления пакетами и репозиториями;
•
штатные средства настройки.
Конечно, при этом местами мы вступаем в пограничную область сравнения дистрибутивов и используемых в них рабочий сред. Ибо один и тот же дистрибутив со средой KDE будет похож на любой другой KDE-ориентированный дистрибутив, нежели на самого себя с GNOME или Xfce. Однако это – тоже показательный момент при сравнении. Потому что все три участника нашего соревнования, с одной стороны, имеют свою коронку в виде рабочей среды, поддерживаемой «по первому разряду»: GNOME 3 для Fedora, KDE для openSUSE, Unity для Ubuntu. А с другой стороны, все «коронные» десктопы любого из них поддерживаются остальными участниками или непосредственно, или силами окружающего сообщества. Исключение тут, понятное дело, Unity – но и как мы увидим в конце концов, весьма показательно.
(обратно)
•
Ирине Киттелль, известной в сети как Алиса Деева – она вдохновляла меня на труды сочинительские;
•
Владимиру Попову, Владимиру Родионову и Сергею Голубеву – немало затронутых здесь вопросов мы обсуждали в реале и виртуале;
•
моим товарищам по форуму POSIX.ru, Юниксфоруму и Джуйке – поимённое их перечисление исчерпало бы мою дисковую квоту.
Искренняя благодарность – участникам проекта Russian Fedora, русскоязычной секции openSUSE Forums и создателям ресурсов по Ubuntu, имя которым – легион. И, разумеется, разработчикам соответствующих дистрибутивов.
(обратно)
(обратно)
aptitude
, что, во-первых, не очень удобно для тех, кто с этим интерфейсом не знаком, во-вторых, в последних релизах Ubuntu работает весьма криво.
Но есть и другой способ установки индивидуализированного набора пакетов – выполнение из Live-режима процедуры debootstrap
, при которой устанавливается так называемая core system, которую в дальнейшем можно нарастить с помощью apt-get
. Тот же результат достигается при альтернативной установке выбором режима Command Line Only.
(обратно)
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
уже в индивидуальном порядке.
(обратно)
•
выбору целевого носителя – если таковым выступает чистый диск, на нём будет автоматически создана разметка в стиле MSDOS; от принятой в прошлых версиях GPT-разметки нынче отказались;
•
назначению его загрузочным устройством или, напротив, отказу от этой возможности; последнее зело полезно, если какой-либо настроенный загрузчик уже имеется;
•
выбору так называемого типа устройства, каковых предусмотрено три – LVM (выбор по умолчанию), btrfs (выбор экспериментатора) и обычный раздел (выбор обычного применителя).
Далее проще всего положиться на автоматику (создание разделов на устройстве целиком или свободном пространстве) или полуавтоматику (автоматическое создание разделов с возможностью ручной коррекции разделов и изменения файловых систем). Не запрещается и полностью ручное создание разделов. Однако оно даёт не много бонусов: в частности, указание опций монтирования невозможно ни в одном случае. Нет и возможности размещения системы на программном RAID'е.
(обратно)
aptitude
, но применителю от этого легче не становится.
Иными словами, в координатах простота/функциональность на противоположных полюсах можно поместить современный инсталлятор Fedora (наиболее простой и самый бедный) и модуль YaST'а из openSUSE (относительно сложный – но исключительно в том случае, если есть необходимость использовать его бесподобный функционал на всё катушку). Графический же установщик Ubuntu займёт близэкваториальную зону между ними.
В заключение раздела ещё раз подчеркну следующие моменты.
Во-первых, когда я говорю о простоте или сложности установки объектов нашего сравнения, это следует понимать очень фигурально: все три равно просты в использовании – просто некоторых эта простота чуть-чуть «равнее».
Во-вторых, это относится и к богатству/бедности функционала: каждый из рассмотренных инсталляторов прекрасно справляется со своими обязанностями, просто некоторые делают это чуть прекрасней.
А в-третьих и главных, все рассуждения по первым двум пунктам имеют какое-то значение либо для совсем начинающих пользователей, либо для очень занятых применителей, которым некогда тратить время на разборки при инсталляции. Применитель же достаточно опытный, с одной стороны, и имеющий толику времени – с другой, каждый из этих дистрибутивов легко может превратить в индивидуализированную систему, хотя и несколько разными путями.
(обратно)
(обратно)
os
с предварением номера релиза и целевой архитектуры, и нет. И включает в себя официоз исключительно свободные программы в самом узком смысле.
Всё, что не поддерживается майнтайнерами, располагается в совершенно отдельном репозитории – rpmfusion
. Каковой в связи с этим разделяется на две части – free
и nonfree
. В первом – полностью свободные пакеты, собранные сообществом, но не удостоенные чести быть включенными в официоз. Во второй же вынесены как раз пакеты, распространяемые с теми или иными ограничениями.
На некоторых зеркалах репозиториев Fedora (например, зеркале Yandex'а) репозитории os
и rpmfusion
можно видеть в едином дереве каталогов. Но это сделано исключительно для удобства нас с вами – то есть граждан одной из (многочисленных) стран, законы которых не признают ограничений свободы распространения программ по патентному, например, признаку. Официально же RPM Fusion – отдельный проект, и разработчики Fedora делают вид, что его репозиторий не имеет к ним ни малейшего отношения.
Кстати, на зеркале Yandex'а можно увидеть и ещё один репозиторий, имеющий к официальному os
ещё меньше отношения, чем rpmfusion
– russianfedora
. Как нетрудно догадаться, он ведётся нашими соотечественниками и включает в себя в основном пакеты, учитывающие российскую специфику. К нему я ещё вернусь перед подведении итогов.
(обратно)
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), которые включают в себя всякого рода мультимедию с не всегдаопределённым (в некоторых отдельно взятых странах) юридическим статусом, и фирменные драйвера, отличающиеся спецификой распространения.
(обратно)
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-репозиториев часто критикуются за нестабильность, однако об этом надо сказать подробней.
(обратно)
rpmfusion
Fedora. Правда, в каждом случае уровень доказательности сводится к «у меня не встал» или «а у меня работает».
Так вот, все они столь же неправы, как и Энгельс с Каутским. Ибо дополнительные пакеты собираются конкретными майнтайнерами, и качество сборки, тестирование на стабильность и совместимость с системой в целом – дело их личной аккуратности. А поскольку одни люди в шахматы играют хорошо, а другие – похуже, то и пакеты могут быть собраны более или менее аккуратно. И никакие дистрибутивы не изменят этого соотношения сил.
Хотя я готов согласиться с тем, что вероятность нарваться на «кривой» пакет из PPA-репозитория несколько выше, чем из OBS, и ощутимо выше, чем из rpmfusion. Но объяснение этому очень простое: в PPA пакетов немного больше, чем в OBS, и существенно больше, чем в rpmfusion
.
(обратно)
rpmfusion
, эта процедура несколько проще. К тому же при установке Fedora с образов проекта Russian Fedora библиотеки рендеринга шрифтов, использующие патентованные алгоритмы, мультимедийные кодеки, проприетарные драйвера и тому подобная музыка устанавливается «искаропки».
В openSUSE, с её разветвлённой структурой репозиториев OBS и внешних external-репозиториев, дело обстоит чуть сложнее. Что, однако нивелируется высокоуровневыми средствами пакетного менеджмента, о чём будет рассказано своевременно. Причём средства эти можно задействовать уже при установке openSUSE в Live-режиме, с их помощью подключить любые дополнительные репозитории и поиметь с них (в том числе и) необходимую мультимедию, о чём говорилось ранее.
Замечу ещё, что применителю любого из сравниваемых дистрибутивов очень редко приходится иметь дело непосредственно со структурой репозиториев – это вахта систем управления пакетами. Хотя понимание её логики подчас оказывается полезным при поисках какой-либо экзотики. Однако тут выделить фаворита или аутсайдера невозможно – скорее это зависит от привычки.
Чисто теоретически самой логичной представляется структура репозиториев Fedora – за счёт чёткого отделения официоза от сообщака и агнцев свободы от козлищ проприетаризма. В Ubuntu обе границы проведены вполне волюнтаристически – и потому не всегда понятно, в какой из четырёх групп её главного репозитория следует искать нужный пакет, и не лежит ли он вообще в PPA-сообщаке. В openSUSE собственно официозная часть выделена очень чётко – однако за её пределами попадаешь в сложное переплетение полуофициоза, сообщака и экстернала. Хотя, раз в нём разобравшись, дальше в этих материях ориентируешься легко и непринуждённо. Впрочем, всё сказанное по поводу лёгкости и сложности – не более чем моё очень субъективное мнение.
(обратно)
russianfedora
(среди объектов настоящего сравнения, разумеется). И дело даже не в том, что он даёт возможность устанавливать мультимедийные кодеки или использовать патентованные методы рендеринга шрифтов «из коробки», хотя и это немаловажно. Главное, в рамках проекта Russian Fedora все баги, ущемляющие национальную гордость великороссов, выявляются мгновенно – и столь же мгновенно ликвидируются.
Конечно, такая же работа проводится и нашими соотечественниками – участниками проектов Ubuntu и openSUSE. Но она не координирована в рамках единых проектов, не сопровождается созданием специальных репозиториев, и результаты её далеко не всегда попадают в апстрим.
(обратно)
non-oss
просто довеском). А ветвь repositories
, хотя и имеет запутанную структуру, но – имеет; и при желании в её логике на так сложно разобраться.
Ubuntu оказывается на последнем месте заслуженно: во-первых, за волюнтаризм, проявленный при разделении базовых пакетов, во-вторых – за полное отсутствие структуры репозиториев PPA, в которых без поллитры Launcher'а не разобраться.
С точки зрения доступности репозиториев картина прямо противоположная: первое место присуждается Ubuntu за возможность доступа к дополнительным пакетам при инсталляции системы. На втором месте – openSUSE, в которой при установке определённым образом дополнительные репозитории прикрутить можно. На третьем месте, по понятным причинам, Fedora (тот самый случай, когда принципы вступают в противоречие с практикой).
Впрочем, с учётом запасного игрока из клубной команды – репозитория russianfedora, картина опять повернётся другим боком, и Fedora вполне может потягаться с Ubuntu за первую ступеньку пьедестала почёта. А поскольку мы живём в этой стране, единственное основание его не учитывать – низкопоклонство перед Западом и укоренившееся недоверие ко всему отечественному. Так что при таком раскладе openSUSE остаются глубоко... на третьей ступени.
По части полноты репозиториев необходимости в спорах нет: первое место принадлежит Ubuntu, второе – openSUSE, третье, и с большим отрывом – Fedora (даже с учётом запасного игрока). Впрочем, если ограничиться только базовой частью системы, можно считать, что победила дружба.
А вот по итогам многоборья первое место я присудил бы 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
. А вот с полуофициальными репозиториями они могут быть не согласованы по версиям.
(обратно)
•
установщики пакетов;
•
менеджеры пакетов;
•
их графические фронт-энды;
•
центры приложений.
С первой группой всё ясно – это низкоуровневые утилиты для работы с единичными пакетами, каковыми в нашем случае выступают самые обычные rpm для Fedora и openSUSE, и dpkg для Ubuntu. Сравнивать тут особенно нечего, по своим функциям они практически идентичны. Да и непосредственно применяются нынче редко – все обыденные манипуляции с пакетами обычно проще выполнять посредством менеджеров пакетов и их графических оболочек, которые и будут основным объектом дальнейшего сравнения.
Что же касается четвёртой группы – это самые высокоуровневые программы, в которых прозрачно для применителя интегрированы функции поиска пакетов в Сети, доступа к содержащим их репозиториями и собственно пакетный менеджмент.
(обратно)
•
в 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'у.
(обратно)
Последние комментарии
2 часов 45 минут назад
3 часов 2 минут назад
3 часов 23 минут назад
6 часов 5 минут назад
13 часов 28 минут назад
19 часов 12 минут назад