19 ms·

DBus, FreeDesktop, and lots of madness

147 points by billiob 12y ago

voltagex_ 12y ago
And this shit is being bolted on to the kernel?! At least the documentation might improve a bit...
- Spidler 12y ago
  Actually, the stuff in the kernel explicitly doesn't care about content of messages. Also, systemd-dbus has already done away with the XML config files. They are parsed only as legacy/compat mode.
  - rektide 12y ago
    Actually, arguments are better when they don't start with "Actually,"
  - deno 12y ago
    As someone not very familiar with D-Bus I’d like to ask what’s exactly wrong with the XML configuration files? It just seems like something everyone takes for granted. From the examples linked in this thread[1] they seem pretty clear and readable to me. [1] https://news.ycombinator.com/item?id=8649477 https://news.ycombinator.com/item?id=8649477
- the_mitsuhiko 12y ago
  The article is completely bullshit but it's good to know that people here trust the first random thing that they read on hackernews over reading the damn spec themselves.
  - voltagex_ 12y ago
    I admit I only skimmed the spec, but the stuff he mentioned is in there. Do you have any info to counter the claims?
guipsp 12y ago
>So there seems to be some confusion what things like "binary" mean I'm pretty sure binary, in this context just means you can't open a payload in notepad.
- hp 12y ago
  No. It means everything is on-wire essentially the same as it would be in memory. Read the spec: http://dbus.freedesktop.org/doc/dbus-specification.html http://dbus.freedesktop.org/doc/dbus-specification.html This article is essentially "I didn't understand something after spending 15 minutes (or so) on it, and here are my criticisms of how I speculate this might work." You know, fair enough. But if you as the reader want actual knowledge you can read the docs and code yourself and spend more than 15 minutes (or however long it was, but not long enough to have accurate info for sure). There are hundreds of people and packages using dbus after many similar technologies were tried and didn't catch on. A curious person might ask why.
  - brainsalad 12y ago
    It's ironic that you reject the validity of the criticisms without investigating their correctness. For instance: "It isn't ASCII only, and I don't even see where the author of this article got that idea. Read the spec instead of the article and you'll learn more: http://dbus.freedesktop.org/doc/dbus-specification.html" http://dbus.freedesktop.org/doc/dbus-specification.html" And it was immediately pointed out to you that if YOU read the documentation, you would have seen that it does state: "A nul byte in any context other than the initial byte is an error; the protocol is ASCII-only." You could not possibly be more lazy, misinformed, offensive, and just wrong in every way.
    - hp 12y ago
      I created dbus and wrote the original spec. There is a nul byte first because some platforms require that to send credentials. Then a plain text protocol modeled on SASL for authentication. After that the binary message protocol begins. Sorry if others could have done it better, but they didn't, and many tried. My way works and exists.
captainmuon 12y ago
I really liked the "predecessor" DCOP better. Applications publish objects, others can call methods (one-shot) or functions (wait for response). From DBUS' own (old) FAQ: > D-Bus is a bit more complex than DCOP, though the Qt binding for D-Bus should not be more complex for programmers. The additional complexity of D-Bus arises from its separation of object references vs. bus names vs. interfaces as distinct concepts, and its support for one-to-one connections in addition to connections over the bus. The libdbus reference implementation has a lot of API to support multiple bindings and main loops, and performs data validation and out-of-memory handling in order to support secure applications such as the systemwide bus. > D-Bus is probably somewhat slower than DCOP due to data validation and more "layers" in the reference implementation. A comparison hasn't been posted to the list though. IMHO DBus suffers from the kind of overengineering that's been endemic in Desktop Linux in the last few years: DConf/GSettings (as a less flexible, IMHO unneccessary replacement for GConf), PulseAudio and NetworkManager (initially really bad, now work nicely, as long as you don't have to debug problems...), all the *Kit stuff, systemd, and so on. For me, libraries like this don't really solve problems on average, but cause regressions.
- guard-of-terra 12y ago
  The main problem is, DCOP was explicit about it being a quick hack. While DBus featured a huge amount of bombast from the day one while being really slow on useful things. I think they did not even have a proper console client a few years into development and some shipping. "due to data validation and more "layers"" You can't really have data validation and proper layers without a spec. You just can't, it would be an annoyance instead of useful feature.
  - hp 12y ago
    Speed wasn't the right design goal for a mechanism used mostly for control purposes that simply didn't have to be fast. Least-common-denominator flexible implementation was the most important thing (threads or main loop, no dependencies, etc) in order to be adopted. And then validation was required to use it on system contexts not only trusted in-user-session contexts. It also had to swap in for both DCOP (KDE) and CORBA (GNOME). These were the choices that made it viable and why it became widely used. Many years later people decided it would be nice to have performance too so they reimplemented with more assumptions that didn't used to be safe, and did the kdbus work. The result is still compatible with the original protocol because it was always possible to make a fast implementation. This is how open source works. People do what they care about. When speed came to the top of the list people did it. Adoption speaks for itself. Things are adopted when they are a viable solution. Others thought speed was the key and they were wrong; dbus was adopted precisely because it focused elsewhere. But speed wasn't precluded by the design and when people cared they solved it.
