I can ask and try to answer my own questions, hopefully others have just as dumb questions to ask as I have, and are not asking. We can number them all so we can build a FAQ at the end.


1 Why do I need trees, and can't have just one with services?

a1 Because not all services can race each other parallely, some services have to complete successfully for next services to start, so at least boot and another tree must be separated.
The main reason is security. We want a machine which boots whatever the runtime service added. We don't care about e.g dbus for booting a machine, and the machine should be operational even if dbus crashes. So, if the boot sequence is completely separated from the rest of the services, we have less chances to complete, by runtime services.


2 Why do I need user services, therefore a user tree? How are other systems handling it?

a2 I think we are talking about pulseaudio and dbus, and how systemd has provided this functionality so desktop/app. devs will adopt in the attempt to make systemd plug/play and invalidate all other systems. We have user dbus, root dbus, and user running something with root rights bus. and someone has to connect all those wires to make unnecessarily complex things to work, like the right to enable/disable audio channels, or mounting disks that are meant for rw of the user. Layers and layers of crap that have denied discussion under the vail "secure". Meanwhile autologin to DE is secure, changing the volume of audio isn't.
So 66 has provided a way to maintain this "fashion" of functionality without systemd. How is sysv,runit,openrc,...etc handling user level services? I can't see how, unless they adopt parts of systemd itself as they have with elogind.
This is also a security reason. Why should a service be launched with root privileges when a regular user can start it? This protects our system.


3 Why does a service file need to be so complicated, or to write a service, and can't just be a one line command line?

a3 The template is complex because 66 provides so many things to configure, this doesn't mean the service run-script has to be that complex if you are not utilizing the complexity available. A service should have at least 2 commands, how it starts, and how it stops "properly", so it doesn't leave trash behind. It can also start and fail, how long will be it be restarted, how frequently, where does it send its output of warnings and errors, ... what needs to run before it is started, ... the list gets longer the more you think about it. The real question is why other systems' service files are so simple and small.
https://web.obarun.org/software/66/v0.6.1.1/frontend.html# Prototype
q3 The question now is what is in this frontend that is absolutely necessary and what is optional?
aq3 (via 66 mailing list from mobinmob:)
I think the minimum template has:
--------------------------------------------

[main]
@ type =
@ description =
@ version =
@ user =


[start]
@ execute =
------------------------------------------- 
4 It appears as things start at /usr/lib/66 create things in /etc/66 go back to /var/lib/66 and the db is used on /run/66 while the machine is running. Each one of those locations has a separate logic on how it populated and how this culture grows in each location. As a user it looks like spaghetti alfredo ..

a4-1 Not the right person to answer this
a4-2 At the command line things are clear, 66-{enable, tree, disable, start, all, intree, inservice} what happens in those directories is really of little concern to the sys-admin, and less to the user. With the exception of making copies of service files from /usr/lib/66/service and into /etc/66/service, editing or creating new ones. But the general logic of why this maze exists should be explained somewhere, maybe the wiki. Possibly with a small introductory summary of how s6 works in comparison to its old cousin, redit. The one crunches scripts and text files for each service the other works on a compiled database of service structures.
4
-> /usr/lib/66 is a place for distro-maintainer and packager. The things installed on that location never change except at upgrade time.
-> /etc/66 is a place for sys-admin, so the sys-admin can overwrite default configurations from distro-maintainer to suit her/his needs.
--> ~/.66 similarly to sys-admin's /etc/66, is reserved for the user to modify user run services.
-> /var/lib/66 is a place for 66. sysadmin or distro-maintainers have nothing to do with this location. This location allows 66 to handle the state of the machine and contains stuff like which services are enabled or not, inner configuration of the services, to know where to install the service, how to create the live directory and what to put inside, and so on. The only one making changes on this place is 66 itself.
-> /run/66 is the live directory and contains what is necessary to handle the live state of the machine. This directory is erased and re-created at each boot. The only one making changes on this location is 66 itself. A distro-maintainer, sysadmin, and user, have nothing to do with this location.
ALL of these locations/paths are configurable at build time and it is up to the sys-admin/distro-manager to redefine their locations.

5 Can there be a gui that lets the sys-admin/user enable/disable trees/services/dependencies/ both for root and user?

a5 I think that would help many users who are not comfortable in doing things with a terminal. Checking boxed of services and drop-down menus of trees, creating deleting trees, defining before after stuff,,.. can all be done in a one page gui, I think. I am trying to learn some of the available tools that can do this, but I may still be far, and there are too many tools for gui creation.

6 Why can't a tree not enabled have a definition of -S (start after) as a dependency? This way when you decide to initialize the tree will only start if a depending tree is active or will have to be initialized as well.

My imagination doesn't go this far to see why this would be problematic but why also this may be needed.


7 On other systems when you install OpenRC, Runit, Sysvinit, systemd, an initial default setup is also in place by the pkg management, so at this stage the user can reboot and a system is functional to work on. With 66 a few more steps of creating and enabling trees and services are necessary. Why can't boot@ system at least be placed with a default configuration in place and a root tree with dhcpcd by a package that sets them up? Like obarun-boot, or 1st-boot (base) that creates boot (boot@ system), and root (dhcpcd), something like root-66serv used to be.

I think it is possible, it may relieve some of the initial stress, and although it is handled by the installer at the moment (5 different themes of trees and services) if one does a manual/chroot installation must also do the 66 setup manually before reboot. IF no trees exist in the system, the defaults would be created by this pkg. If this package is upgraded and trees already exist it does nothing.


