Warum Linux nach all den Jahren immer noch spaltet

systemd ist 10 Jahre alt, aber die Gefühle in der Linux-Community haben sich nicht beruhigt – es ist jetzt so spaltend wie eh und je. Obwohl es von vielen großen Linux-Distributionen verwendet wird, hat die Hardcore-Opposition nicht nachgelassen.

Die Linux-Startsequenz

Wenn Sie Ihren Computer einschalten, bootet die Hardware und dann (je nach Typ des Bootsektors, den Ihr Computer verwendet) wird entweder der Master Boot Record (MBR) oder das Unified Extensible Firmware Interface (UEFI) ausgeführt. Die letzte Aktion von beiden besteht darin, den Linux-Kernel zu starten.

Der Kernel wird in den Speicher geladen, dekomprimiert und initialisiert. Ein temporäres Dateisystem wird im RAM erstellt, normalerweise von einem Dienstprogramm namens initramfs oder initrd . Dadurch können die benötigten Treiber ermittelt und geladen werden. Dies wiederum erlaubt dem User-Space-Dateisystem, die User-Space-Umgebung zu laden und sich darauf vorzubereiten, die User-Space-Umgebung aufzubauen.

Die Erstellung der User-Space-Umgebung wird vom Init-Prozess abgewickelt, der der erste Prozess ist, der vom Kernel in einem User-Space gestartet wird. Er hat eine Prozess-ID (PID) von 1. Alle anderen Prozesse sind entweder direkte oder indirekte Kinder des init-Prozesses.

Vor systemd war der Mainstream-Standard für den Init-Prozess eine Überarbeitung des Unix-Systems V init. Es gab andere Möglichkeiten, aber System V init war die Standardoption in den meisten nicht von Berkeley Software Distribution (BSD) abgeleiteten Distributionen. Da es direkt von System V Unix – dem geistigen Vorfahren von Linux – stammt, betrachten viele Leute es als „den offiziellen Weg“, um Init durchzuführen.

Der Init-Prozess startet alle Daemons und Dienste, die erforderlich sind, damit das Betriebssystem sinnvoll und interaktiv funktioniert. Diese Daemons handhaben Dinge wie den Netzwerkstapel, aktivieren andere Hardware in Ihrem Computer und stellen einen Startbildschirm bereit.

Viele dieser Hintergrundprozesse laufen nach dem Start weiter. Sie erledigen Dinge wie das Protokollieren von Ereignisinformationen, achten auf Hardwareänderungen, wenn Sie Geräte einfügen oder entfernen, und verwalten Benutzeranmeldungen. Es überrascht nicht, dass das Init-System auch Funktionen zum Verwalten von Diensten enthält.

Wir können ps verwenden, um den Prozess mit PID 1 anzuzeigen. Wir verwenden die Optionen f (vollständige Auflistung) und p (PID):

 ps -fp 1 

Wir sehen, dass der Prozess mit PID 1 systemd ist. Das Ausführen desselben Befehls unter Manjaro Linux führte zu einem anderen Ergebnis. Der Prozess mit PID 1 wurde als /sbin/init identifiziert. Ein kurzer Blick auf diese Datei zeigt, dass es sich um einen symbolischen Link zu systemd handelt:

 ps -fp 1

 ls -hl /sbin/init 

Mit der Option ppid (Parent Process ID) mit ps können wir sehen, welche Prozesse direkt von systemd gestartet wurden:

 ps -f --ppid 1 

Es ist eine ziemlich lange Liste, wie Sie im Bild unten sehen können.

Die Alternativen

Mehrere Projekte haben versucht, eine Alternative zum traditionellen System V init zu entwickeln. Eines der Hauptprobleme besteht darin, dass bei System V-Init alle Prozesse seriell nacheinander gestartet werden. Um die Effizienz der Startsequenz zu verbessern, verwenden viele alternative Projekte Parallelität, um Prozesse gleichzeitig und asynchron zu starten.

Hier sind einige Informationen zu einigen davon:

