Announcement

Collapse
No announcement yet.

D-Bus Broker 18 Released While BUS1 In-Kernel IPC Remains Stalled

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Farmer
    replied
    From what I remember one of the two main developers of "BUS1" was Kay Sievers. Given the collision between him and Torvalds over the systemd debug thing I wasn't surprised that BUS1 was being held to a rigid standard. Apparently they couldn't conform to it. Kroah-Hartman tired to place himself between the two groups for BUS1 but that apparently didn't last.

    From memory. Wasn't involved - just remembering from ages later.

    Leave a comment:


  • geearf
    replied
    Since it's provided by my distribution I just switched to using dbus-broker, not sure of the benefits yet but we'll see if it works fine at least.

    Leave a comment:


  • cl333r
    replied
    Yeah, having a faster (and modern) D/Bus is good regardless of whether it's being misused by others.

    Leave a comment:


  • LuukD
    replied
    I'd love to see the dbus-broker more widely adopted, have more distributions embrace it or at-least offer it as a choice. dbus-broker means speeding up (threefold) all sorts of communication behind-the-scenes. If you have ever used Orca (tool using AT-SPI2; an accessibility protocol over D-Bus) you will have noticed a lot of actions yield a noticeable lag with dbus daemon. Now imagine you _depend_ on it. Shivers!
    Either dbus is sped up (which is a full basket of fruit hanging low with dbus-broker available) - or alternatively whole ecosystems (clients, servers and protocol implementors) who at-least care somewhat about responsive behaviour and reliability over dbus has to convince every client and migrate to some other IPC method.

    On a reddit thread on BUS1, someone argued that the push for faster dbus was pushed (or perhaps driven ) by automobile manufacturers and because they should not use dbus for those intents and purposes in the first place, BUS1 should not be included in the kernel.
    Yes, interfaces are abused all the time, but that should not stop us from making those offerings faster, better, stronger. The car manufacturer who may or may not have picked the wrong IPC method will eventually find out. Wasting cycles while we can do much better to nudge some in a different direction is wasting our time and comfort too.

    Leave a comment:


  • LuukD
    replied
    @babali
    Linus' concerns with BUS1 boiled down to security concerns. Linus argued that the design was vulnerable to DoS attacks because of the asynchronous nature of the message service (for performance you would not want the blocking type) plus the kernel service was made responsible for dealing with either problems of some application not accepting replies or a sender filing too many requests - if I understand and paraphrase correctly. That suggests Linus was not opposed to BUS1 IPC mechanism, rather was concerned with its workings. Note that this was in 2016 and I cannot find any more recent comments on the matter, nor can I find a second attempt to get it in(?)
    [ https://marc.info/?l=linux-kernel&m=147751082518647&w=2 ]

    Leave a comment:


  • Guest
    Guest replied
    Funny how for some of Linux's core systems we're basically at the mercy of one large company. If they see some problem as a pain point, it gets fixed, otherwise it gets stalled.

    Leave a comment:


  • Murple
    replied
    Herr is an old but informative article on kdbus

    Leave a comment:


  • babali
    replied
    I wonder why every attempt at introducing kernel level DBUS's IPC failed. Did the BUS1 initiative give up?

    Leave a comment:


  • foob444r
    replied
    Michael,

    You are wrong in assuming efforts around BUS 1 have stalled.

    It is still in the works, as validated by someone asking here: https://github.com/bus1/dbus-broker/...ment-444775507

    shortly after which dvdhrm updated their local snapshot https://github.com/dvdhrm/bus1/commits/bus3

    That commit replaced sender IDs with group tags to make breaking ties and improve total ordering gurantees, and not make it a mere artifact of the mechanism used.

    Leave a comment:


  • D-Bus Broker 18 Released While BUS1 In-Kernel IPC Remains Stalled

    Phoronix: D-Bus Broker 18 Released While BUS1 In-Kernel IPC Remains Stalled

    Version 18 of D-Bus Broker has been released, the D-Bus message bus implementation designed for high performance and better reliability compared to the D-Bus reference implementation while sticking to compatibility with the original specification...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
Working...
X