systemd е на 10 години, но чувствата към него в Linux общността не са се смекчили — сега е толкова разделящ, колкото и винаги. Въпреки че се използва от много големи дистрибуции на Linux, хардкорната опозиция не отстъпи.
Съдържание
Последователността на зареждане на Linux
Когато включите компютъра, хардуерът се зарежда и след това (според вида на зареждащ сектор вашият компютър използва) или основен запис за зареждане (MBR) изпълнява или Единен разширяем интерфейс на фърмуера (UEFI) работи. Последното действие и на двете е да запалите Linux ядро.
Ядрото се зарежда в паметта, декомпресира се и се инициализира. А временна файлова система се създава в RAM, обикновено от помощна програма, наречена initramfs или initrd. Това позволява да се определят и зареждат необходимите драйвери. Това от своя страна позволява на файловата система на потребителското пространство да се зареди и подготви за установяване на средата на потребителското пространство.
Създаването на средата на потребителското пространство се обработва от процеса init, който е първият процес, стартиран от ядрото в потребителско пространство. Има ID на процеса (PID) от 1. Всички други процеси са или преки, или косвени деца на процеса init.
Преди systemd, основното по подразбиране за процеса init беше преработка на Unix System V инициал. Имаше и други налични възможности, но System V init беше стандартната опция в повечето не-Разпространение на софтуер Berkeley (BSD) извлечени дистрибуции. Тъй като идва директно от System V Unix – духовния прародител на Linux – много хора го смятат за „официален начин“ за извършване на init.
Процесът на инициализиране стартира всички демони и услуги, необходими, за да накарат операционната система да работи по смислен и интерактивен начин. Тези демони се справят с неща като мрежовия стек, активиране на друг хардуер във вашия компютър и осигуряване на екран за зареждане.
Много от тези фонови процеси продължават да се изпълняват и след като са започнали. Те правят неща като информация за регистриране на събития, следят за промени в хардуера, докато поставяте или премахвате устройства, и управляват влизанията на потребители. Не е изненадващо, че системата init включва и функции за управление на услуги.
Можем да използваме п.с за да видите процеса, който има PID 1. Ще използваме опциите f (списък с пълен формат) и p (PID):
ps -fp 1
Виждаме, че процесът с PID 1 е systemd. Изпълнението на същата команда на Manjaro Linux даде различен резултат. Процесът с PID 1 беше идентифициран като /sbin/init. Бърз преглед на този файл показва, че е символична връзка към systemd:
ps -fp 1
ls -hl /sbin/init
Използвайки опцията ppid (ID на родителския процес) с ps, можем да видим кои процеси са били директно стартирани от systemd:
ps -f --ppid 1
Това е доста дълъг списък, както можете да видите на изображението по-долу.
Алтернативите
Няколко проекта са се опитали да създадат алтернатива на традиционната System V init. Един от основните проблеми е, че при System V init всички процеси се стартират последователно, един след друг. За да подобрят ефективността на последователността на зареждане, много алтернативни проекти използват паралелизъм за стартиране на процеси едновременно и асинхронно.
Ето малко информация за някои от тях:
първенец: Разработено от Каноничен, беше използван в Ubuntu 9.10, червена шапка, Red Hat Enterprise Linux (RHEL) 6, CentOS 6 и Fedora 9.
Runit: Работи FreeBSD и други производни на BSD, macOS и Соларис, както и Linux системи. Също така е включена системата за иницииране по подразбиране Празно Linux.
s6-linux-init: Този заместител на System V init е проектиран да следва отблизо Unix философия, което често се свежда до звука „направи едно нещо и го направи добре“.
Има много други с различна функционалност и дизайн. Нито един от тях обаче създаде фурора systemd го направи.
Пътят на системата
systemd беше пуснат през 2010 г. и беше използван във Fedora през 2011 г. Оттогава той беше приет от много дистрибуции. Тя е разработена от Ленарт Потеринг и Кей Сивърс, двама софтуерни инженери в RedHat.
systemd е много повече от заместител на init. По-скоро това е пакет от приблизително 70 двоични файла, които обработват инициализацията на системата, демони и услуги, регистриране и журналиране и много други функции, които вече са били обработвани от специални модули в Linux. По-голямата част от тях нямат нищо общо с инициализацията на системата.
Някои от демоните, предоставени от systemd, са:
systemd-udevd: Управлява физически устройства.
systemd-logind: Управлява влизанията на потребители.
systemd-resolved: Предоставя разделителна способност на мрежови имена на локални приложения.
systemd-networkd: Управлява и открива мрежови устройства и управлява мрежовите конфигурации.
systemd-tmpfiles: Създава, изтрива и почиства летливи и временни файлове и директории.
systemd-localed: Управлява настройките за локал на системата.
systemd-machined: Открива и наблюдава виртуални машини и контейнери.
systemd-nspawn: Може да стартира команда или друг процес в олекотен контейнер на пространството от имена, предоставяйки функционалност, подобна на chroot.
И това е само върхът на айсберга, който е и същността на въпроса. systemd отдавна е изпреварил това, което се изисква от система за инициализиране, което, според неговите опоненти, е самото определение за пълзящ обхват.
„Твърде голям е. Прави твърде много.”
Противниците на systemd посочват големия, любопитен микс от функционалност, която обхваща. Всички тези функции вече съществуваха в Linux и може би някои от тях се нуждаеха от опресняване или нов подход. Въпреки това, обединяването на цялата тази функционалност в това, което се предполага, че е система за иницииране, е архитектурно озадачаващо.
systemd е наречена единична точка на отказ за твърде много критични функции, но това изглежда не е оправдано. Разбира се, хвърля Unix философия за създаване на малки инструменти, които работят заедно вместо големи парчета софтуер, които правят всичко извън прозореца. Въпреки че systemd не е строго монолитен (състои се от много двоични файлове, а не от един огромен), той включва много различни инструменти за управление и команди под един чадър.
Въпреки че може да не е монолитен, той е голям. За да добием представа за мащаба, преброихме редовете текст в кодовата база на ядрото 5.6.15 и главния клон на systemd на хранилището на GitHub.
Това беше сравнително груб показател. Той брои редове текст, а не само редове код. И така, това включва коментари, документация и всичко останало. Въпреки това, това беше подобно сравнение и ни даде прост критерий:
( find ./ -name '*.*' -print0 | xargs -0 cat ) | wc -l
Ядрото имаше близо 28 милиона (27 784 340, за да бъдем точни) реда текст. За разлика от тях, systemd имаше 1 349 969, или почти 1,4 милиона. С нашата метрика за късмет, systemd излиза с около 5 процента от размера на ядрото, което е лудост!
Като друго сравнение, броят на редовете за модерна реализация на System V init за дистрибуцията на Arch Linux достигна 1721 реда.
Поетерингът явно не се съобразява с Институт за инженери по електротехника и електроника (IEEE) Компютърното общество, нито Интерфейс за преносима операционна система (POSIX) стандарт. Всъщност той насърчава разработчиците да игнорират POSIX:
„И така, вземете си копие на Linux Programming Interface, игнорирайте всичко, което пише за съвместимостта с POSIX, и хакнете невероятния си софтуер за Linux. Това е доста облекчаващо!”
Имаше обвинения, че systemd е проект на Red Hat, който е от полза само за Red Hat, но все пак се предава насилствено в по-широкия свят на Linux. Да, той е роден в Red Hat и се управлява и управлява от него. Въпреки това, от 1321 участници, само малка част работи за Red Hat.
И така, какви са ползите от Red Hat?
Джим Уайтхърст, президентът на IBM, който беше веднъж главният изпълнителен директор на Red Hat каза:
„Red Hat разгледа много налични опции и дори използва Upstart на Canonical за Red Hat Enterprise Linux 6. В крайна сметка избрахме systemd, защото това е най-добрата архитектура, която осигурява разширяемост, простота, мащабируемост и добре дефинирани интерфейси за справяне с проблемите, които виждаме днес и предвиди в бъдещето.“
Уайтхърст също каза, че виждат предимства и във вградените системи. Red Hat си партнира с „най-големите доставчици на вградени системи в света, особено в телекомуникационната и автомобилната индустрия, където стабилността и надеждността са приоритет номер едно“.
Това изглеждат технически основателни причини. Можете да разберете нуждата на компанията от надеждност и не е неразумно Red Hat да се грижи за собствените си интереси, но трябва ли всички останали да последват примера?
Пиете systemd Kool-Aid?
Някои противници на systemd казват, че дистрибуциите и хората просто сляпо следват примера на Red Hat и го възприемат.
Въпреки това, точно като фразата „пиене на Kool-Aid“, това не е съвсем правилно. Измислен през 1978 г. след това култовият лидер Джим Джоунс, принуди своите над 900 последователи да се самоубият, като изпият течност с вкус на грозде, напълнена с цианид, фразата неправилно срамува Kool-Aid. Групата всъщност пиеше Flavor Aid, но оттогава Kool-Aid е намазан от тази четка.
Плюс това, Linux дистрибуциите не следват сляпо Red Hat; те приемат systemd след сериозно обмисляне. Дебатът бушува на Debian пощенски списъци за дълго време. Въпреки това, през 2014 г. общността гласува да приеме systemd като система за инициализиране по подразбиране, но също така да поддържа алтернативи.
Debian е важен пример, защото не е извлечен от RedHat, Fedora или CentOS. Към Debian не се прилага управление от Red Hat. И Debian, подобно на PID 1, има много потомци, включително Ubuntu и многобройните му отделни продукти.
Решенията, взети от общността на Debian, са широкообхватни. Те също са енергично обсъждани и гласувани за използването им методът на гласуване по Кондорсе. Обществото също не прави този избор с лека ръка.
Той гласува отново през декември 2019 г да продължи да се фокусира върху systemd и да продължи да проучва алтернативи. Обратното на сляпото следване, това всъщност е хрестоматиен пример за демокрация и свобода на избор на работа.
Ограниченията на избора
Обикновено не можете да избирате дали да използвате systemd с конкретна Linux дистрибуция. По-скоро самите дистрибуции избират дали искат да го използват и вие можете да изберете коя Linux дистрибуция предпочитате. Може би една Linux дистрибуция, която обичате, е преминала към systemd. Подобно на любим музикант, който сменя жанровете, това може да бъде смущаващо.
Хората, които използват Debian, Fedora, CentOS, Ubuntu, арх, Solus, и openSUSE, и възразяват срещу приемането на systemd, може да почувстват, че са изгонени от използването на тяхното разпространение на избор. Ако се чувстват достатъчно силно за някой от архитектурните избори, измъкване на обхвата или пренебрегване на POSIX, може да намерят за несъстоятелно да продължат да използват тази дистрибуция.
Има спектър, разбира се. От единия край имате хора, които не разбират проблемите (или дори не им пука), а от другия имате страстни възражения. Някъде по средата са тези, които не обичат промените, но не се притесняват достатъчно, за да скочат кораба. Но какво да кажем за бежанците от разпределението, които не могат да останат на избраното от тях разпределение поради своите предпочитания или принципи?
За съжаление, не е толкова лесно, колкото просто да инсталирате каквато и инициална система искате. Не всеки има техническата способност да направи това, без значение трудностите, които възникват, когато приложения или настолни среди, като GNOME, имат зависимости от systemd.
Какво ще кажете за преминаването към друга дистрибуция? Някои, като Девуан, се появи като несистемни разклонения на дистрибуции (в този случай Debian), които са приели systemd. Използването на Devuan трябва да е подобно на родителската дистрибуция, но това не е така за всички не-системни разклонения. Например, ако напуснете Fedora и преминете към AntiX, Gentoo, или Slackware, ще имате много различно преживяване.
Не отива никъде
Харесвам някои от това, което systemd прави (прости и стандартизирани механизми за контрол на процесите). Не разбирам обосновката за някои от това, което прави (двоични регистрационни файлове). Също така не харесвам някои от това, което прави (обновяване на домашни папки – кой поиска това?).
Дистрибуции като Debian правят умното нещо и проучват алтернативи, за да запазят възможностите си отворени. Въпреки това, systemd е в него за дълго време.
Ако администрирате Linux машини за други, научете systemd, както знаете System V init. По този начин, независимо с какво се сблъскате, ще можете да изпълнявате задълженията си.
Просто да използвате Linux у дома? Ако е така, изберете дистрибуция, която едновременно отговаря на вашите технически нужди и допълва вашата Linux идеология.