True - use a *BSD :~)
Regardless of the actual content of the post, I think that we could be seeing more init systems in the near future and I wonder how they will look.
A troll, and not a particulary good one.
Could you elaborate? I don’t know this debate very well.
The systemd developers are making it harder and harder to not run on systemd. Even if Debian supports not using systemd, the rest of the Linux ecosystem is moving to systemd so it will become increasingly infeasible as time runs on.
By merging in other crucial projects and taking over certain functionality, they are making it more difficult for other init systems to exist. For example, udev is part of systemd now. People are worried that in a little while, udev won’t work without systemd. Kinda hard to sell other init systems that don’t have dynamic device detection.
The concern isn’t that systemd itself isn’t following the UNIX philosophy. What’s troubling is that the systemd team is dragging in other projects or functionality, and aggressively integrating them. When those projects or functions become only available through systemd, it doesn’t matter if you can install other init systems, because they will be trash without those features.
An example, suppose a project ships with systemd timer files to handle some periodic activity. You now need systemd or some shim, or to port those periodic events to cron. Insert any other systemd unit file in this example, and it’s a problem.
This reminds me of a more aggressive version of how Pulseaudio was forced on people…then couldn’t be got rid of when it didn’t really work as well as advertised.
Is that a fair analogy to draw?
It’s the same guy, Pottering. I guess he’s refined his technique.
It’s fair. Only, people are way more mad because you can run Linux without pulseaudio, namely servers. As long as pulse works, no one really cares. But an init system, especially with the scope systemd has, touches a lot more things.
This comment is a bit self-referential by accident.
I dunno if the author is trolling as such, but there’s definitely a lot of argument in bad faith going on there. (That’s something new for systemd!)
To wit: right now, avoiding systemd is possible. However, the systemd devs are acting as though they want it to be as hard as possible in the future (absorbing udev, introducing Gnome dependencies on logind, being actively hostile to external development). Pointing out that right now avoiding it is possible and treating that as addressing the concerns about future compatibility is wrong, either due to stupidity or bad faith.
While I do like systemd as an init and process management system (just see how easy it is to write up a service file for any program and have full control over the created process), I also have worries about where it is heading. Recently the idea has sprung up to replace the Linux kernel’s built-in virtual terminal (CONFIG_VT) with a userspace systemd service. Does that mean that the Linux kernel itself will have a hard dependency on systemd in the future if you want text mode?
I don’t think so. It is an attempt at modularizing the system, though. Moving VT out of the kernel hardens the kernel against attacks against that very service. I read this as “optionally moving that out of kernel space”.
There are many uses of linux (especially in embedded environments) where such an approach doesn’t make a lot of sense, but in the server space, I see a benefit.