Slashdot

D-Bus may not be the answer to everything, individual technologies rarely are, and it's not as if D-Bus was even the only user-level software bus commonly used in Linux, but it has interesting potential. Not sure how well it currently plays with clustering technology like MOSIX, or grid technology, but given the effort being poured into developing user-space software buses precisely for those, I imagine that's just a matter of time.

Personally, I'd rather have more localized limited-purpose buses in any case where a general-purpose solution is slower and/or heavier. The code can't be that maintenance-intensive and too much abstraction must eventually pessimize the resulting code. Moore's Law is worthless if code gets slower at the same rate systems get faster. Nonetheless, any general-purpose abstract IPC that is easier to implement against than traditional mechanisms (RPC, CORBA, Unix sockets, System V messages, etc) must surely be beneficial - even if those end up being the mechanisms used under the hood. In fact, the more of those implemented and the better you could switch data between them, the more portable such a software bus becomes as well as the more optimal - to a point. The whole trend in programming is towards such pluggable solutions, it's surprising IPC is so far behind almost every other mechanism out there, and unless there are specific technological reasons to not use a given generic mechanisms (such as performance costs), you're already using so many that are not following some standard or other that it's absurd to discriminate against one just because it's not specifically POSIX.