On the other hand I was happy and welcoming of systemd then I started to experience way too many breakage due to attitude of the devs.
When you have to spend 2 days to get to a remote server room and back because suddenly systemd decided that a device in fstab not present at boot would halt boot with error and at the same time the emergency shell was broken and going into a loop of asking for credentials, on a debian server, in production.
Ok systemd works most of the time but after experiencing a few of these breakages I've become wary of anything systemd.
Whatever it brings to the table is not worth the wasted time and headaches it causes.
Apart from the two-item sample of personal experience I am kind of torn about systemd - some of the problems it attempts to address are real, and addressing these in general seems like a good idea. The way it does so, however, sometimes (I am being deliberately vague here) brings along some problems of its own.[1]
And the further systemd adoption and systemd's mission creep go along, the harder it becomes to backtrack and replace it in case somebody comes up with a better solution.
[1] Like I said, I have not experienced any of these problems myself, but I have read a couple of reports from people that had problems with systemd that were definitely not just aesthetic.
> I have not experienced any of these problems myself
That's the problem any time[1] a system is designed around ideological purity.
Someone invents something clever that works most of the time for most people (with varying definitions of "most"), so they try to apply it everywhere. As no idea can account for everything[2], this sooner or later the inflexibility of the theory meets the variation of realty and some type of drama happens.
Usually it's better to avoid anything that exhibits that kind of inflexibility and hubris. Systems that build in ways of handing the unexpected or patching around their own weaknesses are necessary or drama is inevitable.
[1] Not just computer systems - this is true most of the time humans build systems. We see the same problems in religion, politics, and social constructs. It's such a common behavior, I suspect there may be an evolutionary basis for it (using a single common rule for many situations requires less energy).
[2] Even the physicists are still working on that problem.
Agreed. Which is why I said On the other hand a certain amount of skepticism and criticism is very much in order.
The problems systemd tried to address are real, and some of the ideas behind it are appealing. But the way it attempts to replace several important pieces of the system at once, and the way it is being forced on people in a "eat it or leave it"-style feels uncomfortable.
Part of what made Unix what it is today is the idea to build a system that might be very far from perfect but that is easy to improve in small, incremental steps so one quickly gets a feeling for what works well and what does not.
Frankly i feel that way to many sub-projects within systemd is at this point "i can rewrite this faster than get patches past the maintainers". Often with the "hilarious" outcome that problem that was solved a decade ago crops up again in the new implementation within systemd.
For one thing, a method service management that does not just fire off commands but monitors services and restarts them if they fail. Also, doing this with an idea of dependencies of services.
Event-based service management is interesting, too, e.g. shutting down a network service when the machine is disconnected from the network and restarts them when a connection becomes available again (think NTP, DHCP clients).
Once you have an idea of how services depend on each other, you get the ability to start services in parallel for free (whether that is so useful or even a good idea is another question).
Given the fact that systemd is hardly the first attempt to solve these issues (think SMF on Solaris, launchd on OS X, or the couple of attempts on GNU/Linux), I think a lot of people have felt the itch to improve on the classical SysV init.
When you have to spend 2 days to get to a remote server room and back because suddenly systemd decided that a device in fstab not present at boot would halt boot with error and at the same time the emergency shell was broken and going into a loop of asking for credentials, on a debian server, in production.
Ok systemd works most of the time but after experiencing a few of these breakages I've become wary of anything systemd. Whatever it brings to the table is not worth the wasted time and headaches it causes.