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

41–50 of 209 posts

Re: “DBus is seriously screwed up”

#41

Post by 72deluxe »

roel_v wrote: post #22
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 com…

COM is indeed an interesting beast and very useful. Being able to integrate other programs into yours, relying on COM to do so is very helpful. I don't know of a way on Linux or OSX to embed a word processor to work on documents but never show the user (but this might be due to my lack of knowledge about those systems - I would welcome being enlightened). I once wrote something that processed a plethora of Word documents using Word via COM to extract data from them and shove it into a database.

I can't fully remember how I did it but I recall type libraries, including generated headers etc. but I remember being impressed by it.

And as you state, all calls within Windows rely on COM. Stop the RPC service and observe as your system becomes unusable.

Re: “DBus is seriously screwed up”

#42

Post by acqq »

The Linus' explanation is here:

http://thread.gmane.org/gmane.linux.kernel/1930358/focus=193...

"Just to make sure, I did a system-wide profile (so that you can actually see the overhead of context switching better), and that didn't change the picture."

"The real problems seem to be in dbus memory management (suggestion: keep a small per-thread cache of those message allocations) and to a smaller degree in the crazy utf8 validation (why the f*ck does it do that anyway?), with some locking problems thrown in for good measure. "

Re: “DBus is seriously screwed up”

#43

Post by byuu »

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.

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

Indeed. I just use shm_open()+mmap(MAP_SHARED) and go about sharing my data between processes, and have had no problems whatsoever. Then throw in sem_open() so only one process is locking the data at a time. Wrap all that in a 2KB header and it's trivial to use in any project.

It would seem that modern computing is all about building abstractions on top of abstractions, to solve 'problems' nobody ever had. Nobody ever seems to consider the costs of such complexity (in terms of maintenance, understanding the system as a whole, attack vectors, etc.)

By all means, if you need a super complex system with tons of features like D-bus, great! But I am pretty confident that Mousepad (Xfce text editor) doesn't need D-bus just to open a text file in a new tab of an existing window.

Re: “DBus is seriously screwed up”

#44

Post by belorn »

reidrac wrote: post #15
TD-Linux wrote: post #6

Earlier quoted context omitted.

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 crash…

Were you using threads? Python really should not crash, but combine it with library imports implemented in c and threads, and you get really subtle race conditions which result in segfaults. I have myself been force to debug why Python segfaulted, and it was a standard library call which internally used threading, and that caused a conflict with a c library that was not threading safe.

Re: “DBus is seriously screwed up”

#45

Post by chris_wot »

bitwize wrote: post #28
userbinator wrote: post #9

Earlier quoted context omitted.

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…

Is there a document that explains the why's and wherefores of dbus? Aside from those posts.

Re: “DBus is seriously screwed up”

#46

Post by kryptiskt »

deng wrote: post #31
fulafel wrote: post #27

Earlier quoted context omitted.

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?

IIRC the use case is to stream media over DBus, which currently no one is doing because it is too slow.

I don't get the use case, why can't the programs use DBus to negotiate the streaming over some low-overhead transport? Why are people so insistent on ramming a square peg into a round hole?

Re: “DBus is seriously screwed up”

#47

Post by icebraining »

72deluxe wrote: post #41
roel_v wrote: post #22

Earlier quoted context omitted.

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 com…

COM is indeed an interesting beast and very useful. Being able to integrate other programs into yours, relying on COM to do so is very helpful. I don't know of a way on Linux or OSX to embed a word processor to work on documents but never show the user (but this might be due to my lack of knowledge about those systems - I would welcome being enlightened). I once wrote something that processed a plethora of Word docum…

LibreOffice uses UNO, which is their own version of COM: http://en.wikipedia.org/wiki/Universal_Network_Objects

Re: “DBus is seriously screwed up”

#48

Post by mburns »

kryptiskt wrote: post #46
deng wrote: post #31

Earlier quoted context omitted.

IIRC the use case is to stream media over DBus, which currently no one is doing because it is too slow.

I don't get the use case, why can't the programs use DBus to negotiate the streaming over some low-overhead transport? Why are people so insistent on ramming a square peg into a round hole?

because they want the square hole for a reason, the square hole being a unified in-kernel IPC system.

Greg KH has given a few talks/blogs about the design goals of kdbus. https://lwn.net/Articles/551969/

Re: “DBus is seriously screwed up”

#49

Post by deng »

semi-extrinsic wrote: post #39
deng wrote: post #31

Earlier quoted context omitted.

IIRC the use case is to stream media over DBus, which currently no one is doing because it is too slow.

So: if DBus was suddenly fast enough to stream media over, what applications would be using this feature, for what sets of streaming endpoints?

I don't know. I'm not advocating kdbus for multimedia, I'm just repeating what I've heard. I think one of the driving forces behind kdbus is Samsung who are interested in kdbus for Tizen.

Re: “DBus is seriously screwed up”

#50

Post by ploxiln »

fulafel wrote: post #27
deng wrote: post #17

Earlier quoted context omitted.

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?

Large packets, I'm not sure. For a long time, you've been able to attach a file descriptor (e.g. one end of a pipe) to a message, and then send bulk data over the file descriptor.

My understanding of this whole thing was that most of the car companies thought they should try using linux for their console / entertainment / etc systems. Electrical and mechanical engineers seem to all only use windows and not know anything about linux, so they asked themselves "what's the bus on linux?" and found D-bus, the desktop bus used by desktop environments and utilities, for a handful of messages a minute.

They used it to send frequent sensor data to all sorts of services that might be interested, like digital gauges, sound distribution, etc. They didn't realize that there are lots of good low-level IPC mechanisms available on linux, and they should have probably used 0mq, or a scheme based on unix sockets with filesystem permissions based access control, etc.

Anyway, they realized that D-bus had way too much overhead, and instead of porting to some other IPC, got to work accelerating D-bus with additional kernel functionality, such as the AF_BUS which was rejected by the linux networking maintainers. (Though that was probably a better idea than kdbus.)

How exactly GregKH got into this project, I'm not entirely sure. He is relatively friendly with the systemd developers. He's paid by the Linux Foundation, and many of those car companies are members of the Linux Consortium, or something like that, I think. I dunno. Apparently a lot of people used D-bus accidentally, and now the thing to do is make the kernel make it faster.

Post reply on HN