Login
Login-Name Passwort


 
Newsletter
Werbung

Thema: dbus-broker erfindet DBus neu

12 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von Tuxentier2011 am Do, 24. August 2017 um 10:48 #

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.

  • 1
    Von blubb am Do, 24. August 2017 um 10:58 #

    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.)

    • 1
      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.

      • 1
        Von blubb am Fr, 25. August 2017 um 08:45 #

        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.)

        • 0
          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.

          Ich finds schade...

0
Von schmidicom am Do, 24. August 2017 um 13:00 #

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?

  • 1
    Von who knows am Do, 24. August 2017 um 15:19 #

    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.
1
Von Historiker am Do, 24. August 2017 um 18:34 #


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].

[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

0
Von cyberpatrol am Fr, 25. August 2017 um 16:16 #

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.
Pro-Linux
Traut euch!
Neue Nachrichten
Werbung