notabot

I'm not disputing that he doesn't think the issues are major, as I said, he's usually pretty ambivalent about what runs on the kernel, so they're not issues he cares about. On the flip side, I do care what is running because I have to manage and support it.

I do wonder if we're talking at cross purposes though. You seem to mostly be talking about the systemd init system, I'm mostly talking about all the other bits it, as a sort of umbrella project, tries to encompass. I don't much like the init system, I prefer to be able to explicitly set the ordering of the steps, rather than having them inferred, and I prefer shell script that I can test to unit files, but it mostly works ok. So does every other init system though, so it's not a selling point.

As I said, the big problem is around how they've tried to do everything, much of it less well than what they're replacing. Yes, you can build a system that uses systemd-init and none of the other components, but that still drags in a load of other dependencies, so you might as well use a different init that's smaller and cleaner.

We came close to the 'systemd apocalypse' recently, when distros hooked the systemd library into openssh without understanding just how bloated it is and how many poorly monitored dependencies it brought in. It was just luck that the right person spotted a slight change in timing and investigated.

Ultimately I suppose it comes down to the level you interact with your systems at. If you just want to install your OS, a few packages they directly support and let it get on with it, then you probably neither know nor care that you run systemd, and that's great. On the other hand, in my experience, when you try to push the system past that and do anything more customized you start running into the sharp edges and misfeatures on the various systemd components.

I obviously find the arguments against systemd more persuasive than you do, and that's fine, it's all open source and we can all make our own choices about it. My experience with it over the years has been, and still is that it vastly over complicates things that used to be simple, often the less commonly used parts just don't work right (the automounter is a particular bugbear of mine, and few distros seem to use the network management component). The arguments do matter in practical terms as they directly impact how it works.

Of the distros you mentioned, centos is a RHEL derivative and so wasn't independent, arch packages multiple init systems, but yes, I'd forgotten opensuse, and they seem to be firmly in the systemd camp.

I may be an internet rando, but I'm not actually angry, more just disappointed. I'd agree with Mr Torvald's opinion that some of the design details are insane, but I think they are more fundamental than just 'details' as many are to do with the fundamental concepts around what systemd is and how it works. Linus can be a real dragon around changes to the kernel, but he's always tended to be more relaxed about the layers above it.

That the developers of systemd are 'much too cavalier about bugs and compatibility' is surely clear to anyone who follows the relevant mailing lists and bug trackers, and should alarm everyone.

Let's agree to disagree on that point. Redhat switched because they invented it, and so took all the RHEL derivative distros with them. Debian switched to prefer it after a rather contentious vote and so took all the Debian derivative distros, including Ubuntu, with them. That just leaves a lot of the smaller distros, most of which seem to have stuck with sysvinit or similar as far as I can see.

Probably not much time, a lot of packages come with init scripts anyway, and they're pretty trivial to write if not.

You can certainly argue it's a philosophical choice, I'd say it's more down to recognising the many poor architectural choices in systemd, rubbing agaist its many pain points and misfeatures and being alarmed at the size of the attack surface it exposes. I understand there is an effort underway to reduce the size and complexity of the main shared library to help address the last point, but just the fact that is necessary shows the scope of the problem.

They seem to. Debian explicitly supports multiple init systems, sysvinit being the primary alternative, so packages have to handle systemd-init not being there.

Debian works fine without systemd too, there's a page on the wiki on how to install without it, or remove it after the fact.

Oof, that sucks. It seems like the universe really does enjoy a cruel prank sometimes. I hope you've found something equally enjoyable to fill the pizza shaped hole in your meals.

Thanks, that rather made my day.

If you have a stove I can definitely recommend heating your pizza in a dry (with no oil) frying pan. Set the temperature medium-low and heat a slice or two at a time for a few minutes. It comes out like it was freshly cooked.

If you don't need external calling you don't need a trunk, it's just for connecting to the outside world. I found [[https://www.asterisk.org/|Asterisk]] was a good place to start. The config is rather involved though, so there are various front ends for it.

You can, but I found it a bit laggy. It basically wraps your tcp stream over https, so I think the extra overhead was what was slowing it down.

That's the thing, if the other guy actually means to harm you and has a knife, and you're within range, you're going to get injured or killed. If they just mean to scare you you might get lucky. Telling the two apart in the instant you have isn't always feasible, but you can usually tell if someone's impaired enough that you can get away. Yes, I got lucky, but it was an 'educated' choice as I'd seen him, rather unstably, coming.

I was taught that if you're faced with a potential fight you try to talk your way out of it, failing that you run, and only if you can't do that do you fight. If you have to fight you do so to end the threat as quickly and safely (for yourself) as possible.