Tobias Hunger

Go ahead, you have my blessing. Not that you need it or care about it :-)

Just out of interest: Where do you think the future of computing is?

The kernal of course has exactly the same functionality as kernels in systemd distributions. What good is that without the user space using the functionality though? A portable init tool will not use any of that… as soon as they do, the portability is gone and they are linux-only.

Systemd-logind delegates priviledged operations like cgroup creation, power management, and such to PID1 (systemd) because that is the process with the necessary privileges and global view of the entire system to perform them. Managing that stuff is the one job systemd-PID1 has, logind is in a layer above and uses the foundational interfaces from the layer beneath it.

Elogind removes that integration by necessity. No idea what it does instead, but going by elogind devs stating that consolekit was good enough and that logind is just a power grab, I doubt they do a very thorough job. That elogind is basically only updated when a new gnome version uses interfaces not provided by elogind does not indicate a very pro-active maintainer team to me.

But you do what you think is best for your systems, I do what I think is best for mine.

IMHO supporting several init tools does more harm than good to any distribution. Its a lot of extra effort that few users will even notice.

Traditionally we used a script to boot. Those of course looked different in each distribution, but the “init tool” was the same. Then we switched over to sysv init (and man did people complain about this overcomplicated mess of symlinks!), yet pretty much all distributions switched to that. Of course they shipped widely different init scripts, but the tool was pretty much the same everywhere. The Linux Standard Base even prescribed the sysv init and any compliant distribution had to use that. We never had a time where distributions offered options wrt. init tooling.

I doubt the portability issue reporting from gentoo makes any difference whatsoever for the BSDs. They come up with all kinds of Linux compatibility stuff and that gets them the software they want.

Of course there are dependencies. They all are tools that do one thing well amd call into other tools to do thenthings those tools were built to do. E.g. many need systemd-init to function as that is the tool to manage the livetime of services running on the system.

So why bother about making init tools portable? You end up with a tool that works poorly on all OSes and nobody needs more of that.

Hardly any of the core systemd people work at Redhat these days. Microsoft employs more of them then Redhat. Right now I think Lennarts new company employes several of the key systemd people.

Contributions are comming in from all major distributions though.

Alpine is a wonderful distribution if you can afford to opt out of all thr security improvements made in the last 20 years.

Just try to log the keystrokes of another user (as root/some other user or even from a program running as the same user) and compare that to a modern systemd system. It is amazing what a difference the new kernel features make (revoking access, only allowing one process access) together with systemd-logind to pass access around to the right processes. There are tons more examples… any progress made right now is in systemd first. In fact most progress is never taken up outside systemd at all.

Out of interest: Which init system is used on several OSes by default? Last I checked all OSes wanted init systems that made actual use of their unique kernel features. Any POSIX compliant init tool will by definition not support OS specific features out of the box. Maybe you can hack them on?

I see this “they depend on systemd-specific features”: Of course. The systemd project listens when user space developers report the probpems they face with their problems and tries to solve them. Of course developers are going to use that, why would they want to hack around a problem poorly instead of using a proper solution that is more stable, robust and has seen way more testing than anything they could write themselves? The problem is not systemd here, its nobody else bothering to do something.