 |
| “In creating dbus, I talked to a bunch of developers at KDE” (comment) | ||
| recommended by 1 user | 2014 | hp on: DBus, FreeDesktop, and lots of madness | linux | original thread | | ||
| hp on Nov 23, 2014 | on: DBus, FreeDesktop, and lots of madness | view on HN | ||
| One user recommended this comment. What they said: |
|
bitwize Apr 28, 2015 | on: “DBus is seriously screwed up” | context
To me, DBUS seems like a solution looking for a problem: The majority of the time there is no real reason to have such a complex layer of abstraction for IPC, when the system already provides much simpler alternatives. Then you need to read and reread and reread Havoc Pennington's posts on why he wrote d-bus in the first place: https://news.ycombinator.com/item?id=8648995 https://news.ycombinator.com/item?id=8649459 D-Bus provides a service discovery system that lets you not only send messages to named endpoints, but also monitor whether there's something on the other end of the endpoint, and if necessary, request that it be started before you send the message in a non-racy fashion. It also provides a common, typed, structured, discoverable, auditable serialization layer which is necessary for doing API-style IPC, and a benefit besides since when you "just use sockets" you have to do all the serialization and deserialization yourself, leading to possibly buggy code. Oh, and it also does multicast, which no other commonly used Unix IPC can do. People who say "I don't see the problem that d-bus solves" aren't looking hard enough and/or are ignorant of the issues of how software gets developed in a modern environment. D-bus solves many problems with IPC under Linux, and makes developers' lives a whole lot easier when they have to connect with other applications or services. |
| Also recommended by people who recommended this: | ||
| 1. | “dbus is not mostly about IPC.” (comment) | |
| recommended by 1 user | 2014 | hp on: DBus, FreeDesktop, and lots of madness | original thread | | ||
In creating dbus, I talked to a bunch of developers at KDE, specifically those who worked on Qt and DCOP, about their requirements. Then I met the requirements they said I had to meet for them to use dbus. I did the same for developers at GNOME. Because dbus met the requirements that the actual decision-making developers had, and allowed them to do useful things, it was adopted.
There was no mechanism to strongarm anybody into anything. KDE and GNOME devs told many ideas and many people to take a hike over the years. dbus was simply a matter of figuring out what those developers wanted and focusing on solving the actual problem, rather than hypothetical or philosophical problems.
When dbus was adopted, remember, people had already been down many roads; ad hoc IPC mechanisms, ad hoc communication through files and timestamps, hacks over X11 protocol, DCOP, multiple implementations of CORBA, SOAP, ICE (the old X-associated one), etc. People had wrestled with this problem space a lot and they had some pretty developed ideas about how to do things ideally. dbus was about coalescing those ideas into running code, and that was successful and stuck for a decade-plus now.
People sometimes have a "wtf" reaction coming from Internet protocols or kernel concerns, and while there are some wtf-worthy details in any piece of software, lots of the time people just don't understand the problem. Just as GNOME and KDE both took years to understand it and flailed around with all those protocols that didn't work out well.