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

11–20 of 209 posts

Re: “DBus is seriously screwed up”

#11

Post by vidoc »

lclarkmichalek wrote: post #8
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…

Naive REST (HTTP, JSON) isn't exactly known for its performance

Agreed, that said, I'm kind of wondering what non-naive (smart?) REST is, no sarcasms :P

Re: “DBus is seriously screwed up”

#14

Post by rasz_pl »

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).

no, both concept and implementation is bad. This thing shovels and computes a LOT of data per call, you cant optimize that out because its what authors of kdbus intended. Its typical 'look at all that CPU we have now, lets use it' mentality that keeps Wirth's law true.

Re: “DBus is seriously screwed up”

#15

Post by reidrac »

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 made a silly desktop app some time ago and it used DBUS to get notifications from NetworkMonitor when the system went online/offline. Nothing too fancy, very few lines of code.

When I was implementing that, I managed to get several segfaults from my Python code. All together seemed a little bit fragile to me :(

That was 5 years ago, things are probably better now (to be fair, I don't know what was causing the crashes; NM was 0.8 back then), but when I read Linus comments I can help to think he's probably right.

This is an anecdote and all, but my point is that until I had to use it... DBUS was pretty good and was working fine :)

Re: “DBus is seriously screwed up”

#16

Post by A_COMPUTER »

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).

He does seem to be saying that kdbus is pointless since those fixes would be in userspace where it's spending most of its time. Or am I misunderstanding?

Re: “DBus is seriously screwed up”

#17

Post by deng »

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.

Re: “DBus is seriously screwed up”

#18

Post by bitwize »

vidoc wrote: post #11
lclarkmichalek wrote: post #8

Earlier quoted context omitted.

Naive REST (HTTP, JSON) isn't exactly known for its performance

Agreed, that said, I'm kind of wondering what non-naive (smart?) REST is, no sarcasms :P

It's called Plan 9.

In Plan 9, each process has its own filesystem tree, and other programs can expose themselves to this process as file servers, meaning that data internal to the programs can be accessed via the same read, write, delete, etc. calls as files. For example, when running under rio, the Plan 9 window system, the current window contents are available at /dev/window and you can write draw calls to /dev/draw to do graphics.

REST is pretty much applying Plan 9 principles to the Web and http.

Re: “DBus is seriously screwed up”

#19

Post by masklinn »

A_COMPUTER wrote: post #16
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).

He does seem to be saying that kdbus is pointless since those fixes would be in userspace where it's spending most of its time. Or am I misunderstanding?

The point of kdbus is to do dbus in kernel space. The one spending lots of time in userspace overhead (not doing actually useful work) is regular dbus.

Linus is saying that kdbus is pointless because its performance gains don't come from being in-kernel, they come from the code not being a complete shit-show, and he believes the same performance should be achievable by fixing regular userspace dbus.

Re: “DBus is seriously screwed up”

#20

Post by riking »

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.

So, basically, systemd-bus would solve the problems even without kdbus, if it avoided all the extraneous memory allocations.
Post reply on HN