drdaeman 12y ago
The protocol is ASCII-only, but strings are UTF-8, and then they talk about endianness? That's not a modern message bus, that's a post-modern one.
- hp 12y ago
  It isn't ASCII only, and I don't even see where the author of this article got that idea. Read the spec instead of the article and you'll learn more: http://dbus.freedesktop.org/doc/dbus-specification.html http://dbus.freedesktop.org/doc/dbus-specification.html
  - riffraff 12y ago
    the author got it from exactly that link, the exact text is the one reported in the article, just CTRL+F "the protocol is ASCII-only". I presume text was edited a few times in different places withou re-checking everything.
    - hp 12y ago
      No. he's confusing the auth protocol with the dbus protocol.
      - riffraff 12y ago
        well, yes, but he's arguing that the documentation is bad, not that the dbus protocol doesn't exist. The phrasing "The text protocol described in this document" (sic) can not easily be interpreted as "the thing described in this section, but not in the rest of the document". I stand by my interpretation of incoherent editing.
      - brainsalad 12y ago
        "Immediately after connecting to the server, the client must send a single nul byte. This byte may be accompanied by credentials information on some operating systems that use sendmsg() with SCM_CREDS or SCM_CREDENTIALS to pass credentials over UNIX domain sockets. However, the nul byte must be sent even on other kinds of socket, and even on operating systems that do not require a byte to be sent in order to transmit credentials. The text protocol described in this document begins after the single nul byte. If the first byte received from the client is not a nul byte, the server may disconnect that client." Oh, technically the dbus auth handshake is defined as not being part of the dbus protocol. That's not convincing.
teddyh 12y ago
So the documentation apparently sucks. OK, this is a bad sign, but can be fixed. Also, apparently the raw on-the-wire protocol is less than optimal. This is harder to change, but the implementation of kdbus has an excellent opportunity to fix this for itself and its associated client library.
- felixgallo 12y ago
  If it's not clear from this that kdbus should be rejected and everyone associated with it removed from any kernel related work immediately...
newuser88273 12y ago
X11 was a great success because it was a protocol that you could write X servers and X clients and X window managers against. Nobody wants to do that anymore. There are two major forces to blame. First, open source. A well designed protocol is much more work, and you can avoid it by just pointing to the open source'd implementation, as this article (hilariously) shows for the case of DBUS. The second force is the adware/spyware model of web and app monetization. You don't want people to use their own clients against a protocol (email, usenet, web 1.0) because you can't serve ads as effectively and you can't run analytics on their every mouseclick, touch gesture and keypress. The whole systemd debacle would be much defused if systemd had been a couple of well thought-out and stable protocols, much like X11, instead of a big source-blob of underspecified and ever-shifting implementation.
- drdaeman 12y ago
  Well, you certainly have a point, but I'm not sure you're right or not. Pointing to a library instead of protocol isn't some recent fad. Say, this was the case with ALSA/libalsa. I guess OSS folks had ranted, yet ALSA is what we've ended with. So, it's certainly not something related to webapps and proprietary APIs. Well, I think in 2000s everyone who had some relation to FLOSS just hated such things. Microsoft's stuff had been a pain in the ass, probably more than they are now. Although, the webapp trend may have had influenced overall mentality with "aw, just link to this and you're good." Some sites, notably, Mega, had even switched to that model from a previous API-first approaches. There are also cases where implementation-first approach has worked well, though. For example SQLite - while most users just link to the library, the format is well-documented, thought out and is quite sane. So, systemd can recover. I'm not keeping myself up-to-date with news on that, but I think I've heard (maybe, incorrectly, though) there are some efforts in that direction. Just my thoughts on this.
