The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 30, 2014 20:45 UTC (Sun) by vonbrand (subscriber, #4458)
In reply to: The Grumpy Editor's guide to surviving the systemd debate by dlang
Parent article: The Grumpy Editor's guide to surviving the systemd debate

Remember the days when much stuff for Linux was developed in/through non-vanilla kernel trees, and Alan Cox' tree was the one most bleeding edge hackers followed? Could set up a git tree and merge said patches in there, that is just a few keystrokes away. Merging in upstream changes is ridiculously easy with git, no need to handle random text patches flying by on mailing lists. Not doing so is a dead giveaway to me that they aren't serious.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 30, 2014 21:02 UTC (Sun) by dlang (guest, #313) [Link] (2 responses)

I remember those days, but you only go to that sort of effort if you _really_ want the functionality provided and it's worth maintaining a fork.

For many people, systemd just isn't that compelling.

It's like the attention paid to fast boot times and suspend/resume, if you are dealing with systemd that stay up and running for months at a time, shaving a few seconds off of the boot time doesn't matter. If you are putting all your attention to servers providing 24/7 service, suspend/resume doesn't matter.

That's not to say that those features aren't interesting to other people, but the people who are interested in them (and correspondingly the people who are interested in features that systemd provides) need to accept the fact that it's not interesting to everyone.

And when there is a regression or performance hit to something that you are interested in because of some feature that you aren't interested in, that's annoying and people crowing about the feature you don't care about don't solve your problem.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 30, 2014 23:21 UTC (Sun) by vonbrand (subscriber, #4458) [Link]

I for one have never claimed systemd's advantage being fast boot, it is that it gives sane process management. That is even much more relevant on servers that should run continuously for months, having to reboot because some idiotic script got irretrievably wedged (yes, has happened to me) isn't acceptable.

The Grumpy Editor's guide to surviving the systemd debate

Posted Dec 1, 2014 0:46 UTC (Mon) by anselm (subscriber, #2796) [Link]

Many people don't seem to find systemd compelling but they're still outraged that portability isn't an important goal of the project so it won't run everywhere right off the bat. This is a bit incongruous to say the least.

From what we hear, systemd does have lots of features that are interesting to many people – from embedded-system developers to server admins. Fast boot times are nice to have and systemd seems to work well in that area, but systemd is not just about fast boot times; they are a fringe benefit of the approach systemd takes for service activation. (Incidentally, even on servers, people who deal with on-demand virtual machines seem to appreciate a faster boot process, so it is incorrect to claim that boot times are irrelevant to servers.)

Of course anybody may feel free not to be interested in systemd's features, which is why systemd is not mandatory to run Linux, and is unlikely to ever be that way as long as those not interested in systemd are willing to put in the work to maintain a systemd-free Linux distribution (if nobody else does). Whether other people – such as upstream developers who would like to avail themselves of systemd's features – will bend over backwards to make it easy for them is of course up to those people. Then you get people like the Debian developers, who on the whole seem to be happy with the concept of supporting several init systems (in particular, sysvinit and systemd) at the same time as long as this is dealt with in the usual way (i.e., by means of wishlist bugs, preferably with patches attached) rather than mandated by GR. This means that if you do notice a regression or performance hit to something you are interested in, the first step towards getting that fixed is to submit a bug report. Crowing about it on an unrelated web site doesn't solve your problem, either.