Dev.SN ♥ developers
Sections
Dev.SN
from the Boot-him?-I-just-met-him! dept.
jbernardo writes:
"Having had several issues with systemd, and really not liking the philosophy behind it, I am looking into alternatives. I really prefer something that follows the Unix philosophy of using small, focused, and independent tools, with a clear interface. Unfortunately, my favourite distro, Arch Linux, is very much pro-systemd, and a discussion of alternatives is liable to get you banned for a month from their forums. There is an effort to support openrc, but it is still in its infancy and without much support.
So, what are the alternatives, besides Gentoo? Preferably binary... I'd rather have something like arch, with quick updates, cutting edge, but I've already used a lot in the past Mandrake, RedHat, SourceMage, Debian, Kubuntu, and so on, so the package format or the package management differences don't scare me."
[ED Note: I'm imagining FreeBSD sitting in the room with the all the Linux distros he mentioned being utterly ignored like Canada in Hetalia.]
(Score: 1) by bluefoxicy on Monday March 10 2014, @06:56PM
All of this sounds like paradigm shift.
I know folks who have embraced systemd and found it extremely useful. As with everything that's survived to replace a prior thing, systemd seems to be starting with a "large effort, small return" curve: it takes a lot of effort to make systemd work all the time, and in the end you're just trying to get it to do the same thing as everything else.
The thing with paradigm shifts is they happen because of the opposite. You start with high effort, low return; you hit low effort, high return; then you hit diminishing returns, where you apply much more effort for much smaller gains.
I remember when devfs faced this kind of mass pushback. Then it was hotplug, which became useful but was usurped by the hated udev, which is now accepted and is extremely important for a working system actually capable of most of what we have now--such as mounting a USB drive writable by a particular user just because that user happens to be the one at the currently active console. Each of these represented a paradigm shift where a prior approach was suddenly painful and clunky, but where the new approach was unrefined and took some effort.
What systemd started as, from what I can tell, is a new init system. You know that whole 'service vsftpd status' 'vsftpd is dead (pid file exists but process is dead)' thing? Well with systemd, you can tell it to restart things. You can configure it so that it takes a host of actions when a service dies, restarting or reloading other services. You can configure dependencies better. The hotplug system even allows for resource-based dependencies: reload proftpd or apache when a new network interface comes up if you want.
I suspect that some time in the near future we will see systemd not only replace the current infrastructure, but also become much better. It will polish its existing features, and distribution maintainers will ship with better support--better default configurations, as they needed with hotplug and udev. That means someone needs to write up init scripts, dependencies, automated actions and reactions, and so on.
After that, systemd will finally surpass ... what is it now, upstart? And people will talk about how it's so much better than all those old, clunky systems that were cobbled together near the end.