> Sysvinit scripts were terrible to write and frequently had bugs because the scripts were usually afterthoughts "Oh yea... I guess we need one of those things".

There were alternative solutions to that problem that didn't require replacing a long and ever-growing list of system components with tightly-coupled (and often buggy) systemd versions. In fact people who really cared about their init system were already using them.

Well systemd service files are great and represent a nice improvement. But I detest journalctl with its arcane query commands and binary storage; much prefer ability to use standard unix tools and my favorite editor for adhoc inspection at least. It's still is an annoyance on a pretty regular basis.

You can tell journald to forward everything to rsyslogd and grep to your heart's content. https://wiki.archlinux.org/index.php/Rsyslog#journald's_sysl...

How do I remove this buggy attack surface from that workflow and why should I have to?

"How do I remove" - I dunno, because I don't care to remove it. Somebody's probably done it. Search on Google? It's open source, so look at the code, submit a patch, fork if you gotta?

"Buggy attack surface" - I am unaware of attacks that target journald; can you point me to a practicable PoC attack?

"Why should I have to" - because other people are building your distros, expending their effort on open source projects, and as part of doing that they made decisions on your behalf. Feel free to not use those distros for ones that make decisions you prefer; the choice is yours.

Then you are commenting on the wrong post. This post is about the systems that do not use systemd. Justifying your own use by demanding examples of failure is... odd here.

So when systemd comes up it's cool for people who Don't Even Own A systemd to go on endlessly about how it's terrible and An Conspiracy, but it's not cool for people to discuss that it might not be the Snidely Whiplash evildoers thing by evil people when the shoe's on the other foot?

Weird flex, but okay.

Well, just excuse my philosophical stance of not liking my computers breaking by a new random cause every couple of months.

This is my experience as well.

Suddenly logins take 30s. Why? Some new systemd problem with reverse DNS.

Suddenly reboots don't happen. Why? Systemd is spinning on a task that didn't used to spin. Yes, probably fixable, but not discovered until trying to reboot.

Can't login at coffee shop WiFi suddenly. Why? Some random systemd DNS issue.

Is my system more secure? Maybe, but possibly because it breaks so often that low uptime keeps it safe!

For my servers, I seriously have to cross my fingers and have the colo phone number handy whenever I reboot, fearful that they won't restart because of some random systemd interaction that happened on some previous upgrade. It's gotten that bad.

sysvinit was at least a thousand times easier than bsd init scripts, and I occasionally see people that are opposed to both systemd and sysvinit and think rc.local was 'it'.

shakes head slowly

BSD rc scripts haven't worked in the way that you think that they have, for decades.

Mewburn rc, which reduced many rc scripts to a couple of shell function calls and a handful of variable declarations, has been used by NetBSD since 2001, and FreeBSD started using it about a year later. OpenBSD, furthermore, reinvented Mewburn rc around 8 years ago. Project Trident (formerly TrueOS formerly PC-BSD) has also since then switched from Mewburn rc to OpenRC.

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

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

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

/etc/rc.local was first declared obsolete in the BSD world and replaced by a system of drop-in files in a directory back in 1995.

* http://jdebp.info./FGA/rc.local-is-history.html

> /etc/rc.local was first declared obsolete in the BSD world and replaced by a system of drop-in files in a directory back in 1995.

OpenBSD still documents it as an implicitly-recommended way to start programs (though if it's possible to start it via e.g. rc.(local.)conf, then that's obviously preferable).

> sysvinit was at least a thousand times easier than bsd init scripts

¿Qué?

I guess we'll have to beg to differ here, but I prefer OpenBSD's (for example) init system over sysvinit or systemd any day. rc.subr is a godsend for eradicating all the boilerplate that "justified" switching to systemd. Enabling/disabling a daemon is as easy as adding a line to /etc/rc.conf.local (or just running "rcctl enable mydaemond", which does that for me). No fiddling with symlinking scripts to runlevel-specific folders (or, in fact, dealing with runlevels at all; if I need single-user mode, that's what bsd.rd is for).

One of these days I'd love to start ripping out the initscripts on my Slackware machines and replace them with something closer to OpenBSD (or hell, I wonder if I can just port OpenBSD's init to Linux?).

I don't hate it, but it has wasted more of my time as a sysadmin than anything else over the last few years.