Hallo, On 08/31/2018 05:59 PM, Jan Kappler wrote: > Am 31.08.2018 um 16:52 schrieb Alexander Reichle-Schmehl: >> Am 2018-08-31 16:45, schrieb Martin Klaiber: >> In der Debian standard Installation ist systemd seit einiger Zeit das >> default init system (zumindest auf den gängigen Architekturen; keine >> Ahnung ob auf allen). >> Diverse Pakete hängen direkt oder indirekt von systemd ab, und das ist >> akzeptabel. > > Ohne einen erneuten Streit beginnen zu wollen - ich sehe das anders. Die > Wahlfreiheit unter Linux wird durch diese Abhängigkeiten untergraben! Ich sehe das als den Kompromiss, den man eingehen muss, wenn man eine Binärdistribution einsetzt. Ich habe es nicht selbst probiert, aber theoretisch sollte man auch heute noch ein Debian installieren können und das dann (nach der Installation) auf sysvinit (oder auch openrc) umstellen können. Davon geht die Abhängigkeit an libsystemd* natürlich nicht weg, die verschiedene Komponenten haben, aber abgesehen von etwas Overhead beim Starten und eventuell auch beim Betrieb sollte das vom Verhalten einer gegebenen Software keinen Unterschied machen. Dass der Faktor in dem heise-Artikel beim Apache-Test zwischen Devuan und Debian so groß ist, finde ich erstaunlich und hätte als Autor noch versucht zu verstehen, woher der Unterschied kommt, bevor ich das in einen Artikel gegossen hätte. Und wenn das reproduzierbar ist und jemand dafür eine Erklärung findet, gehe ich auch davon aus, dass das einen Bugreport bzw. einen Fix wert ist. > Gnome kann man praktisch nicht installieren, ohne sich > systemd-Komponenten auf die Platte zu holen. Das finde ich sehr schade. systemd ist in der Hinsicht nicht anders als dash, util-linux, libaudit oder glibc. Und ohne genau zu wissen, was libsystemd einer Applikation bringt, finde ich von meinem Standpunkt aus schon richtig, dass es Dinge gibt, die sinnvoll in so einer Bibliothek gesammelt werden. systemd erlaubt an manchen Stellen mehr Dinge als sysvinit. So wird einer Applikation z.B. die Möglichkeit gegeben mitzuteilen, dass sie jetzt komplett gestartet und einsatzfähig ist[1]. Das wird per dbus mitgeteilt und ist (für Dämonen, die nicht in Shell geschrieben sind) bestimmt in eine Funktion in libsystemd gekapselt. Und systemd kann auch erkennen, ob ein Dämon hängt[2] und darauf reagieren. Die nötige Funktionalität muss auch nicht jeder Dämon komplett selbst implementieren und deswegen ist das auch in libsystemd gekapselt. Das Logging ist aus Applikationssicht mit systemd auch viel einfacher als wenn man auch mit sysvinit vernünftig loggen will[3]. So ist der Rant "systemd ist viel größer als sysvinit" faktisch richtig, aber da systemd auch mehr leistet als sysvinit, nicht sonderlich überraschend. Für alle, die Zweifel an systemd und dessen Nützlichkeit haben, empfehle ich die Blogbeiträge von Lennard Pöttering zu systemd für Administratoren und Entwickler, die in [2] im ersten Absatz verlinkt sind. Diese Artikel sind natürlich einseitig, aber mit der nötigen Skepsis gelesen, zeigen sie trotzdem nett auf, was systemd leisten kann und warum das eine oder andere so implementiert wurde. Liebe Grüße Uwe [1] systemd-notify(1) [2] http://0pointer.de/blog/projects/watchdog.html [3] http://0pointer.de/blog/projects/journal-submit.html, Abschnitt "printf()"
Attachment:
signature.asc
Description: OpenPGP digital signature