News for hackers. Stuff that matters.
Re:Systemd 254 released, deprecating sysvinit scripts by javajosh on Friday July 28, 2023 @11:23AM (#36908203)
Can we all just take a moment to laugh at the fact that all of this complexity is, roughly speaking, the evolution of AUTOEXEC.BAT?

(Pedants: I know AUTOEXEC.BAT not a direct ancestor of systemd, but it's a close cousin and serves the same purpose: run stuff when you boot.)

Re:Systemd 254 released, deprecating sysvinit scripts by johnday on Friday July 28, 2023 @11:25AM (#36908253)
That's not really fair. systemd does a lot more, and with good reason (among other reasons: there are many, many economies that can be made when "booting" and "managing" services happens in the same hat)
Re:Systemd 254 released, deprecating sysvinit scripts by javajosh on Friday July 28, 2023 @01:00PM (#36909853)
>That's not really fair

Uh, what? It's not fair to say that a vastly more complicated thing evolved from a simple thing? That's how it always happens - each step seems reasonable, and justified, but you look at what those countless rational decisions added up to, and bam. That's the complexity everyone says they hate. In technology, in government, in basically everything.

(Oddly, culture seems to be okay deprecating old bits of culture; the brain is inherently finite so we run in cycles and epicycles of cultural fashion that remains roughly at the same level of complexity.)

Re:Systemd 254 released, deprecating sysvinit scripts by bananapub on Friday July 28, 2023 @04:14PM (#36912660)
what a weird take - the "complexity" of sysv has to include the random shell scripts people write for /etc/init.d of hugely variable quality, and the tooling like start-stop-daemon, and the administrative complexity of not actually being able to reliably shut down (needs a process group) or start up service (needs dependencies).

it is much simpler for some people to write a dependency-based init system and then for my OS to write dependencies for the OS services then for me to say "DependsOn = network.service" to permanently avoid racing dhcp or whatever.

Re:Systemd 254 released, deprecating sysvinit scripts by taf2 on Friday July 28, 2023 @11:23AM (#36908221)
I want my cake and it to boot fast too.
Re:Systemd 254 released, deprecating sysvinit scripts by TacticalCoder on Friday July 28, 2023 @11:42AM (#36908553)
I saw that very often but I run a very lean Devuan (a Debian fork without systemd) and it boots ultra-fast too.

Machines and especially SSDs have gone a long way since ten years ago and people think Linux boots fast "thanks to systemd"... But I'd encourage these people to install Devuan just to give it a try. It may boot a tiny bit slower than Debian (for an identical system) but it's still very quick.

Put it in another way: the savings systemd did brought regarding booting times in 2015 aren't looking anywhere near as impressive today. I don't even know: on my 7700X I think from boot (since the moment I enter the disk decryption password) to (text mode) login prompt it take about a second under Debian (systemd)? Maybe it takes 1.5 seconds running Devuan (non-systemd)?

I mean: 20 seconds instead of 45 seconds may have seen like a bit saving in 2015 but 1 second vs 1.5 second, I don't give a rat's arse.

And people who really need super fast boot times in containers shall use Alpine without systemd anyway.

Re:Systemd 254 released, deprecating sysvinit scripts by op00to on Friday July 28, 2023 @12:33PM (#36909428)
COMMAND.COM is a far more closer “relative” to SystemD than AUTOEXEC.BAT.
Re:Systemd 254 released, deprecating sysvinit scripts by MikusR on Friday July 28, 2023 @01:06PM (#36909937)
AUTOEXEC.BAT is same thing as a sysvinit script.
Re:Systemd 254 released, deprecating sysvinit scripts by bravetraveler on Friday July 28, 2023 @01:32PM (#36910312)
Turns out launching something isn't enough, these days - interdependence, and all.

Took some decades to collectively get tired enough to decide on a language to declare it