OpenBSD soll Systemd-Derivat erhalten

Systemd ist unter Linux bereits ein de-Facto-Standard. Während Googles Summer of Code (GSoC) sollen nun die Möglichkeiten einer Implementierung für OpenBSD geprüft werden.  Systemd ist ein Daemon für Linux-Systeme, der als erster Prozess (init-Prozess mit der Prozess-ID 1) andere Prozesse startet, überwacht und beendet. Lennart Poettering, Kay Sievers und einige andere Entwickler sind die initialen Autoren der heute unter der GNU Lesser General Public License (LGPL) veröffentlichten Version. Durch die Verbreitung von Systemd basieren inzwischen zunehmend mehr Anwendungen darauf. Die Folge: Einige Anwendungen können ohne Systemd nicht einmal gestartet werden, andere erfüllen dann nicht alle Funktionen. OpenBSD hat daher nun angekündigt, eine Lösung zu schaffen. So äußerten Antoine Jacoutot und Landry Breuil, sie wollten im Rahmen des Google Summer of Code (GSoC) vier DBus-Daemonen erstellen, die Systemd-Aufrufe verarbeiten und das Verhalten von Systemd  abbilden: systemd-hostnamed, systemd-logind, systemd-localed und systemd-timedated . Die neue Lösung soll generisch sein und alle unixoiden Systeme unterstützen. Wann sie tatsächlich bereitstehen wird, steht noch nicht fest. Systemd ist abwärtskompatibel zu SysVinit-Skripten. Jedoch wurden auch Funktionen eingesetzt, die nur auf Linux verfügbar sind, aber nicht auf anderen unixoiden Betriebssystemen. Systemd läuft daher nur auf Linux-Kerneln. Gegenseitige Abhängigkeiten von Prozessen werden berücksichtigt. Ein höherer Grad an Parallelisierung führt zudemzu einer besseren Auslastung beim Systemstart. Dabei startet der Init-Daemonalle weiteren Prozesse weitgehend gleichzeitig und nicht - wie bei SysVinit und Upstart - serialisiert. SysVinit dagegen startet die Dienste anhand der Runlevel in einer vorgegebenen Reihenfolge, und zwar jeweils erst dann, wenn die Initialisierung des vorherigen Prozesses abgeschlossen ist. Dies verzögert den Systemstart, vereinfacht dafür eine Diagnose bei Problemen. Upstart ist ein weiterer Init-Daemon. Er basiert auf SysVinit und ist dazu auch abwärtskompatibel. So können SysVinit-Skripte unverändert ausführt werden. Dabei ist Upstart jedoch ereignisgesteuert und erlaubt das gleichzeitige Ausführen von Jobs. Systemd setzt dagegen grundsätzlich auf Parallelisierung, berücksichtigt dabei jedoch die wechselseitigen Abhängigkeiten der Prozesse. Sockets zur Interprozesskommunikation (IPC) und D-Bus-Verbindungen werden schon vor dem Start der zugehörigen Dienste bereitgestellt. Nachrichten werden vom Kernel solange gepuffert, bis der jeweilige Dienst bereitsteht. Gleiches gilt für Anfragen an Filesysteme - hier setzt autofs an. Deklarative Konfigurationsdateien ersetzen bei Systemd die bisherigen Shell-Boot-Skripte anderer Start-Daemons. In ihnen wird festgelegt, wie die jeweiligen Dienste zu starten sind. Sie vermeiden den Overhead von Shell-Skripten und sind generell einfacher zu schreiben. Allerdings ist der Einsatz von Systemd auch etwas umstritten. So wird unter anderem bemängelt, dass mit Systemd ein Monolith entstehe, der schwer zu überblicken sei. Zudem würden bisherige Ansätze unixoider Systeme komplett verworfen. Die Komplexität nehme zu, ohne jedoch relevante Vorteile zu bringen.