Comment by einpoklum | Hacker News Reader

Comment by einpoklum | Hacker News Reader

Parent Full thread

> I sincerely believe that systemd solved a problem that nobody was willing to solve

What problem was there which nobody was willing to solve?

Also, "solving" a problem by creating a mechanism that in itself highly problematic in other ways does not necessarily count as a solution; it is a shifting-around of problems.

-----

The systemd "holy war", such as it is (mostly complaints on forums and in blog posts and in personal chats; don't remember any violence in this war) - is due to four reasons:

* The significant problems which systemd introduces.

* The way systemd has been developed and managed as project (including some grievances with individuals).

* The fact that distributions have not only adopted systemd, but made it effectively impossible to opt out of.

* Faults with the process in which systemd was adopted as a required default by all of the main distributions - bypassing wide opposition without addressing its criticism. So, the adoption of systemd exposed technical-governance/power-dynamics problems in the Linux distro world, with systemd serving as the symbol for those.

I like the off-by-one there, and choose to interpret it as intentional.

The fourth item is what I find to be the most interesting. I really hadn't thought about it that way before. I remember the discussion in Fedora mailing lists around systemd and iirc the criticisms were mostly actually answered and handled. But in Debian it really wasn't and it fractured the community a lot.

It is perhaps the case that the "anti-systemd" crowd wouldn't be "anti-systemd" if they felt like they had been heard. Perhaps that's the bigger lesson we should all be learning: to listen closely and respond respectfully.

> I like the off-by-one there, and choose to interpret it as intentional.

Amongst our weaponry are such elements as... I'll come in again.

https://www.goodreads.com/quotes/1495-nobody-expects-the-spa...

> It is perhaps the case that the "anti-systemd" crowd wouldn't be "anti-systemd" if they felt like they had been heard.

I would say it is the other way around. systemd would not have been adopted as the default init system, had the anti-systemd crowed not been ignored.

But that's not even the main point. The grievance is not about how some individuals did not "hear". It is about the _possibility_ of such a decision being taken with that level of technical-community resistance; i.e. the expectation is that decent process would not depend only on the benevolence of those in charge. That's why it's a structural rather than a personal failure IMNSHO.

And again, there's the conflation, or bundling, of the multiple decisions:

1. Offer systemd in the distribution

2. Make systemd the default option for the distribution

3. Necessitate installation & use of systemd with the distribution

I am specifically pretty certain that Devuan would never have been forked if systemd were merely a configurable installation option in Debian.

> I am specifically pretty certain that Devuan would never have been forked if systemd were merely a configurable installation option in Debian.

You can't stop 5 or so random people on the internet from starting the 100th irrelevant Debian-based derivative.

"* The fact that distributions have not only adopted systemd, but made it effectively impossible to opt out of."

The job of a distro is to decide what to ship and integrate that in the best way possible. Would a distro let you choose between glibc and musl for example? If you want either, use a distro that chooses that.

This has more to do with systemd trying to be a "system layer" project for Linux, and influential projects (initially Gnome, then KDE, and now a lot of other things) going along with it.

Honestly, I see no reason a distribution couldn't support multiple service managers. Indeed, Gentoo officially support OpenRC and systemd and do just fine. However, you need to have the resources to do it and the desire. I think there are multiple distributions with one or the other, but Gentoo is likely the only with both.

> However, you need to have the resources to do it and the desire.

If resources were lacking to offer both regular and systemd-based init and service management, than a systemd offering should have been deferred until such time when resources become available, or different projects did some work of their own to reduce the amount of necessary resources. Offering multiple other init/service management options apparently doesn't require many resources.

(Of course, they could have saved a lot of resources by dropping GNOME until the GNOME people started being civil and not hard-depend on systemd... but I realize that's a bit of a controversial suggestion :-P )

> systemd offering should have been deferred until such time when resources become available

Why would you delay adoption of a technical superior solution if there is no interested/lack of resources in continuing maintenance of the inferior solution?

Distributions did not stop adopting Python 3 and invested in continuing Python 2 either.

> Why would you delay adoption of a technical superior solution if there is no interested/lack of resources in continuing maintenance of the inferior solution?

But a technically superior solution was not on the table to become the default, the suggestion was to use systemd and effectively prevent the use of anything else (including potentially technically superior solutions).

Reply on news.ycombinator.com