S6 appears as the init system that few distributions have chosen as their default init and service management/supervision (obarun and possibly Adélie once stable is released). There are quite a few commercial servers running on this system. For general personal use s6 seems complex, but complex is not always a bad thing. It would be unfair to compare it with older systems such as SysV-init. Sysvinit is the system that the overwhelming majority of enterprise system administrators had learned on and relied on for decades (yes it is more than one). Upstart seems extinct by now, and OpenRC is getting old as well, and didn’t necessarily deviate much from the path of sysvinit. But then there is Runit. Void and Artix appear the first two we think right away that use it. S6 is a step further into the future of unix-like systems.
Runit is great, it is fast, and it is simple. It boots fast, it reads its scripts fast, and starts and monitors services, daemons, and logs their lives. As a young sys-admin it is hard to resist choosing it for the confidence it inspires, due to its simplicity. It has a weakness that s6 doesn’t have, and in rare conditions runit can go down instantly allowing very little trace of the condition that caused it. But this gets too theoretical and scientific. (read articles 1,2 in reference section below) The practical difference is that runit is too simplistic. It is a classic system designed and controlled by the sys-admin that users have to work on. A set system by the boundaries set by someone else. A user, without root rights, can not start, stop, pause, utilize more or less services and daemons. S6 excels in this area.
Don’t underestimate this feature, of user controlled processes as a single system admin and user (most of us hobby admins) because there are times, and it seems it is becoming more in demand these days, that you may need to isolate parts of the system from one another. Containers, cgroups, virtual machines, are all similar efforts that address similar needs. Sometimes it is for security reasons, sometimes due to the complexity of modern systems a crash on one procedure should not affect the health of another, both running on the same machine. S6 can do this very well.
But what is it that 66 can do more than s6?
S6opts (Obarun’s previous service management tool set) was a set of scripts that let the admin, and users, start, supervise, log, and stop services and daemons. There were two problems, as far as I can understand, that the database of services, status, history, was too complex to handle and required too much terminal time to modify. The s6opts program itself had become bulky and as a set of scripts itself it was sometimes slow. It became slower as the system became more complex. So last year the main developer of Obarun devoted the majority of his developing time in creating a whole new suite of service managing tools. He wrote the entire thing in C, compiled it under the arch x64 glibc based system, and delivered. The service scripts for each program now have become very simple, it is trivial for even non-coders to learn to create their own, but Obarun has covered most common bases already. All 66 tools use -h for a quick help section that simplifies their use. This “marvel” has been released for beta testing for some months now and some of us tortured it to extremes to see if everything works as it should. It was refined a few times, not a single bug was really discovered by us users, it was just refined for simplicity of use and efficiency. The goal: To take the magic of the system and put it under the control of the user. – Achieved!
Using 66 as a novice in init and service management helps make sense of all other init systems and service management. What you end up asking is “why is everyone else making things so complicated to control?” or “why doesn’t the other system allow me the user to choose what I want running in the background and what not?”. In summary both root and user can bundle services into what has been called trees. For certain situations, specific work, specific setups, networking, hardware control, you need 2 or 3 or more services to be running. Other times you don’t need this combination but a different one to do something else. You set what you need into a “tree” of services, you initiate the tree, do your work, put the tree to sleep and free up resources for something else. There is a boot tree (classic file-checking and mounting filesystems) and then after this tree has run what is done during boot, the root tree is activated and brings the system to a terminal (tty or display manager running as service). You could have networking service run as root, dbus, consolekit, etc. or simplify it and have nothing other than a tty1. Then create other trees either as root or user depending on what you want to be doing. It is so simple and quick you will be amazed, no matter how much you love your current system. If you want to learn Linux, this may very well be the right place to start. If you want to manage a network of servers with hundreds of users depending on you, this may very well be the place to be.
Once you become proficient with 66 tools you can use those commands that enable and disable trees of services and create your own mini-scripts with those command. For example, if you want to scan, print, down/up-load bluetooth files, you can make a tree called imgprint. Then make a script enabling that tree, starting the software you will be using for such a job, once they are closed, the tree is disabled again, and your system is free to do something else. Do you really need cups-daemon running all day every day, for being able to print your electric bill once a month, taking resources while playing a game, or browsing? Do you have to worry about networking, ssh server, being active when you want to do something that is best done while you are offline?
S6 and 66 will quickly make a true system administrator out of any user. This has been the greatest failure of systemd. Not only has it not helped younger users (not in age but unix/linux experience) but has confused them even more to not even try and mess with such things. Systemd has such a complex structure and uses such odd names for things that are commonly understood with other terms, that people are afraid to modify the original distro setup or the system collapses. Everything is interdependent with such fragile relationships that the only thing you learn is not to mess with what systemd does. It is like ms-windows, once it is locked you better reinstall.
Do you really know what systemd does? It starts everything and makes everything available at all times. It does so in such a complex dynamic way that one little mistake of stopping one thing starts a domino effect of a system crash. And let’s say there is an upgrade of a buggy piece of software that came in and systemd is starting. The service crashes, locks, freezes, whatever. Systemd logs it, kills it, and restarts it, again and again, and again, creating huge useless logs of the same instance, and leaving you clueless on what may have caused this. The inexperienced desktop user may not even know something like this is going on. Not since that last upgrade. A suspicious user will inquire why so many resources are taken up when nothing the user wanted to run is running. A booted desktop idling with 700GB of Ram already being used. You open htop or any tasks management program, you see things jumping up and down, starting, stopping, restarting, so fast you can’t even tell which is doing what, no matter how you order them. A maze only understood by the people who developed systemd itself. They call that reliable and stable. It is a turd in drag!
You don’t want to take a chance and use this little known system as your work system. Why not download one of the isos, read the 66 documentation, and play around with the system in a virtual machine. The live images have 8GB of space to download software, create trees, enable them, modify them, kill them, read their logs, decide what you want logged and what not, and tell us what you think when you are done playing. Use the forum.obarun.org to read what the first users faced with 66, see what problems they had, and how solutions were explained. Personally I’ve never developed such a feeling of control over my machine that I have acquired with 66. I remember liking runit for a while, both Void’s and Artix’s variety, but now it seems as using pliers on precision machine allen bolts. I wouldn’t be surprised if this s6/66 brings a new revolution in open-source and free-software that 5-10 years from now we will be talking of all those other init systems as antiques.
Note: An important detail about 66, and I believe s6 as well, is that it is all written in C and that makes it portable to any unix-like system. This means that it runs just as well build against glibc as with musl. In fact the S6 developer’s server is running on musl, while arch is glibc only. Systemd will never be compiled with musl, it can’t as far as I know. If you think musl is the future and glibc is bound for deprecation this is an important detail to remember.
2 Davin McCall (author of Dinit) https://davmac.wordpress.com/2018/10/26/on-the-vagaries-of-init-systems/
4 66-tools documentation https://web.obarun.org/software
5 OBARUN_x86_64-2019-04-2.iso (minimal)
Obarun-JWM_x86_64-2019-04-2.iso (JWM desktop)
further interest and references suggested by mobinmob in a comment below: