Das Problem ist doch, dass mit kdbus eine direkte Abhängigskeit des Kernels zu systemd implementiert wird. Linux-Systeme ohne systemd werden dann schwer(er) realisierbar.
Und nein, ich bin kein "Poettering-Hasser". Es gibt Fälle, in denen systemd Sinn macht, aber auch Fälle, in denen systemd unnötiger Ballast ist und andere Init-Systeme besser sind. Daher ist es wichtig, die Möglichkeit offen zu halten, Linux ohne systemd zu betreiben.
"dass mit kdbus eine direkte Abhängigkeit des Kernels zu systemd implementiert wird"
Ehrlich gesagt habe ich noch nicht so ganz verstanden, worin diese Abhängigkeit besteht. Ich dachte immer dbus und kdbus wären mehr oder weniger austauschbar, nur dass das eine schneller ist. Irre ich mich da?
Es gibt soweit ich weiß durchaus Unterschiede. Mit kdbus wollen die Entwickler an Informationen ran an die sie mit dbus nicht ran kommen. Das ist auch einer der Kritikpunkte. Einigen gehen zu viele Informationen über diese Schnittstelle.
Außerdem scheint kdbus nur lokal zu funktionieren während dbus theoretisch auch über Netzwerk funktioniert, auch wenn es kaum genutzt wird.
Ich denke aber es sollte nicht schwer sein einen dünnen Layer zu bauen der die Unterschiede ausgleicht. Dann wäre es egal ob Software mit dbus oder kdbus läuft. Zudem ist es so das die meiste Software weder das eine noch das andere benötigen um zu funktionieren.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 29. Jun 2015 um 14:01.
Einigen gehen zu viele Informationen über diese Schnittstelle.
Ja, aber da geht es eigentlich eher um Infos, die bei dbus mitgesendet werden, aber nach Meinung einiger in einem Kernel-internen IPC nichts verloren haben.
Problem bzgl. kdbus vs. dbus wäre vermutlich eher, dass Programme anfangen könnten Dinge über (k)dbus anzustellen (i.e. Versand von größeren Datenmengen), die mit kdbus unproblematisch sind, bei dbus aber problematisch werden würden.
dbus erlaubt das senden von filedescriptoren und damit sind grosse Datenmengen kein Problem. Das Geschwindigkeitsargument wurde auch bereits wiederlegt.
Es geht ja nicht darum, ob etwas mit dbus möglich wäre oder nicht, sondern nur darum, dass es problematisch würde, wenn man Dinge mit dbus anstellt, die mit dbus nicht gut funktionieren.
mit normalem DBus muessen Daten unnoetig in die verschiedenen Addressraeume der Prozesse kopiert werden, eine kernel implementierung umgeht das. Das gleiche macht z.b. auch Androids Binder seit Jahren. Wo der Zusammenhang systemd kdbus ist sehe ich auch nicht!
Es ist allerdings fraglich ob das Kopieren zwischen Addressräumen für dbus Geschwindigkeitsrelevant ist. Die bisherigen Tests wiederlegen das allesamt.
Es ist allerdings fraglich ob das Kopieren zwischen Addressräumen für dbus Geschwindigkeitsrelevant ist. Die bisherigen Tests wiederlegen das allesamt.
Es ist allerdings fraglich ob das Kopieren zwischen Addressräumen für dbus Geschwindigkeitsrelevant ist. Die bisherigen Tests wiederlegen das allesamt.
Von Ödi Pödie und die Ötter Pötter am Mo, 29. Juni 2015 um 14:51 #
> Das Problem ist doch, dass mit kdbus eine direkte > Abhängigskeit des Kernels zu systemd implementiert > wird. Linux-Systeme ohne systemd werden dann > schwer(er) realisierbar.
Umgekehrt könnte ein Schuh draus werden. Dem Kernel ist ziemlich schnurz ob ein systemd, runit, oder was weiß ich als Prozess 1 läuft. Systemd könnte aber eines Tages abhängig vom kdbus sein. Das stört die anderen Init-Systeme aber nicht die Bohne.
Du wurdest ja schon verbessert hinsichtlich Abhängigkeit Kernel zu Systemd. Solange nicht Drittentwickler auf den Zug aufspringen und nur noch KDBUS über Systemd verwenden ist da kein Problem. Ich denke nur, genau das wird auch geschehen. Entwickler sind träge und gehen immer von der Konfiguration der Mehrheit der Nutzer aus. Scheint mittlerweile ja zu guten Ton zu gehören Plattformunabhängigkeit zu opfern.
Von Anonymous Coward am Mo, 29. Juni 2015 um 19:33 #
Das Problem ist doch, dass mit kdbus eine direkte Abhängigskeit des Kernels zu systemd implementiert wird. Linux-Systeme ohne systemd werden dann schwer(er) realisierbar.
Das ist natürlich mal wieder völlig falsch und ein typisches Beispiel für die Realitätsverdrehung der Poettering-Hasser. Fakt ist: kdbus ist vollkommen optional, niemand ist gezwungen, es zu benutzen. Der ganz normale, klassische dbus-daemon wird weiterhin funktionieren. Und auch kdbus benötigt nicht systemd, sondern stellt Syscall-Schnittstellen bereit, die der Userspace nutzen kann. Derzeit tut das nur systemd, aber wenn die Poettering-Hassertruppe so scharf darauf ist, kann sie auch gern eine Alternative implementieren.
Das Problem ist doch, dass mit kdbus eine direkte Abhängigskeit des Kernels zu systemd implementiert wird. Linux-Systeme ohne systemd werden dann schwer(er) realisierbar.
Und nein, ich bin kein "Poettering-Hasser". Es gibt Fälle, in denen systemd Sinn macht, aber auch Fälle, in denen systemd unnötiger Ballast ist und andere Init-Systeme besser sind. Daher ist es wichtig, die Möglichkeit offen zu halten, Linux ohne systemd zu betreiben.
"dass mit kdbus eine direkte Abhängigkeit des Kernels zu systemd implementiert wird"
Ehrlich gesagt habe ich noch nicht so ganz verstanden, worin diese Abhängigkeit besteht. Ich dachte immer dbus und kdbus wären mehr oder weniger austauschbar, nur dass das eine schneller ist. Irre ich mich da?
Es gibt soweit ich weiß durchaus Unterschiede. Mit kdbus wollen die Entwickler an Informationen ran an die sie mit dbus nicht ran kommen.
Das ist auch einer der Kritikpunkte. Einigen gehen zu viele Informationen über diese Schnittstelle.
Außerdem scheint kdbus nur lokal zu funktionieren während dbus theoretisch auch über Netzwerk funktioniert, auch wenn es kaum genutzt wird.
Ich denke aber es sollte nicht schwer sein einen dünnen Layer zu bauen der die Unterschiede ausgleicht. Dann wäre es egal ob Software mit dbus oder kdbus läuft. Zudem ist es so das die meiste Software weder das eine noch das andere benötigen um zu funktionieren.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 29. Jun 2015 um 14:01.Problem bzgl. kdbus vs. dbus wäre vermutlich eher, dass Programme anfangen könnten Dinge über (k)dbus anzustellen (i.e. Versand von größeren Datenmengen), die mit kdbus unproblematisch sind, bei dbus aber problematisch werden würden.
dbus erlaubt das senden von filedescriptoren und damit sind grosse Datenmengen kein Problem. Das Geschwindigkeitsargument wurde auch bereits wiederlegt.
Es geht ja nicht darum, ob etwas mit dbus möglich wäre oder nicht, sondern nur darum, dass es problematisch würde, wenn man Dinge mit dbus anstellt, die mit dbus nicht gut funktionieren.
Wie war das nochmal: Wenn das einzige Werkzeug dass man sein eigen nennt ein Hammer ist, sehen alle Probleme wie Nägel aus.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 30. Jun 2015 um 11:57.mit normalem DBus muessen Daten unnoetig in die verschiedenen Addressraeume der Prozesse kopiert werden, eine kernel implementierung umgeht das. Das gleiche macht z.b. auch Androids Binder seit Jahren. Wo der Zusammenhang systemd kdbus ist sehe ich auch nicht!
Es ist allerdings fraglich ob das Kopieren zwischen Addressräumen für dbus Geschwindigkeitsrelevant ist. Die bisherigen Tests wiederlegen das allesamt.
Es ist allerdings fraglich ob das Kopieren zwischen Addressräumen für dbus Geschwindigkeitsrelevant ist. Die bisherigen Tests wiederlegen das allesamt.
Es ist allerdings fraglich ob das Kopieren zwischen Addressräumen für dbus Geschwindigkeitsrelevant ist. Die bisherigen Tests wiederlegen das allesamt.
> Das Problem ist doch, dass mit kdbus eine direkte
> Abhängigskeit des Kernels zu systemd implementiert
> wird. Linux-Systeme ohne systemd werden dann
> schwer(er) realisierbar.
Umgekehrt könnte ein Schuh draus werden. Dem Kernel ist ziemlich schnurz ob ein systemd, runit, oder was weiß ich als Prozess 1 läuft. Systemd könnte aber eines Tages abhängig vom kdbus sein. Das stört die anderen Init-Systeme aber nicht die Bohne.
Du wurdest ja schon verbessert hinsichtlich Abhängigkeit Kernel zu Systemd.
Solange nicht Drittentwickler auf den Zug aufspringen und nur noch KDBUS über Systemd verwenden ist da kein Problem.
Ich denke nur, genau das wird auch geschehen. Entwickler sind träge und gehen immer von der Konfiguration der Mehrheit der Nutzer aus. Scheint mittlerweile ja zu guten Ton zu gehören Plattformunabhängigkeit zu opfern.