iio7 wroteWell, that's a major turn-off, missing man pages is a bug.

It took Eric a few years to be convinced to have man pages, hence the software lowdown that is a build dependency for 66 and tools. The Skarnet guy doesn't believe it is necessary, man pages are a thing of the past. This is against tradition but it is a religious choice. Lowdown converts .md documentation to html, man, etc.

For anything s6 and execline you will have to look up the site "skarnet.org", or use something like a console browser lynx/elinks etc, and look up /usr/share/doc/s6
All the help is there with the package just not in man form.

%pacman -Ql s6 | grep doc
%pacman -Ql 66 | grep doc

Enjoy

For any questions subscribe to the skarnet lists :)

Obarun, meaning Eric, can only be responsible for his own, 66, not other sw. You are blaming Obarun for what Laurence Bercot does in Skarnet? Go to his list and explain your case.

But man 66-enable does work. And the reason 66 was made is so you don't directly have to deal with s6. Unless it is for sustems' research purpose, an Obarun/66 user/admin, doesn't have to know or learn a single thing about s6.

IOW it is not fair to condemn Obarun or 66 for what Skarnet does.

If you chose a console html browser like elinks and make an alias to man s6 for elinks /usr/share/doc/s6 I believe you have a better way to browse through help.

Also, I think, you can rebuilt your own s6/execline sw with a tool just like lowdown, used in 66, and translate the pages into man format. I am not sure about this, not even if the originals are written in .md or not. But let's say they are in html, and there is a tool that converts html to md or directly to man, it can be done each time skarnet produces an update.

1st there is a difference of saying using software without documentation and using software without a man page.
2nd you are saying that your problem is with lack of man pages, which 66 has, s6 doesn't, and then you say you would rather use vanilla s6. If you think s6 on Obarun is different that what published in skarnet please prove it.

You don't see s6-supervise .... really? You don't have a system then. It is 66 you don't see in processes s6 is all over the place: Here is mine, most simplistic of all systems run by people here:

% ps -A | grep s6
    1 ?        00:00:00 s6-svscan
  253 ?        00:00:00 s6-supervise
  254 ?        00:00:00 s6-supervise
  255 ?        00:00:00 s6-supervise
  257 ?        00:00:00 s6-log
  264 ?        00:00:00 s6-supervise
  265 ?        00:00:00 s6-supervise
  266 ?        00:00:00 s6-supervise
  267 ?        00:00:00 s6-supervise
  268 ?        00:00:00 s6-supervise
  269 ?        00:00:00 s6-supervise
  278 ?        00:00:00 s6-ipcserverd
  279 ?        00:00:00 s6-fdholderd
  297 ?        00:00:00 s6-log
  922 ?        00:00:00 s6-supervise
  923 ?        00:00:00 s6-supervise
  924 ?        00:00:00 s6-supervise
  925 ?        00:00:00 s6-supervise
  931 ?        00:00:00 s6-log
  934 ?        00:00:00 s6-log
 7674 ?        00:00:00 s6-supervise
 7675 ?        00:00:00 s6-supervise
 7679 ?        00:00:00 s6-log
 8291 ?        00:00:00 s6-supervise
 8292 ?        00:00:00 s6-supervise
 8296 ?        00:00:00 s6-log
25250 ?        00:00:00 s6-supervise
25251 ?        00:00:00 s6-supervise
25255 ?        00:00:00 s6-log
% s6-svstat
s6-svstat: usage: s6-svstat [ -uwNrpest | -o up,wantedup,normallyup,ready,paused,pid,exitcode,signal,signum,updownsince,readysince,updownfor,readyfor ] [ -n ] servicedir
 % elinks /usr/share/doc/s6/s6-svstat.html

The only 66 process running is a modified s6-shutdown called
66-shutdownd

It is part of boot module, and one of the first services enabled. It is the only thing that kills Pid1 other than electricity being cut-off.



I think that if it is possible, for Eric to do this, and transform html to man pages for skarnet packages, it is a rational request to make. I personally delete all man pages after installation/upgrade of all packages.

Maybe I should have paid more attention to the s6-supervise list talk but after some disappointment there, I have just been archiving the messages without reading, only if something sticks out on the subject.

Maybe the author of 66 can explain your questions much better than I can, but explain to me why hasn't such a promising project like Adelie offering "as real as it gets" s6 experience, taking off with users writing their own service scripts on s6 and getting rid off all the OpenRC crap. Instead they have adopted elogind so all their demanding guis and funky desktops can work effortlessly?

