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.