Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“DBus is seriously screwed up”

thread.gmane.org

Post reply on HN
Print view View original

21–30 of 209 posts

Re: “DBus is seriously screwed up”

#21

Post by bandrami »

userbinator wrote: post #9
christianbryant wrote: post #2

And https://lwn.net/Articles/636997/ But, let's stop bitching and come up with alternatives, solutions, or closure. I'm tired of hearing about KDBUS (all love to gregkh) and DBUS.

alternatives, solutions, or closure The link you posted has what I think is the right one: The problem is that probably this code is not needed at all. To me, DBUS seems like a solution looking for a problem: The majority of the time there is no real reason to have such a complex layer of abstraction for IPC, when the system already provides much simpler alternatives.

there is no real reason to have such a complex layer of abstraction for IPC, when the system already provides much simpler alternatives

This. So many things that freedesktop does I just kind of look at and think "this just isn't remotely a problem I have, so I can't judge whether it 'solves' it or not."

Re: “DBus is seriously screwed up”

#22

Post by roel_v »

castell wrote: post #5

> Since then I'm convinced that people who are inventing RPC solve non-existing problems. Many RPC solutions ultimately failed, because they were slow and overdesigned/complex. (e.g. CORBA, Network OLE/DCOM, Java RMI, XML-RPC/SOAP and other XML-based protocols, etc.) Whereas e.g. REST (if you call it even RPC) is just very simple and enough for most purposes. It's more like the concept of Component Object Model faile…

You do realize that pretty much whole of Windows is, underneath, based on COM, including most of the .Net-exposed system API's?

I'll agree that COM and DCOM are... hairy, if you're implementing COM objects 'by hand'. But there's a reason for all of it, and I have yet to see an easier and more flexible way to write cross-language components. I could write a COM object in C++, call it from VBScript in a very simple command line program, as well as use it directly in a Web application in (here it comes!) 1999! That's 15 years ago! And while COM is universally reviled now, and none of the cool kids will want to be seen within 100 feet of it (actually, the 'cool kids' don't even know what COM is any more, it's so 2005 to hate on COM...), for those who spend 6 months on understanding it, it worked very well, and has been supported for close to 20 years now (on Windows, that is).

Re: “DBus is seriously screwed up”

#23

Post by bitwize »

christianbryant wrote: post #2

And https://lwn.net/Articles/636997/ But, let's stop bitching and come up with alternatives, solutions, or closure. I'm tired of hearing about KDBUS (all love to gregkh) and DBUS.

People have come up with alternatives. They are:

* AF_BUS, a new socket address family that provides a "generic" bus

* adding multicast and order guarantees to AF_UNIX sockets

None of these have the political traction that kdbus has. Kdbus, systemd, etc. get mainstreamed because they have top developers gunning for them being mainstreamed. The people on the sidelines going "but muh unix" are also-ran haters, nothing more. So let's just throw the switch and fry this sucker.

Re: “DBus is seriously screwed up”

#24

Post by lmilcin »

deng wrote: post #17
vidoc wrote: post #13

It all started with a microbenchmark: http://thread.gmane.org/gmane.linux.kernel/1930358/focus=193... DBUS implementation aside (which seems to leave a lot of room for optimization), my initial reaction was that the gain was rather minimal compared to the claims of the systemd folks.

That was my first reaction as well. But to be fair, the kdbus people always said the real speedup will be seen for large packets. However, the real issue is how slow overall DBus seems to be according to those numbers. As Linus says earlier in the thread: "No way should it take 4+ seconds to send a 1000b message to back and forth 20k times." This is indeed rather shocking.

I would expect any half decent HTTP server to be able to handle more messages per second than that. If that is going to be the future fabric underlying all application ecosystem on Linux I would be as wary of it as Linus is.

I will put it another way: if it can't be more performant than a simple HTTP client/server it doesn't deserve to be included into mainline kernel especially when the costs are so high.

Re: “DBus is seriously screwed up”

#25

Post by dingaling »

TD-Linux wrote: post #6
joelthelion wrote: post #4

He's not saying DBus as a concept is bad, just that the implementation sucks. If he's right, that's something that can be fixed relatively easily (compared to a major architectural change).

I agree, the OP title is a bit misleading. I use dbus every day on my laptop and it works totally fine - I don't notice its existence. I'm all for improvements, but I'm quite patient and quite happy to wait this one out.

> I use dbus every day on my laptop and it works totally fine

My laptop appears to run fine despite dbus, if the hundreds of daily 'Failed to connect to socket' messages are any indication.

