121–130 of 209 posts
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.
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. 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…
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."
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…
Given that, I was able to use dbus to come up with a quick solution for a department feature in an afternoon using Pidgin's libpurple dbus bindings through purple-remote to create a presence tracker and simple announcement bot with bash.
A little digging into Pidgin's DBUS Howto gave me all the documentation that I needed. It just took a lunch hour to have something functional up and running without any real in depth programming knowledge required or needed. In an afternoon, I'd hacked up an RSS feed that showed everyone in the department's current presence as reported by their IM status and that feed could then be consumed by the required apps.
I don't know about dbus' other merits or flaws, but it did help me solve a specific problem quickly. This was a dead simple use case though.
At the time, I assumed that people more knowledgeable than me could do a hell of a lot more with it.
Bootstrapped in itself, of course :) (I have no idea what that would even mean in this context. But hey, it's all wishful thinking, right?)
Earlier quoted context omitted.
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.
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 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.