- nly 12y ago
  It's interesting that you mention X11. The Wayland developers recognised that X11 had not only become fat, which isn't inherently problematic, but that almost all of the old fat had become dead weight. X11 essentially became a horrific over-engineered, vaguely graphics related, IPC mechanism... just like DBus. Wayland is an RPC protocol. I'm kind of hoping IPC mechanisms similar to those used by Wayland, which fell out of all the work on XCB (a clean X11 equivalent binary protocol for Xorg that, iirc libX11 is now built on top of), will ultimately be adopted by other projects. Interestingly they implemented RPC dispatch using libffi, which is pretty elegant. The Wayland FAQ, in fact, has a rationale for avoiding DBus[0]. The core Wayland framework certainly hasn't suffered in terms of bloat or complexity by avoiding it. Go look at the code[1], and compare it to DBus[2]. Admittedly the topologies are different, but as far as I'm aware nothing prevents Wayland clients from establishing their own P2P communications. [0] http://wayland.freedesktop.org/faq.html#heading_toc_j_10 http://wayland.freedesktop.org/faq.html#heading_toc_j_10 [1] http://cgit.freedesktop.org/wayland/wayland/tree/src http://cgit.freedesktop.org/wayland/wayland/tree/src [2] http://cgit.freedesktop.org/dbus/dbus/tree/dbus http://cgit.freedesktop.org/dbus/dbus/tree/dbus
digi_owl 12y ago
Find myself reminded of Joel going over the Excel file format specs after MS released them, and found off hand references like "See Lotus 1-2-3 spec" or something of that nature.
bitwize 12y ago
Careful! If you accidentally discover what dbus is for and why it is here, Lennart will immediately deprecate it and replace it with something even more bizarre and inexplicable! And we'll never interoperate and the year of the Linux desktop gets pushed back another decade or two...
- panzi 12y ago
  "Some people say this has already happened."
tux3 12y ago
That is actually really scary. I tried reading about DBUS a couple of times before, but gave up before getting more than a high level overview.
Animats 12y ago
Somehow, attempts to bolt message passing onto Linux never seem to be very good. Probably because the primitives underneath are a poor match. QNX, which is a real-time microkernel, got message passing more or less right. You connect to a port of another process. Then you send with MsgSend, which sends a message of N bytes, and waits for a reply. So it's like a procedure call. The receiving end (considered the server) does MsgReceive, which blocks waiting for work, gets the bytes, and returns a reply with MsgReply. That's QNX messaging. Everything goes through this, including all I/O. It's very fast, and integrated with the CPU scheduler, so most message passes just transfer control to the other end without scheduling delay. This allows rapid tossing of control back and forth between processes without going to the end of the line for CPU time. Because QNX is a real-time OS, there are some additional features. Messages are ordered by thread priority, so real-time requests are serviced ahead of non-real time. (This works well enough that running a compile or a browser doesn't impact hard deadline real-time work.) Any request can have a timeout, in case the other end has a problem. Finally, when a MsgSend from a high priority process goes to a lower-priority process, the receiving process gets the higher priority until the MsgReply, to avoid priority inversion. Linux messaging almost always goes through unidirectional byte pipes of some sort. So you need a protocol just to figure out where the message boundaries are. D-Bus seems to be struggling with that. Building a call-like mechanism on top of unidirectional pipes means that callers do a write followed by a read. For a moment, between the write and the read, both sender and receiver are ready to run. This means a trip through the scheduler, or worse, starting the receiving process on a different CPU and suffering cache misses. It's one of those things where the wrong primitives at the bottom cascade into layers of complexity above.
- cbsmith 12y ago
  Why, oh why, don't people use datagram sockets for this stuff!?!
  - Animats 12y ago
    That's still a one-way communications scheme, it has a length limit, and you can be spoofed on message source.
