Алексей Федорчук - Священные войны мира FOSS
Но я хотел коснуться возражений против следствия из резюме – что GNOME 3 оказался на текущий момент сдерживающим фактором десктопизации Fedora. Они тоже стандартны, и сводятся к старому детскому анекдоту:
– Мама, я не люблю дедушку... – Не нравится – не ещь!
А конкретней – это предложения:
• оставаться на GNOME 2;
• использовать GNOME 3 в режиме «второгномоподобия»;
• применять более иные рабочие среды.
Ну и без деклараций о свободе выбора и прочих идеологических материях тут уж было никак не обходится.
Но на самом деле всё оказывается не так просто. «Второгном» с выходом «третьегнома» можно смело зачислять в разряд того, что в биологии называют «живыми окаменелостями», вроде рыбы латимерии. Конечно, сам по себе он будет каким-то образом поддерживаться – хотя бы потому, что корпоративные клиенты Red Hat будут использовать его ещё многие годы. Будут существовать и форки – но опыт Trinity уже показал, что этот путь большого энтузиазма в массах не вызывает. Что же до режима «второгномподобия» – то его откровенная ущербность, вроде бы, сомнений ни у кого не вызвала.
А вот с более иными рабочими средами интересней. Казалось, бы – да, не тюрьма народов, «средь мира дольного для сердца вольного» есть и KDE, и XFce, и LXDE. Но это очередной случай того, что в реальности тоже не совсем так, как на самом деле. GNOME 2 в исполнении Fedora был привлекателен для начинающих пользователей и терпим для старых его нелюбителей (типа автора этих строк) своей доведённостью и интегрированностью с системными службами этого дистрибутива. А вот последнего заведомо и близко не лежало у LXDE, с этим были заметные напряги у XFce... ну разве что KDE более или менее, судя по отзывам, в этом отношении допилили.
И в итоге получается, что у Fedora, начиная с 15-го релиза, из колоды, на глазах весьма значительной категории пользователей, выпал весьма сильный козырь. А туз в прикупе, то есть GNOME 3, при ближайшем рассмотрении оказался даже не третьей дамой, а четвёртым валетом, играющим только при единственном раскладе у вистующих.
Что же, дядя Лёша, спросите вы меня, ты что, дяденек из Red Hat'а совсем уж за лохов держишь, которые ферзя от туза не отличают? Отнюдь – отвечу я вам. Дяди эти фишку просекают чётко, и мы скоро в этом убедимся. Но сначала нам надо рассмотреть ещё одно агрессивно продвигаемое новшество Fedora – не менее пресловутую, чем «третьегном»: systemd и связанные с ней материи.
Предстрастие к systemd
«Гномомстрасти», описанные в прошлой заметке, в основном уже отгорели. Хотя и поныне чуть ли не каждую неделю на Distrowatch'е можно видеть дистрибутивы (как правило, клоны Debian'а или Ubuntu) с GNOME 2 или вариациями на его темы в качестве десктопа по умолчанию. А вот страсти по очередной новинке, впервые увидевшей свет в составе Fedora, systemd, только разгораются. И причину их опять надо поискать в истории.
Как известно, исторически сложилось так, что Linux ассимилировал систему инциализации в стиле SysV, с главным процессом init и уровнями запуска (Runlevel) – наборами сценариев на разные случаи жизни. Замечу тут в скобках, что BSD-подобный стиль инициализации некоторых дистрибутивов Linux (Slackware, Gentoo, Arch, CRUX) – своего рода эвфемизм: от присутствия главного сценария инциализации и его конфига уровни запуска в них (свойственные Linux и отсутствующие в BSD-системах) никуда не исчезают.
Инициализации в стиле SysV – сто лет в обед, и время от времени у разработчиков возникало желание её усовершенствовать. Не то чтобы она вдруг в одночасье начала работать плохо. Но росло число устройств, росло количество обеспечивающих их работу стартовых скриптов – и все они запускались в конечном счёте через тот же процесс init, так что время загрузки всё возрастало. И появлялось стремление его сократить.
А сокращение времени загрузки было возможно двумя способами. Первый – это не грузить при старте машины заведомо ненужные сервисы. Но это та земля, где каждый умирает в одиночку. И таким путём проблема могла быть решена только в индивидуальном порядке. Системное же её решение – это параллельный запуск тех сервисов, которые не зависят друг от друга.
Есть, конечно, ещё и третий способ – загрузка графической среды и системы авторизации до окончания работы сценариев инициализации, как это сделано в Windows. Но это создаёт лишь иллюзию ускорения процесса загрузки. Хотя, с точки зрения конечного пользователя, даёт чисто психологический эффект быстроты.
Маленькое отступление про скорость загрузки. Я скромно имхую, что эта материя лежит в сфере не программирования и вообще компьютерных технологий, а исключительно метрологии. Как это было сказано в старом анекдоте про психоаналитиков:
Коллеги, мы же профессионалы. Давайте просто расстегнём штаны и померяем.
Так и время загрузки есть объект для сравнительного измерения при форумных дискуссиях. Практический смысл его сокращения стремится к нулю. Ибо при стационаром использовании в рабочем (не развлекательном!) режиме для персонального компьютера норма – одна загрузка в сутки, а то и реже. И кустарём-надомником это время тратится на совершение утреннего туалета, а офисным работником – на обмен приветствиями с коллегами, первую рабочую сигарету etc. А старт любой более-менее современной машины, пусть и перегруженной сервисами по самые... уши, всё равно пройдёт быстрее, чем эти увлекательные занятия.
Конечно, в мобильном режиме расклад иной – классический пример с коммивояжёром, демонстрирующим свои товары потенциальному клиенту, я слышу уже лет 20 как минимум. Однако в этом случае важна не абстрактная скорость загрузки машины, а приведение её в боевую готовность – включая запуск всех необходимых приложений и их данных, причём подчас с совершенно определённого места. И потому резонные люди в таких условиях не занимаются вылавливанием лишнего стартового демона, а применяют всякого рода спящие и ждущие режимы.
Возражение на счёт серверов ынтырпрайз-сферы, когда каждая секунда простоя способна принести научно-фантастические убытки, тоже старо, как мир. И столь же обосновано. Ибо если тот, чей бизнес зависит от бесперебойной работы компьютерных сетей, не озаботился заранее дублирующими серверами, резервными источниками электроэнергии и так далее, то он сам себе очень злобный буратино. Ну а при глобальных форс-мажорах, типа веерных отключений по всему штату/области/раену, как правило, не так важно, восстановится ли работоспособность одного отдельно взятого сервера через 24 часа 55 минут или через 24 часа, 55 минут и ещё 45 секунд.
В настоящее же время понятие скорости загрузки вообще утрачивает физический смысл. Это связано с постепенным распространением SDD-накопителей, по крайней мере, в качестве носителей для системы и приложений. Скорость чтения с них на порядок превышает таковую для традиционных HDD. И на этом фоне время запуска стартовых служб становится исчезающе малым.
Сужу по своему опыту. Через мои руки прошло два SSD Corsair с интерфейсами SATA II и SATA III, и выполненный в виде платы PCI-E OCZ Revo Drive. Все дистрибутивы, которые у меня были в то же время (Fedora, PCLinuxOS, openSUSE) грузились с любого из них примерно за 20 секунд – из них всё мало-мальски уловимое время уходило на поиск DNS-сервера и синхронизацию по NTP, а собственно процесс инициализации, вне зависимости от схемы её (классический init, upstart или systemd, о которых скоро зайдёт речь) занимал какие-то мгновения.
Скажу больше: нынче и с традиционного HDD система подчас грузится за меньшее время, нежели уходит на процедуру POST при включении машины – особенно на «навороченных» материнских платах. После таких наблюдений любые разговоры о «проблеме скорости загрузки» могут восприниматься только в юмористическом ключе.
Не, я не к тому, что не надо стремиться к сокращению времени загрузки, напротив – это как выпить всю водку и перецеловать всех женщин: цель недостиживая, но, как сказал некогда наш Президент, стремиться к ней нужно.
В старые добрые времена классического SysVinit отлов лишних стартовых сервисов являл собой увлекательное занятие, немало способствующее, к тому же, общему образованию. А построение схемы распараллеливания стартовых процессов, вероятно, очень неплохая гимнастика ума – нечто вроде интеллектуального преферанса, как выражается мой старый товарищ Владимир Попов.
Не случайно, когда несколько лет назад проблема ускорения загрузки вдруг стала актуальной (или показалось, что стала таковой), практически одновременно было разработано несколько «параллельных» альтернатив классическому init'у: runit, daemontools, initng. Была даже попытка портировать на Linux систему инициализации MacOS X – launchd. Правда, некоторую известность из них приобрёл, пожалуй, только initng. Однако и он, насколько я знаю, не прижился даже в родном дистрибутиве – в Gentoo.
