Announcement

Collapse
No announcement yet.

Dbus-Broker 34 Released For High Performance D-Bus Message Broker

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

  • Dbus-Broker 34 Released For High Performance D-Bus Message Broker

    Phoronix: Dbus-Broker 34 Released For High Performance D-Bus Message Broker

    There's been nothing new on the BUS1 front this year for capability-based IPC within the Linux kernel... In fact, the BUS1 out-of-tree kernel module has gone untouched for years now. But out of the BUS1 project has been Dbus-Broker for a high performance D-Bus message broker in user-space that doesn't break existing D-Bus compatibility. Out today is the newest version of that project closely tied to systemd developers...

    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

  • #2
    The thumbnail got me excited for a second: "Could hell have frozen over? Did Linus change his mind over in-kernel D-Bus?"
    Not today I'm affraid.

    Would anyone of you know if it would be feasible to implement it in eBPF?

    Comment


    • #3
      When systemd was first released, Rust was not yet born. So having that critical piece of system software in C is understandable.

      But now, 2023, having another piece of critical system software in C, while Rust is there seems like an odd choice. Maybe C is the "hammer of choice" for the devs.

      Comment


      • #4
        Originally posted by rafanelli View Post
        When systemd was first released, Rust was not yet born. So having that critical piece of system software in C is understandable.

        But now, 2023, having another piece of critical system software in C, while Rust is there seems like an odd choice. Maybe C is the "hammer of choice" for the devs.
        dbus-broker started development in 2017 IIRC. Rust was nowhere ready for a project like this back then.

        Comment


        • #5
          Originally posted by LuukD View Post
          The thumbnail got me excited for a second: "Could hell have frozen over? Did Linus change his mind over in-kernel D-Bus?"
          Not today I'm affraid.

          Would anyone of you know if it would be feasible to implement it in eBPF?
          I'm not an expert on eBPF but I really doubt it would be possible. On the plus side, dbus-broker proves that we may not need a kernel-based implementation after all.

          Comment


          • #6
            Originally posted by LuukD View Post
            The thumbnail got me excited for a second: "Could hell have frozen over? Did Linus change his mind over in-kernel D-Bus?"
            Not today I'm affraid.
            Nobody ever made a compelling case why this would need to be in the kernel. Also, IIRC, Linus never rejected it, it was always the network developers.

            Comment


            • #7
              Originally posted by rafanelli View Post
              When systemd was first released, Rust was not yet born. So having that critical piece of system software in C is understandable.

              But now, 2023, having another piece of critical system software in C, while Rust is there seems like an odd choice. Maybe C is the "hammer of choice" for the devs.
              In 2023 Rust would of be taken more serious if not for the noobs that interject Rust in every conversation out of context.

              Comment


              • #8
                Originally posted by Rallos Zek View Post

                In 2023 Rust would of be taken more serious if not for the noobs that interject Rust in every conversation out of context.
                In 2023 I don't think Rust is exactly lacking in the being taken seriously department.

                Comment


                • #9
                  Originally posted by npwx View Post

                  Nobody ever made a compelling case why this would need to be in the kernel. Also, IIRC, Linus never rejected it, it was always the network developers.
                  Being in the kernel would have benefits, for example MAC systems like SElinux and Apparmor would naturally cover it.

                  Comment


                  • #10
                    I don’t understand why this isn’t the default for all distros that use SystemD. IIRC DBus-Broker requires Linux (so I can appreciate not wanting to add that restriction) but so does SystemD, so that restriction is already there.

                    Comment

                    Working...
                    X