Although flying well under the radar of the average Linux user, D-Bus has been an integral part of Linux distributions for nearly two decades and counting. Rather than using faster point-to-point interprocess communication via a Unix socket or such, an IPC bus allows for IP communication in a bus-like manner for convenience reasons. D-Bus replaced a few existing IPC buses in the Gnome and KDE desktop environments and became since that time the de-facto standard. Which isn’t to say that D-Bus is well-designed or devoid of flaws, hence attracting the ire of people like [Vaxry] who recently wrote an article on why D-Bus should die and proposes using hyprwire instead.
The broader context is provided by [Brodie Robertson], whose video adds interesting details, such as that Arch Linux wrote its own D-Bus implementation rather than use the reference one. Then there’s CVE-2018-19358 pertaining to the security risk of using an unlocked keyring on D-Bus, as any application on said bus can read the contents. The response by the Gnome developers responsible for D-Bus was very Wayland-like in that they dismissed the CVE as ‘works as designed’.
One reason why the proposed hyperwire/hyprtavern IPC bus would be better is on account of having actual security permissions, real validation of messages and purportedly also solid documentation. Even after nearly twenty years the documentation for D-Bus consists mostly out of poorly documented code, lots of TODOs in ‘documentation’ files along with unfinished drafts. Although [Vaxry] isn’t expecting this hyprwire alternative to be picked up any time soon, it’s hoped that it’ll at least make some kind of improvement possible, rather than Linux limping on with D-Bus for another few decades.
Too long didn’t watch, but I agree with the title.
I had a moment with bluez + dbus on a embedded linux device and my god was it strange and required so much manual work.
In my opinion even GET/POST calls made locally between services are easier to handle. xd
Not having watched the video: What’s the performance of hyperwire et al relative to dbus? I presume there is some additional cost at the time of opening to perform the permissions check, though I also presume that once open that check does not have to be repeated so if this is a persistent handle in a demon process or otherwise opened relatively rarely that is a non-issue.
Also, given the documentation issue, testing whether all necessary features of dbus are supported by the replacement may be … Interesting.
My reflex is to say that performance doesn’t matter because it’s not really doing anything, just forwarding packets between different kinds of sockets and an extremely simple database. The variation between implementations should be dismissable.
But on Android every single IPC takes a full second of wall time and that has somehow remained steady as the everything has gotten much faster. So it’s possible to screw this up :)
Reference D-Bus implementation isn’t great, but what about a comparison with actually used one? dbus-broker is used everywhere where d-bus matters.
By all means. Then we’ll have another bus that half the people use and the other half don’t, which will split and balkanize the platform even further for software compatibility and distribution, and require more software shims to be written to make things work.
Year of Linux on desktop 2026.
To me it feels a bit like X versus Wayland. It looks like such projects are started by enthusiasts that want to improve performance in one area, while neglecting other area’s. The devious / conspiracy thinker part of me hints that it’s all done deliberate to split up the Linux system in smaller splinters, which makes widespread adoption more difficult.
Same for for example the metric system. The usa adopted this somewhere in the 19th century, and every sensible person knows it’s better to have one worldwide system for measurements, but when a politician in the usa mentions this, it’s is an almost instant political suicide.
Metric system is used by Russia and China. If using imperial makes it harder for them to steal and copy our tools and equipment, it’s worth it.
It’s been 35 years since USSR fell and Putin still cannot create tank with capabilities similar to Abrams (or Leopard 2 for that matter). Their “amazing” and “brand new” T-90 is just a T-72 fitted with blocks of ERA on top and it pops the turret just like any other design which evolved from WW2-era T-34. That’s how backwards they are.
Most efficient would be to build a wall so high around US that nobody hears from this country anymore. Then use any imperial or nepotist or wathever ´rumpunits inside, nobody would care.
Yours is a compelling idea and one I’m inclined to support if you would agree to the addition of two signs to hang on that wall.
The first would read “Free Ride Closed.” The second: thing: “No Solicitors – Fight your own wars, solve your own problems.”
He says, typing on his digital computer running Windows or MacOS or a UNIX-derived OS, over the Internet.
No one forces the rest of the world to be obsessed with what happens in the U.S., but we introduce a lot of technologies you can’t seem to live without.
Commercialized. Being first to the market doesn’t mean you invented it.
are you talking about designs which are actually in metrics even in USA? :D
I thought the metric system of USA is because of the pirates (according to AJ of the The Why Files YT channel)
I had the complete opposite experience with dbus and enjoy it, but I also love JSON-RPC as alternative to let my python code talk to other processes.
How about replacing it with nothing, since it’s just a useless layer on top of a kernel fully of perfectly good IPC mechanisms?
Half points for your suggestion.
You are correct in that the kernel does support a full suite of perfectly good IPC mechanisms. However, components that want to talk to each other must choose /one/ of those mechanisms, /and/ a common format for messages in order to communicate. This means that components must follow /some/ standard (whether dBus or hyperwire or something else) in order to properly communicate.
I have no doubt that dBus is lacking in something, and that (if given it’s chance) hyperwire will also lack something. But, in either case, those components that need to talk to each other (a proven use-case) need a /standard/ mechanism to do so.
Otherwise, everyone talks, and no one listens.
So? Just pick one that already exists.
THIS!
Haha, yep I can’t stand these Youtubers.
Read Vaxry’s article in the link, that all you need and probably the primary source of that youtubeee.
Hoping GenAI will kill that platform and these youtoubee to find a real job.
The Mighty Algorithm of YouTube kept pushing this video on me for the last two days. Now it’s on Hackaday.
Still not going to watch it ( ͡° ͜ʖ ͡°)
Careful! The wrath of Mighty Al may then fall upon you..
Anybody else miss dcop? As an interface, I vastly preferred it. There were similar security issues, but they could be addressed over time due to what layer it served.
when i see name like “hyprwire” i am already sure i do not want to use it.
as for d-bus working as designed, it probably does. it may have been poorly designed though.