Hi,
raid5atemyhomework <raid5atemyhomew...@protonmail.com> writes:
> GNU Shepherd is the `init` system used by GNU Guix. It features:
>
> * A rich full Scheme language to describe actions.
> * A simple core that is easy to maintain.
>
> However, in this critique, I contend that these features are bugs.
>
> The Shepherd language for describing actions on Shepherd daemons is a
> Turing-complete Guile language. Turing completeness runs afoul of the
> Principle of Least Power. In principle, all that actions have to do
> is invoke `exec`, `fork`, `kill`, and `waitpid` syscalls.
These 4 calls are already enough to run "sleep 100000000000" and wait
for it to finish, or to rebuild your Guix system with an extra patch
added to glibc.
> Yet the language is a full Turing-complete language, including the
> major weakness of Turing-completeness: the inability to solve the
> halting problem.
>
> The fact that the halting problem is unsolved in the language means it
> is possible to trivially write an infinite loop in the language. In
> the context of an `init` system, the possibility of an infinite loop
> is dangerous, as it means the system may never complete bootup.
Limiting ourselves to strictly total functions wouldn't help much here,
because for all practical purposes, computing 10^100 digits of Pi is
just as bad as an infinite loop.
That said, I certainly agree that Shepherd could use improvement, and
I'm glad that you've started this discussion.
At a glance, your idea of having Shepherd do more within subprocesses
looks promising to me, although this is not my area of expertise.
Thanks,
Mark
