Weiterhin könne auf User-Units zum schnelleren Start der KDE-Dienste - analog zu den sonstigen System-Dämonen - gesetzt werden.
Find ich eine gute Idee, denn im Moment muss KDE (wenn ich mich nicht sehr irre) ja seinen eigenen Dienstverwaltungs-Mechanismus pflegen was in meinem Augen einfach keinen Sinn macht wenn schon etwas entsprechendes und/oder besseres vorhanden ist.
Und bei Pulseaudio ab Version 6 ist das neuerdings auch die empfohlene Vorgehensweise
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 05. Feb 2015 um 13:41.
Das ist auch meiner Meinung nach der wesentlichste Punkt in dem ganzen Text. startkde in seiner aktuellen Form ist ein ziemlich undurchsichtiges und lahmes Skript, welches aber auch schon versucht wurde zu ersetzen (Projekt hieß sessionk). Lezteres verlief sich aber im Sand und ich sehe auch keinen Grund, warum man diese Funktionalität nicht direkt in systemd-units übertragen könnte. Durch diesen Ansatz könnte man auch die Diensteverwaltung von z.B. Gnome- und KDE-Anwendungen etwas vereinheitlichen. Aktuell wird nur bei KDE Anwendungen z.B. bei einem Crash direkt der entsprechende Dialog mit Backtrace gestartet. Genau das ist aber für etwas unbedarftere Anwender sehr praktisch, wenn es um Fehleranalyse geht. Wenn man das auf einem KDE Desktop in gleicher Weise auch für Gnome-Programme umsetzen könnte, weil beide die Funktionalität von systemd Units nutzen, dann hätte man hier schon einen signifikanten Mehrwert.
Dazu kommt natürlich noch, dass startkde den Start von KDE deutlich ausbremst und es sich schon lohnen kann, diesen Bremsklotz zu entfernen. Aber hier werden natürlich hier wieder 90% der User einwenden, dass man Computer doch niemals neu startet...
Das startkde script ist in Sekundenbruchteilen durch. Das script ruft kdeinit auf was ksmserver aufruft. Letzteres ist was den Löwenanteil an Zeit und Arbeit kostet und wo sessionk ansetzte (beides session manager). Siehe https://dantti.wordpress.com/2013/02/27/1-2-3-plasma/
Die Aussage das "starting the KDE services in order in a list" ist etwas ungenau bzw. kann durch den Satzbeginn falsch verstanden werden, trifft den Kern des Problems aber ziemlich gut. Das passiert nicht im shellscript sondern ist Verteilt auf diverse Bestandteil die alle C/C++ sind. Der Folgesatz über kded deutet in die Richtung, benennt einen Bestandteile.
Das startkde script ist in Sekundenbruchteilen durch.
Schau dir mal die Analyse von startkde im Rahmen des sessionk Projekts durch. Das ist mitnichten in Sekundenbruchteilen durch. Es gibt sogar teilweise künstliche Wartepausen. Natürlich war das nicht die einzige Motivation für sessionk, aber eben ein Teil.
Mit systemd könnte man Socket-Activation verwenden, so dass Dienste auch dann schon gestartet werden können, wenn ein anderer Dienst noch nicht läuft. Man kann sehr vieles parallel starten und umgeht damit viele der Fragestellungen dieses Skripts.
kded war mir persönlich schon immer ein Dorn im Auge. Wenn man in einem dieser Teile auf ein Problem gestoßen ist, dann wurde es teilweise recht kompliziert herauszufinden, wo genau das Problem sich versteckt. Ich hatte diesen Spaß mal mit einem KIO Interface (glaube bluetooth) und habe Stunden damit verbracht das Problem zu suchen...
Socket activation geht auch ohne systemd. Du hat allerdings Recht, dass startkde nicht gerade schnell ist, und man einen Teil dieses Overheads vermeiden könnte.
Man beachte I/O und mem und vergleiche auf einem ~15 Jahre alten Rechner, die Zeit in der die KDE Startup Infrastruktur entstanden ist. Festhalten lässt sich: Der I/O und mem bound ist fast komplett verschwunden, das sind keine Flaschenhälse mehr. Die Beobachtung kombiniert mit Wissen über damalige Prozesskosten hilft beim Design-Verstândniss, auch von zB kded. Kombiniert mit etwas Wissen über die gewachsene Bedeutung von Nebenläufigkeit und schon sehen einige der damaligen Anforderungen, und damit Lösungen, heute anders aus.
Ferner sind Wartezeiten der einzelnen Komponenten ersichtlich. startkde taucht erst gar nicht auf während hier offensichtlich einige Komponenten andere vom starten abhalten oder später Zeitversetzt starten (zB dbus- oder vergleichbare ondemand-Activations, ein alter Hut mit Bart der von zB KDE schon lange genutzt wird).
Nun braucht es etwas Willen in den Code zu gucken um zu verstehen was, wie und warum überhaupt gestartet wird und warum diese Lücken existieren. Ich verweise auf Dantti's block und stelle damals wie heute fest, und liege damit wohl auf Linie mit David, das die neuen Anforderungen eine Überarbeitung des gesammten Startup-Stacks erfordern. sessionk war da schon ein richtiger Ansatz. Natürlich kann man das auch anders machen, ob nun systemd unitfiles oder eine Sammlung an Shellscripten ist dabei total irrelevant. Mit beiden lässt sich dasselbe erreichen, die neuen Anforderungen (Nebenläufigkeit) umzusetzen.
Warum also systemd unitfiles? Weil es ein möglicher Ansatz ist und den jemand umsetzt! So funktioniert FLOSS nun mal. Natürlich wissen wir auch alle das es dabei nicht bleibt weil immer jemand es besser oder einfach anders macht und wenn der Wille da ist es auch tut. Auch so funktioniert FLOSS.
Und so muss man den auch systemd begreifen. Rumheulen bringt nichts. Selber machen oder warten bis es jemand selber macht. Den wenn eines Gewiss ist, dann das systemd auch nur ein Schritt ist und auf einen Schritt immer der nächste folgt der noch besser oder einfach anders ist. Den auch das ist FLOSS.
Wir implementieren nicht mehr selbst und setzen voraus alle anderen nutzen auch Systemd-kompatiblen Kram. Da wir kein Interesse an Plattformunabhängigkeit und weniger Abhängigkeiten haben sind wir voll zufrieden und tanzen auf dem Kornfeld, nackt.
PS: Alle anderen sind doof, ich hab doch voll die Argumente.
@Peter; bau dir selber was, wenns dir nicht gefällt! Die Entwickler entwickeln, was ihnen gefällt und du kannst es nutzen oder halt nicht. Was ist das Problem?
Leute wie du, die dann sofort wieder wegen unnötigen Forks und Grabenkämpfe im Opensource-Umfeld heulen, obwohl "wir" doch den gemeinsamen pösen pösen Feind aus Redmond besiegen sollten.
Hach ja, wären doch mal alle amd64/SSD/IntelGPU/GNU/Linux/systemd/KDE-Nutzer... Aber die Ungläubigen kriegen wir schon noch klein!
> Wir implementieren nicht mehr selbst und setzen voraus alle anderen nutzen auch Systemd-kompatiblen Kram.
Naja, dass die Desktop Entwickler das gerne benutzen anstatt der komplexen, halbgaren und fehleranfälligen Lösungen die man halt implementiert hat weils nix anderes gab ist klar. Systemd überzeugt halt an der Stelle und setzt so die (defakto) Standards, eben teils wie beschrieben auch an Stellen wo es vorher nix vergleichbares gab. Wer diese Features auf einer anderen Plattform haben will muss halt die Entsprechenden dbus APIs bereit stellen. Hat immerhin den Vorteil, dass es dann alle benutzen können und nicht nur KDE.
Wir implementieren nicht mehr selbst, sondern setzen auf dokumentierte Systemschnittstellen. Das dient besonders der Plattformunabhängigkeit, da wir so platformspezifischen Code nicht mehr selbst implementieren müssen.
PS: Gleicher Inhalt, nur etwas umformuliert. Das bisher nur systemd die Schnittstellen und zentalen Daemonen anbietet ist etwas schade, ich denke aber das andere bald nachziehen werden.
Naja, so ist es dann halt doch nicht. Aktuell haben wir systemd-Unterstützung immer nur zusätzlich eingebaut. Z.B. als ich mittels systemd sicherstellte, dass die Sitzung gesperrt wird, wenn der Rechner in den Suspend geht, haben wir zusätzlich noch einen Fallback für nicht-systemd eingebaut. Dabei Code in mehreren Kompnenten angepasst. Siehe hier und hier. Natürlich werden jetzt nur die systemd Nutzer davon profitieren, da es keine andere Lösung dafür gibt.
Warum hat David sich timedate angeschaut? Naja weil er eine Sicherheitslücke in unserem Code gefunden hat und sie behoben hat und nun nach besseren Lösungen schaut. Im aktuellen Code-Review dafür ist auch der nicht-systemd Pfad noch vorhanden und wir diskutieren darüber, wie man für nicht systemd eine gute Lösung bereitstellen kann.
Aber sorgt diese nicht-systemd Kompatibilität nicht gleichzeitig auch dafür das es für euch schwerer wird den Code zu unterhalten? Irgendwie habe ich das Gefühl das es langsam an der Zeit ist die alten Zöpfe endgültig abzuscheiden.
Nur weil openGLES3 gestern rausgekommen ist schmeisst man heute ja nicht alles OpenGLES2 weg. Mit der Zeit ersetzen neue Sachen alte Sachen. Wenn den keiner oder wenige die alten Sache noch nutzen kommen sie halt raus. In der Übergangszeit unterstützt man halt beides. Migration nennt sich sowas. Passiert aktuell auch zB bei X11 und Wayland und es kann einiges dauern bis sie vollzogen ist. Den: "breaking the desktop is actually not a valid use case"
Klar jeder ifdef erhöht die Komplexität. Man hat da aktuell nicht viele andere Möglichkeiten: schau dir die Kommentare hier und woanders doch an - wenn wir nicht-systemd rauswerfen kommt ein wütender Mob mit Mistgabeln
Ich sehe es so, dass ich von diesen Leuten erwarte, dass sie sich darum kümmern, dass ihr Code weiter funktioniert. So wie ich von BSDs erwarte, dass sie sich um den BSD-spezifischen Code kümmern.
Ich könnte auch die Mistgabel herausholen weil der alte ATI-Grafikchip (mach64) in einem meiner Server vom Linux-Kernel keinen KMS-Treiber bekommt, aber das wäre Energieverschwendung. Also hänge ich eben einen USB2VGA-Adapter von DisplayLink an das Ding, welcher inzwischen ja einen KMS-Treiber hat, und lerne damit zu leben.
Sollen diese Fortschrittsverweigerer doch forken, mal sehen wie lange sie dann noch durchhalten...
Und bei Pulseaudio ab Version 6 ist das neuerdings auch die empfohlene Vorgehensweise
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 05. Feb 2015 um 13:41.Das ist auch meiner Meinung nach der wesentlichste Punkt in dem ganzen Text. startkde in seiner aktuellen Form ist ein ziemlich undurchsichtiges und lahmes Skript, welches aber auch schon versucht wurde zu ersetzen (Projekt hieß sessionk).
Lezteres verlief sich aber im Sand und ich sehe auch keinen Grund, warum man diese Funktionalität nicht direkt in systemd-units übertragen könnte.
Durch diesen Ansatz könnte man auch die Diensteverwaltung von z.B. Gnome- und KDE-Anwendungen etwas vereinheitlichen. Aktuell wird nur bei KDE Anwendungen z.B. bei einem Crash direkt der entsprechende Dialog mit Backtrace gestartet. Genau das ist aber für etwas unbedarftere Anwender sehr praktisch, wenn es um Fehleranalyse geht.
Wenn man das auf einem KDE Desktop in gleicher Weise auch für Gnome-Programme umsetzen könnte, weil beide die Funktionalität von systemd Units nutzen, dann hätte man hier schon einen signifikanten Mehrwert.
Dazu kommt natürlich noch, dass startkde den Start von KDE deutlich ausbremst und es sich schon lohnen kann, diesen Bremsklotz zu entfernen.
Aber hier werden natürlich hier wieder 90% der User einwenden, dass man Computer doch niemals neu startet...
Das startkde script ist in Sekundenbruchteilen durch. Das script ruft kdeinit auf was ksmserver aufruft. Letzteres ist was den Löwenanteil an Zeit und Arbeit kostet und wo sessionk ansetzte (beides session manager). Siehe https://dantti.wordpress.com/2013/02/27/1-2-3-plasma/
Die Aussage das "starting the KDE services in order in a list" ist etwas ungenau bzw. kann durch den Satzbeginn falsch verstanden werden, trifft den Kern des Problems aber ziemlich gut. Das passiert nicht im shellscript sondern ist Verteilt auf diverse Bestandteil die alle C/C++ sind. Der Folgesatz über kded deutet in die Richtung, benennt einen Bestandteile.
Mit systemd könnte man Socket-Activation verwenden, so dass Dienste auch dann schon gestartet werden können, wenn ein anderer Dienst noch nicht läuft. Man kann sehr vieles parallel starten und umgeht damit viele der Fragestellungen dieses Skripts.
kded war mir persönlich schon immer ein Dorn im Auge. Wenn man in einem dieser Teile auf ein Problem gestoßen ist, dann wurde es teilweise recht kompliziert herauszufinden, wo genau das Problem sich versteckt. Ich hatte diesen Spaß mal mit einem KIO Interface (glaube bluetooth) und habe Stunden damit verbracht das Problem zu suchen...
Socket activation geht auch ohne systemd. Du hat allerdings Recht, dass startkde nicht gerade schnell ist, und man einen Teil dieses Overheads vermeiden könnte.
Typisches bootchart: http://i.imgur.com/JYLnv.png
Man beachte I/O und mem und vergleiche auf einem ~15 Jahre alten Rechner, die Zeit in der die KDE Startup Infrastruktur entstanden ist. Festhalten lässt sich: Der I/O und mem bound ist fast komplett verschwunden, das sind keine Flaschenhälse mehr. Die Beobachtung kombiniert mit Wissen über damalige Prozesskosten hilft beim Design-Verstândniss, auch von zB kded. Kombiniert mit etwas Wissen über die gewachsene Bedeutung von Nebenläufigkeit und schon sehen einige der damaligen Anforderungen, und damit Lösungen, heute anders aus.
Ferner sind Wartezeiten der einzelnen Komponenten ersichtlich. startkde taucht erst gar nicht auf während hier offensichtlich einige Komponenten andere vom starten abhalten oder später Zeitversetzt starten (zB dbus- oder vergleichbare ondemand-Activations, ein alter Hut mit Bart der von zB KDE schon lange genutzt wird).
Nun braucht es etwas Willen in den Code zu gucken um zu verstehen was, wie und warum überhaupt gestartet wird und warum diese Lücken existieren. Ich verweise auf Dantti's block und stelle damals wie heute fest, und liege damit wohl auf Linie mit David, das die neuen Anforderungen eine Überarbeitung des gesammten Startup-Stacks erfordern. sessionk war da schon ein richtiger Ansatz. Natürlich kann man das auch anders machen, ob nun systemd unitfiles oder eine Sammlung an Shellscripten ist dabei total irrelevant. Mit beiden lässt sich dasselbe erreichen, die neuen Anforderungen (Nebenläufigkeit) umzusetzen.
Warum also systemd unitfiles? Weil es ein möglicher Ansatz ist und den jemand umsetzt! So funktioniert FLOSS nun mal. Natürlich wissen wir auch alle das es dabei nicht bleibt weil immer jemand es besser oder einfach anders macht und wenn der Wille da ist es auch tut. Auch so funktioniert FLOSS.
Und so muss man den auch systemd begreifen. Rumheulen bringt nichts. Selber machen oder warten bis es jemand selber macht. Den wenn eines Gewiss ist, dann das systemd auch nur ein Schritt ist und auf einen Schritt immer der nächste folgt der noch besser oder einfach anders ist. Den auch das ist FLOSS.
Also ich finds toll
..... KDE und systemd in einem Artikel. Jetzt kommen sie bestimmt gleich wieder aus ihren Löchern gekrochen.
Ich hol mir mal Popcorn
süß oder salzig?
Süß
Das Salz heb' ich mir für die Wunden der KDE-Hasser auf
Wer hasst schon KDE, Mitleid ist da schn eher angebracht.
Wir implementieren nicht mehr selbst und setzen voraus alle anderen nutzen auch Systemd-kompatiblen Kram. Da wir kein Interesse an Plattformunabhängigkeit und weniger Abhängigkeiten haben sind wir voll zufrieden und tanzen auf dem Kornfeld, nackt.
PS: Alle anderen sind doof, ich hab doch voll die Argumente.
@Peter; bau dir selber was, wenns dir nicht gefällt! Die Entwickler entwickeln, was ihnen gefällt und du kannst es nutzen oder halt nicht. Was ist das Problem?
Leute wie du, die dann sofort wieder wegen unnötigen Forks und Grabenkämpfe im Opensource-Umfeld heulen, obwohl "wir" doch den gemeinsamen pösen pösen Feind aus Redmond besiegen sollten.
Hach ja, wären doch mal alle amd64/SSD/IntelGPU/GNU/Linux/systemd/KDE-Nutzer... Aber die Ungläubigen kriegen wir schon noch klein!
Gibt noch jede Menge 32bit Rechner auf denen man KDE4 und systemd benutzen kann. Unsachliches Gejammer!
> Wir implementieren nicht mehr selbst und setzen voraus alle anderen nutzen auch Systemd-kompatiblen Kram.
Naja, dass die Desktop Entwickler das gerne benutzen anstatt der komplexen, halbgaren und fehleranfälligen Lösungen die man halt implementiert hat weils nix anderes gab ist klar.
Systemd überzeugt halt an der Stelle und setzt so die (defakto) Standards, eben teils wie beschrieben auch an Stellen wo es vorher nix vergleichbares gab. Wer diese Features auf einer anderen Plattform haben will muss halt die Entsprechenden dbus APIs bereit stellen. Hat immerhin den Vorteil, dass es dann alle benutzen können und nicht nur KDE.
Wir implementieren nicht mehr selbst, sondern setzen auf dokumentierte Systemschnittstellen. Das dient besonders der Plattformunabhängigkeit, da wir so platformspezifischen Code nicht mehr selbst implementieren müssen.
PS: Gleicher Inhalt, nur etwas umformuliert. Das bisher nur systemd die Schnittstellen und zentalen Daemonen anbietet ist etwas schade, ich denke aber das andere bald nachziehen werden.
Naja, so ist es dann halt doch nicht. Aktuell haben wir systemd-Unterstützung immer nur zusätzlich eingebaut. Z.B. als ich mittels systemd sicherstellte, dass die Sitzung gesperrt wird, wenn der Rechner in den Suspend geht, haben wir zusätzlich noch einen Fallback für nicht-systemd eingebaut. Dabei Code in mehreren Kompnenten angepasst. Siehe hier und hier. Natürlich werden jetzt nur die systemd Nutzer davon profitieren, da es keine andere Lösung dafür gibt.
Warum hat David sich timedate angeschaut? Naja weil er eine Sicherheitslücke in unserem Code gefunden hat und sie behoben hat und nun nach besseren Lösungen schaut. Im aktuellen Code-Review dafür ist auch der nicht-systemd Pfad noch vorhanden und wir diskutieren darüber, wie man für nicht systemd eine gute Lösung bereitstellen kann.
Aber sorgt diese nicht-systemd Kompatibilität nicht gleichzeitig auch dafür das es für euch schwerer wird den Code zu unterhalten? Irgendwie habe ich das Gefühl das es langsam an der Zeit ist die alten Zöpfe endgültig abzuscheiden.
Ach, je kompexer, desto kewler!
Code zu pflegen ist unkewl. Das will eh keiner von denen.
Nur weil openGLES3 gestern rausgekommen ist schmeisst man heute ja nicht alles OpenGLES2 weg.
Mit der Zeit ersetzen neue Sachen alte Sachen. Wenn den keiner oder wenige die alten Sache noch nutzen kommen sie halt raus. In der Übergangszeit unterstützt man halt beides. Migration nennt sich sowas. Passiert aktuell auch zB bei X11 und Wayland und es kann einiges dauern bis sie vollzogen ist.
Den: "breaking the desktop is actually not a valid use case"
Klar jeder ifdef erhöht die Komplexität. Man hat da aktuell nicht viele andere Möglichkeiten: schau dir die Kommentare hier und woanders doch an - wenn wir nicht-systemd rauswerfen kommt ein wütender Mob mit Mistgabeln
Ich sehe es so, dass ich von diesen Leuten erwarte, dass sie sich darum kümmern, dass ihr Code weiter funktioniert. So wie ich von BSDs erwarte, dass sie sich um den BSD-spezifischen Code kümmern.
Mensch, Martin, hast Du schon mal versucht mit einer Mistgabel zu programmieren? Mit Mistgabeln kann man nur forken, sonst nix.
Ich könnte auch die Mistgabel herausholen weil der alte ATI-Grafikchip (mach64) in einem meiner Server vom Linux-Kernel keinen KMS-Treiber bekommt, aber das wäre Energieverschwendung. Also hänge ich eben einen USB2VGA-Adapter von DisplayLink an das Ding, welcher inzwischen ja einen KMS-Treiber hat, und lerne damit zu leben.
Sollen diese Fortschrittsverweigerer doch forken, mal sehen wie lange sie dann noch durchhalten...