Hacker News Reader

Comment by detaro | Hacker News Reader

There is some work on a replacement that does more while fitting the requirements and philosophy of alpine: https://skarnet.com/projects/service-manager.html

View on HN

According to that page "the main reason Alpine aims to replace" OpenRC is they want the init system to "interface with external events". Huh? The thing I like about OpenRC is is if I `grep -R socket` on its codebase then it comes up empty. Alpine seems to be leaning towards s6 according to that page, which appears to have a treasure trove of network services. Last thing I want is to wake up one morning after updating Alpine and have all these scampering daemons like skadnsd, s6-fdholderd, s6-sudod, s6-ipcserverd, s6-ftrigrd, s6lockd, and ucspilogd skulking in the background. Also the boldness of the name. If you name it System 6 then you're claiming you've built something better than Bell System V. The init process has total power over the rest of userspace. I'm sorry but I don't think your system administration paradigm that MiTMs DNS deserves to be /sbin/init. I just want a UNIX-like system with few opinions that stays out of the way.

Those last four s6-* programs are not daemons. They are chain loading programs that modify permissions or the environment then exec into the next program in the chain.

To be frank s6 and its cousins like runit have so much fewer lines of code -- I'm pretty sure it's fewer than OpenRC and traditional SysV both -- because of simple and thought-through architecture. If you're gonna do a systemd alternative at all, ever, it'd have to be on one of these sane foundations.

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).

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?

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.

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?

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.

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?

Good read, thank you!

Reply on news.ycombinator.com