Live data from Hacker News

“DBus is seriously screwed up”

thread.gmane.org

151–160 of 209 posts

Re: “DBus is seriously screwed up”

#151

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…

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

Re: “DBus is seriously screwed up”

#152

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?

As far As I can remember in mailling list one of kernel developer mention "android IPC (Its name I think is binder) is completely broken" , He didn't mention any evidence for his claim.

Re: “DBus is seriously screwed up”

#153
post #76
post #22

Earlier quoted context omitted.

You do realize that pretty much whole of Windows is, underneath, based on COM, including most of the .Net-exposed system API's? I'll agree that COM and DCOM are... hairy, if you're implementing COM objects 'by hand'. But there's a reason for all of it, and I have yet to see an easier and more flexible way to write cross-language components. I could write a COM object in C++, call it from VBScript in a very simple com…

COM sort of works, on Windows, when when one or preferably both sides of the connecting components are made by Microsoft. You never see non-Microsoft code talking to non-Microsoft code from a different vendor via COM. This is not a successful component interface standard.

Huh? ArcGIS is wholly extendable, and complete businesses are based on the Arc extension ecosystem, using COM. AutoCAD can (could?) be extended using COM. I've personally written extendable systems using COM. COM is a hugely successful component interface standard. Name any other standard with the same speed, flexibility and adoption.

Again, I'll agree that it's not trivial to implement a COM object. You need good understanding of C(++), the Windows API, threading, and some more things. There are tools to make it easier (e.g. to write a COM object in Visual Basic) but they generally don't make for robust components. In the hands of a competent, experienced developer, COM is a massively powerful tool.

Re: “DBus is seriously screwed up”

#154

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

Re: “DBus is seriously screwed up”

#155

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

Re: “DBus is seriously screwed up”

#156

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…

Indeed, decomposition is easier than extracting modules. This is often an argument in favor of modularity! :) As others have mentioned, the second issue can be addressed with tooling.

But, is excessive modularity really the culprit? Are you saying you read the code and found that to be the case, or it's just a hunch? Reading through the comments here, it seems that whatever one's personal hobby-horse happens to be is what will get the blame.

Re: “DBus is seriously screwed up”

#157
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…

> 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 overtook commercial Unix in the enterprise space. (Monopoly schmonopoly: Windows was the better platform. It was easy to develop for and relatively uniform across desktop and server deployments.)

The Unix philosophy has proven inadequate to meet the needs of real-world software integration: what's needed is the COM philosophy, wherein services register themselves under globally named endpoints and present typed structured discoverable APIs. D-bus provides that for Linux and no one so far has presented a better solution.

As for Plan 9... yes, that's what you get when you apply the Unix philosophy in the extreme. Note that the UX for Plan 9 sucks, and if you look at the Plan 9 developer community it's a) very small and b) packed with the pathologically neckbearded.

Re: “DBus is seriously screwed up”

#158

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…

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.

Re: “DBus is seriously screwed up”

#159

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…

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.

Re: “DBus is seriously screwed up”

#160
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…

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

Post reply on HN