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

171–180 of 209 posts

Re: “DBus is seriously screwed up”

#171

Post by TD-Linux »

TheLoneWolfling wrote: post #133
_pmf_ wrote: post #114

Earlier quoted context omitted.

> Its a nightmare. It tends to be the kind of code you feel productive while writing ("I'm cleaning up this 200 line function"), but is really just making the codebase worse (is there a general term for this kind of false productivity? It's a common problem I see). This issue is pervasive when Desktop/Web developers try to improve embedded software. I've achieved a thousandfold increase in performance by converting a…

The compiler doesn't do the parsing for printf at compile time for the common cases? That's semi-surprising.

In fact it does.

http://stackoverflow.com/questions/19499618/gcc-printf-optim...

Re: “DBus is seriously screwed up”

#172

Post by comex »

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'm not terribly convinced by this point, since it's relatively easily solved by the "transparent direct connection" idea that's been suggested in LKML. That is, rather than making the application set up its own Unix socket connection for the media, the DBus library would have a simple call to switch to a direct socket connection as a transport for a given DBus connection. This wouldn't work for multicast, but who needs to multicast raw media data to whatever local process feels like receiving it?

Re: “DBus is seriously screwed up”

#173

Post by the_why_of_y »

jschwartzi wrote: post #120
scrollaway wrote: post #62

Earlier quoted context omitted.

KDBus was designed with sandboxed applications in mind. So use-case wise think android-style "use the camera app to take a picture/video", where the camera app transfers the media to another app over kdbus, thus without leaking information about the system.

If the point is to have Android style IPC, why not just pull a version of Binder into the mainline kernel?

Android's Binder was already merged into the Linux kernel (not just "staging", the real thing) since 3.19... half a year now.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....

But not many people are aware of that; since neither systemd nor Lennart Poettering have anything to do with it, the usual armchair architects did not paste their, uhm, well considered opinions about how much it sucks and is the end of the UNIX philosophy all over the comment threads when it happened.

Re: “DBus is seriously screwed up”

#174

Post by cpwright »

drzaiusapelord wrote: post #144
outworlder wrote: post #103

This whole pulling crap out of the Linux kernel mailing list is doing the industry a disservice. Quotes are taken out of context, used by people who lack the required technical understanding, which then reach the ears of managers, who will promptly act on overblown concerns. All of it somehow backed by Linus' word, even when he doesn't actually mean it. I've started a stopwatch to see how long it will take for some o…

>Quotes are taken out of context, used by people who lack the required technical understanding What? This is literally the maintainer of the Linux kernel on his mailing list voicing his opinion on something kernel related. Funny when he bashes things HN hates like Nvidia drivers, suddenly he's a truth teller and his words repeated on the mountains. When he's bashing something you like suddenly you're "OMG GUISE IGNOR…

The thing is Linus does know what he is talking about; and can separate the performance concerns, from functionality, etc. I think the real point of the message is to change dbus not the kernel to address the performance issues.

But if someone without the proper technical understanding looks at the just the pull quote, they might think it is a lost cause or not worth using.

Re: “DBus is seriously screwed up”

#175

Post by supertruth »

Linus is just being Linus. He's brusque, non-chalant. He's inflammatory to get people to listen. His thesis here is that bad DBus performance isn't due to context-switching overhead or buffer copies (which can be solved by moving the daemon into the kernel), but instead it's due to malloc-intensive / utf8-parsing-intensive marshalling.

Secondly, he's saying that if performance is being used as an argument for kdbus, then that's an invalid argument.

He's totally right by the way. In this pure message-passing benchmark, where the message-passing overhead is the majority of the work, the slowness is not in kernel-scheduling/system-call/kernel-buffer-copies. People confused a potential impossible-to-overcome bottleneck as the most relevant bottleneck.

But that doesn't mean there isn't a reason for kdbus. Kdbus allows for much better authentication than UNIX sockets do (you can authenticate with pid, pgid, uid, gid, kdbus token, etc.). Also it allows for message-passing security policies to live in the kernel which is crucial for security applications. The tangential performance benefits are nice too, even though the bottleneck wasn't in the kernel to begin with.

Re: “DBus is seriously screwed up”

#176

Post by digi_owl »

ploxiln wrote: post #50
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?

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

The same car companies that put the entertainment system and the brake servos on the same bus...

Re: “DBus is seriously screwed up”

#177

Post by digi_owl »

bitwize wrote: post #80
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?

X is going to be migrated into the recycling bin. Lennart wants to migrate PA to dbus, and the possibility exists for doing the same for some future version of Wayland.

Ugh, and here i thought Wayland was doing good...

Re: “DBus is seriously screwed up”

#178

Post by jff »

XorNot wrote: post #68
pjc50 wrote: post #32

Some form of notification publish/subscribe functionality is necessary in modern Linux. But dbus isn't very UNIX-y. It's also strangely opaque. With pipelines, you can see how the plumbing works. With dbus, programs can interact in nonobvious ways. Even worse is polkit, a poor replication of Windows Group Policy. The most unixy solution is buried at the bottom of this thread, from Plan 9: https://news.ycombinator.com…

Plan 9 in no way implies performance. Just because you can make it look like a filesystem, doesn't mean it actually is going to achieve anything special performance wise.

And in fact the performance of Plan 9 tended to be extremely poor when compared apples-to-apples with Linux.

It's just that everything was so simple it felt fast, even if your filesystem throughput was crap.

Re: “DBus is seriously screwed up”

#179

Post by the_why_of_y »

elwin wrote: post #97
bandrami wrote: post #26

Earlier quoted context omitted.

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…

Signals are too brittle and complex. That's why you have to read three whole manpages to figure out what happens if a process gets the same signal twice in rapid succession. They are also un-Unixlike: they are used to communicate three or four different kinds of information, and they do most of them badly.

Exactly. Signal mechanism makes sense to notify synchronous errors that arise from the thread's own execution, like SIGSEGV or SIGILL or SIGFPE.

Most of the rest of the traditional UNIX signals are events that should be communicated asynchronously via file descriptors that a process can poll at its leisure, which would be more UNIX-y.

Well at least Linux has signalfd(2) now.

Re: “DBus is seriously screwed up”

#180

Post by detaro »

TD-Linux wrote: post #171
TheLoneWolfling wrote: post #133

Earlier quoted context omitted.

The compiler doesn't do the parsing for printf at compile time for the common cases? That's semi-surprising.

In fact it does. http://stackoverflow.com/questions/19499618/gcc-printf-optim...

Or rather: compilers exist that do. The embedded world has a lot of strange toolchains
Post reply on HN