
Announcing s6-rc: an s6-based service manager for Unix systems - vezzy-fnord
https://www.mail-archive.com/supervision@list.skarnet.org/msg01005.html
======
bnarf
Mmh, binary configuration blobs. No, thanks.

~~~
JdeBP
_Text_ configuration in individual small files, described at length in the
doco, merely _compiled into a database_ for runtime use; just like /etc/pwd.db
and /etc/spwd.db (compiled with pwd_mkdb from /etc/master.passwd)
/usr/share/misc/termcap.db (compiled with cap_mkdb from
/usr/share/misc/termcap) /usr/share/terminfo/?/* (compiled with tic) data.cdb
(compiled with tinydns-data from data) nsd.db (compiled with zonec)
/etc/postfix/virtual.db (compiled from /etc/postfix/virtual with postmap) and
so on and so forth.

~~~
bnarf
passwd is accessed by multiple programs and fast lookups are a reason to
implement binary formats. Same for termcap, timezones, etc (though I wouldn't
call those configuration files...). Postfix might also need fast lookups and
doesn't keep in-memory state.

For a service manager however these reasons do not apply. Having it use a
binary configuration database makes no sense as there is only a single program
accessing the configuration that doesn't need fast access to these. And no, I
don't think claiming that it's just "compiled for runtime use" makes this much
better[1]: it doesn't help with having the proprietary binary format and its
source go out of sync, requires special tools to debug (rescue systems might
not have s6-rc's compiler installed[2]) and so on.

    
    
      [1] That's like saying the Windows registry is just "compiled for runtime use" from *.reg files ;)
      [2] Yes, one might be able to use the compiler via a chroot, but why should I have to spend more effort?

~~~
skarnet
As Jonathan said: the reason for the compilation phase is efficiency. The
information in the compiled database is organized for fast loading and
immediate access to the complete dependency tree.

And yes, efficiency is important. The point of s6-rc is to provide a
dependency-based system manager with _minimal overhead_. Time a s6-rc run
against an equivalent openrc run, and you will see a notable difference.
strace both runs and you will understand why: OpenRC performs all its
dependency analysis at run time, _every time_ you run a script, and it has to
read the whole database of scripts to do so. s6-rc performs the "read a
zillion scripts, do the dependency analysis" part only once, and offline.

There are also other benefits: for instance, simple checking - when you write
an invalid set of services, the error is detected at compile-time, not at run-
time when it could prevent your machine from properly booting.

The database format is not proprietary. It's undocumented, which is not the
same thing; and if people insist, I may document it. In the meantime, the code
that reads it is in src/libs6rc/s6rc_db_read.c, a function that you can use in
your own code, or that you can analyze to understand the format. It's not a
complex one.

Going out of sync is not specific to s6-rc. It's a risk as soon as you compile
something. It may happen with OpenRC too, if you forget to rc-update. It may
happen with your binaries, if you forget to make install. "Things may go out
of sync" is not an argument against compiled designs, it's an argument in
favour of paying a little attention.