quotemstr 12y ago
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.
- badgersandjam 12y ago
  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.
  - quotemstr 12y ago
    I wish the FOSS world hadn't abandoned CORBA all those years ago.
    - badgersandjam 12y 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.
- mmastrac 12y ago
  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.
general_failure 12y ago
In this day, I would just use http and websockets instead of dbus even for local communication. It just makes sense
- hp 12y ago
  Switching dbus to websocket/http instead of its own outer layer equivalent would get you about 1% done implementing dbus. It doesn't address or answer 99% of why dbus exists or what it does. So it's a fine thing to consider (since websocket exists now) but I'd question the word "just" here. It's like saying the way you'd implement an Amazon web service would be to "just use http." OK. Now what is the service? ;-) I hope that makes sense. It's a mistake to view the problem solved here as "sending messages." The problem is all about the semantics of sending them and the lifecycle services provided by the central daemon.
  - general_failure 12y ago
    Can you tell me something which dbus solves but something over http cannot? By this I mean in practice and not what it can possibly do. I have used it KDE and network manager and the like. They are all better off with rest style APIs actually.
    - hp 12y ago
      That question is like asking "can you tell me something the Twitter API solves that http does not?" - it doesn't make any sense. They are distinct layers. One builds on the other. http+websocket is a way to set up a full-duplex stream of messages where messages are anything you like. dbus does have that part, but then it defines additionally what the messages actually look like in enough detail to bind them to method calls; it defines semantics such as guaranteed ordering and errors; it defines a central bus daemon; it adds broadcast messages over the daemon; it adds security features to allow mixing user and system domains; it adds a way to locate the bus daemon; it adds a way to launch and track the lifecycle of named processes; etc, a number of other APIs. It is not just a socket. Could you implement a dbus-equivalent using http? Sure. But http does not include a "free" implementation of dbus, any more than it includes an implementation of Twitter. dbus-on-http would have to define how method signatures and types map into http, and then it would still have to actually implement the daemon with its features and semantics. http wouldn't make any material difference here; it would have some bikeshed-level pros and cons, but not change the system design in a material way.

147 points by billiob 12y ago

voltagex_ 12y ago

And this shit is being bolted on to the kernel?! At least the documentation might improve a bit...

Spidler 12y ago
Actually, the stuff in the kernel explicitly doesn't care about content of messages. Also, systemd-dbus has already done away with the XML config files. They are parsed only as legacy/compat mode.
- rektide 12y ago
  Actually, arguments are better when they don't start with "Actually,"
- deno 12y ago
  As someone not very familiar with D-Bus I’d like to ask what’s exactly wrong with the XML configuration files? It just seems like something everyone takes for granted. From the examples linked in this thread[1] they seem pretty clear and readable to me. [1] https://news.ycombinator.com/item?id=8649477 https://news.ycombinator.com/item?id=8649477
the_mitsuhiko 12y ago
The article is completely bullshit but it's good to know that people here trust the first random thing that they read on hackernews over reading the damn spec themselves.
- voltagex_ 12y ago
  I admit I only skimmed the spec, but the stuff he mentioned is in there. Do you have any info to counter the claims?

guipsp 12y ago

>So there seems to be some confusion what things like "binary" mean I'm pretty sure binary, in this context just means you can't open a payload in notepad.

hp 12y ago
No. It means everything is on-wire essentially the same as it would be in memory. Read the spec: http://dbus.freedesktop.org/doc/dbus-specification.html http://dbus.freedesktop.org/doc/dbus-specification.html This article is essentially "I didn't understand something after spending 15 minutes (or so) on it, and here are my criticisms of how I speculate this might work." You know, fair enough. But if you as the reader want actual knowledge you can read the docs and code yourself and spend more than 15 minutes (or however long it was, but not long enough to have accurate info for sure). There are hundreds of people and packages using dbus after many similar technologies were tried and didn't catch on. A curious person might ask why.
- brainsalad 12y ago
  It's ironic that you reject the validity of the criticisms without investigating their correctness. For instance: "It isn't ASCII only, and I don't even see where the author of this article got that idea. Read the spec instead of the article and you'll learn more: http://dbus.freedesktop.org/doc/dbus-specification.html" http://dbus.freedesktop.org/doc/dbus-specification.html" And it was immediately pointed out to you that if YOU read the documentation, you would have seen that it does state: "A nul byte in any context other than the initial byte is an error; the protocol is ASCII-only." You could not possibly be more lazy, misinformed, offensive, and just wrong in every way.
  - hp 12y ago
    I created dbus and wrote the original spec. There is a nul byte first because some platforms require that to send credentials. Then a plain text protocol modeled on SASL for authentication. After that the binary message protocol begins. Sorry if others could have done it better, but they didn't, and many tried. My way works and exists.

