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:)
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
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 =
-------------------------------------------
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
