I too am sick of people telling me to accept ubiquitous containerisation (snapd), locking down of filesystems (macOS), overly complex init systems (systemd (1)), lack of server access (manage it via ansible/k8s, not ssh). Usually the arguments given are "it's necessary 'for security'", "this is where everything is going", "you have to trust the vendor". This is not the spirit of Linux or open source. I totally see the effect you mention of paid maintainers forcing projects into their employer's direction. As such I found it sad when even Arch fell to the systemd camp. And it's one of the few things it really enforces, it supports 6 different network initialisation methods for example, where all other distributions just pick one and go with it.
(1) I'm not all anti-systemd by the way. I agree init was bad. But I think other systems like OpenRC are way easier to work with.
Arch has only supported one init system at all times. We could still have stuck with the sysvinit with hacks to look like openrc, but nobody liked that. The initscripts where a mess to maintain and systemd enabled us to not having to care about these details.
If we stuck with the old system, what would the argument be today? "Arch only supports sysvinit! That is not the UNIX philosophy!"? You don't see any complaints on distributions that only support one init which is either runit, s6 or openrc. But when it's systemd somehow people get sad?
Runit will just run 3 scripts then supervise your service directory. _That's it_ and no other choices are made for you. You can compose runit with many other different types of systems according to your own tastes.
Systemd, ostensibly also just an init system, ties you to so many other non-init choices that I can understand the feeling of unease people have towards it.
The issue I have with systemd was mainly related to its heaviness not really fitting in with Arch's simplicity. And with the products of corporatism seeping through even one the most noncommercial variants of Linux. Basically what cwyers mentioned above.
I've been putting up with systemd as all the distributions I use have moved to it, but I never really liked it.. I don't like the way the scripts are so far hidden in the filesystem and I don't like journalctl, I prefer having simple logfiles.
I discovered Alpine linux recently as a server distro (previously I thought it was mainly developed for docker containers) and I really took a liking to OpenRC. It reminded me that things could still be simple even in a modern init system. I think it would have been a good choice for Arch, for me it would have been better than systemd. I don't even know the other systems you mention, I'm not an expert on init systems.. My opinion is just that of a user.
Arch is a pragmatic distribution first and foremost. If we can build systemd, and ship it as-is to have a complete init, and more features along with it, that is much more enticing then the alternative.
> I think it (openrc) would have been a good choice for Arch, for me it would have been better than systemd.
It would still entail maintaining some form of initscripts. I don't think most users realize how much of a burden this is, they don't really deal with that part of the system.
And there are things I do like about systemd, I also have to say. Especially the way you can pass a variable to a server with @, like run 2 instances on different ports.
I know very well that the rc scripts were a pain to maintain as I've written some as well in the past. So I really understand the benefit of upstream-provided service configs.
The transition to systemd for me as a user was just a bit more difficult. It deviates so much from earlier conventions, and adapting it I found difficult. It enforces a lot more than just the init system.
For some reason I always end up having to compile some of the software I use myself, and having to make scripts then. I found this a lot easier with OpenRC than with Systemd (having pretty much no knowledge of either).
But anyway I'm just one user and you support millions, I know you're making the right choices for the platform. Thanks for taking the time to reply to me in fact!
I'll be amazed if Arch has a million users. Our napkin math using steam user statistics put us on around 500k-600k users.
We forgot what we were doing somewhere. Oh yes, solving problems.
Or we can replace perfectly functional systems simply because replacing legacy systems with modern solutions has some intrinsic value on its own, even if the modern system brings no additional value.
There are bunch of real problems that could be solved with software, but there's no money in it so why bother? It's better to roleplay technical expert and collect consultation rewards doing nothing.
Policy proposal: Accept contributions only from people who have not done paid work for a large organization in the last 24 months. Large organizations are entities with 50 or more paid engineers. Contributions include bug reports, feature requests, pull requests, and donations of money or equipment. Anyone may contribute documentation and training materials.
So you end up in a situation where package and distro maintainers face some work to support systemd, and because everybody else is supporting it it lessens the burden. There's this sort of gravity to these big projects that's hard to escape, and frankly a lot of people don't feel the need to; they view it as something they can get in a stable orbit around, not as something they're being sucked into.
This, I think, is the key to understanding this whole rant. It is entirely of a piece with the anti-systemd crowd, and I think understanding what was really going on there helps explain this rant, and a lot of other agita in the community these days.
Like, if you followed the drama on the Debian mailing list, it could sometimes feel very surprising that they were willing to go to war over the least sexy thing ever, an init system. Part of the reply is that systemd is more than that, it's a bunch of low-level plumbing all lashed together. But, who cares about low-level plumbing that much?
The answer (other than 'the exact sort of people who run Debian') is this. Linux started off as being written by hobbyists, for each other. It was very often a labor of love. Even the people making money off it weren't doing so in Big Business sort of ways. Linux and the associated stack around it is being taken over by a lot of big corporate interests: Intel, Red Hat, Google, even Microsoft. Are they bad? That's a matter of opinion. Are they inept technically? Probably not, but a lot of it revolves around how you measure things.
But what is absolutely happening is that people who are paid to maintain these projects on the behalf of large corporate interests are more plentiful, both in headcount and in personhours, than people who are maintaining these things for each other. For people who were used to Linux as this anti-corporate space, that's a huge and distressing change. And they can feel powerless against it, because it's really hard to reach a critical mass of people who feel the same way as you, and are willing to do all the things to not just support a fork but to keep the rest of the ecosystem they live in open to the fork.
It's not about any one piece of software, and it's not _really_ about pure technical merit. It's about the culture and the system of values and the way that decisions are made and it's about who's in control. The author's complaint isn't so much that the Google style is bad (although I'm sure he believes that very strongly), but that it's harder and harder to find somewhere to escape its reach.