The Grumpy Editor's guide to surviving the systemd debate [LWN.net]

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 22, 2014 10:16 UTC (Sat) by anselm (subscriber, #2796)
In reply to: The Grumpy Editor's guide to surviving the systemd debate by thedevil
Parent article: The Grumpy Editor's guide to surviving the systemd debate

It is the lack of a third option -- keep waiting for something more clearly better -- that is the main objection. Surely this is obvious from the Debian GR, if nothing else. Pretending that this POV doesn't exist serves nobody.

The problem with this POV is that ”waiting for something more clearly better” is no guarantee that something more clearly better will in fact come along eventually. Someone would have to do active work to make that happen.

In particular, the main problem with this POV is that, especially given that most of the rest of the Linux world seems to be reasonably happy with systemd, the pool of people who are (a) sufficiently unhappy with systemd to actually roll up their sleeves to come up with something “more clearly better”, (b) sufficently qualified to do so, and (c) sufficiently committed to the long-term viability of such a project appears to be small indeed. (It is also fairly clear that very few if any of the current crop of vocal “systemd haters” seem to belong to that pool – we hear a lot of complaints of how systemd is badly designed etc., but nobody so far has condescended to propose a better design, let alone an implementation.)

to post comments

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 22, 2014 18:16 UTC (Sat) by thedevil (guest, #32913) [Link] (2 responses)

"sufficiently unhappy with systemd to actually roll up their
sleeves to come up with something"

"nobody so far has condescended to propose a better design"

You assume this is just due to laziness or pure troll malice, but
I think there is more to it. By all signs systemd's design _as
an init replacement_ is excellent, and that's why we don't see
any alternative proposals from qualified people. The problem
with systemd is its ever increasing scope, devouring (and
changing beyond recognition) more and more parts of the base
system. The solution isn't a complete redesign but splitting it
up, but that can only be done either 1. with the help of
upstream, which has not been forthcoming, or 2. by forking it.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 23, 2014 2:43 UTC (Sun) by seyman (subscriber, #1172) [Link] (1 responses)

> The solution isn't a complete redesign but splitting it up

Given how modular systemd is, I'm not convinced splitting it up would be a huge gain. Perhaps what's needed is a document explaining how to disable all non-core features and how to re-enable them once you're comfortable with your running system.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 23, 2014 7:13 UTC (Sun) by brodo (subscriber, #4049) [Link]

> Perhaps what's needed is a document explaining how to disable all non-core features and how to re-enable them once you're comfortable with your running system.

... or even something like "make config".