> That's subjective. I've talked to a lot of Windows users who all say Linux is a terrible solution for them.
That's a different statement. I said those linux parts are good solutions to a libc library and unix kernel. Not good solutions to needs of Windows users.
> Most users don't touch the init system that much.
Most BFU users don't touch the init system. If you're a developer/administrator/power user, you do. Yes there is more BFUs (website users, android users) than power users, but that does not mean that the latter group should be pushed to not care about their init system.
> Those are all optional
Not in practice; some of those options are integrated and others are chosen by the distributions. It's hard to reconfigure the system to opt out of journald or user session control.
> You don't have to use socket activation. It's there if you want it and you don't need to strictly order services.
Yes, but that won't solve the problem entirely, systemd is non-deterministic init system where you can't fix the boot order reliably.
> Not sure what this means or what keyboard input you were pressing. In systemd the keyboard shortcut to force reboot is pressing Ctrl+Alt+Del 7 times
Ctrl+C, Ctrl+Z. I mean I don't always want to reboot because something went wrong in the boot process and systemd is stalling. I want info from my init what went wrong, and the option to fix the problem in the shell if possible. This is often not allowed by systemd when it could.
> Not sure what this means either. You can disable those.
It means systemd launches bogus processes slowing down the system. It's well known, it's in the trackers, yes I can and i do disable them.
The point is this sucks and neither the systemd developers neither the distribution(rhel and derivatives) care to fix this.
> these use-cases were not sufficiently covered in the past.
Many systems do not have those use cases. Everybody needs an init system, so that's where systemd could have been the fix to the deficiencies of sysvinit (as marketed). Instead, it merely kind of works as init, sometimes with random errors and disrespecting the keyboard input when things go wrong. And then instead of fixing and polishing that experience, developers expanded into million other directions, including DNS, container management and what not. Systemd is becoming a bad OS like Windows is.
> User session are also now handled in systemd - one less component to be developed by the "Desktops" - yay!
But systemd is used on servers too, and the user sessions and broken behaviour it introduces are a needless pain best to be disabled there. User sessions and related is really something Desktops should be handling, since it only makes sense on Desktops.
> I want the tools I use to be good so I buy good tools
Right, good strategy.
> A significant part of the Linux community seems to me to be deeply toxic and that leads to what I consider to be suboptimal technical choices.
Do you mean toxic users influence some developers to make bad decisions? Any examples? Toxic users dumping on systemd may be one, but I don't think they have that much impact, systemd seems pretty successful in not giving away. Anyway systemd is a very specific case, this is not representative of all linux software projects.
Security is a spectrum, and too much security means less freedom and shitty life experience.
I don't have a problem with a new tool such as systemd-run.
I do have a problem with breaking well established workflows in the name of security/efficiency/ideology, when users didn't ask for it. That is a policy question with different answers on different systems.
Anybody who cares about that kind of restrictions has to think and implement policies on their systems on their own. Relying on systemd to do the right policy thing for everybody is unrealistic, naive and warped idea of what users need.
What kind of user services and "portable services" are you managing? I have trouble imagining what that means. User pulseaudio daemon on your laptop/desktop? Or some server services for many clients?
> Without systemd, bootstrapping a complicated desktop environment would be a hot mess
What is a complicated desktop environment? Why should I run it? I want to run simple desktop environment, like Xfce. I run startx in tty, and get unprivileged Xorg with Xfce on sysvinit system. It's rock solid.
> Systemd is really well designed and makes Linux workstation use predictable and more secure across distros in numerous ways. You can have any service you want now, even xorg/ wayland, as an unprivileged user. It basically removes all need to use root if used correctly.
It sometimes randomly fails to boot, waiting for some strange condition, while I am not able to intervene via keyboard in any way. That is "well designed"?
I run Xorg as unprivileged user by executing startx, on sysvinit system. There is no problem that needs systemd solution here.
> Production systems should never be changed or administered in place, only replaced. Servers should be immutable appliances. They do not need a package manager, or systemd, or ssh, or even a shell. Such things are developer tools and only belong in development environments like workstations.
That is a very restrictive work methodology (unikernels,exokernels). Although interesting and certainly useful in some cases (high security, rare updates), Bryan Cantrill was partially right on this - in the real world, we often need to debug stuff running in production and support paying customers who require that. Your idea of "production systems" and "servers" seems very specific and the "should" statements are often not true in practice.
Developer tools definitely belong on the server too, you need them to determine how to build your stack binaries in the best way for the OS and HW architecture there and keep them updated and secure.
> the bare minimum that typical end users need to know to stop systemd from breaking use cases that have worked for years?
That is bound to be a losing strategy. Systemd development (of breaking changes) is not stopping anytime soon. The simplest solution is to switch to an OS without systemd, like Devuan or Alpine or BSD.
systemd is usually a root process, regular user does not control it. Whether user being logged off means no such user processes should run is a policy question that has different answer on different systems and depends on the user as well. Systemd "unified solution" - killing user processes on logout - is not working well for many people especially on shared machines.
> I personally decided Linux was a lost cause and definitely switched to macOS.
That is an strange course of action. So because you saw some low quality discussion on the internet, you switched from free software you can influence to commercial one you can't?
Even then, the default broke decades of standard behaviour so systemd failed users here.
> long-running processes are services.
Not all of them. A data processing/computation job running for tens or hundreds of hours is usually not a service. What is "long-running" anyway? Again, people used nohup for running their jobs for decades without being logged in. That is the standard usage of nohup, systemd broke it.
> it is definitely our intention to gently push the distributions in
the same direction so that they stop supporting deviating solutions ... -- Lennart Poettering - Red Hat, Inc.
I recall part of the problem was that in some cases, Debian packagers/developers did not know how to integrate systemd with sysvinit properly, there were weird problematic constructions such as sysvinit scripts calling systemctl or vice versa and some breakage due to the way they used systemd. Of course, one could ask whether this was partly due to bad systemd documentation and unfulfilled expectations of promised systemd behavior.
You're right that systemd provides useful things that sysvinit was not strong about. That is not enough to make systemd as distributed a good init system. It is a bloated C codebase with no definition of goals, instead it suffers never-ending mission creep.
In mainstream distros, while it does init, it also meddles in too many things it should not, like spawning zillions of needless user session processes hogging the system, mutilated system and service logging and others. It hangs randomly nondeterministically on boot too often, disrespects the user by ignoring keyboard input, etc.
The major point of critique of systemd push is to make people know that many don't like the offered product for its mediocre results as an init system, and uncalled for meddling in other business such as system logging. And we welcome new leaner init systems, such as s6.
But debian has chosen to adopt systemd, so at least some substantial part of Debian developers preferred going with it to keeping the status quo with sysvinit. Maybe they were badly influence by Redhat/Poettering, but it was their call.