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 filesCounter 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
OpenPGP_0x71C7C85A2EA30F62.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
