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