Hey everybody,

yes this project is still alive and making progress - but real life is 
taking its time toll.

I want to spark another discussion to collect some arguments and 
perspectives:

As of now I have had the following structure:

- The package manager puts service source directories for both user and 
system services to /usr/lib/s6-rc/{user,system}/src/service.

- The package manager puts initial bundles to 
/etc/s6-rc/{user,system}/src/bundles;
    those can be changed by the sysadmin to decide whatever is startet when.

- Custom services can be created at /etc/s6-rc/{user,system}/src.

- The package manager puts initial per-service config files to 
/etc/s6-rc/{user,system}/config,
    those can the be changed by the sysadmin to configure system 
services and set global defaults for user services.

- The sysadmin or the user can copy a skeleton from 
/etc/s6-rc/skel/{config,src} (which is populated by the package manager 
with configs and initial bundles)
    to ${HOME}/.config/s6-rc/, this folder shall be used for 
configuration and custom user services.

That is the current state I have been running on my Desktop for ~2 Months.

After reading through Nosh (https://jdebp.uk/Softwares/nosh/), its ideas 
and its documentation,
as well as reading through some forums of both BSD and Linux, I have 
encountered an alternative idea,
which is, as far as I know, the old standard anyway:

- The package manager puts service source directories and an initial set 
of bundles
    for system services to /etc/s6-rc/system/src/{services,bundles}.

- The package manager puts service source directories and an initial set 
of bundles
    for both user and system services to /usr/share/s6-rc/{user,system} 
as a reference of the defaults.

- The sysadmin or the user can copy a skeleton from 
/etc/s6-rc/skel/{config,src} (which is populated by the package manager 
with configs and initial bundles)
    to ${HOME}/.config/s6-rc/, this folder shall be used for configuring 
existing and custom user services.

- The idea of config files is completely dropped and the "editing the 
config" part is shifted to "editing the run-script"

Following are my current thoughts about this:

Advantages:

- Simplicity: I have realized that parsing and importing the KEY=value 
pairs from the config files makes up about 80% of each service script.
                    Removing config reduces the amount of files and 
directories enormously and makes the scripts very small, hence easy to 
understand and customize.

- Flexibility: A sysadmin has way more options in changing the script 
than in changing the KEY=value pairs.

Apparent disadvantages:

- "Beginner friendliness" is way higher for simple KEY=value config files
    Counter argument: From my experience, people that would be able to 
edit configs but not scripts, do not edit service files anyways,
                                   whilst those who do are profiting 
from the finer control the script editing offers.

Disadvantages:

- User services that first source a config file at 
/etc/s6-rc/user/config and after that another one at 
${HOME}/.config/s6-rc/config
   can have global defaults set by the sysadmin from the former, this is 
not possible with a non-config approach.

- Config allow to group and expose the most relevant options in self 
explaining variable names requiring less insight by the sysadmin.
   Counter argument: The sysadmin is most likely pretty invested in the 
program the service file he is editing belongs to anyway,
                                   hence he wants to deviate from the 
default.


What do you think is better and why?

Do you suggest any alterations or even a completely different approach?


Regards,

Paul