captainmuon 12y ago

I really liked the "predecessor" DCOP better. Applications publish objects, others can call methods (one-shot) or functions (wait for response). From DBUS' own (old) FAQ: > D-Bus is a bit more complex than DCOP, though the Qt binding for D-Bus should not be more complex for programmers. The additional complexity of D-Bus arises from its separation of object references vs. bus names vs. interfaces as distinct concepts, and its support for one-to-one connections in addition to connections over the bus. The libdbus reference implementation has a lot of API to support multiple bindings and main loops, and performs data validation and out-of-memory handling in order to support secure applications such as the systemwide bus. > D-Bus is probably somewhat slower than DCOP due to data validation and more "layers" in the reference implementation. A comparison hasn't been posted to the list though. IMHO DBus suffers from the kind of overengineering that's been endemic in Desktop Linux in the last few years: DConf/GSettings (as a less flexible, IMHO unneccessary replacement for GConf), PulseAudio and NetworkManager (initially really bad, now work nicely, as long as you don't have to debug problems...), all the *Kit stuff, systemd, and so on. For me, libraries like this don't really solve problems on average, but cause regressions.

guard-of-terra 12y ago
The main problem is, DCOP was explicit about it being a quick hack. While DBus featured a huge amount of bombast from the day one while being really slow on useful things. I think they did not even have a proper console client a few years into development and some shipping. "due to data validation and more "layers"" You can't really have data validation and proper layers without a spec. You just can't, it would be an annoyance instead of useful feature.
- hp 12y ago
  Speed wasn't the right design goal for a mechanism used mostly for control purposes that simply didn't have to be fast. Least-common-denominator flexible implementation was the most important thing (threads or main loop, no dependencies, etc) in order to be adopted. And then validation was required to use it on system contexts not only trusted in-user-session contexts. It also had to swap in for both DCOP (KDE) and CORBA (GNOME). These were the choices that made it viable and why it became widely used. Many years later people decided it would be nice to have performance too so they reimplemented with more assumptions that didn't used to be safe, and did the kdbus work. The result is still compatible with the original protocol because it was always possible to make a fast implementation. This is how open source works. People do what they care about. When speed came to the top of the list people did it. Adoption speaks for itself. Things are adopted when they are a viable solution. Others thought speed was the key and they were wrong; dbus was adopted precisely because it focused elsewhere. But speed wasn't precluded by the design and when people cared they solved it.

drdaeman 12y ago

The protocol is ASCII-only, but strings are UTF-8, and then they talk about endianness? That's not a modern message bus, that's a post-modern one.

hp 12y ago
It isn't ASCII only, and I don't even see where the author of this article got that idea. Read the spec instead of the article and you'll learn more: http://dbus.freedesktop.org/doc/dbus-specification.html http://dbus.freedesktop.org/doc/dbus-specification.html
- riffraff 12y ago
  the author got it from exactly that link, the exact text is the one reported in the article, just CTRL+F "the protocol is ASCII-only". I presume text was edited a few times in different places withou re-checking everything.
  - hp 12y ago
    No. he's confusing the auth protocol with the dbus protocol.
    - riffraff 12y ago
      well, yes, but he's arguing that the documentation is bad, not that the dbus protocol doesn't exist. The phrasing "The text protocol described in this document" (sic) can not easily be interpreted as "the thing described in this section, but not in the rest of the document". I stand by my interpretation of incoherent editing.
    - brainsalad 12y ago
      "Immediately after connecting to the server, the client must send a single nul byte. This byte may be accompanied by credentials information on some operating systems that use sendmsg() with SCM_CREDS or SCM_CREDENTIALS to pass credentials over UNIX domain sockets. However, the nul byte must be sent even on other kinds of socket, and even on operating systems that do not require a byte to be sent in order to transmit credentials. The text protocol described in this document begins after the single nul byte. If the first byte received from the client is not a nul byte, the server may disconnect that client." Oh, technically the dbus auth handshake is defined as not being part of the dbus protocol. That's not convincing.