8 What is the least input required for Obarun to boot, as far as 66 is concerned?

Basically the least amount of Obarun you can have, a 1GB system installed, is "base", a kernel, a boot-loader.
Assuming all the packages in "base" group are installed (boot@ -66serv dhcpcd-66serv included) a boot tree is needed to enable the boot module on that tree (boot@ -66serv). Without configuration you get ttys (tty1 and tty2) plus the fallback emergency tty12, you get a hostname "obaruns6", tz=GMT, etc. But you can log into the system.
# 66-tree -n boot
# 66-enable -t boot boot@ system
"If" you need networking through ethernet you can create a 2nd tree and enable dhcpcd, also included in "base" group.
# 66-tree -ncE net
# 66-enable -t net dhcpcd
At this point you can reach the repositories through pacman and get anything else you need to build a system. What the Obarun installer calls minimal is much more than this. But you can get from "base" to "minimal" with little effort and a little more knowledge.

9 How do we configure mounted tmpfs, particularly the size of /tmp

??? It is done in boot@ module by a oneshot service called mount-tmp and its default behavior is to make its size = 1/2
RAM How do we get more or less and up to what amount is it safe?

1/2 is just the default amount for a tmpfs. The size of a tmpfs can be configured on mount, using the size parameter:
https://www.kernel.org/doc/html/latest/ … tmpfs.html
For the mount-tmp service that means the addition of the switch in the cmd_args.
The default should be safe for almost everyone smile
Just providing my two cents on some question.

1 -> the main reason is a security reason. We want a machine which boot whatever the runtime service added. We don't care about e.g dbus for booting a machine and the machine should be operational even if dbus crash. So, if the boot sequence is completely separated from the rest of the service, we have less chance to stuck the boot process by a runtime services.

2 -> this is again a security reason. Why should i launch a service with root privileges when a regular user can start it? This is protect our system.

4
-> /usr/lib/66 is the place for distro-maintainer and packager. The things installed on that location never change except at upgrade time.
-> /etc/66 is the place for sys-admin, so overwritting stuff from distro-maintainer to suit our needs.
-> /var/lib/66 is the place for 66. sysadmin or distro-maintainers have nothing to do on that location. This location allow 66 to handle the state of the machine and contain stuff like which service are enabled or not, inner configuration of the service to know where to install the service, how to create the live directory and to put inside, and so on. The only one making changes on that place is 66 itself.
-> /un/66 is the live directory and contain the necessary to handle the live state of the machine. This directory is erased and created again at each boot. The only one making changes on that location is 66 itself. A distro-maintainer, sysadmin and user having nothing to do on that location.
I added your answers, and on 4 I took the liberty to add ~/.66 to the set.
eric wrote
4
-> /usr/lib/66 is the place for distro-maintainer and packager. The things installed on that location never change except at upgrade time.
-> /etc/66 is the place for sys-admin, so overwritting stuff from distro-maintainer to suit our needs.
-> /var/lib/66 is the place for 66. sysadmin or distro-maintainers have nothing to do on that location. This location allow 66 to handle the state of the machine and contain stuff like which service are enabled or not, inner configuration of the service to know where to install the service, how to create the live directory and to put inside, and so on. The only one making changes on that place is 66 itself.
-> /un/66 is the live directory and contain the necessary to handle the live state of the machine. This directory is erased and created again at each boot. The only one making changes on that location is 66 itself. A distro-maintainer, sysadmin and user having nothing to do on that location.

Just adding that ALL of these locations/paths are configurable :)
10 days later
fungal_net wrote9 How do we configure mounted tmpfs, particularly the size of /tmp

??? It is done in boot@ module by a oneshot service called mount-tmp and its default behavior is to make its size = 1/2 RAM
How do we get more or less and up to what amount is it safe?
1/2 is just the default amount for a tmpfs. The size of a tmpfs can be configured on mount, using the size parameter:
https://www.kernel.org/doc/html/latest/filesystems/tmpfs.html
For the mount-tmp service that means the addition of the switch in the cmd_args.
The default should be safe for almost everyone :)
10 Can one use the basic skarner/s6 and oblibs/66 software and service/module scripts installed in Arch?

10a Of course it is possible to get a base system booting and loging-in with just the bare minimum of s6/66 and then use arch, which means commenting out the Obarun repositories in pacman.conf and just leaving the arch repositories already present in Obarun. In practice you will run into problems right away because many essential software require systemd/-libs. This is exactly what 95% of software in Obarun repositories are, replacements of Arch's software without dependencies to systemd and its libs. So it is worth a try as a learning experience but expect trouble for anything beyond a very basic bare system. Still Arch is much cleaner in this respect than other major distributions, like debian, fedora, etc. A close look at especially obcore will list you exactly the software you will have problems with (pacman -Sl obcore -- ignore what is grouped under s6-suite), not that obextra/obcommunity is less essential.
5 months later
11 What changes to trees and services can happen without a reboot?

Very few changes on boot tree can have any effect on a session, once boot is complete the boot tree changes will only affect the next reboot. The only services that are continuously running and supervised are tty12 (and if other ttys are enabled) and udev. The rest are oneshots and bundles of oneshots.
The rest of the trees can be destroyed and recreated or replaced by other trees, as long as you haven't stopped tty access. Even when in the module you specify 0 tty, you have tty12. From tty12 you can remove all system and user trees, create new ones, populate them, modify them, and start them.

Powered by Obarun