Not only can you describe the desired system state and have your init figure out dependencies, you can list just the dependencies and have your init set up all possible system states until you find one to your liking!

exactly! the way I imagined it, service definitions would be purely declarative Prolog, mutable system state would be asserts on the Prolog in-memory factbase (and flexible definitions could be written to tie system state sources like sysfs descriptors to asserts), and service manager commands would just be a special case of the system state assert system. I’m still tempted to do this, but I feel like ordinary developers have a weird aversion to Prolog that’d doom the thing.

Emacs as pid 1 is a classic of the genre, but a prolog too? Wouldn’t a Kanren make more sense or is elisp not good for that?

this idea was usually separate from the Prolog init system, but it took a few forms — a cut-down emacs with a Lisp RPC connection to a session emacs (namely the one I use to manage my UI and as a window manager) (also, I made a lot of progress in using emacs as a weird but functional standalone app runtime) and elisp configuration, a declarative version of that implemented as an elisp miniKanren, and a few other weird iterations on the same theme.

Sounds like the real horseshoe theory is that nerds of all kinds of heterodox political stripes will eventually reinvent/discover Lisp and get freaky with it.

the common thread might boil down to an obsession with lambda calculus, I think

it’s not insulting at all! I’m not a Linux kernel dev by any means, but I have what I consider a fair amount of knowledge in the general area — OS design and a selection of algorithm implementations from the Linux kernel were part of what I studied for my degree, and I’ve previously written assembly boot and both C and Rust OS kernel code for x86, ARM, and MIPS. most of my real expertise is in the deeper parts of userland, but I might be able to give you a push in the right direction for anything internal to the kernel.