But do you run systemd and complain or why do you even hate it?
its linux right, if a linux distribution decides to use it, its not systemds fault to be used and if you use it and don't take the time and effort to have it your way, you shouldn't complain either?
One of the most important feature of prior tools were transparency. Since they were single-purpose tools written with UNIX philosophy in mind, they were simpler, more robust and has less fail-modes. Systemd is pretty opaque and non-deterministic in that regard. This is not a "old man yells at cloud" stuff. You can't trust to a piece of code you can't trace and debug. Systemd makes it almost impossible with all the intertwined gears and IPC layers it has.
On the "I didn't have any problems" with it side. It might be working on your system, for your use case. It might not show its bugs on a system with a 90-day average uptime. I don't live on that world. I manage way more systems with way more different, niche, interesting hardware and software than that, and this tends to surface edge cases and where things break.
On the "do you run systemd?" part, yes I run it. On many, many machines 7/24/365.
It's easy to say "Why do you even run it, it's Linux, just distro-hop", when you have a single system. I don't. Projects, software has requirements, compatibility targets, etc. Also, considering the hardware we run, it's not that simple either.
Lastly, I run Debian personally since version 3. We use other distributions alongside Debian in our datacenter. I'm very involved and rooted in these systems, and Debian feels like home after using, contributing, and developing derivatives on top of that.
...and how systemd has been forced into systems is another story. I have been there, watched that, so, errm, it's not all voluntary, peaceful and friendly, to put it kindly.
Been there too. The thing I disliked most, that it sometimes get stuck in some strange pose, without any reasonable way of remediation. And because it is so annoying to debug, reboot become the only tool do deal with it.
The sheer complexity of systemd created nasty feedback loop: it is too complex to be debugged; people prefer to reboot it; that keeps problems keep accumulating inside.
We are no longer 50 years ago were a linux system or distro was fitting on a floppy disk.
The handful of tools like grep, cp, etc. have a complexity of a banana and everything else successful is so big, that it doesn't fit at all.
Blender, container, ffmpeg, vlc, vim, firefox and co. Huge code bases. And if someone woudl argue "yeah but firefox is doing one thing, its browsing" thats an argument you can bring for systemd too.
Systemd is just not a 'start services in the right order' tool. Its more holistic
All the examples you give fit into UNIX philosophy rather well. Firefox doesn't do text editing and ffmpeg doesn't render web pages, and vim doesn't transcode videos. They do one thing and do it well. They are as simple as they need to be not more.
Also, if GNU coreutils have a complexity of a banana, why uutils still can't replicate them as-is? Why they had ~140 CVEs in one release despite being written in Rust? If grep is simple, why we have only two performant implementations, grep and ripgrep?
Even FreeBSD guys discussed this: https://lists.freebsd.org/pipermail/freebsd-current/2010-Aug...
You're simplifying too much, I believe. Try writing a cp clone, why not?
systemd started as a start services in the right order tool, then bloated from there. Being holistic is not the problem, being holistic in the wrong way is.
Now, they decided that DBus is not nice enough and created their own IPC mechanism. What was that? Varlink? They don't stop there even. They say "Hey, why not try Varlink?". So to translate: "We want to kill DBus so, we will force Varlink on you".
Just starting a service at boottime doesn't help much and ignores a lot of stuff around.
What do i start when a user logs in? how many resources is the service allowed to use? How do i control that service and read its logs?
If i already start a service, i can also start a service based on other events like bus events (which are needed potentially anyway for services to communicate) or by time.
And all of this needs to shutdown properly when finished.
Actually, I would argue that browsers are doing too much :-). Webapps shouldn't be a thing, browsers should be for loading websites. Apps should run outside the browser in the OS.
You did not deal with the most important complains that is the easy of debugging, modifying and changing stuff. It lacks a lot of this and one can question how much of an improvement ini like files are that are then interpreted in opaque ways that to provide desired features such as containerization or jailing. I personally want to usually run containers with podman, do systemd containers give me anything or is it just more cruft, same with isolation, do I really gain much from the complex namespace abstraction rather then using unshare.
> "yeah but firefox is doing one thing, its browsing"
Browsers as they exist today where a mistake that is clear. those other tools you mentioned might be large but they don't violate do just one thing well.
I am not even that much of a unix guy (I use emacs which the unix people like to shit on of course and does not fit with the do one thing well). But you are not providing arguments against the issues we have with systemd and have not demonstrated its value over other init 1 systems and even the harder case you seem to argue for it's applicability everwhere.
For me systemd is similar to blender, firefox and co.
But the unix philosophy thing came not from a time of blender, firefox and systemd but a time of ls, cat, grep, xargs and co.
I explicitly said firefox is not like this (and browsers are bad) and I don't really see your point with blender (though don't use the program so I can defer to you knowledge), I even said I am a heavy emacs user and so don't believe in dogmatically following 'do only one thing well' principle.
All you have to demonstrate is what is the value.
> But the unix philosophy thing came not from a time of blender, firefox and systemd but a time of ls, cat, grep, xargs and co
are you trying to say ls, cat and grep have been superseded? this is absurd these tools are still useful and not replaced what is your point here what are you trying to establish?
My question would be where is systemd a better experience or easy to work with then openrc, have you ever had to disable any of the systemd defaults services such as resolving or networking and had issues with the way a distro set things up. I don't know how you can claim you have never an into an issue with it given that any piece of software you will run into issues with.
I am also arguing more for openrc which is a newer project that has notions of dependence's and such.
If I may show where I think 'do only one thing well' is violated and correctly so is emacs (at least in part), for by having emacs as what boils down to a constant text interface I can use generalized text editing, searching and deriving buffers all in one program not having to configure anything else, my editor is my console and I can use my editor tools in my console even the ones I make.
So where is it demonstrated that the coupling is a boon that out weights the cost.
unix fixed MULTICS which on 70s hardware was already too complex. The unix philosophy is applicable to problems of whatever complexity and is a mere instantiation of problem solving strategies that humans and even crows have been using for ages.
It's difficult to avoid systemd at this point and it's not because it's the best technical solution for all use cases in the same way that modern windows is a complete shit show but still everywhere.
My question would be what does systemd do that is not possible outside of openrc and launching what ever daemons you want for the tasks you want or combining it with what ever programs you want to do things like sand-boxing or containerization? Not saying openrc is a panacea but systemd is definitely not either and for many systems is just plain annoying, I can consed for people who want a normal desktop (plug and play distro experiences) experience it can provide that.
As I said, i'm using it for probably a decade by now.