upvote
The definition of my and your ages might differ a little. I have used many things which have came before systemd and did a lot of work on them. As a result, I have seen and experienced a lot of fail-modes of both systemd and others which came before.

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.

reply
> On many, many machines 7/24/365

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.

reply
I hate this 'unix philosophy in mind' 'principle' as an argument.

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

reply
You can hate it all you want, but UNIX philosophy isn't related at codebase size at all.

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".

reply
Wait till you do have an issue or even just want to disable one of the 'helpful closely coupled' services something works to better fit what ever you doing or for security/reliability reasons (D-Bus is a great example for me).

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.

reply
How much longer should I wait?

As I said, i'm using it for probably a decade by now.

reply