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

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

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

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

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

Не случайно, когда несколько лет назад проблема ускорения загрузки вдруг стала актуальной (или показалось, что стала таковой), практически одновременно было разработано несколько «параллельных» альтернатив классическому init'у: runit, daemontools, initng

. Была даже попытка портировать на Linux систему инициализации MacOS X – launchd. Правда, некоторую известность из них приобрёл, пожалуй, только initng. Однако и он, насколько я знаю, не прижился даже в родном дистрибутиве – в Gentoo.

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

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

, как прогрессивная, была включена... куда? Разумеется, в самый фронтирный дистрибутив своего времени, в Fedora 9-го релиза.

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

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

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

Страсти по systemd

Итак, фронтирнейший дистрибутив Fedora включает в себя вполне такую фронтирную систему инициализации upstart

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

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

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

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

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

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