• Upstart: Entwickelt von Canonical, wurde es in Ubuntu 9.10, Red Hat, Red Hat Enterprise Linux (RHEL) 6, CentOS 6 und Fedora 9 verwendet.
• Runit: Läuft auf FreeBSD und anderen BSD-Derivaten, macOS und Solaris sowie Linux-Systemen. Es ist auch das Standard-Init-System auf Void Linux.
• s6-linux-init: Dieser Ersatz für System V init wurde entwickelt, um sich eng an die Unix-Philosophie zu halten, die oft auf den Soundbite „Mach eine Sache, und mach es gut“ reduziert wird.

Es gibt viele andere mit unterschiedlicher Funktionalität und Design. Allerdings hat keiner von ihnen für so viel Furore gesorgt wie systemd .

Der systemd-Weg

systemd wurde 2010 veröffentlicht und 2011 in Fedora verwendet. Seitdem wurde es von vielen Distributionen übernommen. Es wurde von Lennart Poettering und Kay Sievers, zwei Softwareentwicklern bei RedHat, entwickelt.

systemd ist viel mehr als ein Init-Ersatz. Vielmehr handelt es sich um eine Suite von ungefähr 70 Binärdateien, die die Systeminitialisierung, Daemons und Dienste, Protokollierung und Journaling und viele andere Funktionen handhaben, die bereits von dedizierten Modulen in Linux gehandhabt wurden. Der Großteil davon hat nichts mit der Systeminitialisierung zu tun.

Einige der von systemd bereitgestellten Daemons sind:

• systemd-udevd: Verwaltet physische Geräte.
• systemd-logind: Verwaltet Benutzeranmeldungen.
• systemd-resolved: Bietet Netzwerknamensauflösung für lokale Anwendungen.
• systemd-networkd : Verwaltet und erkennt Netzwerkgeräte und verwaltet Netzwerkkonfigurationen.
• systemd-tmpfiles: Erstellt, löscht und bereinigt flüchtige und temporäre Dateien und Verzeichnisse.
• systemd-localed: Verwaltet die Gebietsschemaeinstellungen des Systems.
• systemd-machined: Erkennt und überwacht virtuelle Maschinen und Container.
• systemd-nspawn: Kann einen Befehl oder einen anderen Prozess in einem leichtgewichtigen Namespace-Container starten und bietet eine ähnliche Funktionalität wie Chroot.

Und das ist nur die Spitze des Eisbergs, die auch der springende Punkt ist. systemd hat längst die Anforderungen eines Init-Systems übertroffen, was laut seinen Gegnern die Definition von Scope Creep ist.

"Es ist zu groß. Es macht zu viel.“

Gegner von systemd weisen auf die große, merkwürdige Mischung von Funktionen hin, die es umfasst. Alle diese Funktionen gab es bereits in Linux, und vielleicht brauchten einige von ihnen eine Auffrischung oder einen neuen Ansatz. All diese Funktionalitäten jedoch in etwas zu bündeln, das ein Init-System sein soll, ist architektonisch verwirrend.

systemd wurde für zu viele kritische Funktionen als Single Point of Failure bezeichnet, aber das scheint nicht gerechtfertigt zu sein. Zugegebenermaßen wirft es die Unix-Philosophie, kleine Tools zu entwickeln, die zusammenarbeiten, anstelle von großen Softwarestücken, die alles erledigen, aus dem Fenster. Obwohl systemd nicht streng monolithisch ist (es besteht aus vielen Binärdateien und nicht aus einer einzigen großen), enthält es viele unterschiedliche Verwaltungstools und Befehle unter einem Dach.

Es ist zwar nicht monolithisch, aber groß. Um eine Vorstellung von der Größenordnung zu bekommen, haben wir die Textzeilen in der Kernel-5.6.15-Codebasis und im systemd -Master-Zweig des GitHub-Repositorys gezählt.

Dies war eine relativ grobe Metrik. Es zählte Textzeilen, nicht nur Codezeilen. Dazu gehörten also Kommentare, Dokumentation und alles andere. Es war jedoch ein Like-for-Like-Vergleich und gab uns einen einfachen Maßstab:

 ( find ./ -name '*.*' -print0 | xargs -0 cat ) | WC-l

