Hacker News Reader

Comment by outworlder | Hacker News Reader

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 of my former coworkers to contact me with concerns about DBus. We used it pretty heavily.

As for DBus itself: guys, it is useful. It works. You can count on it being there and working in most distributions, you can talk to most things nowadays. Its easy to use (for most use cases), language bindings are everywhere.

So, turns out is slow. It's so cool that we have identified that. Let's fix it.

Even if the slowness doesn't seem to bother many of its use cases.

View on HN

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 near ready to understand the LKML post. Then pad out the rest with some hemming and hawing about: Has Linus gone TOO FAR!?

On HN, these kind of submissions are just as trashy, but because they point directly to LKML we can be fooled into thinking to be something loftier.

It should be called "kdbus patch review: dbus performance overhead may be in userspace library, not context switching." But nobody would submit that because it's not catchy. I'd still click that link, but the title would be boring and technical, just like the post it links to is. I actually flagged the other front page LKML post "Big-Endian is effectively dead."

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.

Sure, but you don't need to defend dbus in this branch of the thread. I'm showing the difference in kind from "DBus is seriously screwed up." I knew my title wasn't great but in the context of that comparison, my proposed title and yours are effectively the same.

"On HN, these kind of submissions are just as trashy, but because they point directly to LKML we can be fooled into thinking to be something loftier."

No, it's because of the cognitive dissonance in play on HN. It's a fucking news-re-blog, for crying out loud, but because of the stated goals[0] of the site there's some idea that we're rising above the trash and nonsense of sites like Slashdot.

Don't get me wrong; articles get posted here before they get reposted on Slashdot or The Register etc., but that's all there is to HN. It's not a better place for discussion than either of those two sites.

[0]https://news.ycombinator.com/newswelcome.html

So totally this; it's what I've said time and again. Is Linus abrasive? Yes, he can be. He usually has reason. But people seem to rarely read the whole thread, and even if they did, they are usually outsiders who lack both the technical chops to make valid criticisms, and they aren't familiar with Linus' management style. I for one count myself as one of the former as I've been outside of kernel land for quite some time. I'll say this though: the N900, with 256MB of RAM and a single core 600MHz ARM chip from 2009 had DBus, and it didn't seem to suffer too much from it. Hell, it's kind of impressive to be able to make phone calls from the command line, say over SSH:

https://wiki.maemo.org/Phone_control#Make_a_phone_call

Can improvements be made? Probably. Should they be? Why the hell not? Should clickbait headlines stop distracting us from real work? I only wish they would.

As much as I loved the N900 for its system transparency and malleability (I still use it), it was hardly a paragon of performance. I don't know how much D-Bus played into it, though.

While i enjoyed the N800 for the time, the waves that Maemo has since created across the Linux ecosystem has me wondering if the project should never have happened.

Strigi desktop search and NEPOMUK semantic desktop extensively relied on D-Bus. The D-Bus background daemon often hung and NEPOMUK itself was known to be slow and wasteful on hardware resources. Maybe it wasn't D-Bus fault at all, but the years long problems lead to a bad impression. http://en.wikipedia.org/wiki/Strigi , http://en.wikipedia.org/wiki/NEPOMUK_(framework)

Comparing a PPC (WinCE), iPhone1 and N900 with the similar hardware specs - there was no clear winner.

I don't lack the required technical understanding. The headline is correct; Linus identified several embarrassing and obviously stupid problems with kdbus, including security concerns, in that thread.

I am wondering if there are "Linux Insurgents", which are groups of people with a particular agenda that find small bits of data which can be made to serve their cause and expose them. Or maybe they just don't like DBus. Or maybe they just want to feel like they are having a larger debate.

If it is any consolation, while I worked at Sun in the kernel group and later, this sort of 'cherry pick a message to start a debate' technique was also present. Sometimes it is just someone who believes something is broken and they use the message to bolster their argument.

I also wonder if the reverse happens, with people sabotaging the system by breaking things that work, making easy things harder, and replacing fast things with slower things.

I don't think it's fair to call systemd or dbus sabotage. It's entirely possible to construct explanations that rely on blinkered, tasteless incompetence, naivete, and personality cults rather than maliciousness.

I was thinking more along the lines of reimplementing the Windows registry in Samba...

> I am wondering if there are "Linux Insurgents", which are groups of people with a particular agenda that find small bits of data which can be made to serve their cause and expose them. Or maybe they just don't like DBus. Or maybe they just want to feel like they are having a larger debate.

D-Bus is related to systemd (in that systemd relies on it), so this issue seems to have garnered a fair bit of spillover from the larger systemd debate.

No doubt the spillover is real.

Clearly highlights one of the challenges of Linux user land, I guess in the 'Bazaar' model this might be equivalent to trying to ban the selling of meat from endangered species amongst all the vendors.

The bazaar works in the sense that each vendor stick to their product.

but with systemd one vendor is "branching out", and offering (tightly) interconnected products.

And for a certain subset of customers, distro maintainers, this offer is tantalizing. Because it may make their life easier.

Or maybe to go back to the meat, it is not the kind of meat thats the problem. But that now you have one vendor selling whole meals.

And to stretch it a bit further, they are not selling it to the eater, but the chef.

Say you have a favorite restaurant, and when you sit down you can combine this meat with that potato etc.

But then one day you come in and you find the menu had changed to pre-set meal. Now if you want your favorite kind of meat you can only have it alongside a potato you barely tolerate (if not downright dislike).

This because the restaurant switched supplier to one that only sell pre-packaged meals rather than individual components.

This is the best analogy of systemd project I've seen so far.

I understand the whole point of putting dbus into kernel was to fix performance. The objections are mainly because performance haven't really materialized but the costs are very much present.

What's being taken out of context here? It seems the conversation is about dbus being slow, and you agree that it is?

Probably referring to the link title, which could imply quite a bit more than it simply being slow.

Well how can it be slow but not screwed up?

By working?

Scroll-up to earlier discussion there, it's about security implications and conditional byte swapping, so it;s not all about the performance.

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.

>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 IGNORE LINUS HE DOESNT KNOW WHAT HES TALKING ABOUT!!"

Come on.

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.

Reply on news.ycombinator.com