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

Но предположим, что для нашего пользователя метрологические соображения (в данном случае не у кого

орган

длиньше, а у кого, наоборот,

процесс

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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