“DBus is seriously screwed up” • Hacker News Board

Re: “DBus is seriously screwed up”

#131

Post by hp » Tue, Apr 28, 2015, 2:15 PM UTC

forgottenpass wrote: post #123

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…

This whole pulling crap out of the Linux kernel mailing list is doing the industry a disservice. The worst part is that I sorta understand why some low-rent blogo-journolist pulls that nonsense. Hacker News should be better than this. A juicy pullquote can be an attractive headline and cheap and easy to write article. Start with a basic technical introduction paraphrasing wikipedia but doesn't get the reader anywhere…

I would call it "dbus performance overhead is userspace library AND context switching" See: http://article.gmane.org/gmane.linux.kernel/1939651

Or really, it isn't "context switching"; it's that there's the bus daemon in the middle which multiplies the userspace library overhead by 2, since messages are read and written twice as many times if you have the daemon in the middle.

Speeding up read/parse and marshal/write is completely separable from doing fewer read/parse marshal/write operations. Two different performance issues that aren't related as far as I can tell.

Re: “DBus is seriously screwed up”

#132

Post by vezzy-fnord » Tue, Apr 28, 2015, 2:21 PM UTC

thuffy wrote: post #128

lmilcin wrote: post #36

It blows my mind how such a simple operation as passing messages from process to process can baloon to waste the measured half a million CPU cycles. People manage to have full-blown HTTP servers service a request with less than that. Heck, I have worked on an algorithmic trading platform that in the limit of 5us receives market data, dedups it (multiple multicast streams for redundancy), uncompresses it (fricking zli…

Moores Law works to make it eventually more than fast enough. Moores Law does not help it get more secure. How about we work on things that mater in this post-Snowden world, like increasing security -- and let Moore do the performance improvements! Seems a more reasonable and efficient approach, no? Adding more attackable surface area to the Kernel is not a good idea at all. It is an NSA wet dream.

Moore's law makes it faster, but Wirth's law compensates for that dearly. Let's also not forget that pesky Amdahl making our bottlenecks stay bottlenecks, as some things are just fundamentally wrong for performance.

Re: “DBus is seriously screwed up”

#133

Post by TheLoneWolfling » Tue, Apr 28, 2015, 2:23 PM UTC

_pmf_ wrote: post #114

yoklov wrote: post #102

Earlier quoted context omitted.

Frequently the second problem is exacerbated by cache misses. Every operation becomes (much!) slower, but nothing stands out. Not a popular opinion here, but excessive modularity like that is practically the definition of bad, hard to follow code though IMO. Ignoring performance issues, everything happens somewhere else, and large changes now take several times longer, since the changes are not local to a function. T…

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

Re: “DBus is seriously screwed up”

#134

Post by stevejones » Tue, Apr 28, 2015, 2:24 PM UTC

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…

We've always known it's slow. It has a ton of other problems as well, not least of which is pointless duplication. But its speed has always been terrible.

Re: “DBus is seriously screwed up”

#135

Post by alextgordon » Tue, Apr 28, 2015, 2:28 PM UTC

thuffy wrote: post #128

lmilcin wrote: post #36

It blows my mind how such a simple operation as passing messages from process to process can baloon to waste the measured half a million CPU cycles. People manage to have full-blown HTTP servers service a request with less than that. Heck, I have worked on an algorithmic trading platform that in the limit of 5us receives market data, dedups it (multiple multicast streams for redundancy), uncompresses it (fricking zli…

Moores Law works to make it eventually more than fast enough. Moores Law does not help it get more secure. How about we work on things that mater in this post-Snowden world, like increasing security -- and let Moore do the performance improvements! Seems a more reasonable and efficient approach, no? Adding more attackable surface area to the Kernel is not a good idea at all. It is an NSA wet dream.

Security is usually correlated with efficiency, not inefficiency. Think djbware. If something is inefficient, it means nobody has bothered thinking through the design, and well...

Re: “DBus is seriously screwed up”

#136

Post by thuffy » Tue, Apr 28, 2015, 2:29 PM UTC

vezzy-fnord wrote: post #132

thuffy wrote: post #128

Earlier quoted context omitted.

Moores Law works to make it eventually more than fast enough. Moores Law does not help it get more secure. How about we work on things that mater in this post-Snowden world, like increasing security -- and let Moore do the performance improvements! Seems a more reasonable and efficient approach, no? Adding more attackable surface area to the Kernel is not a good idea at all. It is an NSA wet dream.

Moore's law makes it faster, but Wirth's law compensates for that dearly. Let's also not forget that pesky Amdahl making our bottlenecks stay bottlenecks, as some things are just fundamentally wrong for performance.

Kinda good points; however: Wirth's law is more true for commercial software where profit is the motive. Amdahl's law only really makes sense in parallel computing. All that is beside the real point; which is that in this post-Snowden world, we should not be sacrificing security for performance.

Re: “DBus is seriously screwed up”

#137

Post by hp » Tue, Apr 28, 2015, 2:29 PM UTC

phjesusthatguy3 wrote: post #130

Can someone point out where the quote comes from? I'm not a DBus developer but I'd like to know why the subject is what it is, and not something like "Issues with capability bits and meta-data in kdbus" or "Kdbus needs meaningful review".

It's Linus being hyperbolic. Read follow-ups in the linux-kernel thread to see more specifically what these benchmarks mean.

Re: “DBus is seriously screwed up”

#138

Post by thuffy » Tue, Apr 28, 2015, 2:30 PM UTC

alextgordon wrote: post #135

thuffy wrote: post #128

Earlier quoted context omitted.

Moores Law works to make it eventually more than fast enough. Moores Law does not help it get more secure. How about we work on things that mater in this post-Snowden world, like increasing security -- and let Moore do the performance improvements! Seems a more reasonable and efficient approach, no? Adding more attackable surface area to the Kernel is not a good idea at all. It is an NSA wet dream.

Security is usually correlated with efficiency , not inefficiency. Think djbware. If something is inefficient, it means nobody has bothered thinking through the design, and well...

So let us make the user space implementation more performant instead of going down the more inherently risky path in regards to security.

Re: “DBus is seriously screwed up”

#139

Post by antocv » Tue, Apr 28, 2015, 2:31 PM UTC

thuffy wrote: post #121

Let's talk about the elephant in the room. This is quite obviously the NSA adding massive additional attackable surface area to the Linux kernel. They did it to SSL/TLS, they did it to many others, they are now doing it in earnest to Linux. First systemd, now kdbus. Keep this up and OpenBSD, or something else, is going to kill the Swiss cheese that Linux is becoming. I love Linux, so it is sad to see this happening.

systemd, kdbus and pulseaudio - wow r00t lol. kthxbai /nsa.

Seriously, its already a huge mess to administate a GNU/Linux with systemd and dbus and polkit already as it is. Its the only parts of my system where I feel I cant really inspect its inner workings. Its a black box.

Re: “DBus is seriously screwed up”

#140

Post by thuffy » Tue, Apr 28, 2015, 2:33 PM UTC

antocv wrote: post #139

thuffy wrote: post #121

Let's talk about the elephant in the room. This is quite obviously the NSA adding massive additional attackable surface area to the Linux kernel. They did it to SSL/TLS, they did it to many others, they are now doing it in earnest to Linux. First systemd, now kdbus. Keep this up and OpenBSD, or something else, is going to kill the Swiss cheese that Linux is becoming. I love Linux, so it is sad to see this happening.

systemd, kdbus and pulseaudio - wow r00t lol. kthxbai /nsa. Seriously, its already a huge mess to administate a GNU/Linux with systemd and dbus and polkit already as it is. Its the only parts of my system where I feel I cant really inspect its inner workings. Its a black box.

I absolutely agree it is a mess for other reasons as well; but let us attack it on all angles, and I think security is the most important one these days.