Genau wie der Kernel ist auch systemd durchaus zum Teil modular.
Der Kernel kann größer oder kleiner gebaut werden, je nach benötigtem (Grund-)Funktionsumfang. Das ist für systemd auch möglich, nicht alle Funktionen müssen benutzt werden.
Der Kernel lädt viele Module nur nach, wenn sie benötigt werden und entlädt sie bei Nichtgebrauch auch wieder. Das ist bei systemd auch so, es werden nur die Services gestartet, die auch zur Laufzeit benötigt werden.
Es wird immer so getan, als sei systemd ein riesiger BLOB, dabei sind das durchaus mehrere Handvoll Tools.
Was das digitale Wutbürgertum angeht, hast Du allerdings komplett recht.
> Es wird immer so getan, als sei systemd ein riesiger BLOB, dabei sind das durchaus mehrere Handvoll Tools.
Der Grund dafür liegt darin, dass diese Tools alle von Systemd abhängig sind, selbst wenn dies nicht nötig gewesen wäre. Eine Ausmahne bildet dabei meines Wissens nur udev. Für udev und logind gibt es dann noch die abgekoppelten Ersätze eudev und elogind mit anderen Maintainern. Für sämtliche anderen Tools gibt es keine.
Die Library libsystemd0 besitzt zwar einen shim, dieser hat aber systemd als build dependency und generiert eine Library die absolut nichts tut. Das heisst, ein Programm das libsystemd Funktionen nutzt und mit dem shim genutzt wird, funktioniert höchstens noch teilweise. wird z.B. sd_journal_print fürs logging verwendet, gibt es keine Logs mehr.
Das Hauptproblem mit libsystemd ist aber, dass unterschiedliche APIs die nichts miteinander zutun haben in der selben library sind. Dies hat zur folge, dass auf Distributionen mit Binarypacketen nicht z.B. nur die sd_journal Funktionen fürs Logging von einem binary Packet ersetzt werden kann, sondern auch alle anderen Funktionen von einer Library ersetzt werden müssen, was unpraktikabel ist.
Das Problem damit, dass alle Tools voneinander abhängig sind ist, dass Programme, die von den Tools abhängen, ohne Systemd dann nicht mehr funktionieren. Um ein paar prominente Beispiele davon zu nennen: * Snap funktioniert nicht auf nicht systemd Systemen, da es die CGroup und Namespace abstraktionen von Systemd nutzt. * iio-sensor-proxy, dieses Programm ist notwendig, um den Bildschirm z.B. eines Tablets automatisch mitdrehen lassen zu können. * Diverse Desktop Environments und Login Manager, insbesondere Gnome. Bei diesen haben Nicht-Systemd Distributionen haben viel mühe damit, die Abhängigkeiten zu entfernen. Einige versuchen es gar nicht mehr erst.
Ich weise ausserdem schon im vornherein darauf hin, dass diese Abhängigkeiten der Tools zu systemd bei der Entwicklung in keinster weise notwendig gewesen wären. Systemd hätte seine Tools nutzen können, ohne das die Tools auf Systemd angewiesen gewesen wären. Es bietet auch keine bessere Integration in Systemd, die Userinterfaces hätten dafür in keinster weise geändert werden müssen.
Digitales Wutbürgertum? Das Wort beschreibt überhaupt nicht den Stand der Dinge. Warum sind bitte Alle, die systemd ablehnen auf einmal in einer Schublade? Ich habe beispielsweise nicht einmal im Entferntesten Herrn Poettering persönlich attackiert oder verbal sonst irgendwie abgewertet. Die Kritik bezieht sich einzig darauf, dass meiner Meinung nach Distributionen Vielfalt anbieten sollten. Schön, dass systemd gibt. Aber ebenso schön, dass es andere INIT-Systeme wie OpenRC, S6 oder runit gibt. OpenRC beispielsweise finde ich klasse und setze das zusammen mit Hyperbola auf meinem Desktop-System ein. Und nur weil ich systemd aus verschiedensten Gründe ablehne, bin ich ein "digitaler Wutbürger"?
Warum schreibt ihr hier überhaupt dann, wenn systemd für euch so passt? Was kümmert euch dann eine Distribution, die eben auf das Ganze verzichten möchte?
Es war schon immer so, dass eine Distribution meist nur ein einziges Init-System angeboten hatte. Ausnahme sind Source-basierte Distributionen wie Gentoo, wo man ohnehin alles selbst konfigurieren kann.
Der Begriff "Digitales Wutbürgertum" kommt wohl daher, dass einige systemd-Gegner plötzlich was von einer "Init System Freedom" erzählen und die systemd-Entwickler als brutale Unterdrücker darstellen.
Das macht natürlich keinen Sinn, Devuan bietet z.B kein systemd an, ist aber deswegen nicht unterdrückerisch. Jede Distribution kann ja selbst entscheiden, welche Software sie paketieren möchte. Wem das nicht gefällt, der nimmt eine andere Distro, gibt ja genug.
Vielleicht hat Debian da auch falsche Erwartungen geschürt, z.B als sie neben Linux noch kFreeBSD und Hurd anbieten wollten und dann dachten die Leute das müsse beim Init System genauso sein. Ich halte es für sinnvoller, sich auf eine Lösung zu beschränken, zumindest bei so grundlegenden Komponenten, sonst hat man einen Haufen Arbeit und am Ende funktioniert es sowieso nicht zufriedenstellend.
Genau wie der Kernel ist auch systemd durchaus zum Teil modular.
Der Kernel kann größer oder kleiner gebaut werden, je nach benötigtem (Grund-)Funktionsumfang. Das ist für systemd auch möglich, nicht alle Funktionen müssen benutzt werden.
Der Kernel lädt viele Module nur nach, wenn sie benötigt werden und entlädt sie bei Nichtgebrauch auch wieder.
Das ist bei systemd auch so, es werden nur die Services gestartet, die auch zur Laufzeit benötigt werden.
Es wird immer so getan, als sei systemd ein riesiger BLOB, dabei sind das durchaus mehrere Handvoll Tools.
Was das digitale Wutbürgertum angeht, hast Du allerdings komplett recht.
> Es wird immer so getan, als sei systemd ein riesiger BLOB, dabei sind das durchaus mehrere Handvoll Tools.
Der Grund dafür liegt darin, dass diese Tools alle von Systemd abhängig sind, selbst wenn dies nicht nötig gewesen wäre. Eine Ausmahne bildet dabei meines Wissens nur udev. Für udev und logind gibt es dann noch die abgekoppelten Ersätze eudev und elogind mit anderen Maintainern. Für sämtliche anderen Tools gibt es keine.
Die Library libsystemd0 besitzt zwar einen shim, dieser hat aber systemd als build dependency und generiert eine Library die absolut nichts tut. Das heisst, ein Programm das libsystemd Funktionen nutzt und mit dem shim genutzt wird, funktioniert höchstens noch teilweise. wird z.B. sd_journal_print fürs logging verwendet, gibt es keine Logs mehr.
Das Hauptproblem mit libsystemd ist aber, dass unterschiedliche APIs die nichts miteinander zutun haben in der selben library sind. Dies hat zur folge, dass auf Distributionen mit Binarypacketen nicht z.B.
nur die sd_journal Funktionen fürs Logging von einem binary Packet ersetzt werden kann, sondern auch alle anderen Funktionen von einer Library ersetzt werden müssen, was unpraktikabel ist.
Das Problem damit, dass alle Tools voneinander abhängig sind ist, dass Programme, die von den Tools abhängen, ohne Systemd dann nicht mehr funktionieren. Um ein paar prominente Beispiele davon zu nennen:
* Snap funktioniert nicht auf nicht systemd Systemen, da es die CGroup und Namespace abstraktionen von Systemd nutzt.
* iio-sensor-proxy, dieses Programm ist notwendig, um den Bildschirm z.B. eines Tablets automatisch mitdrehen lassen zu können.
* Diverse Desktop Environments und Login Manager, insbesondere Gnome. Bei diesen haben Nicht-Systemd Distributionen haben viel mühe damit, die Abhängigkeiten zu entfernen. Einige versuchen es gar nicht mehr erst.
Ich weise ausserdem schon im vornherein darauf hin, dass diese Abhängigkeiten der Tools zu systemd bei der Entwicklung in keinster weise notwendig gewesen wären. Systemd hätte seine Tools nutzen können, ohne das die Tools auf Systemd angewiesen gewesen wären. Es bietet auch keine bessere Integration in Systemd, die Userinterfaces hätten dafür in keinster weise geändert werden müssen.
Digitales Wutbürgertum? Das Wort beschreibt überhaupt nicht den Stand der Dinge. Warum sind bitte Alle, die systemd ablehnen auf einmal in einer Schublade? Ich habe beispielsweise nicht einmal im Entferntesten Herrn Poettering persönlich attackiert oder verbal sonst irgendwie abgewertet. Die Kritik bezieht sich einzig darauf, dass meiner Meinung nach Distributionen Vielfalt anbieten sollten. Schön, dass systemd gibt. Aber ebenso schön, dass es andere INIT-Systeme wie OpenRC, S6 oder runit gibt. OpenRC beispielsweise finde ich klasse und setze das zusammen mit Hyperbola auf meinem Desktop-System ein. Und nur weil ich systemd aus verschiedensten Gründe ablehne, bin ich ein "digitaler Wutbürger"?
Warum schreibt ihr hier überhaupt dann, wenn systemd für euch so passt? Was kümmert euch dann eine Distribution, die eben auf das Ganze verzichten möchte?
Es war schon immer so, dass eine Distribution meist nur ein einziges Init-System angeboten hatte. Ausnahme sind Source-basierte Distributionen wie Gentoo, wo man ohnehin alles selbst konfigurieren kann.
Der Begriff "Digitales Wutbürgertum" kommt wohl daher, dass einige systemd-Gegner plötzlich was von einer "Init System Freedom" erzählen und die systemd-Entwickler als brutale Unterdrücker darstellen.
Das macht natürlich keinen Sinn, Devuan bietet z.B kein systemd an, ist aber deswegen nicht unterdrückerisch. Jede Distribution kann ja selbst entscheiden, welche Software sie paketieren möchte. Wem das nicht gefällt, der nimmt eine andere Distro, gibt ja genug.
Vielleicht hat Debian da auch falsche Erwartungen geschürt, z.B als sie neben Linux noch kFreeBSD und Hurd anbieten wollten und dann dachten die Leute das müsse beim Init System genauso sein. Ich halte es für sinnvoller, sich auf eine Lösung zu beschränken, zumindest bei so grundlegenden Komponenten, sonst hat man einen Haufen Arbeit und am Ende funktioniert es sowieso nicht zufriedenstellend.