ein bißchen Beigeschmack hat diese Linux-kernel-only-Bindung dann doch. Zumindest wenn userland-programme dbus-broker mal zwingend voraussetzen sollten. Was sollen dann BSD & Co machen (siehe gnome/gdm mit systemD)? Solange die Wahl bleibt ist es ja okay. Oder man holt gleich mal ein paar Leute anderer Kernel mit ins Boot und schaut, was sich da machen läßt. Wäre ja für alle schön, wenn etwaige Schwächen eines solchen Userland-Systems ausgebügelt werden könnten.
Zumindest aktuell ist es ja als kompatibel zu dbus geplant, also sollte es da keine Probleme geben.
Mittelfristig soll es wohl nach Möglichkeit auf Bus1 aufsetzen, alleine damit wäre halt schon die Linux-Bindung gegeben. Aber wenn es möglich wäre das auf Bus1 aufzubauen, dann könnte es ja auch möglich sein das mit einem anderen IPC zu erreichen.
Ich kann die Linux-only Geschichte aber schon verstehen. Erstens sind das meistens Leute die auf Linux entwickeln und sich dementsprechend nicht unbedingt gut mit dem Kernel der BSD auskennen und zweitens ist es ja auch nicht unbedingt verkehrt die Möglichkeiten, die der Linux Kernel bietet auch auszuschöpfen. Wenn man sich immer auf den kleinsten gemeinsamen Nenner verständigen will, dann muss man ggf. mit signifikanten Einschränkungen leben. (Ob die hier jetzt signifikant sind oder nicht vermag ich nicht zu beurteilen.)
Von Anon Y. Mouse am Do, 24. August 2017 um 21:47 #
Man kann von den entwicklern um pöttering und ihrer sw ja halten was man möchte. Da möchte ich mich auch garnicht drauf einlassen. Ich finds einfach nur arrogant und kurzsichtig alles auf linux only auszulegen. Ich berszehe ja, dass man zb bsd nicht kennt. Aber mindestens eine mail auf die paar einschlägigen entwicköer mls zu senden mit dem angebot zur beteiligung dürfte einen ja nicht das gesicht verlierwn lassen...
Schade drum, linux wird mehr und mehr zur egoistwen oase, die die welt drumherum nicht mehr wahrnehmen will.
Mag sein, wobei man nicht genau weiß, ob solche Gespräche stattgefunden haben oder nicht.
Soweit ich mich an solche Diskussionen erinnern kann war es auch häufig so, dass die BSD Entwickler eh nicht so viel Interesse daran hatten da gleiche Schnittstellen zu schaffen, sondern eher dazu tendieren ihr eigenes Ding zu machen.
Abgesehen bleibt dann immer noch das Problem, dass man sich oft auf den kleinsten gemeinsamen Nenner beschränken muss. Dadurch verlagert man unter Umständen auch vieles in den Userspace, was möglicherweise auch bedeutet, dass man einiges an Konzepten und Code dupliziert. (Die Diskussion was in den Userspace und was in den Kernel gehört möchte ich aber gar nicht erst anfangen, das würde wohl kein Ende nehmen.)
Von Anon Y. Mouse am Fr, 25. August 2017 um 20:24 #
Ohne etwas konkretes zu wissen bin ich mir fast sicher dass da nicht mal im Traum an eine Zusammenarbeit gedacht wurde. Äusserungen bei systemd gnome aber auch ath5k etc warem meist mehr in der Richtung nehmen ist ok zurückgeben ist schlecht weil gpl, bsd will nicht, kann nicht, zählt nicht. Und sonst kommen Argumente wie live wallpapers werden langsam wenn wir nicht auf linuxismen zurückgreifen dürfen oder dann muss man ja 2 backends pflegen.
dbus-broker sieht sich nicht mehr als »Bus«, sondern ermöglicht nur noch die Kommunikation zwischen jeweils zwei Partnern.
Wie soll ich das verstehen? Können hier nur noch zwei Prozesse mit einander kommunizieren? Was passiert zum Beispiel im Fall von MPRIS wo gern mal mehrere Frontends versuchen den Media-Player zu steuern?
Ich vermute mal, dass der Umstieg vom Bus auf eine Sterntopologie hier keine Nachteile hat. Das dürfte in etwa dem Unterschied zwischen einem Switch und einem Hub in einem Netzwerk entsprechen. Der Vorteil ist die im Artikel beschriebene Kontrolle der Ressourcen. Probleme könnte es nur dann geben, wenn einer der Kommunikationspartner Teile der veralteten Spezifikation verwendet. Änderungsbedarf bei den Kommunikationspartnern sehe ich hier nur Aufgrund des Umstandes, dass eine fehlgeschlagene Zustellung in einer Fehlermeldung durch den dbus-broker resultiert. Das Konzept gefällt mir deutlich besser, als die Implementierung im Kernelspace, wie sie Kdbus vorsah. Bezüglich der Kompatibilität zu den BSD kann ich nur empfehlen: Falls dbus-broker eine linuxspezifische Schnittstelle nutzt, so sollte man einerseits im BSD-Umfeld prüfen, ob die Implementierung einer vergleichbaren Schnittstelle sinnvoll ist oder andererseits die Möglichkeit besteht auf eine in beiden Welten, besser noch im gesamten POSIX-kompatiblen Bereich, existierende Schnittstelle umzusteigen besteht.
who knows Edit: Satzbau
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 24. Aug 2017 um 15:26.
mit Kdbus eine entsprechende Beschleunigung auch für DBus im Kernel zu implementieren, scheiterte jedoch vor bald zwei Jahren an technischen Gründen, da verschiedene Entwickler es weder für allgemein noch für schnell genug hielten, und wurde danach auf unbestimmte Zeit verschoben.
Nicht ganz. Das Hauptproblem waren fehlerhafte Design-Entscheidungen [1][2]. Daher auch die Folgeentscheidung kdbus nicht nur zu überarbeiten sondern komplett neu zu designen [3]. Bus1 war genau dieses redesign [4].
Wenn ich so lese: Greg Kroah-Hartman, Tom Gundersen, in deren Bug-Tracker dann auch noch Kay Sievers, Fedora und Arch Linux, im Wiki auf github u.a. "systemctl --user enable dbus-broker.service" und im Blog "Rethinking ...", und dann noch das Totschlagargument schlechthin, dass dbus ja schon sooooo (15 Jahre) alt ist und man deshalb unbedingt was neues braucht, dann werd ich das Gefühl nicht los, dass da schon wieder Poettering und seine Fanboys dahinter stecken. Bin mal gespannt, wie viele Abhängigkeiten zu systemd da wieder verbaut sind, wann das komplett in systemd integriert wird und ob es überhaupt möglich sein wird, das auch ohne systemd zum Laufen zu bringen.
Und bei dem Begriff "Dysfunctional Programming" kommen mir eigentlich auch nur Poettering und Konsorten in den Sinn. "Ponyhof" bringt mich auch nicht unbedingt auf bessere Ideen.
Bin mal gespannt. Aber immerhin wirds dbus ja erstmal noch weiterhin geben.
Im Übrigen steht auf Wikipedia was von "Initial release: November 2006; 10 years ago". Da haben Poettering und seine Kumpanen wohl vom Aufkommen der ersten Idee zu sowas wie dbus gerechnet.
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 25. Aug 2017 um 16:28.
Idiotischer Kommentar. Einfach besser machen. Pöttering und seine "Fanboys" helfen dabei, Linux auf moderne Füße zu stellen. Systemd war lange überfällig und ein Ersatz für DBus aus den im Artikel genannten Gründen notwendig. Geh mit der Zeit oder geh
Der war gut. "Poettering und seine Fanboys helfen dabei, Linux auf moderne Füße zu stellen. Systemd war lange überfällig." YMMD!
Ich hoffe, du meintest das nicht ernst.
Ist im Übrigen schon sehr peinlich, auf einen fast zwei Jahre alten Kommentar zu antworten. Poettering und seine Fanboys halt. Da klappt das selbst mit der Zeitrechnung nicht so richtig, wie im ursprünglichen Kommentar ja schon bewiesen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 15. Apr 2019 um 05:25.
ein bißchen Beigeschmack hat diese Linux-kernel-only-Bindung dann doch. Zumindest wenn userland-programme dbus-broker mal zwingend voraussetzen sollten. Was sollen dann BSD & Co machen (siehe gnome/gdm mit systemD)? Solange die Wahl bleibt ist es ja okay.
Oder man holt gleich mal ein paar Leute anderer Kernel mit ins Boot und schaut, was sich da machen läßt. Wäre ja für alle schön, wenn etwaige Schwächen eines solchen Userland-Systems ausgebügelt werden könnten.
Zumindest aktuell ist es ja als kompatibel zu dbus geplant, also sollte es da keine Probleme geben.
Mittelfristig soll es wohl nach Möglichkeit auf Bus1 aufsetzen, alleine damit wäre halt schon die Linux-Bindung gegeben.
Aber wenn es möglich wäre das auf Bus1 aufzubauen, dann könnte es ja auch möglich sein das mit einem anderen IPC zu erreichen.
Ich kann die Linux-only Geschichte aber schon verstehen.
Erstens sind das meistens Leute die auf Linux entwickeln und sich dementsprechend nicht unbedingt gut mit dem Kernel der BSD auskennen und zweitens ist es ja auch nicht unbedingt verkehrt die Möglichkeiten, die der Linux Kernel bietet auch auszuschöpfen.
Wenn man sich immer auf den kleinsten gemeinsamen Nenner verständigen will, dann muss man ggf. mit signifikanten Einschränkungen leben.
(Ob die hier jetzt signifikant sind oder nicht vermag ich nicht zu beurteilen.)
Man kann von den entwicklern um pöttering und ihrer sw ja halten was man möchte. Da möchte ich mich auch garnicht drauf einlassen. Ich finds einfach nur arrogant und kurzsichtig alles auf linux only auszulegen. Ich berszehe ja, dass man zb bsd nicht kennt. Aber mindestens eine mail auf die paar einschlägigen entwicköer mls zu senden mit dem angebot zur beteiligung dürfte einen ja nicht das gesicht verlierwn lassen...
Schade drum, linux wird mehr und mehr zur egoistwen oase, die die welt drumherum nicht mehr wahrnehmen will.
Mag sein, wobei man nicht genau weiß, ob solche Gespräche stattgefunden haben oder nicht.
Soweit ich mich an solche Diskussionen erinnern kann war es auch häufig so, dass die BSD Entwickler eh nicht so viel Interesse daran hatten da gleiche Schnittstellen zu schaffen, sondern eher dazu tendieren ihr eigenes Ding zu machen.
Abgesehen bleibt dann immer noch das Problem, dass man sich oft auf den kleinsten gemeinsamen Nenner beschränken muss.
Dadurch verlagert man unter Umständen auch vieles in den Userspace, was möglicherweise auch bedeutet, dass man einiges an Konzepten und Code dupliziert.
(Die Diskussion was in den Userspace und was in den Kernel gehört möchte ich aber gar nicht erst anfangen, das würde wohl kein Ende nehmen.)
Ohne etwas konkretes zu wissen bin ich mir fast sicher dass da nicht mal im Traum an eine Zusammenarbeit gedacht wurde. Äusserungen bei systemd gnome aber auch ath5k etc warem meist mehr in der Richtung nehmen ist ok zurückgeben ist schlecht weil gpl, bsd will nicht, kann nicht, zählt nicht. Und sonst kommen Argumente wie live wallpapers werden langsam wenn wir nicht auf linuxismen zurückgreifen dürfen oder dann muss man ja 2 backends pflegen.
Ich finds schade...
Was passiert zum Beispiel im Fall von MPRIS wo gern mal mehrere Frontends versuchen den Media-Player zu steuern?
Ich vermute mal, dass der Umstieg vom Bus auf eine Sterntopologie hier keine Nachteile hat. Das dürfte in etwa dem Unterschied zwischen einem Switch und einem Hub in einem Netzwerk entsprechen. Der Vorteil ist die im Artikel beschriebene Kontrolle der Ressourcen. Probleme könnte es nur dann geben, wenn einer der Kommunikationspartner Teile der veralteten Spezifikation verwendet. Änderungsbedarf bei den Kommunikationspartnern sehe ich hier nur Aufgrund des Umstandes, dass eine fehlgeschlagene Zustellung in einer Fehlermeldung durch den dbus-broker resultiert.
Das Konzept gefällt mir deutlich besser, als die Implementierung im Kernelspace, wie sie Kdbus vorsah.
Bezüglich der Kompatibilität zu den BSD kann ich nur empfehlen: Falls dbus-broker eine linuxspezifische Schnittstelle nutzt, so sollte man einerseits im BSD-Umfeld prüfen, ob die Implementierung einer vergleichbaren Schnittstelle sinnvoll ist oder andererseits die Möglichkeit besteht auf eine in beiden Welten, besser noch im gesamten POSIX-kompatiblen Bereich, existierende Schnittstelle umzusteigen besteht.
who knows
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 24. Aug 2017 um 15:26.Edit: Satzbau
Nicht ganz. Das Hauptproblem waren fehlerhafte Design-Entscheidungen [1][2]. Daher auch die Folgeentscheidung kdbus nicht nur zu überarbeiten sondern komplett neu zu designen [3]. Bus1 war genau dieses redesign [4].
[1] http://lkml.iu.edu//hypermail/linux/kernel/1504.1/03981.html
[2] https://lkml.org/lkml/2015/11/12/8
[3] http://lkml.iu.edu/hypermail/linux/kernel/1511.1/00247.html
[4] https://www.golem.de/news/systemd-konferenz-kdbus-ist-nicht-tot-1511-117313.html
Der Kommentar ist deutlich konziser, korrekter und informativer als der Artikel.
Wenn ich so lese: Greg Kroah-Hartman, Tom Gundersen, in deren Bug-Tracker dann auch noch Kay Sievers, Fedora und Arch Linux, im Wiki auf github u.a. "systemctl --user enable dbus-broker.service" und im Blog "Rethinking ...", und dann noch das Totschlagargument schlechthin, dass dbus ja schon sooooo (15 Jahre) alt ist und man deshalb unbedingt was neues braucht, dann werd ich das Gefühl nicht los, dass da schon wieder Poettering und seine Fanboys dahinter stecken. Bin mal gespannt, wie viele Abhängigkeiten zu systemd da wieder verbaut sind, wann das komplett in systemd integriert wird und ob es überhaupt möglich sein wird, das auch ohne systemd zum Laufen zu bringen.
Und bei dem Begriff "Dysfunctional Programming" kommen mir eigentlich auch nur Poettering und Konsorten in den Sinn. "Ponyhof" bringt mich auch nicht unbedingt auf bessere Ideen.
Bin mal gespannt. Aber immerhin wirds dbus ja erstmal noch weiterhin geben.
Im Übrigen steht auf Wikipedia was von "Initial release: November 2006; 10 years ago". Da haben Poettering und seine Kumpanen wohl vom Aufkommen der ersten Idee zu sowas wie dbus gerechnet.
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 25. Aug 2017 um 16:28.Alles Verschwörung!
so isses....
i love artix
Idiotischer Kommentar. Einfach besser machen. Pöttering und seine "Fanboys" helfen dabei, Linux auf moderne Füße zu stellen. Systemd war lange überfällig und ein Ersatz für DBus aus den im Artikel genannten Gründen notwendig.
Geh mit der Zeit oder geh
*rofl*
Der war gut. "Poettering und seine Fanboys helfen dabei, Linux auf moderne Füße zu stellen. Systemd war lange überfällig." YMMD!
Ich hoffe, du meintest das nicht ernst.
Ist im Übrigen schon sehr peinlich, auf einen fast zwei Jahre alten Kommentar zu antworten. Poettering und seine Fanboys halt. Da klappt das selbst mit der Zeitrechnung nicht so richtig, wie im ursprünglichen Kommentar ja schon bewiesen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 15. Apr 2019 um 05:25.