Hacker News new | past | comments | ask | show | jobs | submit login

> Not one or two, all of them. Writing an initscript started with copying the template from /etc/skel, and it was already pretty long. Compare that with the actual init scripts from FreeBSD/OpenBSD. Some are literally 3 lines long.

Unfortunately, a lot of the BSD wisdom is lost on people who try OpenBSD on their laptops, can't figure out how to connect to wifi without NetworkManager or wpa_supplicant, and automatically conclude it's arcane shit from another age. Clean init management is just one of the lessons that Linux could learn from there.

> Others have mentioned the code quality; I can't comment because I haven't looked at the code. One thing that really bothers me though, is the tight coupling with dbus. It doesn't matter how good the systemd-* code is, if dbus is borked then your whole system goes down with it. I can debug a misbehaving init script by starting it with sh -x. With dbus, it's a nightmare.

I've read the systemd source code here and there. At line level, the code is actually pretty good, idiomatic and clean. I don't remember seeing any obvious blunders.

Engineering-wise, I've seen better. The lack of a serious debugging infrastructure is just one of them, and that plagues pretty much any D-Bus application, not just systemd. A lot of features are gratuitous/unneeded, exist just because the developers couldn't bother to read documentation or didn't like the defaults of some tool so they wrapped it in a systemd interface, or simply because of Gnome.

Then again, a lot of things are badly-engineered and we run them. The only thing I very strongly dislike is the deployment/distribution model. It's a huge suite of tools of massive complexity; at any given time, for any given version, at least one of them is basically of beta-level quality, which means that, for any version N, you end up knowing at least one or two workarounds for a set of bugs. Then N+1 pops up. The old bugs are resolved, but now two other tools have been added, another one has been rewritten because reasons, and now there's a new generation of bugs that you have to learn and remember. The fun grows exponentially with the number of platforms that you need to support; I now know about, like, more than a dozen systemd bugs across five versions, because I have to support targets that use five different versions. I'm a walking bug tracker at this moment.

Edit: I know this is technically "the distributions' fault", but sometimes you don't quite have a choice, e.g. when working with whatever SDKs a manufacturer provides, or when dealing with systems where upgrades are difficult and infrequent for various reasons (regulatory, remote access etc.). Devops is not the answer to everything.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact