Why would I want to start working on software I don't use or need? Why do systemd advocates always insist that every implementation must include the features they think are important? The entire point of designing for modularity is that different people have different requirements; operating systems cannot be "one size fits all".
> yet when logind came around, had lots of strong things to say.
Yes, we had strong things to say about software requiring logind, because it is a terrible (and poorly documented, at least at the time) design. If you want to use logind, go right ahead, that's your choice. We were (and are) only angry about software that we used to be able to use adding dependencies to logind (or other systemd components).
> And none of the alternatives seem to really get away from the bash script paradigm
That probably won't happen, because shell scripting is the easiest/simplest solution for certain types of problems. Some of us have tried a lot of variatio9ns, and keep returning to openrc/bash because it's easier and has fewer problems, at least in some situations. However, on a traditional system (or openrc) nothing is stopping you from replacing the bash init scripts with another language or replacing the entire init subsystem with something else (like upstart, s6, something new?). The complaint isn't that your should use my favorite tools (like bash) instead of systemd; it's that we should strive for modular software so we can all use the components that work best for our different needs,
If you don't care about multi-user session management, sure, but considering practically every window manager/DE relied on consolekit and now logind to provide that functionality, I find it hard to believe it's not desirable by a large majority of users, some of which would belong to the group I was talking about.
I love how people who are obliviously not the target audience feel the need to chime in.
> Yes, we had strong things to say about software requiring logind, because it is a terrible (and poorly documented, at least at the time) design.
I agree about the lacking documentation, but in terms of design it seems quite solid. Any technical specifics as to why it is terrible? It's interesting that systemd's detractors always seem to be rather vague in this regard, makes me suspicious as to whether they did more than have a knee-jerk reaction to a tool that is different than what they used before.
> because it's easier and has fewer problems, at least in some situations
Am going to need specifics, because in my experience, the bash scripts always ended up being a hot mess of variable quality as per the individual author's scripting skills with inconsistent behavior across scripts.
Not to mention that none of the alternatives give me the functionality I want, because their authors strictly focus on the init part, whereas systemd's much more useful even after the system is up and running due to its event driven nature.
Now I realize that not everybody needs some of the extra features, but for those of us that do, (like container management), s6, openRC etc. is even less of an alternative in a real sense.
> nothing is stopping you from replacing the bash init scripts with another language
The init system needs to be designed to support declarative services from the get go, am not simply talking about using Perl instead of bash here, am talking more along the lines of the Nix vs apt paradigm.
> or replacing the entire init subsystem with something else
And is something stooping you? This is my biggest gripe with the anti-systemd crowd, am personally happy with systemd, so it's not me who needs to look for alternatives. It's you. And there are plenty, so please pick one that suits you. The constant anti-systemd bashing every time the name is mentioned from people who seem to barely know much about what it's trying, (rather successfully), to do is rather annoying.
As it currently stands, anyone who wants that basic functionality on Linux - something that's been supported on all other platforms since forever - has to drag along all the baroque undocumented complexity of multi-seat, multi-user support. Why? Well, it seems Red Hat has some customers who sell solutions based on that, or at least used to once upon a time... With the current price of a docking station used to support a single seat in such a setup being comparable to that of a fairly decent refurbished SFF PC, I can't see a huge market for this.
The constant misrepresentation and/or refusal to address the actual "anti-systemd" complaints by systemd advocates is also rather annoying.
> makes me suspicious as to whether they did more than have a knee-jerk reaction to a tool that is different than what they used before.
Resorting to accusations of incompetence only add toxicity to the discussion. You'll have to take my word for it, but I assure you I know what I'm talking about.
> but considering practically every window manager/DE relied on consolekit
Mine doesn't. Some of the special-purpose computer's I used to use didn't use a window manager. These may be uncommon use cases; so what? They solve the problems they are supposed to solve without any unnecessary overhead.
> I find it hard to believe it's not desirable by a large majority of users
So only popular need should be supported? The entire point I'm making is that there are many different reasons people use computers, including many that are unique or almost unique. I may use an older window manager, others might prefer to use consolekit or logind, someone else could be interested in developing a totally new post-window-manager design that doesn't even use metaphors like "desktop", "windows", "sessions", etc. All I'm arguing for is the freedom choose any of those options, which includes variations where consolekit isn't used even if it is used in popular configurations.
The alternative is to argue that one design must be used everywhere, even when it is inappropriate or unwanted.
> in my experience, the bash scripts always ended up being a hot mess
I disagree, but you're welcome to your own opinion. If other software works better for you, then great, use it. I'm not trying to convince you to write bash scripts; I'm trying to explain why a single "one size fits all" design isn't possible, because we may be trying to solve different problems or prefer different tools. If systemd wasn't tightly cou0led and instead played nice with the rest of the systemj, we simply replace parts of it when necessary and we wouldn't be having his argument.
> Not to mention that none of the alternatives give me the functionality I want
Which is why I want you to have the freedom to use the tools you prefer to use, even systemd. Shouldn't other people have the freedom to made different choices?
https://unix.stackexchange.com/questions/5877/what-are-the-p...
As I said in other comments, if you want to replace inis scripts with systemd format service descriptors I will support your efforts becuase using shell script is broken. If you in the making of replacing init with something better also replace logging, ntp, dns, dhcp and a bunch of more then I will say no. This is exactly what systemd does. Rewriting rock solid, CPU efficient code with something shaky and CPU intensive. No thanks.
>>> And none of the alternatives seem to really get away from the bash script paradigm.
Factually incorrect. There are many init alternatives that got away from the shell script paradigm. Including SMF in Solaris. https://www.thegeekdiary.com/a-beginners-guide-to-service-ma...
Good for you then. I am sure you were happy with X11's rotting core & didn't need Wayland in your life, you also likely weren't the one having to maintain its decades old codebase.
> If you want to write a better init system, go for it.
Am personally happy with systemd, thanks, if you're not, why don't you go ahead and write a better one, instead of complaining every time systemd's name is mentioned?
> This is exactly what systemd does. Rewriting rock solid, CPU efficient code with something shaky and CPU intensive.
That doesn't seem factual. systemd is a system manager, useful even after the system is booted up, I think people need to understand that first, it's not just an init system, because many modern services fit an event driven model these days. It's written in C and can run fine on tiny embedded systems.
> Factually incorrect. There are many init alternatives that got away from the shell script paradigm. Including SMF in Solaris.
Yeah, and launchd on macOS, by which systemd was literally inspired by, we're talking about Linux here, since that's where systemd runs, at least I was.
How about picking up the work as well?
And none of the alternatives seem to really get away from the bash script paradigm & more towards the declarative side of things, which doesn't feel like much beyond keeping all that was terrible about sysvinit around in thin wrappers.
Maybe GuixSD is the one exception to this.