@ iio7
First at all, thanks for your constructive remarks :).
So, actually each 66 tools is used. No useless tools are provided. Even if some of them are not directly called by user (because they don't need to worry about), they are used by 66 internally. For example the call of 66-start at some point call the 66-svctl or 66-dbctl tool. Another concrete example can be the 66-boot tool which call at some point the 66-scandir and 66-init tool. Each tools are inter-dependent but each tool accomplish one task.
If i want to provide extra functionnalities (meaning you don't need such functionalities to properly handle your system), i implement it on the 66-tools package. The last example was 66-ns. 66 do not depend of 66-tools and you're not forced to install it on your system.
Actually, i think 66 only provide the base tools to facilitate the manipulation of the s6/s6-rc service.
Now to be objective the e.g instantiated feature is not "mandatory" on a system. You can live without it. But if i think from a distro maintainer point of view, this feature avoid the repetition of a service declaration. I try to only provide useful tool and only useful tool.
Now, about the 66-backup. Actually, the 66-tree -C options provide a part of this tool. The main purpose of the 66-backup should provided an easy way to deploy the same service configuration on many machines (park of server) in one pass. The 66-backup make an archive of a tree which all the need inside(frontend file declaration,configuration file and so on), then you send it on a server with the method of your choice and restore the archive.
But to be honest, i don't know yet if i will provide this tool and even if i provide it i don't know if i will provide it on 66 or 66-tools.
Is it to provide an alternative init system to systemd with the same functionality?
I guarantee you that not the case. Systemd is actually an OS, not a simply an init system. 66 is a "service manager" that's all. Now, you should consider the actual Linux eco-system. More and more dev become lazy and expect that the functionalities are handled by the service manager instead of properly develop their own program. A simple example is the notification. Many many services now use the libsystemd to provide the notification while it's simply 3 line of code is C. So, if you want to be able to use that program you need to have the ability to handle such functionalities. Don't make me wrong, it's certainly not a reason to incoporate stupid features but some of then are essential mostly on desktop machine (like the fact to track user which is a horrible thing).
Is it to provide an alternative init system to systemd with the same functionality
I have no interest of that. As being said, not all part of systemd need to go on trash, they have good idea sometime but the manner as they implement it is generally badly designed. Being against Systemd just because it's Systemd is not my manner to see the thing.
Please do not confuse the goal of Obarun and the goal of 66. The goal of 66 is to provide facilities to implement an s6/s6-rc eco-system on your machine. The goal of Obarun is to provide the necessary packages and tools to run a system without systemd. The two are independent from each other. 66 is portable (many POC was made on different distro) and not build especially for Obarun where Obarun can use s6/66 or runit(Obarun first used runit).
As being said, expect to see the complexity to s6-rc growing a little bit. Laurent Bercot will give the possiblities to handle service events which is unavoidable (thinking about e.g. network).