The "Devuan" Debian fork

libsystemd doesn't require pid 1 to be systemd however. Is this really worth a fork?

It is worth noting that package that depend on libsystemd but not on systemd as pid 1 will probably not use the library at run time. It's there only to allow the binary to be loaded and the program to look for systemd and do something if, and only if, systemd is pid 1. I don't believe this is worth a fork.

So please, if you don't like systemd, help us (Debian) to make a better OS by providing us test and code to let system that don't run systemd run well, but don't split the community.

I always wondered why the "tight coupling with init" issue has not simply been solved by providing two systemd "start"packages: a systemd-init package that makes systemd the init and a system-notinit package that installs a start script for other inits.

The systemd package would depend on these as alternatives. People with any other init would install the second package, thus keep their init as-is but still solve all dependencies higher up.

But of course, if as you say the goal is to not run systemd at all, then this would not help.
However, why then phrase the discussion in terms of init when this is not actually the contended issue?

Thank you for posting this comment. It describes the case exactly. I'd like to add a piece to the puzzle so far.

For some the reason for separating from Debian is that the previous iteration of Lennartware, i.e. Pulseaudio's injection between ALSA and userspace, was an unmitigated disaster that (in gentle terms) brought no increase in performance or functionality to systems that were well-configured with ALSA. Instead it changed e.g. the meaning of the mixer volume level as applied by most applications, breaking UI behind the application's back.

I waited out the pulseaudio storm to no decrease in functionality. The way I achieved this is with about five stanzas in an apt-prefs file that's still necessary to keep pulseaudio the hell out. This is because even years after Pöttering discontinued his involvement, PA continues to hang on to the model of being the only network-capable sound service in town. (In the case of PA's design it makes the other servers its clients, which brings out various implementation discrepancies in the way PA reimplemented the ALSA APIs.)

Then along came that same guy's "init system, device manager, login manager, cron, DNS resolver, console terminal emulator, package manager, kitchen sink, slopbucket, API breaker" project's adoption as dependency in the Debian Gnome packages. Since then it's been worming its way in piece by piece through dependencies in other programs; most recently bsdutils pulls in libsystemd0 which combines the freshly de-modularized group of libsystemd-{journal,daemon,login,...} program-level APIs. (who knows, maybe it looks smaller that way.)

Opinions of course vary and the technical minutes are too involved to quote here, but in my view there is no problem that systemd solves that isn't one of those introduced by the systemd design itself. Out of the possible reasons to have such an architecture in GNU/Linux, systemd doesn't meet utility, necessity, or even practical desirability.

The inclusion of systemd's libraries (and PAM modules, and root-privileged daemons, and...) isn't the problem by itself, of course: a library that implements its APIs in terms of local services that don't exist can't cause much trouble (unless root). Rather these libraries are an indication, a first warning of some program being about to become feature-dependent on an API from an architecture controlled by people who're on public record wrt their intent to e.g. break interfaces and make lock-step upgrades the norm. Having something like systemd-shim replacing Pöttering's systemd doesn't help here: for a well-defined architecture it matters relatively little who completed the implementation (or even how).

There are many people who'd like to sit out systemd as could be done with Pulseaudio. Personally I'd prefer to accomplish this by some means that isn't eternal vigilance towards my preferred distribution's packagers and politicians. Such things weren't needed in the time when Debian was a distribution of GNU/Linux first and one of Gnome only a distant second alongside every other userspace program.

Pinning against the entirety of systemd and packages that depend on it would result in many programs staying behind from a time between Wheezy and Jessie while others moved ahead. This tends to expose unstated dependencies between userspace programs which hadn't been reported by the legion of people upgrading regularly from `testing'. The mutually exclusive options for systemd doubters are therefore 0) adopt systemd and damn the icebergs, 1) pin against systemd and become a dinosaur, and 2) pool efforts, fork Debian, and move on.

Hence Devuan. (which, for the record, I'm not actively involved in.)

If things don't work out for it, there'll be others. Haters won't slow this puppy down.