David Edmundson: Wie KDE Plasma von Systemd profitiert

Für die Plasma-Oberfläche von KDE werden bereits Werkzeuge aus Systemd verwendet, und die Nutzung könnte weiter ausgebaut werden. Entwickler David Edmundson erklärt, welche Vorteile sich daraus für das Projekt ergeben.

Artikel veröffentlicht am 4. Februar 2015, 8:49 Uhr, Sebastian Grüner

KDE Plasma 5.2 benutzt bereits Werkzeuge aus Systemd. (Bild: KDE/CC-BY-3.0)

Das aktuelle KDE Plasma 5.2 greift bereits auf die Logind zu, um die Bildschirmsperre sicher umzusetzen. Die Verwendung dieses und weiterer Werkzeuge aus Systemd bringe dem Desktop wesentliche Vorteile, schreibt der KDE-Entwickler David Edmundson in seinem Blog. Er bietet dafür eine kleine Übersicht an und stellt klar, dass der eigentliche Init-Dienst Systemd für Plasma nicht relevant sei.

Einige Werkzeuge aus der Systemd-Sammlung lösten aber bekannte Probleme und vereinfachen damit die Entwicklung. So benötige Plasma eine Liste der laufenden Sitzungen, um zwischen diesen zu wechseln oder den Nutzer beim Herunterfahren zu warnen, falls noch eine andere Sitzung aktiv ist. Logind löse dies besser als die bisherige KDE-Technik. Der Daemon erlaubt der Fensterverwaltung zudem als einziger Anwendung, Eingaben von Geräten anzunehmen und weiterzuleiten, wobei für andere Anwendungen der direkte Zugriff blockiert wird.

Außerdem wurden damit sogenannte Inhibitor Locks umgesetzt. Anwendungen können darüber eine Verzögerung erzwingen, bevor ein System in den Ruhezustand versetzt oder heruntergefahren wird. So sind noch anstehende Operationen sicher ausführbar, was etwa für die Bildschirmsperre genutzt wird. Erst wenn diese tatsächlich läuft, wird das System in einen anderen Zustand versetzt.

Übergreifend weniger Programmierarbeit

Zurzeit verwendet der Plasma-Desktop ein selbst geschriebenes Werkzeug, das mit Root-Rechten läuft und Zugriff per D-Bus zur Konfiguration von Datum und Uhrzeit erlaubt. Eine kleine Hilfsanwendung greift auf eine von sechs verschiedenen NTP-Anwendungen zu, um die Uhrzeit zu stellen. Genau diese Funktionalität bietet Timedated, die auch desktopübergreifend zur Verfügung steht. Die Verwendung vereinfacht die Pflege für alle Beteiligten.

Ebenso informiert Timedated über den Wechsel von Zeitzonen. Um den gleichen Effekt zu erzielen, läuft für den KDE-Desktop derzeit ein eigener Daemon, der die lokale Zeit überwacht und Veränderungen an jede Anwendung sendet. Würden alle Anwendungen die Zeitzone über Timedated ändern, wäre der Mehraufwand für die KDE-Entwickler nicht mehr nötig. Ähnliche Argumentationen ließen sich auch für Hostnamed, Machined oder weitere vom Systemd-Team gepflegte Anwendungen anführen, schreibt Edmundson.

Darüber hinaus könnte die Systemüberwachung so erweitert werden, dass angezeigt wird, in welchem Seat oder Container eine Anwendung läuft. Ein zentraler Ort für Logdateien könnte außerdem den Log-Viewer wiederbeleben. Statt der bisher genutzten Shell-Skripte zum Starten und Überwachen der KDE-Dienste könnten außerdem User-Units genutzt werden. Diese erlauben eine Parallelisierung, vereinfachtes Logging, eine schnellere Ausführung und automatische Neustarts der Dienste bei verringertem Entwicklungsaufwand.

Edmundson hofft, dass seine Ausführungen Verständnis für die Verwendung von Systemd hervorrufen. Vor allem weist er darauf hin, dass eine optionale Unterstützung der Schnittstellen von Systemd dem eigentlichen Ziel widerspreche, eine Verringerung des Arbeitsaufwandes zu erzielen. Das Systemd-Team weist immer wieder darauf hin, dass diese Schnittstellen auch auf anderen Betriebssystemen oder von anderen Init-Systemen umgesetzt werden könnten, wodurch Software wie Plasma weiterhin portierbar bleibe. In einem GSOC-Projekt ist das für BSD-Systeme bereits versucht worden.