Hacker News Reader

Comment by vezzy-fnord | Hacker News Reader

LSB is actually somewhat to blame for prolonging sysvinit's lifespan, in its specification of standard initscript functions (which ultimately were seldom used and laughable compared to /etc/rc.subr in BSD-land) and the awkward dependency headers that required a preprocessor like insserv(8) to scan them.

systemd as base system will certainly happen, regardless.

View on HN

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.

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.

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?

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, and many others, prefer sysvinit over systemd...

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

> systemd as base system will certainly happen, regardless.

That's really a shame. Systemd is almost comically bad.

Has someone made a resource where noobs like me can go and read about why systemd is "almost comically bad" in a succinct fashion?

I've seen a lot of political stuff, and a lot of claims that sysvinit ain't broke so we shouldn't fix it (which makes little sense to me), but haven't seen a good resource discussing technical merits, or the lack thereof.

Ugh.

I could probably do it, but in all honesty, the "debate" has been so spoiled that I doubt anyone would take it seriously. My relatively technical article about FreeBSD and launchd (which had only one error about where plists were parsed, a relatively minor gripe in the text) was near-universally misunderstood and derailed by commentators who went on rants tangential to what I actually discussed. Same with my init history article.

But, if enough people want to, maybe I'll bite the bullet. Not sure if I'd like to subject myself to it, but I think I might end up writing a rather long treatise if there's demand and I do go with it.

I'd also be interested. I kinda like systemd as far as I've tried it, but as you say, the discussion around it is just inane. I'm sure there are valid complaints buried in there, and you seem to be a reasonable sort about these things.

There are other pages out there claiming to be neutral overviews, but they generally just take a neutral tone while rehashing the same long-debunked myths and spreading FUD.

The specific thing I like about systemd is the init replacement. It's just so much better! Automatically tracking daemon child processes, even detached ones. Supporting all the different modes daemons work, so I don't need to write yet another damn clean-up-all-the-children function in a SysVinit script. It's wonderful.

But systemd is a lot more than an init system and I don't really have strongly formed opinions on those.

You should start by reading the stuff that xe has already written:

* http://blog.darknedgy.net/technology/2015/09/05/0/

* http://uselessd.darknedgy.net/ProSystemdAntiSystemd/

Another persons writings to read, for similar reasons, is Ian Sutton, who is the bloke who did SystemBSD:

* https://news.ycombinator.com/item?id=10176275

Those don't cover the technical aspects, although to be fair, something like 70-90% of the systemd "debate" is about non-technical issues, like "the Unix philosophy" or "change for change's sake"--just read the comments here!

Well no, I've never written a central architectural critique of systemd, only scattered criticisms across comments. I will nonetheless be remedying that soon.

I'd be interested :-)

Bring it on!

http://without-systemd.org/wiki/index.php/Arguments_against_...

http://systemd-free.org/

This conflict between Linus/kernel devs and systemd devs is pretty fascinating, I hadn't seen it before.

Here's an example:

http://lkml.iu.edu//hypermail/linux/kernel/1404.0/01331.html

https://bugs.freedesktop.org/show_bug.cgi?id=76935

Indeed, that bug report is an interesting example. I can see both sides failing.

1. It was not a good bug report. 'Do not parse "debug" command line parameter' is not a bug. The actual bug is "assertion in systemd-journald" which is a clear regression, but independent of kernel parameters. According to comments 17 and 22, it was promptly fixed.

2. According to projects process, discussions about design are to be done on the mailinglist and not in the bug tracker. Most commenters violate this.

3. No systemd dev explained why they parse the debug parameter.

4. Sievers closed the bug report without explicitly acknowledging the assertion problem.

5. The kernel devs (especially Linus) are too hot headed and misread this. Systemd caused and fixed (!) the assertion problem.

Well, it makes the whole adoption story even more irritating.

Literally everyone with a clue in the matter seems to hate systemd with passion[1].

A long-term Debian Maintainer quit over the issue[2].

Linus himself (as you quoted) seems more than a little annoyed by systemd and its developer.

And yet somehow systemd made its way into all major distros...

[1] https://lkml.org/lkml/2014/8/12/459

[2] http://err.no/personal/blog/2014/Nov/16

You're quoting a troll as reference for "anyone with a clue". Further, you're referencing that the systemd Debian maintainer quit on the harassment in the systemd discussion because he wanted systemd _in Debian_.

Linus called out on some behaviour. That is not him saying that people should stop developing. It's him saying stop this behaviour.

You're quoting a troll as reference

Christopher Barry is most certainly not a troll.

As shown in the LKML and Debian debates, the systemd infestation was firmly opposed by nearly everyone outside the 'vested interest' RedHat filter bubble. And still is.

Some high profile names would be Eric S. Raymond or Patrick Volkerding (creator of Slackware).

Debian has been forked over this; https://en.wikipedia.org/wiki/Devuan

That is not him saying that people should stop developing. It's him saying stop this behaviour.

It's him finally calling Kay Sievers out for being incompetent and an asshole. Which was long overdue.

Sadly it's by far too late and will very likely not change a thing about systemd's "break and extinguish" strategy.

Systemd will continue to break other peoples projects in its effort to replace every mature service implementation with a hacked up systemd imitation.

At least until, hopefully, the major distros finally acknowledge their mistake and roll this disaster back.

http://ewontfix.com/14/ is one of the classic posts here, but it deserves a good rebuttal, not the straw-man one included. (The starting point I'd make is, if init were really as simple as purported, why isn't it built-in to the kernel? Why not simply skip all the kernel code to reparent children to init, and have children die immediately instead of becoming zombies if their parent has exited? Why not remove all the code to panic if pid 1 dies, and make it just a process like any other?)

There is stunningly little content in that link. There's a lot of broad points absolutely devoid of serious examples of how they are problems under systemd.

You can't just go "attack surface" and have said anything useful, nor can you point at volume of code if that code is actually needed. All criticisms of systemd usually depend on people completely ignoring the very serious problems you can't solve with sysvinit and which do make actual, practical systems less secure (i.e. cgroup process isolation is amazing, and a lack of real service management is a huge problem and any service management is going to be running as root period. Yet there's been a real claim that service management is "what your sysadmin does". Why even bother with computing then?)

Reply on news.ycombinator.com