Thanks for all your hard works guys, users will should appreciate it
3 months later
There have been some minor improvements on the wiki in general and the completion of 66 v0.2.xx documentation is now in place http://wiki.obarun.org/doku.php?id=66.2

Let me know of any needed corrections, suggestions for improvement, proposed additions etc.
18 days later
I've read some part and made my first service (for my Alienware laptop LED with alieneffects).
I'm not sysadmin, just 3d graphist.
The wiki seem good. Thanks :)
13 days later
Now that 66 is taking a more refined form, expect little surprise soon, I have been working on trying to make an introductory s6/66 document to assist new users in implementing and managing services without being overwhelmed by the volume of the 66 documentation. I need feedback because for those accustomed to s6/s6opts/66 for some time things become obvious that are not so obvious to newcomers. Nearly nobody here has s6 experience before Obarun.

The way I see it, when someone coming from other systems, especially systemd, they may be administering a system for years and never really pay any attention to init and service management. They just install packages and they start and run daemons all the time. They may have worked on ubuntu, mint, manjaro, and never had to stop, disable, start a service. Obarun stimulates the curiosity on how this is done and passes control to the user to manage all this "mesh". Runit in a way, and maybe openrc, are similar but if you have 10 service/daemons it is like having a board of 10 switches, on/off. The possibilities with 66 are nearly endless. I sometimes wonder even if Eric uses all the tools he has created without forgetting he made some :)

So how should I try to make an introduction for a 10 year old into the field of particle physics?
I am glad the boot tree contents are bundled up and nobody has to deal with their details unless they are really interested to go that deep. When you run 66-info -T boot you see the details and maybe wonder how is all this done with other systems. We all see gibberish flooding the screen when linux boots up, but now it begins to make sense. It is also layered in a more understandable way. With systemd you may see it take a long time saying waiting 90sec for network interface to be configured, and all this is mixed up with udev and filechecks, all in one giant blob.

The strict developer's attitude is usually "the documentation is there, go read it ALL". Not here, that's not the Obarun way. We assume someone has not taken the time to read the documentation when they run into problems. Then there are those of "us" that do read it, and still don't understand some/much of it. You can't go from arithmetic to quantum geometry in one read. What makes a service a "one-shot"? I thought I knew, or imagined. If you have been discussing init systems with Laurent Bercot for 10 years then you know what a "scandir" is.

The more I work on this document the more lost I get, and as you may know I write long documents and sentences, many times I don't even go back and read them myself. HELP!!!
The best manner to get help here is:

"ASK TO THE DEV!!" :p

I completely forgot to update the wiki with the new version o_O
Probably not too much of a help but I tend to read everything I write one to two times before pressing any "publish" button and then again three to four times after publishing to go back and correct minor and/or major things. Not here on Forums, but in general, be it a small comment or a large article. I'd say go easy. That sounds like you're about to unleash a PhD in s6/66/obarun on us. ;)

If it was for user services (even if they were root services) that are needed for everyday tasks, I was surprised to learn how most of them are often actually very simple one liners in the end that I could simply throw at the command line myself. Also understanding what is available at what time of computing (boot > tty > X) and how some things relate to each other are quite interesting to know (although not very deeply maybe).
i will try to be serious a few seconds :p.

The concept of the tree seems to be the first thing to learn. I mean, when i learn something i need to practice but i will get troubles, it's obvious. So, i want to be safe and i don't want to destroy my system. Understanding the concept of the tree allow me to have my own and make what i want inside it without any risks for my system. tree boot,root do not touch. Create a new one instead and play with it.

So, i got a safe place to play with. Now i need to know how Obarun deal with service. For the last majority of distribution, service is automatically installed and available(maybe started) at package installation. That's not the case on Obarun. Well, how to know if a service is available and how to install it.

I have now my service installed on my system: how i start it. The knowledge of 66-enable and 66-start (and their opposite) is needed.

finally, How to check the status of the service and how to see the log: 66-info.

This is very basic and should be know by every user.So, a little synthesis:

66-tree -ncE < this 3 options are common and need to be know and understand correctly
66-enable -t <tree> <service> < the concept of the tree appear here, understanding the -c/C is not necessary at first approach because user should not touch the original frontend
66-start -t <tree> <service> < unavoidable command like 66-enable
66-info -T/-S -p <nline> < unavoidable command too

With the explanation of this 4 command, user should have the necessary to deal with service.

User usually do not care about what happens under the wood and do not care about init or service management, they just want an operational system."i press the power button of my machine and that's all".
The audience of Obarun is a little different. Generally, they comes here to get alternative and they ready to learn new things. Simple user do not need to understand deeply 66. Admin should know a little be more. So maybe separate the user and admin documentation might be a good idea.
If I showed you what I've done already you might say we have a match, more or less.
I was thinking of waiting a bit for the 66-info replacement to come out at the same time, since it is a key tool for most users, to see what you have done is actually taking effect, now and after reboot.

The user/admin differentiation on one side it seems like a good idea, on the other side it seems as anti-unix/linux, where every user needs to become admin too. Even windows had admin, many people didn't know, of what they could do with it. The way I understand it is the "user" mode is the one who doesn't know or needs to know what s6/66 do. They make an installation, boot and go to work or play. They may be stuck with sddm and plasma for an eternity and will not know how to change to lxdm, or how to enable remote access, or get accurate time on the system, but they have had they installed. So a non-admin user doesn't even need an introductory manual. Why read an introduction to dog breeding if you don't like dogs and never going to have one, or two? :)

