Announcement

Collapse
No announcement yet.

Dbus-Broker 28 Released

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

  • Dbus-Broker 28 Released

    Phoronix: Dbus-Broker 28 Released

    With still no sign of BUS1 on the horizon for the mainline kernel or any other successor to BUS1 or KDBUS for in-kernel IPC, Dbus-Broker remains the best bet currently in 2021 for a more performant D-Bus implementation while retaining compatibility with the D-Bus reference implementation...

    https://www.phoronix.com/scan.php?pa...er-28-Released

  • #2
    I think Broker should be the only active project:

    1. KDBUS poses a security risk
    2. BUS1 means reinventing the wheel and therefore having to rewrite every application

    Comment


    • #3
      Originally posted by tildearrow View Post
      I think Broker should be the only active project:

      2. BUS1 means reinventing the wheel and therefore having to rewrite every application
      This shouldn't be an excuse if BUS1 is a lot better. I'd for one use it if it's easier to learn and use (not to mention faster).

      Comment


      • #4
        Originally posted by tildearrow View Post
        I think Broker should be the only active project:

        1. KDBUS poses a security risk
        2. BUS1 means reinventing the wheel and therefore having to rewrite every application
        So add BUS1 and use Broker for old applications.

        Comment


        • #5
          I’ve always been curious about what the performance of these actually means for the end user

          Comment


          • #6
            I don't know the difference between message broker, message queue, message bus, service bus, enterprise service bus, etc. 😕️

            Comment


            • #7
              Originally posted by scottishduck View Post
              I’ve always been curious about what the performance of these actually means for the end user
              Kinda the same like wayland vs X11. You wouldn't know, unless some singular process is exhausting globally shared resources. Dbusbroker is doing its job more reliable/isolated.

              Comment


              • #8
                Originally posted by tildearrow View Post
                I think Broker should be the only active project:

                1. KDBUS poses a security risk
                kdbus does not pose any security risks, where did you get that notion?

                Originally posted by tildearrow View Post
                2. BUS1 means reinventing the wheel and therefore having to rewrite every application
                BUS1 does not "reinvent the wheel". It implements a completely different idea of an IPC, one that was suggested by kdbus reviewers in fact.

                Comment


                • #9
                  Originally posted by scottishduck View Post
                  I’ve always been curious about what the performance of these actually means for the end user
                  My understanding is that the value proposition for things like KDBUS and BUS1 is similar to how Rust gets marketed. It's not so much about the performance of current uses, but about enabling programmers who currently point their efforts elsewhere because there's nothing that meets requirements without being difficult enough to use that they don't feel motivated to do it as a hobby project.

                  (eg. Zero-copy IPC can be used for streaming decoded media between applications as long as the per-packet overheads and latency aren't crazy and, currently, you have to resort to stuff like rolling your own from shared memory. Something like KDBUS or BUS1 would be more like how, in Rust, if you send a Vec<T> from one thread to another, you're just sending a 24-byte (data pointer, capacity, length) stack object that acts as the ownership token for the on-heap memory which doesn't move, and the compiler takes care of making sure you actually follow the access-control semantics of such a paradigm without imposing runtime overhead.)

                  Comment


                  • #10
                    Originally posted by intelfx View Post

                    kdbus does not pose any security risks, where did you get that notion?
                    Bug in KDBUS = Buffer overflow = Exploit and since KDBUS runs in kernel space = Potential privilege escalation

                    Bug in D-Bus or dbus-broker = Buffer overflow = D-Bus runs in user space and on its own user = No privilege escalation

                    Originally posted by intelfx View Post
                    BUS1 does not "reinvent the wheel". It implements a completely different idea of an IPC, one that was suggested by kdbus reviewers in fact.
                    It does reinvent the wheel since D-Bus already exists and BUS1 is a completely unrelated thing.
                    On the other hand, dbus-broker keeps compatibility

                    Comment

                    Working...
                    X