Why has void struggled with s6 for years now, and only a couple of packagers have brought 66 onboard to deal with handling it?

My deduction is, s6 is not as simple as you make it sound.

On s6-svstat my guess is that it probably needs better configuration at build time, and it may be reading output from /run/s6 instead of /run/66 to produce its own output. Or maybe use s6-svc to define the directory where s6-svstat looks for dhcpcd ... I don't know. If I really had to study s6 for my own use I would probably end up in runit at no time. The only reason I use s6 is because of 66.

A good reason not to use s6 without 66:

@ iio7
simply provide the absolute path of the service to check (and this is the good way to do with every s6-xxx program whatever the distro which use s6)

% sudo s6-svstat /run/66/scandir/0/boot-udevd
up (pid 376) 2438 seconds, ready 2437 seconds
obarun@ S6 ~ % sudo s6-svstat /run/66/scandir/0/dhclient 
up (pid 810) 2439 seconds

Not because I wanted to, but because the procedure required at Debian was too much work!

This is exactly the same reason for me to not handle s6/s6-rc man pages. Laurent Bercot do not provide it and i don't have the time to make it. If you cannot live without man page, do not use s6 at all :).
As being said, Laurent Bercot provide full documentation on html and i provide full documentation of 66 in html AND man pages.

You can do manually what 66 do. So, yeah no need of 66. As being said, now just try to create an instantiated service for s6-rc with the ability to remove/add as many time as you want (courage). And please try to provide what 66-stop -u <service> do that's mean unsupervise a daemon from an s6-rc DB without removing all the DB from the supervision tree. Maybe you also try to provide a way to change the configuration file of the daemon without touching the service directory declaration and restart your service.
Try to do it and i pretty sure that you will see the interest of 66 (or other s6 helper program). This simple examples ask for many many manipulation of files and directory in a precise order to do it where 66 make it in one command.
66 just make easier to implement and handle the s6/s6-rc ecosystem. On a server it's easy to implement s6/s6-rc because the things are static, on a desktop machine is not the same thing.
As being said, some people like 66 some other do not see the interest and it's good as it :).

As I see it the desktop support mechanisms is a side effect of the capabilities the couple s6/66 have. A functionality made necessary by desktop designer's autistic reliance to the systemd hydra. The enormous advantages I see is to large and complex set of servers. This is where the simplicity of runit runs out of options and folds due to design redundancy. Systemd fails due to operational overhead. That is that its own mechanisms under severe loads consume such large amount of resources they tend to crash due to its own loads.

To provide a non-computing example of what I mean I would draw from the example of health care. The same amount of healthcare provided in a US private hospital with private insurers would cost about 2.5 times the health care provided in the UK under NHS. A US hospital uses about 30% of its revenue for internal administrative accounting. Further out there are huge networks of independent providers of services, products, and insurance, that also add profit and operational costs. The German gov. provided insurance and private health services run closer to the US model than to UK's NHS, which unfortunately has to pay for US market machinery, tools, standards to justify health provision. The Cuban system is a fraction of the UK's cost and health indicators/statistics have surpassed those of the US since the 70s.

Systemd burns half of the fuel to run itself, runit and s6 run on fumes for their internal operation, they just guide the actual processes doing productive work. I would predict that large scale networks of servers running constantly at more than 50% load capacity cannot afford not to use s6. The fact you can utilize this potential to run logind, 5 dbus-es, so Gnome icons can be squashy and live, is a side-effect. It can do that too.

Running a wm without logind service, and no dbus, no user services, no pulseaudio, I see no benefit at all from s6; runit is plenty for me and this is what runit does best. But if I am to use s6 I would be a fool to use it as artix or adelie does. without 66.

This is why when I test some things for obarun, to see how they work, like I recently did with lxdm since others keep breaking with upgrades, to have boot-user and user services, I get goosebumps and swollen glands for the reasons someone has to do all this. The reason is the systemd impact. And it is not even init related, it is the dreaded elogind/dbus couple that has derailed desktops to this dysfunctionality. LXDE was fine without it. Now half of xfce needs dbus/logind. Pcmanfm crashes on slackware if dbus and logind is not functional, because they have mandated automounting into pcmanfm. It works on arch but it doesn't work on slackware ... and people wonder why did I write with disgust about slackware.

@ 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).