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

181–190 of 209 posts

Re: “DBus is seriously screwed up”

#181

Post by digi_owl »

npsimons wrote: post #154
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…

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

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.

Re: “DBus is seriously screwed up”

#182

Post by mzs »

tcfunk wrote: post #113
m0th87 wrote: post #112

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.

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

Re: “DBus is seriously screwed up”

#183

Post by digi_owl »

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 is a "weird" one.

It came out of the initial freedesktop project to improve interaction between KDE and Gnome.

KDE already had system called DCOP for internal use (allowed for instance Konqueror to be web browser, file manager and multi-pane FTP/SFTP client all at once).

But as with much of KDE it was created using C++. And Gnome is made using C.

So DBUS is something like a reimplementation of DCOP in C.

And the rest is history...

Re: “DBus is seriously screwed up”

#184

Post by DannyBee »

FeepingCreature wrote: post #83
userbinator wrote: post #51

I can make two observations and hypotheses from the profiling results, which agree with Linus' conclusion of "bad user-level code": - Memory allocation/deallocation are taking the most time. - All the percentages for each function are very small. The former is a characteristic of code which heavily abuses dynamic allocation. It's surprising to see how many programmers are not aware of the overhead it adds and would m…

Somebody should modify perf to log "time spent in call", "time spent in stackframe setup", "time spent in mov", "time spent in branches", etc.

So, you can get some of these kinds of cycle counts by changing the event that gets used for record. https://perf.wiki.kernel.org/index.php/Tutorial#Events

So you could use record -e branch_instructions, for example.

Past that, things like "time spent in stackframe setup" is not sane to measure on an optimized binary, because the instructions hat set up the stack frame may be all over the place (due to shrink wrapping, etc).

This means the overhead of counting them would probably require instrumentation and be quite high (and perf is sampling based, not instrumentation based)

Re: “DBus is seriously screwed up”

#185

Post by digi_owl »

bandrami wrote: post #21
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.

there is no real reason to have such a complex layer of abstraction for IPC, when the system already provides much simpler alternatives This. So many things that freedesktop does I just kind of look at and think "this just isn't remotely a problem I have, so I can't judge whether it 'solves' it or not."

Freedesktop was a interesting idea at the outset, but has since grown into what seems like another branch of RH alongside Fedora and Gnome.

Re: “DBus is seriously screwed up”

#186

Post by ChuckMcM »

pcwalton wrote: post #165
ChuckMcM wrote: post #148

Earlier quoted context omitted.

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

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

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.

Re: “DBus is seriously screwed up”

#187

Post by digi_owl »

stevejones wrote: post #160
bitwize wrote: post #157

Earlier quoted context omitted.

> But dbus isn't very UNIX-y. This is what I call the "but muh unix" argument, beloved of neckbeards and often invoked against systemd as wellas kdbus. Sorry to say, but "does this feature make application developers happy" trumps "muh unix" when considering whether to add something to the kernel. Any inversion of this priority is a recipe for Microsoft to eat your lunch, as they did in the early 90s when Windows NT…

> Sorry to say, but "does this feature make application developers happy" trumps "muh unix" when considering whether to add something to the kernel. Which application developers? A hell of a lot of developers are really really happy with "muh unix". Why should a bunch of hipsters with half baked ideas get to rob those developers of that happiness because pushing through half baked ideas makes them happy?

It seems to me that more and more of this comes up as people are moving onto Linux for "cloud services", bringing with them mental models honed on Windows (and to some degree, OSX).

Re: “DBus is seriously screwed up”

#188

Post by smorrow »

vezzy-fnord wrote: post #166
bitwize wrote: post #157

Earlier quoted context omitted.

> But dbus isn't very UNIX-y. This is what I call the "but muh unix" argument, beloved of neckbeards and often invoked against systemd as wellas kdbus. Sorry to say, but "does this feature make application developers happy" trumps "muh unix" when considering whether to add something to the kernel. Any inversion of this priority is a recipe for Microsoft to eat your lunch, as they did in the early 90s when Windows NT…

The Unix philosophy has proven inadequate to meet the needs of real-world software integration I'm assuming that's why it's so trendy to talk about "microservices" these days. What's needed is the COM philosophy, wherein services register themselves under globally named endpoints and present typed structured discoverable APIs. The Unix philosophy doesn't say anything against implementing service discovery mechanisms.…

Actually... I can't think of a better word for people who envangelise Plan 9 on comment sites but never actually use it themselves.

Re: “DBus is seriously screwed up”

#189

Post by jude- »

coldtea wrote: post #107
byuu wrote: post #93

Earlier quoted context omitted.

> Is that sarcasm, or you don't know what dbus is used for? I know what it's used for in the desktop application space; but you might want to ask the authors of Xfce components like Mousepad that make their software rely on it for simple tasks like reusing an existing window when opening a file. Because I'd sure like to be able to run my Xfce desktop with D-Bus off in FreeBSD. "D-Bus is a message bus system, a simple…

> With shared memory (IPC) or sockets (RPC), applications can talk to each other. The whole idea is the "standard" part, not merely the "talk to each other part".

I think what you're looking for is API standardization? If so, dbus does nothing more to help you than POSIX IPC, since each dbus-speaking application can define arbitrary methods with arbitrary signatures and arbitrary side-effects. Dbus is basically a way to do library calls across address spaces--it doesn't help me write programs that are loosely-coupled to one another.

Re: “DBus is seriously screwed up”

#190

Post by pjc50 »

vezzy-fnord wrote: post #166
bitwize wrote: post #157

Earlier quoted context omitted.

> But dbus isn't very UNIX-y. This is what I call the "but muh unix" argument, beloved of neckbeards and often invoked against systemd as wellas kdbus. Sorry to say, but "does this feature make application developers happy" trumps "muh unix" when considering whether to add something to the kernel. Any inversion of this priority is a recipe for Microsoft to eat your lunch, as they did in the early 90s when Windows NT…

The Unix philosophy has proven inadequate to meet the needs of real-world software integration I'm assuming that's why it's so trendy to talk about "microservices" these days. What's needed is the COM philosophy, wherein services register themselves under globally named endpoints and present typed structured discoverable APIs. The Unix philosophy doesn't say anything against implementing service discovery mechanisms.…

Grandparent comment has already been zapped, but:

What's needed is the COM philosophy, wherein services register themselves under globally named endpoints and present typed structured discoverable APIs.

There is a real tension between RPC-orientated systems and protocol-orientated systems. The RPC and distributed object model (COM,DCOM,CORBA) produces tightly coupled systems that provide more functionality if all parts are from the same vendor/team. The protocol-orientated style gives us the RFC protocols with a much wider diversity of implementations.

The question is which application developers do you make happy. The Windows/GNOME style is a single system with lots of moving parts that can't be individually replaced. One of the attractions of UNIX has been its hetrogeneity.

Post reply on HN