Der Kernel hatte fast 28 Millionen (27.784.340, um genau zu sein) Textzeilen. Im Gegensatz dazu hatte systemd 1.349.969 oder fast 1,4 Millionen. Mit unserer Happy-Go-Lucky-Metrik kommt systemd auf etwa 5 Prozent der Größe des Kernels heraus, was verrückt ist!

Als weiterer Vergleich kam die Zeilenzahl für eine moderne Implementierung von System V init für die Arch-Linux-Distribution auf 1.721 Zeilen.

Pöttering hat ganz offensichtlich keine Rücksicht auf die Computer Society des Institute of Electrical and Electronics Engineers (IEEE) oder den Portable Operating System Interface (POSIX)-Standard. Tatsächlich ermutigte er Entwickler, POSIX zu ignorieren:

„Also, besorgen Sie sich eine Kopie von The Linux Programming Interface, ignorieren Sie alles, was dort über die POSIX-Kompatibilität steht, und hacken Sie Ihre erstaunliche Linux-Software weg. Es ist ziemlich erleichternd!“

Es gab Anschuldigungen, dass systemd ein Red-Hat-Projekt ist, das nur Red Hat zugute kommt, aber dennoch in die breitere Linux-Welt eingespeist wird. Ja, es wurde in Red Hat geboren und wird von Red Hat verwaltet und gesteuert. Von den 1.321 Mitwirkenden arbeitet jedoch nur ein Bruchteil für Red Hat.

Was sind also die Vorteile für Red Hat?

Jim Whitehurst, der Präsident von IBM, der einst CEO von Red Hat war, sagte:

„Red Hat hat viele verfügbare Optionen in Betracht gezogen und sogar Canonicals Upstart für Red Hat Enterprise Linux 6 verwendet. Letztendlich haben wir uns für systemd entschieden, weil es die beste Architektur ist, die die Erweiterbarkeit, Einfachheit, Skalierbarkeit und klar definierte Schnittstellen bietet, um die Probleme zu lösen, die wir sehen heute und für die Zukunft voraussehen.“

Whitehurst sagte auch, dass sie auch Vorteile in eingebetteten Systemen sehen. Red Hat arbeitet mit „den größten Embedded-Anbietern der Welt zusammen, insbesondere in der Telekommunikations- und Automobilindustrie, wo Stabilität und Zuverlässigkeit an erster Stelle stehen“.

Dies scheinen technisch stichhaltige Gründe zu sein. Sie können das Bedürfnis des Unternehmens nach Verlässlichkeit verstehen, und es ist nicht unvernünftig, dass Red Hat auf seine eigenen Interessen achtet, aber sollten alle anderen diesem Beispiel folgen?

Trinken Sie das systemd Kool-Aid?

Einige Gegner von systemd sagen, dass Distributionen und Leute einfach blind dem Beispiel von Red Hat folgen und es übernehmen.

Aber genau wie der Ausdruck „Kool-Aid trinken“ ist das nicht ganz richtig. Der Satz wurde 1978 geprägt, nachdem der Kultführer Jim Jones seine über 900 Anhänger zum Selbstmord gezwungen hatte, indem er eine mit Zyanid versetzte Flüssigkeit mit Traubengeschmack getrunken hatte. Der Ausdruck beschämt fälschlicherweise Kool-Aid. Die Gruppe hat tatsächlich Flavor Aid getrunken, aber Kool-Aid wird seitdem von diesem Pinsel geteert.

Außerdem folgen Linux-Distributionen nicht blindlings Red Hat; sie übernehmen systemd nach ernsthafter Überlegung. Die Debatte tobte lange auf den Debian-Mailinglisten. Im Jahr 2014 stimmte die Community jedoch dafür, systemd als Standard-Init-System zu übernehmen, aber auch Alternativen zu unterstützen.

Debian ist ein wichtiges Beispiel, weil es nicht von RedHat, Fedora oder CentOS abgeleitet ist. Es gibt keine Lenkung von Red Hat auf Debian. Und Debian hat wie PID 1 viele Nachkommen, darunter Ubuntu und seine vielen Ableger.

