Dbus is bloated hell. Whoever came with the idea "let's cram all communications from all sources into the single unified data stream, and let the clients fish what they need out of it" had the strange mapping of mental processes, to say the least. Most other forms of IPC are better (more scalable, more elegant, more comprehensible) — "everything is a file" is better, actor model is better, and I nearly think that even plain shared memory is better than a common bus.
There is a reason there is no "shared bus" in Internet communications.
> There is a reason there is no "shared bus" in Internet communications.
Yes, but dbus isn't _for_ Internet communications. It was designed to wire together the multiple processes that act more-or-less as a whole to implement a desktop environment.
"Better" is contextual. The main problems dbus solves aren't "IPC" at all - they are things like lifecycle tracking, service discovery, and getting events across the system/user-session security boundary.
>Dbus is bloated hell. Whoever came with the idea "let's cram all communications from all sources into the single unified data stream, and let the clients fish what they need out of it" had the strange mapping of mental processes, to say the least.
Yeah, god forbid anyone attempts to unify similar concerns and do away with the mess of ad-hoc solutions that is POSIX/Linux.
The concern is more that they seem to have ignored literally decades of prior art when designing it, and in doing so in an overly complicated way have added to the mess rather than reduce it.
Well, there's multicast, but nobody uses that. Some things use link-local broadcast.
Personally I think the Windows messaging system would actually be a pretty good model to follow, especially if you could give it an actual payload and not just two words. It would certainly solve the actual problems DBus was built to address - media change notifications and things like that.
We actually rely on multicast here at the NRAO for monitor and control of the VLA. I admit it's the only place I've heard of it being used.
ZeroMQ is getting used more for those kinds of purposes; the Greenbank Telescope uses it for one of their instrument backends and we are now using it for VLITE and REALfast. The new archive system I'm helping build uses AMQP.
This is fascinating (as an amateur astronomer), have you written anything else on the systems design of these types of instruments, or have any good pointers? I imagine for large instruments there is a massive amount of data involved and lots of stuff to control. I know it's bad enough with just my one telescope setup :)
There is quite a bit of technical documentation about our systems, and the code is supposed to be open-source (though a lot of it isn't publicly accessible as it should be). But I haven't written anything meant to be a high-level overview of how it works. I think I will try and do that in a few days and send you an email.
I have been joking about how we should build a "total sh*t array" out of old Dish/DirecTV antennas, so that we could explore the systems design without worrying too much about whether anything could be done with the data collected. This hasn't interested my coworkers that much :) There is an amateur radio astronomy society, and there are plans for how to build various levels of radio telescope, starting from ~$50 and an old Dish receiver and going up. And our open-skies policy means that you do not have to be a professional astronomer to use our instruments, although I only know of one or two amateurs that have proposed for time. (They did get it, though).
As a rough back-of-the-hand deal, we allow anybody who gets time to access about 25 MB/s of data. The correlator we have currently (WIDAR) can certainly output much more than that, up to gigabytes per second, but the rest of the infrastructure certainly can't keep up at that rate sustained. It's not unusual for an observation to top a few TB in size. ALMA data files are probably even larger on average.
We are already in the early design stage for a next-generation VLA, which will increase the number of antennas to about 300. At that point, we probably won't be able to keep correlated but unprocessed raw data, just because of the sheer size of it.
Thanks, this is interesting! I work at JHU/APL where there are people that do similar stuff, although I don't personally. The APL Astronomy Club is actually in the midst of trying to get some of our unused scopes & equipment in better shape and possibly put to use so I'm thinking about ways to automate things. Plus I'm not happy with the state of data processing for amateurs, it seems like everything is bespoke and old freeware or expensive software packages. That is what got me thinking about how the pros do things. Looking forward to your email!
The actual reasoning was "we need to get something to make desktop guys happy. Something is better than nothing. Dbus is something". And it is a valid reasoning, right. However, it left some legacy and can now be rethought.
You make it sound like D-Bus is a first attempt and even a hastily put together attempt to solve its target problem. It's not.[1] D-Bus is heavily influenced by (and intended to replace) DCOP, the communication system used by KDE 1 and KDE 2. DCOP was widely lauded as an extremely well-designed system.
yep. as noted in https://news.ycombinator.com/item?id=8648995 it wasn't even just dcop - KDE had tried CORBA before switching to DCOP, and GNOME of course tried CORBA (two different ORBs), then tried Bonobo-on-top-of-CORBA, and SOAP. There were tons of documented protocols on top of X11 (many still in use today). And that's ignoring the countless ad-hoc solutions that various apps used...
Linux desktops are implemented as process swarms and communication among processes is one of the central things they have to deal with.
It isn't better than those categorically. But it's definitely better than them for building a multi-process desktop.
"better" depends on what you are trying to do.
Of course CORBA and SOAP are considered old and horrible now, 15 years later. But currently-popular stuff is in many ways equally unsuited to coordination of local desktop processes, because it's not designed for that.
It largely depends on the use case. dbus is functionally just a transport layer - it can very easily be used to implement an actor model if you choose to do-so (services can dynamically register and unregister channels).
There are quite a few cases where reliable 1-to-many and many-to-many communications need to occur. This is particularly the case when you have many loosely affiliated independent applications with optional communication paths. d-bus, for all of its flaws... does that well enough that I rarely notice it's running on my system.
There is a reason there is no "shared bus" in Internet communications.