Ovion schriebsystemd kombiniert viele Dinge, die vorher nicht kombiniert wurden (Dienste und Systemstart + Logging + Cron + wasnichnoch), was nicht mehr ganz so "one tool, one job" ist
Vorsicht. 🙂 Das stimmt nicht einmal so ganz, systemd ist eine
Sammlung von unabhängigen Modulen, die untereinander über eine dokumentierte API kommunizieren. Die Dokumentation ist vielleicht nicht perfekt, aber weit überdurchschnittlich (*Samba tret*). Journald, hostnamectl, timedatectl usw. usf. können bei Bedarf durchaus ausgetauscht werden. Nur besteht nicht wirklich Bedarf. 🙂
(Okay, außer vielleicht im Embedded-Bereich, wo der um ~10 MiB höhere RAM-Verbrauch tatsächlich merkbar ist… aber selbst da tret ich lieber unseren Hardware-OEM, als mich weiter mit sysvinit rumschlagen zu müssen. Wenn der RAM-Verbrauch sich nicht ohnehin normalisiert, nachdem man diverse andere Dæmons und Krücken rausgerissen hat, die man mit systemd implementieren kann.)
und (was vermutlich schwerer wirkt) als eine Art "Anspruch" auf zentrale System-Administration verstanden werden könnte, sprich, "willst du systemd, sollst du auch gleich das und das und das mit austauschen"
Was nur begrenzt wirklich forciert wird. Um systemd-init und logind (bzw. API-kompatible Implementierung) kommst du nicht wirklich drum herum (was, zwecks effektivem Sessionmanagement so beabsichtigt wird), der Rest (z.B. Cron-Ersatz) ist optional oder kann deaktiviert werden (siehe journald).
(daher z.B. die harte Abhängigkeit auf dbus)
kdbus kommt. Ob ihr wollt oder nicht. Fuck yeah, endlich ein brauchbares IPC-System! 😃
Und er pusht systemd halt schon extrem.
Dafür wird er schließlich von RedHat bezahlt.
*) Nichtportabilität auf andere Kernel wird ebenfalls angeführt, von wegen Zusammenarbeit in der OpenSource-Community und so. Da ist systemd halt raus (in seiner "Produktsparte") weil unportabel linux-only. Für manche Projekte sicher ein Punkt (siehe Debian/kFreeBSD). Wohl aber im Allgemeinen eher ein kleinerer Punkt, insbesondere bei Linux-only-Distris.
…zumal das ziemlich fadenscheidig ist, da die alle auch nicht wirklich zu Archs oder Debians sysvinit kompatibel sind/waren. Debian selber hat da iirc ordentlich frickeln müssen, weil die ranzigen, schlecht gewarteten, von irgendwo her copypastaten Sysv-Initscripte intern Linux-APIs (diverser /proc-Kram, z.B.) verwenden.
*) Der udev-Merge ("udev außerhalb von systemd ist deprecated") war natürlich ebenfalls ein diplomatischer Glücksgriff, wo doch faktisch keine andere Lösung da draußen im Einsatz ist. Reiht sich in etwa in den zweiten Punkt sowie in den Punkt "Zusammenarbeit" ein. Damit dürften sich die systemd-Leute nicht viele Freunde gemacht haben (weil vor allem der (Ex-)udev-Maintainer nun systmd-Developer ist, wenn ich das richtig im Kopf habe; die haben also faktisch udev nicht für systemd geforkt, sondern wirklich in systemd überführt).
Jop. Ist aber afaik immer noch getrennt kompilierbar.