Re: “DBus is seriously screwed up”

#26

Post by bandrami »

castell wrote: post #5

> Since then I'm convinced that people who are inventing RPC solve non-existing problems. Many RPC solutions ultimately failed, because they were slow and overdesigned/complex. (e.g. CORBA, Network OLE/DCOM, Java RMI, XML-RPC/SOAP and other XML-based protocols, etc.) Whereas e.g. REST (if you call it even RPC) is just very simple and enough for most purposes. It's more like the concept of Component Object Model faile…

It's more like the concept of Component Object Model failed. For example OLE (the base technology behind DCOM) doesn't fly beside the legacy Office usage.

True, but the idea of the self-registering COM object eventually seemed to limp across the finish line.

Anyways. "Two key kdbus developers" (ahem) have said that the entire kernel signal mechanism should be deprecated because it's "too brittle and complex". When I read that, a big light bulb turned on in my head about what the actual problem is here.

Re: “DBus is seriously screwed up”

#27

Post by fulafel »

deng wrote: post #17
vidoc wrote: post #13

It all started with a microbenchmark: http://thread.gmane.org/gmane.linux.kernel/1930358/focus=193... DBUS implementation aside (which seems to leave a lot of room for optimization), my initial reaction was that the gain was rather minimal compared to the claims of the systemd folks.

That was my first reaction as well. But to be fair, the kdbus people always said the real speedup will be seen for large packets. However, the real issue is how slow overall DBus seems to be according to those numbers. As Linus says earlier in the thread: "No way should it take 4+ seconds to send a 1000b message to back and forth 20k times." This is indeed rather shocking.

So what's the use case for sending large packets of data over dbus where the performance gains warrant integrating the dbus server to the kernel? Are they planning to migrate the X server to dbus?

Re: “DBus is seriously screwed up”

#28

Post by bitwize »

userbinator wrote: post #9
christianbryant wrote: post #2

And https://lwn.net/Articles/636997/ But, let's stop bitching and come up with alternatives, solutions, or closure. I'm tired of hearing about KDBUS (all love to gregkh) and DBUS.

alternatives, solutions, or closure The link you posted has what I think is the right one: The problem is that probably this code is not needed at all. To me, DBUS seems like a solution looking for a problem: The majority of the time there is no real reason to have such a complex layer of abstraction for IPC, when the system already provides much simpler alternatives.

To me, DBUS seems like a solution looking for a problem: The majority of the time there is no real reason to have such a complex layer of abstraction for IPC, when the system already provides much simpler alternatives.

Then you need to read and reread and reread Havoc Pennington's posts on why he wrote d-bus in the first place:

https://news.ycombinator.com/item?id=8648995

https://news.ycombinator.com/item?id=8649459

D-Bus provides a service discovery system that lets you not only send messages to named endpoints, but also monitor whether there's something on the other end of the endpoint, and if necessary, request that it be started before you send the message in a non-racy fashion.

It also provides a common, typed, structured, discoverable, auditable serialization layer which is necessary for doing API-style IPC, and a benefit besides since when you "just use sockets" you have to do all the serialization and deserialization yourself, leading to possibly buggy code.

Oh, and it also does multicast, which no other commonly used Unix IPC can do.

People who say "I don't see the problem that d-bus solves" aren't looking hard enough and/or are ignorant of the issues of how software gets developed in a modern environment. D-bus solves many problems with IPC under Linux, and makes developers' lives a whole lot easier when they have to connect with other applications or services.

Re: “DBus is seriously screwed up”

#29

Post by pmr_ »

lmedinas wrote: post #12

Another great Linus quote: "The people who talk about how kdbus improves performance are just full of sh*t." http://thread.gmane.org/gmane.linux.kernel/1930358/focus=193...

You are not quoting the part where he shows his benchmark results, analysis of the problem, and suggested solution. I don't necessarily agree with Linus' tone or choice of words, but what you are doing is far worse. I'm not even sure if you are trying to be sarcastic, but that does not even matter: You are not contributing anything either way.

Re: “DBus is seriously screwed up”

#30

Post by anc84 »

TD-Linux wrote: post #6
joelthelion wrote: post #4

He's not saying DBus as a concept is bad, just that the implementation sucks. If he's right, that's something that can be fixed relatively easily (compared to a major architectural change).

I agree, the OP title is a bit misleading. I use dbus every day on my laptop and it works totally fine - I don't notice its existence. I'm all for improvements, but I'm quite patient and quite happy to wait this one out.

Maybe your laptop would be much faster if dbus was faster.
Post reply on HN