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

161–170 of 209 posts

Re: “DBus is seriously screwed up”

#161

Post by frik »

roel_v wrote: post #153
ntoshev wrote: post #76

Earlier quoted context omitted.

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

It's not about COM.

COM is: "Unlike C++, COM provides a stable ABI that does not change between compiler releases. This makes COM interfaces attractive for object-oriented C++ libraries that are to be used by clients compiled using different compiler versions." http://en.wikipedia.org/wiki/Component_Object_Model

Others are talking about the compound document format OLE. And about DCOM (Distributed Component Object Model). Both OLE 1+2 and DCOM are not that great implementation wise, in retrospect. COM on the otherside is fine.

D-Bus is like DCOM, and has similar/other deficits, as do the competition: CORBA, RMI, XML-RPC, SOAP.

MDI and compound document format were an oversold concept, that failed. Today we have HTML5 with iframes.

Re: “DBus is seriously screwed up”

#162

Post by random28345 »

thuffy wrote: post #136
vezzy-fnord wrote: post #132

Earlier quoted context omitted.

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.

> Amdahl's law only really makes sense in parallel computing.

Contemporary computing is parallel computing. Even phones have multiple cores.

Re: “DBus is seriously screwed up”

#163

Post by angersock »

bitwize wrote: post #157
pjc50 wrote: 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…

Gross oversimplification.

The Unix workstations were by and large simply a great deal more expensive, and there weren't any compelling options on x86 other than Windows, DOS, maybe OS/2, and a few other clones.

It was pretty much pure business--the technical merits don't enter into it. That said, Microsoft took on a heroic burden to attempt backwards-compatibility.

If you want a vindication of the Unix philosophy, look at the server space.

Re: “DBus is seriously screwed up”

#164

Post by thuffy »

random28345 wrote: post #162
thuffy wrote: post #136

Earlier quoted context omitted.

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.

> Amdahl's law only really makes sense in parallel computing. Contemporary computing is parallel computing. Even phones have multiple cores.

Nice job missing the point.

Re: “DBus is seriously screwed up”

#165

Post by pcwalton »

ChuckMcM wrote: post #148
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…

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 the larger systemd debate.

Re: “DBus is seriously screwed up”

#166

Post by vezzy-fnord »

bitwize wrote: post #157
pjc50 wrote: 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…

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.

...if you look at the Plan 9 developer community it's a) very small and b) packed with the pathologically neckbearded.

My God, "pathologically neckbearded". That's just rich. Let's shit on everyone who shows us different ways of building systems that allow for greater composability and emergent features.

Re: “DBus is seriously screwed up”

#167

Post by zurn »

detaro wrote: post #109
zurn wrote: post #104

Earlier quoted context omitted.

You don't fling uncompressed video between apps like that, it goes straight to the hardware-accelerated h.264 (or whatever) encoder and then a low bandwidth stream comes out. Local AF_UNIX sockets (aka userspace dbus) provide ample bandwidth for that use case.

I think the idea is "why use dbus to coordinate creation, rights assignment, ... of local sockets when you can push the data over dbus"?

Yes, that's what I was talking about. Current dbus is is using local AF_UNIX sockets for transport -> the current transport is plenty fast enough to push encoded video over.

Re: “DBus is seriously screwed up”

#168

Post by phjesusthatguy3 »

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…

"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

Re: “DBus is seriously screwed up”

#170

Post by codys »

kzrdude wrote: post #85

But this doesn't benchmark systemd's userland dbus implementation. That one is much better, right?

I hope so, but no one except systemd is using it yet. Last time I checked the sd-bus.h header isn't installed with systemd yet due to the systemd folks concern that that API for sd-bus wasn't finalized yet.

It would be very interesting to benchmark it against the glib implementation (which most people, even if they aren't using glib directly, are using these days).

Post reply on HN