Алексей Федорчук
Итак, фронтирнейший дистрибутив Fedora включает в себя вполне такую фронтирную систему инициализации upstart
, что вроде бы обрекает последнюю на светлое будущее во всех дистрибутивах. И действительно, в виде опции она появляется в тестовой ветке консервативнейшего Debian’а, поговаривают о включении её в openSUSE (и вроде бы она промелькнула в какой-то из тестовых версий 10-го релиза).
Но что это за фронтирный дистрибутив, который довольствуется новшествами, написанными в дистрибутиве ином? Непорядок, который срочно должен быть исправлен. И весной 2010 года Леннарт Поттеринг, сотрудник Red Hat, ранее прославленный созданием аудиосервера PulseAudio, выступает с новой прогрессивной инициативой — системой инициализации по имени systemd
.
Сначала она имеет статус прототипа, к лету того же года обретает права 1-го релиза, а уже весной 2011 года оказывается в составе Fedora 15 — одновременно с GNOME 3, о котором говорилось ранее.
Коренных отличий systemd
от upstart
— два. Первое — ещё большее распараллеливание процедуры запуска стартовых служб за счёт полного отказа от их последовательного осуществления: сначала создаётся канал связи между зависящими друг от друга сервисами, а затем уже происходит их запуск.
И второе — большинство сервисов штатно запускается не shell-скриптами, а скомпилированными Си-программами. Хотя пока, в целях совместимости, не возбраняется и запуск сценариев, в том числе и самописных.
Чем это чревато для пользователя? Двумя обещаниями: во-первых, фантастического роста скорости загрузки системы, во-вторых, возможности гибкого управления уже запущенными сервисами. Здорово, правда? А давайте посмотрим, насколько здорово.
О том, насколько «важна» для пользователя ныне скорость загрузки системы — я уже говорил в прошлой заметке. Как и о том, что распространение SSD-накопителей вообще снивелирует разницу между любыми схемами инциализации, какие только хватит фантазии придумать.
Но предположим, что для нашего пользователя метрологические соображения (в данном случае не у кого орган длиньше, а у кого, наоборот, процесс короче) имеют высший приоритет: все мы люди, все мы человеки, и какой же русский не любит быстрой загрузки? Будут ли удовлетворены его амбиции?
Я не поленился, и провёл эксперимент. Благо, дистрибутив openSUSE, вслед за Fedora внедривший новую прогрессивную инициализацию, сохранил (в релизе 12.1 и в тестируемой версии будущего релиза 12.2) возможность лёгкого, безболезненного и обратимого отката с умолчального Systemd на SysVinit. Так вот, на ноутбуке с медленным HDD (5400 об./мин.) скорость загрузки при возврате sysvinit
не только не увеличилась, но даже уменьшилась на 9 (девять!) секунд (46 против 55 секунд, соответственно). Иными словами, systemd
проиграл старику-традиционалисту вчистую.
На значимости абсолютных цифр не настаиваю — тем более что с SSD на десктопе система в обоих случаях грузилась за равное, в пределах ошибки эксперимента, время (вот странно-то, да?). Но факт тот, что одно из декларируемых преимуществ systemd
над предшественниками напоминиает опять-таки старый анекдот о советстком устройстве, специально сделанном для попадания… ну сами знаете для попадания куда.
Что же до управления запущенными демонами… Возможно, это важно для системных администраторов — не являясь таковым, судить не берусь. Но вот что-то не припомню я пользователей, которые круглыми днями предаются этому занятию. И их активное взаимодействие с системой инциализации сводится обычно к правке нескольких параметров в конфигах для стартовых скриптов, и некоторым вполне тривиальным действиям в аварийных ситуациях.
А вот как раз с этим-то и может возникнуть напряжонка. Конечно, пока ещё при инциализации в стиле systemd
использование стартовых сценариев допускается. Но надолго ли хватит такого либерализма? В одном из своих сетевых заявлений Поттеринг обещал подготовить полностью shell-loss систему — и, возможно, уже выполнил это обещание.
У сторонников systemd
есть два, как им представляется, неубиенных аргумента в её защиту (кроме, разумеется, утверждения, что это система новая и потому уже хорошая по определению):
- докажи мне, что
systemd
плох (более мягкий вариант — покажи, в чём именно он плох); - сначала изучи
systemd
как следует, а потом говори о его недостатках.
Первый аргумент демонстрирует некоторую напряжёнку с логикой у его авторов. Не могу отказать себе в удовольствии процитировать высказывание Goodvin’а в одном из обсуждений на Юниксфоруме:
Согласно логике, бремя доказательства ложится на того, кто утверждает, что та или иная вещь или явление существуют, а не на том, кто в этом сомневается.
И далее вполне к месту упоминается знаменитый чайник Рассела.
В данном случае бременем доказательства сторонники systemd
себя не отягощают — более того, на все возражения типа того, что никакого профита пользователю он не даёт, следует повторение того же тезиса: докажи, что это плохо.
Хотя с точки зрения той же логики очевидно, что если что-то новое, мягко говоря, не лучше старого (а мы недавно видели, что, совсем мягко говоря, это так и есть) — то оно плохо уже этим. Ибо требует переучивания без адекватной отдачи.
Так что в данном случае мы имеем дело даже не с ошибкой в логике, а с самым банальным передёргиванием, которое так любят все гипермодернисты и революционеры. Их любимое занятие — пытаться поставить оппонента в положение оправдывающегося.
Вот второй аргумент, казалось бы, имеет под собой основания. Да, многие из тех, кто высказываются о systemd
… ээээ… недостаточно восторженно, не овладели со страшной силой знаниями по этому предмету (признаю, что автор этих строк — в их числе).
Однако второй аргумент легко опровергается отрицанием первого. Ибо нелепо тратить время и силы на изучение того нового, что ничуть не лучше существующего (и иcправно работающего) старого. Не говоря уже о том, что неизвестно, сколько времени это новое просуществует.
Некогда я затратил немало времени на ковыряние с файловой системой устройств в Linux (devfs) и HAL’ом в нём же. Последний, кстати, даже прикручивал, и вполне успешно, к FreeBSD. О потраченном времени не жалею — но возникает вопрос: и где теперь эти devfs и HAL? Брошены и погребены в одной могиле. И рядом с ней, возможно, заготовлено место и для upstart
.
С ней я, кстати, каюсь — тоже не разбирался. Ибо пока собирался это сделать — оказалось, что это никакой не последний писк прогресса, а сплошной ретроградный консерватизм (отстой, по простому). А все прогрессисты должны срочно кидаться на systemd
.
Вообще, стереотип поведения чукчи-хирурга, полосующего внутренности больного большим хирургическим скальпелем со словами
— Опять ничего не получилось!
весьма характерен для многих проектов Open Source, особенно связанных с Linux’ом: не доведя до ума имеющегося, всё бросать и создавать новый клон, форк, подсистему etc. Мир BSD этим грешит меньше: в частности, devfs, выскобленная и выглаженная, безотказно служит в ней по сей день.
Правда, в нынешней ситуации надежд, что для systemd
пора столбить участок по соседству с HAL’ом и devfs,весьма мало: уж очень тяжёлая артиллерия пущена в ход для поддержки, да и фланговое прикрытие имеет место быть. Но об этом мы поговорим на следующей странице.