systemd er 10 år gammel, men følelserne omkring det i Linux-fællesskabet er ikke blevet blødere – det er lige så splittende nu, som det nogensinde har været. Selvom det bruges af mange store Linux-distributioner, har hardcore-oppositionen ikke givet efter.
Indholdsfortegnelse
Linux Boot Sequence
Når du tænder for din computer, starter hardwaren, og derefter (i henhold til typen af boot sektor din computer bruger) enten master boot record (MBR) udfører eller Unified Extensible Firmware Interface (UEFI) kører. Den sidste handling af begge disse er at fyre op Linux kerne.
Kernen indlæses i hukommelsen, dekomprimerer sig selv og initialiseres. EN midlertidigt filsystem er oprettet i RAM, normalt af et hjælpeprogram kaldet initramfs eller initrd. Dette gør det muligt at bestemme og indlæse de nødvendige drivere. Dette gør det igen muligt for brugerpladsfilsystemet at indlæse og forberede sig på at etablere brugerrumsmiljøet.
Oprettelsen af brugerrumsmiljøet håndteres af init-processen, som er den første proces, der startes af kernen i et brugerrum. Den har en proces-id (PID) på 1. Alle andre processer er enten direkte eller indirekte børn af init-processen.
Før systemd var den almindelige standard for init-processen en omarbejdning af Unix System V init. Der var andre valgmuligheder, men System V init var standardindstillingen i de fleste ikke-Berkeley Software Distribution (BSD) afledte distributioner. Fordi det kom direkte fra System V Unix – den spirituelle forfader til Linux – betragter mange mennesker det som “den officielle måde” at gøre det på.
Init-processen starter alle dæmoner og tjenester, der kræves for at få operativsystemet til at fungere på en meningsfuld, interaktiv måde. Disse dæmoner håndterer ting som netværksstakken, aktiverer anden hardware inde i din computer og giver en opstartsskærm.
Mange af disse baggrundsprocesser fortsætter med at køre, efter de er startet. De gør ting som at logge begivenhedsoplysninger, holde øje med hardwareændringer, når du indsætter eller fjerner enheder, og administrerer brugerlogin. Ikke overraskende inkluderer init-systemet også funktioner til at administrere tjenester.
Vi kan bruge ps for at se processen, der har PID 1. Vi bruger mulighederne f (fuldformatliste) og p (PID):
ps -fp 1
Vi ser, at processen med PID 1 er systemd. At køre den samme kommando på Manjaro Linux gav et andet resultat. Processen med PID 1 blev identificeret som /sbin/init. Et hurtigt kig på filen viser, at det er et symbolsk link til systemd:
ps -fp 1
ls -hl /sbin/init
Ved at bruge ppid (overordnet proces-id) mulighed med ps kan vi se, hvilke processer der er blevet direkte lanceret af systemd:
ps -f --ppid 1
Det er en ret lang liste, som du kan se på billedet nedenfor.
Alternativerne
Flere projekter har forsøgt at producere et alternativ til det traditionelle System V init. Et af hovedproblemerne er, med System V init, at alle processer startes serielt, en efter en. For at forbedre effektiviteten af opstartssekvensen bruger mange alternative projekter parallelisme til at starte processer samtidigt og asynkront.
Her er nogle oplysninger om nogle af disse:
Opkomling: Udviklet af Kanonisk, det blev brugt i Ubuntu 9.10, rød hat, Red Hat Enterprise Linux (RHEL) 6, CentOS 6, og Fedora 9.
Kør det: Kører videre FreeBSD og andre BSD-derivater, macOS og Solaris, samt Linux-systemer. Det er også standard init-systemet på Ugyldig Linux.
s6-linux-init: Denne erstatning for System V init er designet til nøje at følge Unix filosofi, som ofte reduceres til lyden “gør én ting, og gør det godt.”
Der er mange andre med forskellig funktionalitet og design. Dog ingen af dem skabte furore systemd gjorde.
Den systemiske måde
systemd blev udgivet i 2010 og blev brugt i Fedora i 2011. Siden da er det blevet adopteret af mange distributioner. Den er udviklet af Lennart Poettering og Kay Sievers, to softwareingeniører hos RedHat.
systemd er meget mere end en init-erstatning. Det er snarere en pakke med cirka 70 binære filer, der håndterer systeminitialisering, dæmoner og tjenester, logning og journalføring og mange andre funktioner, der allerede blev håndteret af dedikerede moduler i Linux. Hovedparten af disse har intet at gøre med systeminitialisering.
Nogle af dæmonerne leveret af systemd er:
systemd-udevd: Styrer fysiske enheder.
systemd-logind: Administrerer brugerlogin.
systemd-resolved: Giver opløsning af netværksnavne til lokale applikationer.
systemd-networkd: Administrerer og registrerer netværksenheder og administrerer netværkskonfigurationer.
systemd-tmpfiles: Opretter, sletter og rydder op i flygtige og midlertidige filer og mapper.
systemd-localed: Administrerer systemindstillinger for lokalitet.
systemd-machined: Registrerer og overvåger virtuelle maskiner og containere.
systemd-nspawn: Kan starte en kommando eller anden proces i en letvægts navnerumsbeholder, hvilket giver en funktionalitet svarende til chroot.
Og det er kun toppen af isbjerget, som også er sagens kerne. systemd har for længst overgået, hvad der kræves af et init-system, som ifølge dets modstandere er selve definitionen af scope creep.
“Den er for stor. Det gør for meget.”
Modstandere af systemd påpeger den store, nysgerrige blanding af funktionalitet, det omfatter. Alle disse funktioner eksisterede allerede i Linux, og nogle af dem trængte måske til en opfriskning eller en ny tilgang. Men at samle al denne funktionalitet i, hvad der formodes at være et init-system, er arkitektonisk forvirrende.
systemd er blevet kaldt et enkelt fejlpunkt for for mange kritiske funktioner, men dette ser ikke ud til at være forsvarligt. Ganske vist kaster det Unix filosofi at skabe små værktøjer, der arbejder sammen i stedet for store stykker software, der gør alt ud af vinduet. Selvom systemd ikke er strengt monolitisk (det består af mange binære filer snarere end en enkelt enorm), inkluderer den en masse forskellige administrationsværktøjer og kommandoer under én paraply.
Selvom det måske ikke er monolitisk, er det stort. For at få en idé om skala talte vi tekstlinjerne i kerne 5.6.15-kodebasen og systemd-mastergrenen af GitHub-lageret.
Dette var et relativt råt mål. Det talte tekstlinjer, ikke kun kodelinjer. Så dette inkluderede kommentarer, dokumentation og alt muligt andet. Det var dog en lignende sammenligning og gav os en simpel målestok:
( find ./ -name '*.*' -print0 | xargs -0 cat ) | wc -l
Kernen havde næsten 28 millioner (27.784.340, for at være præcis) tekstlinjer. Derimod havde systemd 1.349.969, eller næsten 1,4 mio. Med vores happy-go-lucky-metrik kommer systemd ud på omkring 5 procent af kernens størrelse, hvilket er vanvittigt!
Som en anden sammenligning var linjeantallet for en moderne implementering af System V init til Arch Linux-distributionen 1.721 linjer.
Poettering tager tydeligvis ingen hensyn til Institut for Elektro- og Elektronikingeniører (IEEE) Computer Society, ej heller Bærbart operativsystemgrænseflade (POSIX) standard. Faktisk han opfordrede udviklere til at ignorere POSIX:
“Så skaf dig en kopi af Linux-programmeringsgrænsefladen, ignorer alt, hvad der står om POSIX-kompatibilitet, og hack din fantastiske Linux-software væk. Det er ret befriende!”
Der har været beskyldninger om, at systemd er et Red Hat-projekt, der kun gavner Red Hat, men alligevel bliver det tvangsfodret til den bredere Linux-verden. Ja, den blev født i Red Hat og styres og styres af den. Men af de 1.321 bidragydere er det kun en brøkdel, der arbejder for Red Hat.
Så hvad er fordelene ved Red Hat?
Jim Whitehurst, præsidenten for IBM, som var engang sagde Red Hats administrerende direktør:
“Red Hat overvejede mange tilgængelige muligheder og brugte endda Canonicals Upstart til Red Hat Enterprise Linux 6. I sidste ende valgte vi systemd, fordi det er den bedste arkitektur, der giver udvidelsesmuligheder, enkelhed, skalerbarhed og veldefinerede grænseflader til at løse de problemer, vi ser. i dag og forudse i fremtiden.”
Whitehurst sagde også, at de også så fordele ved indlejrede systemer. Red Hat samarbejder med “de største embedded-leverandører i verden, især i telekommunikations- og bilindustrien, hvor stabilitet og pålidelighed er den største bekymring.”
Disse virker som teknisk forsvarlige grunde. Du kan forstå virksomhedens behov for pålidelighed, og det er ikke urimeligt, at Red Hat varetager sine egne interesser, men skal alle andre følge trop?
Drikker du den systemd Kool-Aid?
Nogle modstandere af systemd siger, at distributioner og folk bare blindt følger Red Hats ledetråd og adopterer det.
Men ligesom sætningen “at drikke Kool-Aid”, er det ikke helt rigtigt. Opfundet i 1978 efter kultleder, Jim Jones, tvang sine over 900 tilhængere til at begå selvmord ved at drikke en væske med druesmag fyldt med cyanid, sætningen skammer Kool-Aid forkert. Gruppen drak faktisk Flavor Aid, men Kool-Aid har været tjæret af den børste lige siden.
Plus, Linux-distributioner følger ikke blindt Red Hat; de vedtager systemd efter seriøse overvejelser. Debatten rasede på Debian postlister i lang tid. Men i 2014 stemte samfundet for at vedtage systemd som standard init-system, men også for at understøtte alternativer.
Debian er et vigtigt eksempel, fordi det ikke er afledt af RedHat, Fedora eller CentOS. Der er ingen styring på Debian fra Red Hat. Og Debian har ligesom PID 1 mange efterkommere, inklusive Ubuntu og dets mange spin-offs.
Beslutninger truffet af Debian-fællesskabet er vidtrækkende. De er også heftigt debatteret og stemt om at bruge Condorcet-stemmemetoden. Samfundet træffer heller ikke sådanne valg let.
Det stemte igen i december 2019 at fortsætte med at fokusere på systemd og fortsætte med at udforske alternativer. Det modsatte af at følge blindt, dette er faktisk et lærebogseksempel på demokrati og valgfrihed på arbejdspladsen.
Valgets begrænsninger
Du kan generelt ikke vælge, om du vil bruge systemd med en bestemt Linux-distribution. Tværtimod vælger distributionerne selv, om de vil bruge det, og du kan vælge, hvilken Linux-distro du foretrækker. Måske skiftede en Linux-distribution, du elsker, til systemd. Ligesom en yndlingsmusiker, der skifter genre, kan dette være rystende.
Folk der bruger Debian, Fedora, CentOS, Ubuntu, Arch, Solus, og openSUSE, og protesterer mod vedtagelsen af systemd, kan føle, at de er ved at blive ude af at bruge deres valgfri distribution. Hvis de føler stærkt nok omkring nogen af de arkitektoniske valg, omfangskryb eller tilsidesættelse af POSIX, kan de finde det uholdbart at blive ved med at bruge denne distribution.
Der er selvfølgelig et spektrum. I den ene ende har du de mennesker, der ikke forstår problemerne (eller endda bekymrer sig), og i den anden ende har du de passionerede modstandere. Et sted i midten er dem, der ikke kan lide forandringer, men ikke er generet nok af det til at springe skib. Men hvad med fordelingsflygtningene, som på grund af deres præferencer eller principper ikke kan blive på deres valgte fordeling?
Desværre er det ikke så nemt som bare at installere hvilket init-system du ønsker. Ikke alle har den tekniske evne til at gøre det, uanset de vanskeligheder, der opstår, når applikationer eller skrivebordsmiljøer, såsom GNOME, har afhængigheder af systemd.
Hvad med at flytte til en anden distribution? Nogle, som Devuan, dukkede op som ikke-systemd-gafler af distributioner (i dette tilfælde Debian), der havde adopteret systemd. Brug af Devuan burde svare til forældredistributionen, men det er ikke tilfældet for alle ikke-systemd-gafler. For eksempel, hvis du forlader Fedora og flytter til AntiX, Gentoo, eller Slackware, vil du få en meget anderledes oplevelse.
Det går ingen vegne
Jeg kan godt lide noget af det systemd gør (enkle og standardiserede kontrolmekanismer for processer). Jeg forstår ikke begrundelsen for noget af det, det gør (binære logfiler). Jeg kan også ikke lide noget af det, det gør (fornyelse af hjemmemapper – hvem bad om det?).
Distributioner som Debian gør det smarte og undersøger alternativer for at holde dets muligheder åbne. Systemd er dog i det i det lange løb.
Hvis du administrerer Linux-maskiner for andre, skal du lære systemd lige så godt, som du kender System V init. På denne måde, uanset hvad du støder på, vil du være i stand til at udføre dine opgaver.
Bruger du bare Linux derhjemme? Hvis ja, så vælg en distribution, der både opfylder dine tekniske behov og komplementerer din Linux-ideologi.