51–60 of 69 posts
Earlier quoted context omitted.
It depends if you are a fan of a centralized server vs decentralized communication. Anyway, all the complexities of using sockets/FIFOs could be hidden inside libraries.
Once you hide the complexities of using sockets you just end up with some sort of message bus that each application connects to and registers an ID with... which is essentially what dbus is.
Earlier quoted context omitted.
From the article: > udev and dbus are forced dependencies.
Dbus isn't a systemd project any more than a libc is a systemd project. Systemd just requires it as a dependency. It's a freedesktop project.
Earlier quoted context omitted.
> Edit: thanks for all the replies, yes, I get that dbus is for sending messages between applications, but what is wrong with e.g. UNIX domain sockets? I think the reason for dbus is that all of these processes want to talk to all the other ones, and they need to rendezvous somewhere. You probably don't want to open a unix socket for every 'topic' you want to respond to, and anyway if there's multiple programs intere…
> if there's multiple programs interested in the topic, how do you make sure they all get all of the messages, if they all listen to the socket, only one gets the message. Well, you could listen on a socket for subscribers ... (Basically a decentralized approach vs a centralized approach) > OTOH, dbus doesn't transit over the network, so eog on a remote host can't communicate with your desktop environment, so that's…
"I'm afraid to inform you that you have built a message bus with RPC features.
You had a program that needed to broadcast some information. You have built some simple mechanism using a UNIX socket. You send everything anytime someone connects to your socket and close the connection.
Then, your software grew and could provide various other things. It became impractical to send everything everytime so you needed some way to advertise what information your software provides, and receivers would send the list of what they need when they connect.
Your program grew again, and you needed people to be able to call your code to do some actions, so you added a way to call methods that can take parameters and to advertise them.
With the mess you ended up with, you felt the need to standardize how information and methods are represented and used. You designed a DSL to write schemas and some kind of code generator using this schema to automatically build interfaces for these methods and this exposed data.
You figured calling methods and requesting information through a UNIX socket directly is unwieldy, so you wrote a small library hiding this complexity to the caller and making everything more convenient to use.
Your program evolved again and you needed the callers to be able to receive events without having to poll. Your library now contains an event loop that the callers need to handle.
Your program kept evolving. Before the number of generated events and the performance issues it caused, you felt the need to add a mechanism to filter / subscribe to events to avoid flooding the callers.
Time passes, and your to had to write a new, unrelated program that also needed to communicate. You wanted to reuse the same mechanism. Callers needed to listen to multiple programs. Those multiple service providers could come and go and you noticed requiring callers to poll multiple UNIX paths to find out if there is a socket there was not practical nor efficient because of the syscalls and that it's better if they could tell some kind of daemon they are interested in a service and get informed when it becomes available. Therefore, you took the whole mechanism out of the first program and made it a daemon so callers had a central place to discover what is here, and providers to advertise themselves. This daemon of course needed to be run at system start, or at least in a lazy fashion, or the different actors would, again, need to do the UNIX socket path dance, which is not quite convenient after all.
Time passes again. In the bag of services you wrote, some are related to the system, and some are only relevant to a logged user. You wrote some kind of integration with your init system and your session manager.
I'm afraid you have built D-Bus."
In reference to the recent HN repost [1] of [2]
(edit: damned, I spent an hour writing this shit)
Earlier quoted context omitted.
> if there's multiple programs interested in the topic, how do you make sure they all get all of the messages, if they all listen to the socket, only one gets the message. Well, you could listen on a socket for subscribers ... (Basically a decentralized approach vs a centralized approach) > OTOH, dbus doesn't transit over the network, so eog on a remote host can't communicate with your desktop environment, so that's…
> Well, you could listen on a socket for subscribers ... "I'm afraid to inform you that you have built a message bus with RPC features. You had a program that needed to broadcast some information. You have built some simple mechanism using a UNIX socket. You send everything anytime someone connects to your socket and close the connection. Then, your software grew and could provide various other things. It became impr…
No of course, not, I would use a shared object file to do it for me. I.e. all functionality inside a library instead of a centralized process that can crash or hang.
Earlier quoted context omitted.
> Well, you could listen on a socket for subscribers ... "I'm afraid to inform you that you have built a message bus with RPC features. You had a program that needed to broadcast some information. You have built some simple mechanism using a UNIX socket. You send everything anytime someone connects to your socket and close the connection. Then, your software grew and could provide various other things. It became impr…
> "I'm afraid to inform you that you have built a message bus with RPC features. No of course, not, I would use a shared object file to do it for me. I.e. all functionality inside a library instead of a centralized process that can crash or hang.
Could you expand on your shared file idea? I'm interested. How do you implement this library without a central service? Note that in my humorous comment I still expose why I think a central program is necessary, now you can disagree with the use case of course.
It's heartening to see the Luddites failed to stop progress on this occasion at least.
The "Luddites" were right about the monoculture becoming a problem, though.
That said, what problems do you see with the systemd monoculture? Well, I'm not sure it's a mono-culture neither, we still have different init systems, both in Linux distributions and in other operating systems, so let's say its widespread usage?
Earlier quoted context omitted.
> "I'm afraid to inform you that you have built a message bus with RPC features. No of course, not, I would use a shared object file to do it for me. I.e. all functionality inside a library instead of a centralized process that can crash or hang.
We were talking about bare UNIX sockets and their potential drawbacks. I think they don't really scale / answer to all the needs D-Bus fulfills. Could you expand on your shared file idea? I'm interested. How do you implement this library without a central service? Note that in my humorous comment I still expose why I think a central program is necessary, now you can disagree with the use case of course.
Anyway, I feel that all the microservices are making me lose control over my system (and systemd is quite literally the mother of all these microservices, hence why I bring it up here).
Earlier quoted context omitted.
The "Luddites" were right about the monoculture becoming a problem, though.
I disagree with the Luddites designation. That said, what problems do you see with the systemd monoculture? Well, I'm not sure it's a mono-culture neither, we still have different init systems, both in Linux distributions and in other operating systems, so let's say its widespread usage?
And it's obvious why a monopoly is bad.
The systemd monoculture is the same kind of bad as a Google Chrome monoculture.