Hacker News Reader

Comment by AdmiralACK | Hacker News Reader

I, and many others, prefer sysvinit over systemd, which I consider overly bloaty and not in-line with the unix philosophy of 'do one thing and do it well'. It's far too involved in the overall systems where, now, some desktop environments require it? That's absolute crap.

View on HN

I don't know of many people who actually liked sysvinit. It's mostly apathy due to its low surface (though actually sysvinit is still monolithic and overly coupled compared to members of the daemontools family like runit or s6).

It's a red herring, anyway. People have been replacing classic BSD and SysV initialization schemes since 1992 [1], but systemd was the first to penetrate the scene quite massively for a plethora of reasons that no one can seem to agree on.

[1] http://blog.darknedgy.net/technology/2015/09/05/0/

Responses to software seem to follow patterns. Sysvinit is basically Windows XP. People hated it for its lack of sophistication until it got replaced by Vista with its enhanced permissions, which people found inconvenient because they required slightly different interactions, and then XP became, if not good, at least the best in existence. Systemd will eventually be replaced by a minor revision which addresses the main complaints of the vocal minority, and then when NeoUpstart establishes dominance despite a massive list of bugs, systemd will rise to immaculate status and everyone will brag about how they used it before it was cool.

> Sysvinit is basically Windows XP.

Honestly that's unfair to XP/Windows Server 2003 which had much better supervisor capability than sysvinit provides.

To be fair NT4 had a better service management story in 1996.

And it would be interesting to see how much of that it took from VMS.

> not in-line with the unix philosophy of 'do one thing and do it well'

I'm not sure how you could, with a straight face, claim that sysvinit fits this description. It does many things, none of them particularly well.

Replacing a bad system (sysvinit) with another bad system (systemd) is just change for change's sake.

ah yes, the old "everything must be perfect before we are allowed to change anything" scree.

The only thing this accomplishes is ensuring no progress is made, ever.

Well, in fairness, systemd isn't really a matter of changing sysvinit. It's changing the entire low-level userspace, so there's a lot more one can object to, in principle.

Though I'm not going to say I really care for sysvinit - I prefer it to systemd as well. Every interaction I've had with systemd just ends up confusing me until I either successfully get it work _somehow_ outside of logic I can actually comprehend or giving up entirely. A lot of people I know have had similar experiences.

Interesting perspective. My experience has been the complete opposite - writing unit scripts used to be a real pain, but systemd unit files take two minutes and just work every time.

My machines start much faster with systemd too, which is a nice side effect.

I used to be on the fence. I knew I hated journald with a passion. But for systemd, the last straw was trying to mount a USB drive one day. I would do "mount", and nothing was mounted. I looked through the logs and noticed it was being unmounted on mount. What the fuck, right? Turns out, a prior unmount of a USB stick killed some service that systemd runs. So systemd thinks the service is dead, which means it should not be mounted, which means it keeps umounting the damn thing. Totally braindead.

That's also when I learned systemd was running an entire virtual fstab layer. Because, you know, /etc/fstab just isn't good enough anymore.

This is actually a good thing. You might have found it bothersome, but what it was doing was intelligently trying to reason whether a device would cause problems in your machine. It did not make the correct decision, but the infrastructure is there.

I would file a bug on systemd mentioning this behavior. But I like the fact that that my usb wifi card will not screw my system.

I don't want intelligent tools. The smarter the tool the more difficult it is to fix when it inevitably breaks. The intelligence might save a few minutes every so often, but the failures can cost hours, and at a time when you might urgently need things to work correctly. Predictability is more valuable.

> You might have found it bothersome, but what it was doing was intelligently trying to reason whether a device would cause problems in your machine.

What was intelligent about that?

I don't need intelligent tools, I need tools that do what I say! That's why they're tools, damn it!

This sounds very strange. Could you add a bit more detail. Which service crashed? Same service that caused the unmount? Any log messages?

> I, and many others, prefer sysvinit over systemd...

Do you prefer sysvrc over -say- OpenRC, Upstart, runit, etc, etc?

Reply on news.ycombinator.com