Re: RMS: users request you perhaps program HURD: they fear the path the linux kernel is going.

[Jean Louis]

* Alexandre François Garreau <address@hidden> [2019-11-15 10:51]:
> > In case of the service manager I would rather like to see technical
> > advantages over some others.
> 
> I disagree.  When Debian used SysVinit, I recall when running a server I 
> hacked *a hell lot* of shellscripts to install new stuff, modify how my 
> stuff was ran, disable services, etc.  It was pretty straightforward when 
> knowing commands (but I don’t recall to having found a central manual 
> (man, info, --help, whatever) so I didn’t know so much about its automatic 
> symlinking and such… unlike systemd and DMD/Shepherd!  Except I’d barely 
> like to read a manual from a linux tool that keep eating monolithically, 
> changing, and is only GPLv2 (systemd)), and when ignoring the standard 
> right-way of doing stuff, it was pretty straightforward to get anything 
> done by hacking some script in the place you wanted…

Hello Alexandre,

what I meant is that there are many various service managers, and
unless there is some technical advantage of one over the other, I
would not switch to any fancy one.

The fact is that services are written by various authors and have
various configurations, so service managers always make some scripts
to accomodate variabilities, for example "service start
name-of-service" would be for each service the same way to start it,
but underlying technical stuff does matter.

Please read here:
http://skarnet.org/software/s6-rc/why.html

Excerpts:

The problem of integrated init systems is that: 

* They have been developed by companies and associations, not individuals, and
 despite the licensing, they are for all intents and purposes closer to 
proprietary
 software than free software; they also suffer from many of the technical flaws 
of
 enterprise software design. 
* As a result, and despite being backed by tremendous manpower, they have been
 very poorly thought out. The manpower goes into the coding of features, not 
into
 architecture conception; and the architects were obviously not Unix experts, 
which
 is a shame when it's about creating a process 1 for Unix. This is apparent
 because: 
* They have been designed like application software, not system software, which
 requires a fairly different set of skills, and careful attention to details 
that are not
 as important in application software, such as minimal software dependencies and
 shortness of code paths. 

Pages and pages could be - and have been - written about the shortcomings of
integrated init systems, but one fact remains: they are not a satisfying 
solution to
the problem of service management under Unix. 

The best of both worlds 

s6-rc aims to be such a solution: it is small and modular, but offers full 
functionality.
Parallel service startup and shutdown with correct dependency management (none
of the systemd nonsense where services are started before their dependencies are
met), correct readiness notification support, reproducible script execution, and
short code paths. 

* s6-rc is a service manager, i.e. the equivalent of sysv-rc or OpenRC. It is 
not an
 init system. You can run s6-rc with any init system of your choosing. Of 
course,
 s6-rc requires a s6 supervision tree to be running on the system, since it
 delegates the management of longrun services to that supervision tree, but it
 does not require that s6 be the init system itself. s6-rc will work when 
s6-svscan
 runs as process 1 (on Linux, such a setup can be easily achieved via the help 
of the
 s6-linux-init package), and it will also work when s6-svscan runs under another
 init process. 
* The service manager runs on top of a supervision suite. It does not try to 
make it
 perform boot/shutdown operations or dependency management itself; and it
 does not substitute itself to it. s6-rc uses the functionality provided by s6, 
but it is
 still possible to run s6 without s6-rc for systems that do not need a service
 manager. It would also be theoretically possible to run s6-rc on top of another
 supervision suite, if said supervision suite provided the hooks that s6-rc 
needs. 
* A significantly time-consuming part of a service manager is the analysis of a 
set
 of services and computation of a dependency graph for that set. At the time of
 writing this document, s6-rc is the only service manager that performs that 
work
 offline, eliminating the dependency analysis overhead from boot time, shutdown
 time, or any other time where the machine state changes. 
* The source format for the s6-rc-compile tool is purposefully simple, in order 
to
 allow external tools to automatically write service definitions for s6-rc - for
 instance for conversions between service manager formats. 
* Like every skarnet.org tool, s6-rc is made of very little code, that does its 
job and
 nothing else. The binaries are small, it is very light in memory usage, and 
the code
 paths are extremely short. 

> > GNU project has one other program invocation and execution
> > supervisor, that is pies:
> 
> It seems to be made by Sergey Poznyakoff, the same who did DMD in
> the first place.  I’m pretty sure they don’t totally overlap.  Also
> I guess GNU pies is not an init (pid 1) software.

It can be, so it says in the manual.

I like the philosophy of daemontools, upon which s6 software have been
made.

See:
https://en.wikipedia.org/wiki/Daemontools

Jean