teddyh 12y ago

So the documentation apparently sucks. OK, this is a bad sign, but can be fixed. Also, apparently the raw on-the-wire protocol is less than optimal. This is harder to change, but the implementation of kdbus has an excellent opportunity to fix this for itself and its associated client library.

felixgallo 12y ago
If it's not clear from this that kdbus should be rejected and everyone associated with it removed from any kernel related work immediately...

newuser88273 12y ago

X11 was a great success because it was a protocol that you could write X servers and X clients and X window managers against. Nobody wants to do that anymore. There are two major forces to blame. First, open source. A well designed protocol is much more work, and you can avoid it by just pointing to the open source'd implementation, as this article (hilariously) shows for the case of DBUS. The second force is the adware/spyware model of web and app monetization. You don't want people to use their own clients against a protocol (email, usenet, web 1.0) because you can't serve ads as effectively and you can't run analytics on their every mouseclick, touch gesture and keypress. The whole systemd debacle would be much defused if systemd had been a couple of well thought-out and stable protocols, much like X11, instead of a big source-blob of underspecified and ever-shifting implementation.

drdaeman 12y ago
Well, you certainly have a point, but I'm not sure you're right or not. Pointing to a library instead of protocol isn't some recent fad. Say, this was the case with ALSA/libalsa. I guess OSS folks had ranted, yet ALSA is what we've ended with. So, it's certainly not something related to webapps and proprietary APIs. Well, I think in 2000s everyone who had some relation to FLOSS just hated such things. Microsoft's stuff had been a pain in the ass, probably more than they are now. Although, the webapp trend may have had influenced overall mentality with "aw, just link to this and you're good." Some sites, notably, Mega, had even switched to that model from a previous API-first approaches. There are also cases where implementation-first approach has worked well, though. For example SQLite - while most users just link to the library, the format is well-documented, thought out and is quite sane. So, systemd can recover. I'm not keeping myself up-to-date with news on that, but I think I've heard (maybe, incorrectly, though) there are some efforts in that direction. Just my thoughts on this.
nly 12y ago
It's interesting that you mention X11. The Wayland developers recognised that X11 had not only become fat, which isn't inherently problematic, but that almost all of the old fat had become dead weight. X11 essentially became a horrific over-engineered, vaguely graphics related, IPC mechanism... just like DBus. Wayland is an RPC protocol. I'm kind of hoping IPC mechanisms similar to those used by Wayland, which fell out of all the work on XCB (a clean X11 equivalent binary protocol for Xorg that, iirc libX11 is now built on top of), will ultimately be adopted by other projects. Interestingly they implemented RPC dispatch using libffi, which is pretty elegant. The Wayland FAQ, in fact, has a rationale for avoiding DBus[0]. The core Wayland framework certainly hasn't suffered in terms of bloat or complexity by avoiding it. Go look at the code[1], and compare it to DBus[2]. Admittedly the topologies are different, but as far as I'm aware nothing prevents Wayland clients from establishing their own P2P communications. [0] http://wayland.freedesktop.org/faq.html#heading_toc_j_10 http://wayland.freedesktop.org/faq.html#heading_toc_j_10 [1] http://cgit.freedesktop.org/wayland/wayland/tree/src http://cgit.freedesktop.org/wayland/wayland/tree/src [2] http://cgit.freedesktop.org/dbus/dbus/tree/dbus http://cgit.freedesktop.org/dbus/dbus/tree/dbus

digi_owl 12y ago

Find myself reminded of Joel going over the Excel file format specs after MS released them, and found off hand references like "See Lotus 1-2-3 spec" or something of that nature.

bitwize 12y ago

