Hast du dir mal den historisch gewachsen Verhau X11 unter der Haube angeschaut?
Irreparabel.
Ja, habe ich (Das Video [noch] nicht, den Code und die API schon). Und alle Alternativen sind bislang daran gescheitert, dass sie inkompatible Änderungen einführen wollten und niemand migrieren wollte. Was meinst du, warum ich so auf Rückwärtskompatibilität rumhacke? Dieses systemd-wayland-mir-Unix-Desktop Desaster verdanken wir IMHO der Hegemonie von freedesktop.org, wo seit Jahren alle Vorschläge von GNOME blockiert werden, die sie nicht selber spezifiziert haben (jüngstes mir bekanntes Beispiel: libnotification, kam von KDE und wurde von Canonical mit aufgegriffen, GNOME hat es blockiert, und das war wohl einer der Gründe warum sie Unity von GNOME geforkt haben). Standardkomitees können eben Fluch und Segen zugleich sein.
Der Desktop ist nicht umsonst seit 2 Jahrzehnten die Achillesferse unter Unix. Immerhin konnte niemand zwischenzeitlich eine bessere Lösung auf die Beine stellen.
Was aber vornehmlich aus politischen Gründen gescheitert ist, s.o.
In diesem Fall sollte sich jemand finden lassen, der auf den vorhandenen Programmen aufsetzt und daraus eine Lösung macht, die besser ist als systemd-logind. Ich würde nicht darauf wetten.
Und dann müsste es auch noch in GNOME integriert werden. Daran habe ich auch, trotz anderslautender Lippenbekenntnisse, persönliche Zweifel, dass das auch tatsächlich gemacht würde. Die Maintainer wollen „ihre“ Software nicht „hergeben“, haben aber auch keine Lust, fremden Code zu warten. Dann muss man forken? Ich weiß nicht, ob das tatsächlich gut gehen würde und vermutlich bin ich nicht der einzige, der so denkt. Immerhin wurde systemd schon durch uselessd imitiert, aber eine alternative API zu systemd-logind?
Ich habe lieber gute systemspezifische als schlechte portable Implementierungen. Beruflich hatte ich bereits das Vergnügen, systemnahen C/C++-Code zu entwickeln, der in der ersten Version auf drei unterschiedlichen Plattformen laufen musste. Portabilität gibt es nicht umsonst.
Wenn man unter Portabilität nur „#if defined(__LINUX__) #elsif defined(__FreeBSD) #else #endif“ versteht, dann kann ich mir das vorstellen.
Ich finde aber, wenn man Portabilität gut durchdacht hat, dann wirkt sie sich positiv auf die allgemeine Codequalität aus, weil die Abstraktionen „natürlicher“ verlaufen.
Würdest du an Stelle der systemd-Entwickler den zigfachen Aufwand für eine portable Lösung treiben? Wie würdest du zwingend benötigte Features wie
cgroups abbilden, so dass sie auch unter Plan 9 und NetBSD laufen?
Ich würde mir definitiv Gedanken machen, ob ich Subsysteme, welche
ganz allgemein X11-basierte Desktops als Klienten haben, so einfach auf plattformspezifische APIs festnagle, ja. Ich hätte zumindest versucht, systemd-logind so modular zu machen, dass er nicht unbedingt auf dem ganzen Rest aufbaut, der cgroup nutzt. Ich hätte allerdings auch nicht alle Funktionalität in PID 1 gestopft…
OT: Plan 9 passt IMHO nicht in die Liste, dort gibt es kein X11. Und es hatte native per process namespaces AFAIK schon vor Linux, da dürften sich cgroups vermutlich etwas einfacher emulieren lassen. Aber Plan 9 war schon ein tolles System…
Ich hatte aber noch den Zusatz dabei, dass eben Pulse-Audio und Gstreamer diejenige Software ist, welche die meisten Probleme mit Session-Management verursacht.
ConsoleKit wurde 2007 gestartet. Im Jahre 2015 erwarte ich Kleinigkeiten wie ordentliche Multi-Seat-Unterstützung, vernünftiges Handling der Sessions u.a. beim Shutdown und zuverlässiges Aufräumen der Sessions beim Logout.
Gut, dann mache ich es mal wie die systemd-Apologeten, vielleicht kannst du dann auch ein bisschen nachvollziehen, wie es mir die ganze Zeit geht:
Bei mir hat Multiseat mit KDE ziemlich zuverlässig funktioniert, mit Ausnahme von Pulse-Audio. Ich habe keine Defizite beim Session-Handling feststellen können, außer dass man nach der ersten Session keinen Sound mehr hatte, weil Pulse-Audio irgendwo hängen geblieben ist.
Seit ich kein KDE mehr nutze brauchte ich auch kein Session-Handling mehr, aber davor hat es für mich einwandfrei funktioniert.
Außer PulseAudio eben. Von wem war das nochmal? Ach…
Und da wunderst du dich, dass ich systemd nicht zutraue, das Problem zuverlässig zu lösen?!