Hacker News Reader

Comment by quotemstr | Hacker News Reader

Under Windows, COM and RPC are a dream compared to this mess. Interfaces are clearly-defined, versioned entities that support transmitting arbitrarily complex values (even ones containing circular references!) over a variety of protocols. It's also very fast: the "ncalprc" transport uses ALPC, which is the best IPC system I've seen on any platform. [1]

Using dbus, I feel like I have to type the same goddamn namespace name three or four times and that I never really feel like I've gotten it right.

Also, FOSS developers are in general completely obvious to interprocess race conditions. When you refer to something by an "id" and that "id" can be reused and recycles between subsequent calls, you've gotten it fundamentally wrong. I see developers make this mistake over and over in POSIXland.

[1] No, ALPC isn't like RPC-specific like kdbus: it's just a very, very good implementation of message passing over socket-like kernel handles.

View on HN

That's not fair at all. I know it's en vogue to hate on some of the parts of the Linux desktop, but COM in Windows has a ton of warts all of its own. DCOM is brutally complicated to set up and operate properly. COM uses poorly-specified and difficult to parse TLB files. The IDL tool used to be brutally buggy and crashy. Don't get my started on the way that proxies worked.

Many of the critiques in this article could probably be applied to COM in many places. I imagine they might have ironed out some of the kinks, but it's got 10+ years on DBUS.

When COM was as old as DBUS is now, good luck finding the documentation for the more advanced uses outside of the books written by the third-party COM experts.

Interesting, because one of the things that attracts me to Linux over Windows is the use of well-defined interoperable wire protocols rather than RPC systems. This makes it much easier for the different ends of the communication to be written by unrelated teams without quite such coordination costs. Meanwhile RPC-style is much easier if the same team is writing both ends.

This is why there are a zillion IMAP clients and several servers but only one reliable Exchange client and server, the Microsoft one. The wire protocol is basically MAPI over DCOM, and this requires a server architecture identical to the MS one (and at much greater risk of copyright/patent problems).

GNOME have been able to produce such a bad wire protocol for dbus because they're writing both ends and happy to break compatibility regularly. It doesn't have to be this way and is a function of the project management style.

(There are some Linux clients for Exchange but no server, which is the wrong way round as it's much easier to get people to switch on the server rather than the desktop)

> because one of the things that attracts me to Linux over Windows is the use of well-defined interoperable wire protocols rather than RPC systems.

NFS is an RPC system. Both protocol-based and RPC-based systems can be well-documented and well-specified. Both kinds of system can be arbitrary nightmares. I don't think you're drawing a useful distinction. Both ecosystems have some services provided over RPC and some services provided over some kind of other message format.

> [RPC] requires a server architecture identical to the MS one

No it doesn't. It "requires" Exchange-style architecture in the same way that IMAP "requires" maildir storage. In the end, you have a message-passing protocol, and you can choose to respond to messages any way you'd like.

> GNOME have been able to produce such a bad wire protocol for dbus because they're writing both ends and happy to break compatibility regularly

They claim that the dbus wire protocol is stable and that individual dbus services will present broadly compatible interfaces. Dbus is for everyone, not just internal communication inside GNOME. That's what makes dbus being awful especially annoying.

It's a stylistic opinion rather than a hard distinction. Yes, in both cases you're exchanging messages and responses between turing-equivalent systems. However, the systems you end up with are different depending on which pieces are designed first and with higher priority.

Spot on. I can't say enough good things about COM; it's enabled some quite amazing things for me over the years and really top notch distributed systems that are easy to manage.

I wish the FOSS world hadn't abandoned CORBA all those years ago.

I'm not sure why you were downvoted - it's a valid solution.

To be honest, I'd rather see DCE/RPC (DCOM's ancestor) make an appearance without some of the pain points of DCOM.

Reply on news.ycombinator.com