Unsere Computer werden immer wichtiger für unser Leben; Probleme damit trüben unsere Stimmung und unseren Humor. Windows-Nutzer neigen da natürlich eher zu Panikattacken: Viren ( es lebe Linux! ), Festplattendefragmentierung, die Suche und Installation von Clean Master für den PC ( wobei auch unter Linux eine Systemreinigung nötig ist; BleachBit ist eine beliebte Alternative ). In letzter Zeit haben einige Linux-Nutzer mit einem Problem namens systemd zu kämpfen.
Um nun zum Punkt zu kommen: Ich habe einen interessanten Artikel über systemd gelesen , das heutzutage ja sehr beliebt zu sein scheint.
Systemd , das manche ( und ich zitiere einen Freund ) als „alles, was sie beherrschen “ betrachten, ist anderen völlig egal; solange der Computer funktioniert, ist es ihnen egal, ob init dies oder jenes tut oder ob systemd verwendet wird. Ich persönlich bevorzuge init; ich finde es einfacher.
Ich lasse den Artikel hier:
Bevor ich beginne, muss ich sagen, dass ich die Entscheidung, in Debian Änderungen vorzunehmen, entschieden ablehne. Ich habe aber nicht die Absicht, mein geliebtes Spiral-System aufzugeben. Ich möchte lediglich sicherstellen, dass wir, falls wir ein Thema besprechen, so gut wie möglich vorbereitet sind, auch wenn ich mich selbst nicht als systemd-freundlich bezeichnen würde. Um systemd verständlicher zu machen, werde ich auf eine Website zurückgreifen, auf der Entwickler ihre Ansichten teilen . Auf diese Website bin ich durch einen Kollegen aufmerksam geworden, der systemd anscheinend befürwortet, obwohl er kein Debian-Nutzer ist. Damit kann ich nun versuchen, die Diskussionen um systemd zu entmystifizieren.
systemd ist binär basiert
Vielleicht ist dies einer der Aspekte, die uns am meisten schockieren. Wenn alles auf Binärdaten basiert, wie überwachen wir die Dinge, die wir normalerweise durch Protokolle tun? Ich habe keine Ahnung, wie dieser Mythos geboren wurde, aber es ist nicht absolut wahr.
systemd wird fast ausschließlich über Klartextdateien konfiguriert. Einige Einstellungen, die auch über die Kernel-Befehlszeile und über Umgebungsvariablen geändert werden können. Ihre Konfiguration enthält nichts Binäres (nicht einmal XML). Nur eine einfache, unkomplizierte und leicht zu lesende Textdatei.
Das Ding ist monolithisch und kontrolliert alles
Bevor ich auf die oben genannte Website komme, gestehe ich, dass ich selbst so gedacht habe, aber nachdem ich gelesen habe, was die Entwickler sagen, hat meine Meinung etwas geändert ...
Wenn Sie systemd mit allen aktivierten Konfigurationsoptionen kompilieren, erstellen Sie 69 einzelne Binärdateien . Diese Binärdateien erfüllen unterschiedliche Aufgaben und sind aus mehreren Gründen sorgfältig voneinander getrennt. Beispielsweise wurde systemd mit Blick auf die Sicherheit entwickelt; daher laufen die meisten Daemons mit minimalen Berechtigungen (z. B. mithilfe von Kernel-Funktionen) und sind nur für sehr spezifische Aufgaben zuständig, wodurch ihre Angriffsfläche und ihre Auswirkungen minimiert werden. Außerdem parallelisiert systemd den Bootvorgang stärker als jede vorherige Lösung. Diese Parallelisierung wird durch die parallele Ausführung mehrerer Prozesse erreicht . Somit ist klar, dass systemd sehr gut in viele Binärdateien und folglich auch in Prozesse unterteilt ist. Tatsächlich sind viele dieser Binärdateien so gut voneinander getrennt, dass sie auch außerhalb von systemd sehr nützlich sind.
Ein Paket mit 69 einzelnen Binärdateien kann man kaum als monolithisch bezeichnen . Der Unterschied zu früheren Lösungen besteht jedoch darin, dass wir mehr Komponenten in einem einzigen Tarball ausliefern und diese in einem einzigen Repository mit einem einheitlichen Release-Zyklus zusammenfassen.
Das sieht nicht nach Unix aus
Daran ist sicherlich etwas Wahres. Die systemd-Quelldateien enthalten keine einzige Codezeile aus den ursprünglichen UNIX-Zeilen. Die Inspiration stammt jedoch von UNIX, und daher gibt es in systemd viel UNIX. Ein Beispiel wäre die UNIX-Idee "Alles ist eine Datei", die sich darin widerspiegelt, dass in systemd alle Dienste zur Laufzeit in einem Kernel-Dateisystem verfügbar gemacht werden cgroupfs. Eine der ursprünglichen Funktionen von UNIX war die Unterstützung mehrerer Sitze, basierend auf der integrierten Terminalunterstützung. Mit systemd haben wir wieder Unterstützung für mehrere Sitze eingeführt, diesmal jedoch mit vollständiger Unterstützung für die heutige Hardware, die Grafiken, Mäuse, Audio, Webcams und mehr abdeckt. Tatsächlich ist das Design von systemd als Suite integrierter Tools, die jeweils ihren eigenen Zweck haben, aber zusammen mehr als die Summe der Teile sind, was mehr oder weniger den Kern der UNIX-Philosophie ausmacht. Die Art und Weise, wie unser Projekt gehandhabt wird (d. H. Den größten Teil des Betriebssystemkerns in einem einzigen Git-Repository zu halten), ist dem BSD-Modell (das im Gegensatz zu Linux ein echtes UNIX ist) viel näher, um Dinge zu erledigen (wo der größte Teil des Kerns liegt) Das Betriebssystem wird in einem einzigen CVS / SVN-Repository gespeichert, was unter Linux nie der Fall war.
Letztendlich spielt die Frage, ob etwas UNIX ist oder nicht, nur eine sehr geringe Rolle. Da es technisch hervorragend ist, ist es kaum einzigartig für UNIX. Für uns ist UNIX ein wichtiger Einfluss (in der Tat der größte), aber wir haben auch andere Einflüsse. Daher wird systemd in einigen Bereichen sehr UNIX sein, in anderen etwas weniger.
Das ist sehr komplex ...
Daran ist sicherlich etwas Wahres. Moderne Computer sind komplexe Bestien, und das Betriebssystem, auf dem sie ausgeführt werden, wird es offensichtlich auch sein, daher müssen sie komplex sein. Systemd ist jedoch sicherlich nicht komplexer als frühere Implementierungen derselben Komponenten. Es ist einfacher und hat weniger Redundanz. Auf der anderen Seite erfordert das Erstellen eines einfachen systemd-basierten Betriebssystems weit weniger Pakete als herkömmliche Linux-Anwendungen. Weniger Pakete erleichtern den Aufbau Ihres Systems, beseitigen Abhängigkeiten und das unterschiedliche Verhalten aller beteiligten Komponenten.
Das lässt mich keine Shell-Skripte verwenden
Das ist völlig falsch. Wir verwenden sie einfach nicht für den Bootvorgang, weil wir sie für diesen Zweck nicht für optimal halten. Das bedeutet aber nicht, dass systemd inkompatibel mit ihnen ist. Shell-Skripte lassen sich problemlos als systemd-Dienste oder -Daemons ausführen; Skripte in beliebiger Sprache können als systemd-Dienste gestartet werden, da systemd der Inhalt der ausführbaren Datei völlig egal ist. Darüber hinaus nutzen wir Shell-Skripte selbst intensiv: für die Installation, das Kompilieren und das Testen von systemd. Sie können die Skripte in den frühen Startvorgang einfügen, sie für normale Dienste verwenden oder sie beim Herunterfahren ausführen – es gibt praktisch keine Einschränkungen.
An diesem Punkt dürften einige der wichtigsten Annahmen geklärt sein. Obwohl ich mich nicht als Verfechter von Veränderungen sehe und meine Vorbehalte gegenüber der Idee eines „ Allzweck-Systems “ habe, glaube ich, dass am Ende niemand wagen wird zu behaupten, es funktioniere überhaupt nicht. Ich kenne sogar einige Nutzer, die feststellen, dass ihr PC mit systemd schneller läuft, aber das ist ein anderes Thema. Vorerst kann ich Sie nur einladen, Ihre Standpunkte zu diesem Init-System, das viele Distributionen übernommen haben, hier zu diskutieren. Die heftigsten Reaktionen gibt es derzeit in der Debian-Community, die deswegen sogar einen neuen Fork hervorgebracht hat. Ob Sie es mögen oder nicht, ist Ihre persönliche Angelegenheit; ich für meinen Teil möchte lediglich meinen Beitrag zur Entmystifizierung von systemd leisten, das schließlich in Jessie, der nächsten stabilen Version von Debian, enthalten sein wird.
Ich habe den Artikel auf GUTL gesehen (der wiederum von DesdeAbreus stammt ).
Systemd aktuell?
Ich gehöre zu denen, die nicht viele Nachrichten lesen, wenn etwas so viele Kontroversen hervorruft, ich bleibe lieber bei technischeren Details. Die Sache ist…. Manchmal habe ich das Gefühl, dass bestimmte Themen keine rein technische Diskussion oder Debatte mehr sind, sondern zu einem Showbiz-Klatsch werden
Zuerst eine offene Tirade eines Nutzers über systemd mit dem Titel systemd VS intelligence , dann Linus Torvalds, der meint, systemd sei gar nicht so schlecht , wie es dargestellt werde ( und da hat er durchaus recht ), ein Fork namens uselessd ... kein Kommentar ... und um es kurz zu machen, schließlich Devuan.
Ich will nicht sagen, ob es so schlimm ist, wie behauptet wird, weniger schlimm oder schlechter. Das System funktioniert für mich einwandfrei, persönlich würde ich aber init bevorzugen, da mir dessen Art der Organisation verschiedener Dinge (wie zum Beispiel Logs) gefällt. Aber gut, wenn systemd als Rennpferd bezeichnet wird und init ersetzen soll ( wäre es dann unser Arbeitstier, das alles erledigt, nur langsam? ), nun ja … solange die Änderung nicht zu drastisch ist, die Benutzer sich ohne große Probleme anpassen können und das System besser funktioniert (ja, besser, vielleicht reicht mir das nicht!), dann nur zu! 😉