3 ms·

Interesting, I have a lot more faith in the alpine team implementing something like this than in RedHat. Even when RedHat made consumer OSes (before spinning th

Interesting, I have a lot more faith in the alpine team implementing something like this than in RedHat. Even when RedHat made consumer OSes (before spinning them off to Fedora) I didn't like them. What they're doing looks like a great alternative. I also hope they will not have any reliance on dbus as systemd does. Reliance on dbus is one of the main issues I have with systemd (besides its size and complexity).

zxzax 6y ago
I've seen a lot of these comments to this effect but I'm still not quite sure: what is the issue with dbus? Is there another replacement that meets all the use cases?
- detaro 6y ago
  Question is if an init system needs all the use cases dbus can support. Dbus always feels unwieldy to work with, especially once you leave specific desktop stacks, and for me personally, the biggest failures of systemd-based systems have been issues with dbus not working properly for whatever reason.
  - zxzax 6y ago
    I don't know the status of this on a practical level (e.g. in any given distro) but systemd does support daemonless dbus access over a private socket (/var/run/systemd/private) in some scenarios. Would that help?
- GekkePrutser 5y ago
  The problem I have with it is that it's not easy to interact with, and something that's very desktop focused. I think it's one of the examples of Systemd pulling in way too wide a scope.
  - zxzax 5y ago
    Can you elaborate? I found it very easy to interact with once I learned how to use the tooling (busctl, d-feet, etc). I also don't think I would say it's desktop-focused, it was designed for that use case originally, but it seems it can be used by anything else that happens to use a similar OOP-based RPC design (and it seems systemd is one of those things). Is there another replacement that's of a smaller scope that would cover all the use cases that systemd needs?

zxzax 6y ago

I've seen a lot of these comments to this effect but I'm still not quite sure: what is the issue with dbus? Is there another replacement that meets all the use cases?

detaro 6y ago
Question is if an init system needs all the use cases dbus can support. Dbus always feels unwieldy to work with, especially once you leave specific desktop stacks, and for me personally, the biggest failures of systemd-based systems have been issues with dbus not working properly for whatever reason.
- zxzax 6y ago
  I don't know the status of this on a practical level (e.g. in any given distro) but systemd does support daemonless dbus access over a private socket (/var/run/systemd/private) in some scenarios. Would that help?
GekkePrutser 5y ago
The problem I have with it is that it's not easy to interact with, and something that's very desktop focused. I think it's one of the examples of Systemd pulling in way too wide a scope.
- zxzax 5y ago
  Can you elaborate? I found it very easy to interact with once I learned how to use the tooling (busctl, d-feet, etc). I also don't think I would say it's desktop-focused, it was designed for that use case originally, but it seems it can be used by anything else that happens to use a similar OOP-based RPC design (and it seems systemd is one of those things). Is there another replacement that's of a smaller scope that would cover all the use cases that systemd needs?