Working on the 66wiki, especially after the addition of 66-tools, I look at it and say that I need to print this and have it hanging next to my screen because I will never memorize all those tools.

By the way:
1 You make a tree called boot (66-tree -n boot), then you make root -cnE root, and then a third called play (-cn play)??? When you use # 66-enable acpid, does it go to root or play? It errors out as no tree being current. If play didn't exist it would automatically go to root. Is this correct?
2
# 66-enable -t play acpid
# 66-start -t play acpid

or
# 66-enable -t play -S acpid

Is there a difference?
marianarlt wroteread everything I write one to two times before pressing any "publish" button and then again three to four times after
I think it is some form of learning disability I have, I couldn't even copy from myself since I was little. If I write a sentence in paper and try to copy it in the computer or a better piece of paper, I nearly always change it. When it is 2-3 sentences, by the time I get to third it no longer fits in, so I am writing the whole thing over again. Imagine doing this over several pages. The more I read it over the more changes the less it makes sense. So it is first hit or nothing. I started writing this intro a few days ago, I threw some commands in like Erik says, and build explanations around them. If I go and read it over I will change it so much it will be a new document, and probably quicker to write the whole thing from scratch till I finish. This is why sometimes I don't start stuff unless I know I can finish it.

It is a mental lock, isn't it? It is like writing for me is a "one-shot" service :)
I was thinking of waiting a bit for the 66-info replacement to come out at the same time, since it is a key tool for most users, to see what you have done is actually taking effect, now and after reboot.
i thought to tell you that. Actually, i'm just waiting the 20 October(end of the obnews announcement about the v0.2.1.2). The next release is ready yet and so it will come with the 66-intree and 66-inservice which are clearly better to use, more flexible and more understandable.
The user/admin differentiation on one side it seems like a good idea, on the other side it seems as anti-unix/linux, where every user needs to become admin too. Even windows had admin, many people didn't know, of what they could do with it. The way I understand it is the "user" mode is the one who doesn't know or needs to know what s6/66 do. They make an installation, boot and go to work or play. They may be stuck with sddm and plasma for an eternity and will not know how to change to lxdm, or how to enable remote access, or get accurate time on the system, but they have had they installed. So a non-admin user doesn't even need an introductory manual. Why read an introduction to dog breeding if you don't like dogs and never going to have one, or two?
it's not what i had in my mind. A future user want to know quickly if Obarun and s6/66 is a one for him. So, a general view can help at the start like a general overview or a quick start(something like this).
Working on the 66wiki, especially after the addition of 66-tools, I look at it and say that I need to print this and have it hanging next to my screen because I will never memorize all those tools.
That's the point. Some tools are unavoidable (66-{enable,disable},66-{start,stop},66-tree,66-{intree,inservice} and maybe 66-all), the rest are clearly usefull on debug or very special tasks. Do you have played with 66-svctl, 66-init or 66-scandir? I don't think so. It's generally not necessary for a day to day use.
Tools at 66-tools was especially spitted for this reason. It's not a part of 66 and should be on another wiki. Those tools are made to help on service scripts and have nothing to do with service management. Service creation is a policy decision where 66 works on mechanism, it's not the same thing (some dev/user have some difficulty to understand the difference).
1 You make a tree called boot (66-tree -n boot), then you make root -cnE root, and then a third called play (-cn play)??? When you use # 66-enable acpid, does it go to root or play? It errors out as no tree being current. If play didn't exist it would automatically go to root. Is this correct?
for example: 
# 66-tree -n boot
# 66-enable -t boot boot
# 66-tree -nE root
# 66-enable acpid
At the last enable command 66 will complain: "unable to find the current tree. You must use -t option". By default you don't have any tree set as current. In this case you must provide the -t option. So , yes when you pass the -c option to a tree every followed command will be apply on this tree. That's why the (blinking) field current exist at 66-info -T command, to show which is the current one
2
# 66-enable -t play acpid
# 66-start -t play acpid
or
# 66-enable -t play -S acpid
Is there a difference?
No difference but i think it's better to explain each command separately to understand clearly which command do what. Also, i found a little trouble with the command 66-enable -F -S acpid where acpid in a classic one and already running. 66 will complain but do the stuff, i need to investigate this before making the new release. Enable a service doesn't mean starts a service. The difference should be understand by every one. For example when you works on a server , you want to change the state of your server after a reboot not the current state of your server. This difference in this case is really important and usefull.
Ok, moved 66-tools separately and also added brief desctiptions of each tool in the 66 tools list?
That must be 1 step away from being blasted into the unknown, I hope.
4 days later
11 days later
Very nice Fungal, just read all of it and I think it's neither too long nor too short for anybody interested in getting a grasp on the suite. It's a bit emotionally disappointing to not get any example of user scenarios after you mention it at the very beginning, but the link is adequate :)
It is basically a short wiki entry on how to set user services up, the few that we have ready on observice, so it would be redundant. Now why and how you create new ones would be interesting but it would be beyond the scope of this document. My little experience with them in the past (early 66 days) was that once the /run////...1000 scandir is created and started then pretty much anything that applies for root applies for user.
Thanks for your hard work fungalnet, this is really appreciated from my side and surely for new user
No job, no money, might as well put some energy somewhere else :)
Imagine if we had all the IBM and NSA funding Leonard gets! For a while I was expecting the Kurds will send some funds, but there goes that hope ...

https://sysdfree.wordpress.com/281

If they are not shooting at us we must be doing something wrong, maybe we pay so much attention to Leonard we forget Linus.

Powered by Obarun