We no longer need it. We have pipewire and wireplumber. They do that job and some other jobs too. The combo replaces both pulseaudio and JACK, and also connects ALSA clients so they get their own volume controls as well.

Which countries consume the largest amounts of these drugs?

You see how that's not better though, right? Debian put all that stuff in their init scripts, if it was too complicated, they have themselves to blame. Since a unit script is just a pile of unique key value pairs separated by equals signs, you could have an init script which parsed them and you wouldn't need systemd but they chose to adopt systemd anyway. And not as an option which would have been ok, but as the only supported option, because yes you could and can change init systems but then tons of things don't work — even things which have explicitly provided non-systemd support upstream. That was an openly anti-user move.

It is not a problem if an init script is long. It is only a problem when it is hard to understand. Debian's lsb-inherited functions library for init scripts and the specific structure used is what makes them easy to write. Shell scripting is a fundamental Unix feature, people should understand it well enough to copy an init script and make a few changes. There is a skeleton script to start with so you don't have to actually even understand what you're doing, you only have to (slightly) understand shell scripting.

Also, init scripts work fine on Debian even without any of that. If you take an init script written in bourne shell from a classic SysV system and slap it onto Debian it will work with zero changes, but you may have to give additional arguments to update-rc.d if you don't add the runlevel and dependency info to the top of the script depending on what your service requires or is required by.

That's why it's wrong. The GPL is about the user. Debian is in very large part about the GPL. Debian should be about the user. If there's a bit less software in the core distribution because some of the would-be maintainers are confused by a core Unix feature, okey dokey. People who need an outdated version of it provided to them by their distribution can run a derivative. A ton of Debian software is woefully outdated and you have to go looking for a newer version if you want to run modern software anyway, so it's not like they are keeping up in general despite the handholding.

Okay.

What?

But both of those things are actually used. So are the IDs, they actually have meaning. And the runlevels are part of dependency. You pass through runlevels on your way to other runlevels.

Almost total. It's relevant to ttys :)

init being limited is good. We want it to be simple. It doesn't often have to do anything but you want it to respond right away when it does. Today we can afford to burn more memory so we can afford a more complicated init from that perspective, but having more complexity in the one of the two processes that absolutely must not have a problem which has always been very simple is very arguably not the best idea.

With all of that said, none of what you said addressed the question. What's so bad about init scripts? Allow me to pose my version here: Given that most users will never need to write an init script or unit file, for the same reasons, what is the problem with init scripts supposed to be? I can take an ancient init script and slap it into place on a modern system and it will likely still work, and if I want boot order dependency to work I will only need to slap some structured comments into the top of it.

My recollection of the Debian argument for systemd looks like this: "GNOME is going to it and some maintainers are confused by writing init scripts." But understanding Debian packaging (bop it! twist it! pull it!) is like ten times harder than that, so I just don't get this argument at all. I do comprehend the GNOME argument, I just don't find it compelling because GNOME was enshittifying at the time, so it wasn't worth enshittifying Debian with systemd.

It's not clear exactly what you mean here. Do you mean that he's jealous of competent developers? There could actually be jealousy of his influence despite his lack of skill. As a statement which someone would be willing to make openly in public, that would also make sense. Everything he touches turns to poo.

I think you got modded down for begging the question.

What I mean here is, do people outside of the Linux world actually even hear about any of that stuff, let alone get scared off by it? What little I see about Linux from the mainstream tech press is generally cautiously optimistic and points users towards specific low-friction distributions where they won't be making a lot of choices. KDE vs GNOME is completely irrelevant to your average user, who wouldn't use advanced features if they had them. They don't do anything complicated enough to benefit from them. In that regard GNOME is correct, it's too bad they just torpedoed all the advanced functionality the nerds were using. That's why KDE has a much better clue, if you don't care you can just leave settings along and it just works, but it also has much more configurability. They should really adopt a simple/advanced settings system though, the problem with actually having all the settings in one place is that there's a lot of them.

And there I go off into the weeds again, as the average person won't even ever open settings. They just want to launch a couple of things, and everything will autoconfigure for them.

People have been having technical arguments about platforms as long as there's been platforms to argue about. Linux's arguments are out in the open because of the nature of the thing, so if people are seeing how sausages are made that could be a putoff. I just don't think they are in fact seeing those things unless they are the kind of people who are interested in such things to begin with. You have to go out of your way to encounter these kinds of discussions, and most people aren't swimming in the nerd end of the pool.

At the time that was done with interface aliases. ifconfig eth0:1 blah blah blah

It's a second-class citizen. Those log messages are passed on to the real log daemon by systemd. If it fails to do that properly, which is often true in the early phases of the process, then log messages don't always make it.

The correct way to do what they did there would have been to add logging to an existing syslogd. It would have been a lot less work, too. Instead they felt they had to add their own incompatible solution instead. That's the biggest thing wrong with systemd in a nutshell.

Debian has a script or script library I believe originally from the lsb which does this easily from some boilerplate at the top of the init script. That's how update-rc.d works, but it's also used to make init scripts require that other scripts have started successfully.

startpar

daemontools, inetd...

Funny thing about standards.

There already were standard ways to do this in the shell, and therefore in init scripts. They are even already used.

That's always been a part of init scripts.

All of those things are available in a standard Devuan install right now. And they were available in a standard Debian install before they adopted systemd, too.

All of those things are reviled to various degrees.

sysvinit's only crimes were that it was slow and you had to write scripts. startpar solved the slow problem and scripts are an integral and fundamental feature of the OS, and avoiding them is missing the point. Init scripts are made with skeletons and boilerplate and just aren't that complicated anyway.

There have been Linux distributions which used the BSD init script system. It's just inferior to doing it the System V way, which is yet still basically the same thing as the BSD way — after all, it's only shell scripts being run in a predetermined order.

> the entertainment offered

If this was the "entertainment" what was the business whilst they were there?

It is the antithesis of the Unix way. This has been argued back and forth all along, and if you don't agree I won't try to convince you here.

The problem with systemd and unit scripts is that they cannot do all the things that a script can do, so you often wind up using a script anyway. In that case you have really not made things any simpler than the usual case. Meanwhile you've added a whole lot of complexity which is largely unnecessary, some of which is utterly dependent on other parts so it is difficult to impossible to switch out portions of it, and much of which doesn't work very well. systemd is arguably better at typical run time logging but is worse at early boot logging, which is what got me to drop it. I was having problems with root on zfs on Debian, which had been working, and I couldn't tell what had happened without a debugger. So I switched to Devuan.

In fact I just did a fresh install of Devuan excalibur (Debian trixie) with root on zfs from the trixie instructions on the openzfs site, where I had a dumb problem with grub which I solved in a hacky way by dropping a script into grub.d (the script which creates the root= part of the cmdline doesn't detect the pool the root volume is on correctly) and also had to do an init script in place of their .service file. It took me about 45 seconds to whack a related init script into what I needed and add it to the boot sequence.

When Debian switched to systemd, I adapted. I switched to Devuan.

I therefore trust that it will continue to be shit.

Not needing a pantograph but needing isolators between rail segments is just trading one problem for another. Pantographs aren't cheap, but they are simple in principle and highly reliable.