Careful! If you accidentally discover what dbus is for and why it is here, Lennart will immediately deprecate it and replace it with something even more bizarre and inexplicable! And we'll never interoperate and the year of the Linux desktop gets pushed back another decade or two...

panzi 12y ago
"Some people say this has already happened."

tux3 12y ago

That is actually really scary. I tried reading about DBUS a couple of times before, but gave up before getting more than a high level overview.

Animats 12y ago

Somehow, attempts to bolt message passing onto Linux never seem to be very good. Probably because the primitives underneath are a poor match. QNX, which is a real-time microkernel, got message passing more or less right. You connect to a port of another process. Then you send with MsgSend, which sends a message of N bytes, and waits for a reply. So it's like a procedure call. The receiving end (considered the server) does MsgReceive, which blocks waiting for work, gets the bytes, and returns a reply with MsgReply. That's QNX messaging. Everything goes through this, including all I/O. It's very fast, and integrated with the CPU scheduler, so most message passes just transfer control to the other end without scheduling delay. This allows rapid tossing of control back and forth between processes without going to the end of the line for CPU time. Because QNX is a real-time OS, there are some additional features. Messages are ordered by thread priority, so real-time requests are serviced ahead of non-real time. (This works well enough that running a compile or a browser doesn't impact hard deadline real-time work.) Any request can have a timeout, in case the other end has a problem. Finally, when a MsgSend from a high priority process goes to a lower-priority process, the receiving process gets the higher priority until the MsgReply, to avoid priority inversion. Linux messaging almost always goes through unidirectional byte pipes of some sort. So you need a protocol just to figure out where the message boundaries are. D-Bus seems to be struggling with that. Building a call-like mechanism on top of unidirectional pipes means that callers do a write followed by a read. For a moment, between the write and the read, both sender and receiver are ready to run. This means a trip through the scheduler, or worse, starting the receiving process on a different CPU and suffering cache misses. It's one of those things where the wrong primitives at the bottom cascade into layers of complexity above.

cbsmith 12y ago
Why, oh why, don't people use datagram sockets for this stuff!?!
- Animats 12y ago
  That's still a one-way communications scheme, it has a length limit, and you can be spoofed on message source.

quotemstr 12y ago

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.

badgersandjam 12y ago
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.
- quotemstr 12y ago
  I wish the FOSS world hadn't abandoned CORBA all those years ago.
  - badgersandjam 12y 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.
mmastrac 12y ago
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.

general_failure 12y ago

In this day, I would just use http and websockets instead of dbus even for local communication. It just makes sense

hp 12y ago
Switching dbus to websocket/http instead of its own outer layer equivalent would get you about 1% done implementing dbus. It doesn't address or answer 99% of why dbus exists or what it does. So it's a fine thing to consider (since websocket exists now) but I'd question the word "just" here. It's like saying the way you'd implement an Amazon web service would be to "just use http." OK. Now what is the service? ;-) I hope that makes sense. It's a mistake to view the problem solved here as "sending messages." The problem is all about the semantics of sending them and the lifecycle services provided by the central daemon.
- general_failure 12y ago
  Can you tell me something which dbus solves but something over http cannot? By this I mean in practice and not what it can possibly do. I have used it KDE and network manager and the like. They are all better off with rest style APIs actually.
  - hp 12y ago
    That question is like asking "can you tell me something the Twitter API solves that http does not?" - it doesn't make any sense. They are distinct layers. One builds on the other. http+websocket is a way to set up a full-duplex stream of messages where messages are anything you like. dbus does have that part, but then it defines additionally what the messages actually look like in enough detail to bind them to method calls; it defines semantics such as guaranteed ordering and errors; it defines a central bus daemon; it adds broadcast messages over the daemon; it adds security features to allow mixing user and system domains; it adds a way to locate the bus daemon; it adds a way to launch and track the lifecycle of named processes; etc, a number of other APIs. It is not just a socket. Could you implement a dbus-equivalent using http? Sure. But http does not include a "free" implementation of dbus, any more than it includes an implementation of Twitter. dbus-on-http would have to define how method signatures and types map into http, and then it would still have to actually implement the daemon with its features and semantics. http wouldn't make any material difference here; it would have some bikeshed-level pros and cons, but not change the system design in a material way.