> 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.
> 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.