But there’s no sense crying after every mistake.

You just keep on trying 'til you run out of cake.

systemd-resolved is an independent binary and entirely optional, just developed by the same project.

That said, it’s good. Supported DoT and DNSSEC early, easy to configure. No complaints for simple usage.

deleted by creator

That’s the very opposite of the Unix philosophy though.

Did you know Gentoo has binary packages now?

I use gentoo, so I feel that

My initial learning was in 2004 with Ubuntu, so Upstart and I also messed with FreeBSD, so I was familiar with the RC system. Systemd took me a bit to wrap my head around, and I don’t mind it. It’s good to know both.

Are you profiting from running systemd?

I also use systemd a lot and it baffles me people can claim sysvinit was more reliable with a straight face.

Half the time I restarted MySQL in the sysvinit days (pre-upstart as well), it would fail to stop it then try to start a new instance of it with the old one still running and the only way to fix it was to manually stop the other instance.

Process management is like the one thing systemd really does well thanks to cgroups, it’s impossible for it to lose track of processes because the process lied about its pidfile.

SysV init does one job, it runs a set of scripts in an admin defined order, the init portion of SystemD attempts to solve a dependency graph at boot time and execute the startup scripts (units) in the order it devines from that. The big problems I’ve had around that have been services silently failing to start because it failed to resolve the ordering, and the difficulty of inserting a new unit into the ordering in a specific place. It’s doable if there happens to be a target at the point you want, but if not you can’t really do it as the existing, and any new, services all sequenced on the existing target. With SysV, of course, setting the service start order is trivial.

The thing is, if SystemD was just an init system it wouldn’t be as bad, and has some useful ideas, but it tries to replace huge swathes of the system. As you say, some, and I’d say most, of the default housekeeping services suck, and you need to replace them. Unfortunately this then breaks the much vaunted integration of those services. Leaving them on the system isn’t a great plan as it just leaves the extra attack surface. So now you need to contemplate repackaging it to exclude the stuff you don’t need, which is a huge pain, and makes keeping up-to-date a big job. You’ve also got to worry about breaking dependencies from other packages.

Probably the biggest issue though is the huge attack surface SystemD exposes on your system. We’ve just seen an example of how that can be taken advantage of, with malware in a library way down the dependency chain from the system library that gets jammed into all sorts of things. I understand there is an effort underway to reduce those dependencies, but it’ll always be worse than simply not doing that in the first place.

The architectural and design issues are to do with the way the different parts are so tightly linked when they have no rational reason for being, the level of complexity introduced to core services and the incoherence of some of the choices around behavior. A recent bugbear was the automounter. It works most of the time, but if a mount unit fails it just gives access to the mountpoint, when by definition you obviously and explicitly didn’t want that. It also has a nasty habit of marking the unit failed, so future attempts also get bypassed until you reset it or have a recovery unit to do that.

Anyway this turned into a wall of text, and its late, so I’m going to stop there, I hope it’s reasonable coherent.

Systemd has a larger attack surface area since it touches more things, even though you can assign user accounts and such. Just the simple fact that it does more things than simply executing a shell script (like everything before systemd does) makes it more vulnerable.

Such as?

/s is bloat, say it like you mean it!

I actually don’t remember why I lost my patience and just tried Void then (4 years ago). Maybe had something to do with installing a Linux on a laptop after using only FreeBSD for some time, and sound setup and brightness control being confusing (actually everything in Linux is more clumsy and messy, so wanted a simple distribution).

Debian I like, but it has a bit older versions of packages, as everyone knows, and also kernel versions, thus hardware support.

Fedora - I don’t like the culture.

OpenSUSE - I like it, but didn’t bother back then and now why change anything.

Arch - I don’t like the idea of regularly solving problems which can be avoided by maintainers. AUR is attractive. The culture of clueless people proud of the fact that they installed Arch is a bit irritating.

Gentoo and Funtoo - I like them, but time spent on compilation could be used better.

Slackware - my favorite distribution, but it’s a bit manual, so even more chores than with Arch. I think I might try it again.

And also Void has something just a bit similar to FreeBSD ports. I’d prefer it to be a real ports collection like in CRUX (which I might try some day), and I use pkgsrc anyway for such things now.

the logo is cool :)

People don’t need more recent complaints when those complaints are still relevant today.