D-Bus is absolutely not exclusively for the desktop! Please understand this. It's a data processing mechanism that runs as a headless daemon; or, more specifically, it's an IPC mechanism. The benefit of having it is that applications that need to talk to one another don't need to invent their own custom IPC mechanism (such as listening on a TCP port over a custom TCP or SOAP protocol; using UNIX sockets to send bytes back and forth; and so on).
So, we can solve all sorts of problems once and let programs reuse the functionality:
* Service / exclusive resource discovery (answers the question, "Is anybody else on the whole system using this resource?" -- such as a hardware device that can only be used by one process at a time, like an ALSA card). It's also easy to make this operation atomic, so that you can ask for resource availability, and if it's available, take it -- all in one operation -- so that it's impossible for two programs to query it, see that it's available, then both ask to claim it (that'd be a race condition).
* Bidirectional communication with a well-defined interface (answers the question, "What messages are there? What is expected of my program? What will the other program send me?"
* Asynchronous callbacks: Ask a remote server to let you know when it's done processing something, then continue doing something, then get the callback event and process it.
On Windows, there's WCF for something similar. And they (rightly) encourage people to use WCF not only for desktop applications, but especially for client/server communication and interprocess communication.
Anyway, if D-Bus becomes widely used by both client and server, it won't become just another annoying daemon; it'll be a central part of the operating system that everyone accepts. I'm not necessarily saying that we should convert existing applications' protocols over to D-Bus, but new applications are free to use D-Bus as they wish. And systemd does -- so what?
Another generalized IPC mechanism with some overlap with D-Bus is ZeroC ICE. Mutter uses that. While I think ICE is good, consider that if we use every IPC mechanism out there simultaneously, the combined library load on RAM is going to be much higher than if we just pick one. Since D-Bus has been around a long time and is fairly well-tested, standardizing on that would actually increase system performance and available RAM, not decrease it. (You can apply this same argument to any other IPC mechanism out there.)
BTW, systemd isn't just useful for fast booting, either. It has quite a lot of useful administrative functions that make it better than SysVinit for managing daemons. What do servers run? Daemons! Lots of them.
I don't know where anyone got the perception that either D-Bus or systemd are somehow geared for the desktop, designed for desktop use cases, designed for fast boot performance at the expense of bloat, or designed to benefit desktops while slowing down servers. All of that is unfounded. These two daemons are engineered primarily by Red Hat employees. Red Hat makes a majority of their income on selling server operating systems (RHEL is much less useful on the desktop than on the server due to its frequent obsolescence on the desktop. But many many corporations and governments buy RHEL support for servers.) Don't you think they have servers in mind just a little bit when planning out the core system utilities that will go into RHEL 7?
So, we can solve all sorts of problems once and let programs reuse the functionality:
* Service / exclusive resource discovery (answers the question, "Is anybody else on the whole system using this resource?" -- such as a hardware device that can only be used by one process at a time, like an ALSA card). It's also easy to make this operation atomic, so that you can ask for resource availability, and if it's available, take it -- all in one operation -- so that it's impossible for two programs to query it, see that it's available, then both ask to claim it (that'd be a race condition).
* Bidirectional communication with a well-defined interface (answers the question, "What messages are there? What is expected of my program? What will the other program send me?"
* Asynchronous callbacks: Ask a remote server to let you know when it's done processing something, then continue doing something, then get the callback event and process it.
On Windows, there's WCF for something similar. And they (rightly) encourage people to use WCF not only for desktop applications, but especially for client/server communication and interprocess communication.
Anyway, if D-Bus becomes widely used by both client and server, it won't become just another annoying daemon; it'll be a central part of the operating system that everyone accepts. I'm not necessarily saying that we should convert existing applications' protocols over to D-Bus, but new applications are free to use D-Bus as they wish. And systemd does -- so what?
Another generalized IPC mechanism with some overlap with D-Bus is ZeroC ICE. Mutter uses that. While I think ICE is good, consider that if we use every IPC mechanism out there simultaneously, the combined library load on RAM is going to be much higher than if we just pick one. Since D-Bus has been around a long time and is fairly well-tested, standardizing on that would actually increase system performance and available RAM, not decrease it. (You can apply this same argument to any other IPC mechanism out there.)
BTW, systemd isn't just useful for fast booting, either. It has quite a lot of useful administrative functions that make it better than SysVinit for managing daemons. What do servers run? Daemons! Lots of them.
I don't know where anyone got the perception that either D-Bus or systemd are somehow geared for the desktop, designed for desktop use cases, designed for fast boot performance at the expense of bloat, or designed to benefit desktops while slowing down servers. All of that is unfounded. These two daemons are engineered primarily by Red Hat employees. Red Hat makes a majority of their income on selling server operating systems (RHEL is much less useful on the desktop than on the server due to its frequent obsolescence on the desktop. But many many corporations and governments buy RHEL support for servers.) Don't you think they have servers in mind just a little bit when planning out the core system utilities that will go into RHEL 7?
Comment