(Obligatory, this is honestly not trolling, but...)

> For me, this, plus pre-systemd levels of stability and debuggability is a winning combination.

As a developer who uses a Mac every day, and has experience with Linux only at a distance, administrating servers a little, using Ansible, debugging the odd production failure...

I actually find it easier to debug a system using systemd. I'm not sure why this is. Some ideas I have are:

- It could be that I never learnt the old way?

- I find the config files easier to grok than the scripts, and I don't think I've ever had an issue with systemd itself, so never needed to go further down that path than the config files.

- I find it a bit more consistent between different parts of the system.

> I don't think I've ever had an issue with systemd itself

You've been very lucky :-).

My favourite gem, which I haven't been able to figure out by the time I'd finally decided I've had enough and ditched the damn thing, was not being able to reboot my computer if I had some filesystems mounted over the network. It irked me considerably, because I was running a rolling-release distro at the time and I rebooted fairly often.

(Edit: to be clear -- I'm sure there are tons of valid use cases that systemd serves much better than any other init system. I know a lot of very knowledgeable people who use it. My computers just don't seem to have those use cases :-) )

> The rough edges I’ve hit can all be attributed to systemd brain damage (like the fact that the linux kernel no longer has a working, synchronous, “probe the network cards and create a logical interface for each one” primitive).

Multithreaded device probing exists far before systemd. It was introduced around Linux 2.6.18.

It's your basic grand conspiracy theory setup. You see a bunch of sensible features that don't add up to any particular larger plan, they see a sprawling plot by innumerable enemies to destroy a status quo that never actually existed outside their imagination.

It is amusing to me that they call themselves "Veteran Unix Administrators" because an operating system needs _software engineers_ or at the very least _hackers_ and the last people you want doing this would be sysadmins I think all the very worst software I have to interact with was built by sysadmins who had the idea that programming wasn't that hard so they'd do a bit in their spare time...

The main driver behind the initial fork isn't even a sysadmin, but an art student who initiated Devuan as part of an art project and his PhD thesis: https://pearl.plymouth.ac.uk/handle/10026.1/11101

As a fun fact the thesis is released under a Creative Commons license, but states "no quotation from the thesis and no information derived from it may be published without the author's prior consent". Forbidding quotations and building further work on it is also an interesting approach to the idea of science.

That's boilerplate that Plymouth imposes, and not Denis Roio's choice. You'll find that this is fairly common, although the boilerplate varies from university to university. Here are some example rules from Durham, Brunel, Oxford, and Ulster, all with similar requirements to add such boilerplate.

* https://www.dur.ac.uk/graduate.school/current-students/submi...

* https://www.brunel.ac.uk/__data/assets/pdf_file/0014/213107/...

* https://www.ox.ac.uk/sites/files/oxford/field/field_document...

* http://www.ulster.ac.uk/academicservices/staff/PREPARATION%2...

Back in the old days, insmod and modprobe were synchronous. If you wanted concurrency during boot, you could use fork/join to get it (using the & line suffix and “join” command in bash, for instance).

In the brave new world, all kernel events are published over some wonky bus thing, so you need to write a daemon that listens for hardware events and replicates the kernel’s current state of the world in dram, and also is fault tolerant, and has a security subsystem that authenticates user requests before forwarding them to the kernel.

The new approach is fundamentally broken because it is too complicated to understand or implement correctly.

Also, it is gratuitously reimplmenting basic kernel functionality (security, process lifecycle) in user space, and in at least one case that has hit me personally (DriSetMaster) the systemd contingent has been blocking straightforward patches to the Linux kernel that make it possible for non systemd init systems to work without adding their own crappy shim processes.

I run Linux because I want a working unix environment. Systemd is turning it into something else.

I think it is telling that we’re seeing things like fuschia and renewed interest in the BSD’s specifically because Linux on the desktop / laptop is increasingly an unsupportable mess.

"Back in the old days, insmod and modprobe were synchronous"

No, back in the old days, CONFIG_MODULES was scary and new and the Veterans would have been demanding it be removed because "I want a working unix environment" and if they buy a new hardware device obviously they would install a C compiler and rebuild the operating system kernel to support the new device properly.

Now get off my lawn.

insmod and modprobe are still synchronous. Once you have loaded a network driver, you can be assured the corresponding devices have been created.

What's new (around 2006) is the kernel will probe buses in parallel and invoke modprobe in parallel to load the appropriate drivers if they match the driver's alias.

Introduction of userland components to populate /dev also largely predates systemd. devfs was introduced during 2.3.x. udev replaced it during 2.5.x.

Is there an alternative to elogind? From what I can tell most software needs it.

I think elogind is used because at least Gnome and KDE are dependent on logind.

Thanks. I don’t use either of those. (Also, does “gnome” include “mate” in this context, I wonder?)