Die von der Debian-Gemeinschaft getroffenen Entscheidungen sind weitreichend. Sie werden auch heftig debattiert und mit der Condorcet-Abstimmungsmethode abgestimmt. Auch die Community trifft solche Entscheidungen nicht auf die leichte Schulter.

Es stimmte im Dezember 2019 erneut dafür, sich weiterhin auf systemd zu konzentrieren und weiterhin Alternativen zu prüfen. Das Gegenteil von blindem Folgen, dies ist tatsächlich ein Lehrbuchbeispiel für Demokratie und Wahlfreiheit am Arbeitsplatz.

Die Einschränkungen der Wahl

Sie können im Allgemeinen nicht wählen, ob Sie systemd mit einer bestimmten Linux-Distribution verwenden möchten. Vielmehr entscheiden die Distributionen selbst, ob sie es verwenden möchten, und Sie können auswählen, welche Linux-Distribution Sie bevorzugen. Vielleicht ist eine Linux-Distribution, die Sie lieben, auf systemd . Wie bei einem Lieblingsmusiker, der das Genre wechselt, kann dies irritierend sein.

Leute, die Debian, Fedora, CentOS, Ubuntu, Arch, Solus und openSUSE verwenden und gegen die Einführung von systemd , könnten das Gefühl haben, dass sie von der Verwendung ihrer bevorzugten Distribution abgehalten werden. Wenn sie eine der architektonischen Entscheidungen, das Einschleichen des Umfangs oder die Missachtung von POSIX stark genug empfinden, finden sie es möglicherweise unhaltbar, diese Distribution weiter zu verwenden.

Es gibt natürlich ein Spektrum. Auf der einen Seite haben Sie die Leute, die die Probleme nicht verstehen (oder sich nicht einmal darum kümmern), und auf der anderen Seite die leidenschaftlichen Verweigerer. Irgendwo in der Mitte sind diejenigen, die Veränderungen nicht mögen, sich aber nicht genug darum kümmern, um das Schiff zu verlassen. Aber was ist mit den Verteilungsflüchtlingen, die aufgrund ihrer Vorlieben oder Prinzipien nicht auf ihrer gewählten Verteilung bleiben können?

Leider ist es nicht so einfach, einfach das gewünschte Init-System zu installieren. Nicht jeder hat die technischen Möglichkeiten dazu, ganz zu schweigen von den Schwierigkeiten, die entstehen, wenn Anwendungen oder Desktop-Umgebungen wie GNOME Abhängigkeiten von systemd haben.

Was ist mit dem Wechsel zu einer anderen Distribution? Einige, wie Devuan, erschienen als Nicht- systemd Forks von Distributionen (in diesem Fall Debian), die systemd übernommen hatten. Die Verwendung von Devuan sollte der übergeordneten Distribution ähneln, aber das ist nicht bei allen Nicht- systemd -Forks der Fall. Wenn Sie beispielsweise Fedora verlassen und zu AntiX, Gentoo oder Slackware wechseln, werden Sie eine ganz andere Erfahrung machen.

Es geht nirgendwo hin

Ich mag einiges von dem, was systemd tut (einfache und standardisierte Kontrollmechanismen für Prozesse). Ich verstehe die Begründung für einiges nicht (Binärprotokolle). Ich mag auch einiges nicht, was es tut (Überarbeitung von Home-Ordnern – wer hat danach gefragt?).

Distributionen wie Debian tun das Kluge und untersuchen Alternativen, um ihre Optionen offen zu halten. systemd ist jedoch auf lange Sicht dabei.

Wenn Sie Linux-Maschinen für andere verwalten, lernen Sie systemd so gut wie Sie System V init kennen. Auf diese Weise können Sie, egal welchen Sie begegnen, Ihre Pflichten erfüllen.

Nur Linux zu Hause nutzen? Wählen Sie in diesem Fall eine Distribution, die sowohl Ihren technischen Anforderungen entspricht als auch zu Ihrer Linux-Ideologie passt.

VERWANDT: Systemd ändert die Funktionsweise Ihres Linux -Basisverzeichnisses