Puh, there's so much to say to this that I do not know where to start.

SysV init is a lot but robust and reliable? No, sorry. It works if rc-scripts play according to the rules of SysV. If they fail (of cause, they are simply not allowed to fail, right? ) the service does not work - bad and no other init system solves that - but the user or admin is the last who learns that because there's no service supervision. The service might also start and fail later for any reason and again, no one takes notice. The logs will not even show an error code.

Service supervision is just a modern requirement. I mean, come on, should the system really not try to fix a terminated service by restarting it? Should always an admin be there? What are normal users supposed to do? I also guess there's a reason why BSD is not the chosen Unix for the majority of servers or desktops. And sorry, but from here the mentioned philosophy sound so much like "Trust me bro, I'm a programmer and know what I do". No way.

I fully agree to this. But the other half of that "harsh reality" is that SysV init is something for hobbyist.

Is SysV stable? Yes - which is part of the problem. It's simple: times, expectations and requirements have change since SysV was invented or later introduced to Linux in the mid 90s. It was then a big step forward but it failed to meet evolveing expectations. There is a reason why there were / are so many alternatives to SysV exists. They were no invented for fun but for real reasons.

Simplicity? I don't know. But when you look into one of the init-scripts you see that all scripts source /lib/lsb/init-functions. Doesn't that "feel" wrong? Shouldn't this environment not be provided by some "master" process which runs all the time, very much like pid1 (with or without supervision)? For me, that's a clear sign of bad design. Not bad for the mid 90s but really not good enough for 201x or later.

A problem I remember was (is it still?) that if a service was not configured to automatically start ("START=no" in the defaults file), even root couldn't do this manually from the command line. Thanks to shell scripts that could be changed (check for a tty and ignore the START parameter). But when the runlevel was later changed SysV didn't care about the extra process and didn't stop that. No, it was stupidely processing the links in rc2.d, nmot caring about the actual system status. Not what I would call a super clever solution.

To sum it up: I can easily imagine better init systems than SysV and prefer to do my own stuff and ignore / bypass the system's init system as much as possible. But nowadays I'm also only a hobby hacker.

Btw.: if you use runit (I don't) you might want to take a look at nitro from voildlinux which is (as I understand it) a runit plus some enhancements: https://leahneukirchen.org/blog/archive … runit.html.

When you say are created with systemd in mind, can you give some examples?

Yor are right, EDX-0, pico-init has become large (it's no longer "pico"). I see two major scenarios where it fits:

• as pidN service controller/supervisor if the use case is strong enough (e.g. for a Rasperry Pi gadget device) or

• as experimental or test kit for processes control: as soon as you know what you want and need you would copy&paste idea and/or code to your project.

Just yesterday I got an idea for a possible scenario 2 .

Of course, "no one" needs another editor and this is also not what the apps do. E.g., the console notes app is a large GNU awk script that uses vi (or nano or your-editor) for editing. So, what is the script doing?

- Years ago I decided to put my notes where they belong - into the project directories. To keep the directories uncluttered, all notes go into the file Notes.md and they begin with a `###` markdown header. So the app's first function is to know the format and present the notes as directory.

- Displaying notes inserts ANSI sequences to color markdown markup and uses `less -XRF` for output.

- Then the app understands where to look when I enter `Lin:` (opens Linux.md from the "wiki" directory) or "micro:" (opens Notes.md from micro-boot directory).

- The app knows where to find all files when I run a search through all of my notes (`//systemd +boot`)

- Then the app can open links in a console (or GUI) browser, start a shell, open the editor or duplicate itself in a new xterm, tmux or screen window.

- It also knows how to open files on a gvfs directory.

So while it's true, that there are plenty of good text editors, there is so much more around organising and finding notes and this is what the apps really do.

Hello EDX-0, I like your shell approach and the idea of being agnostic of window system. init-system or whatever is there. (I'm using a similar thing for my own stuff on Raspberry Pi.) I have a small suggestion just in case there are distro maintainers with aversion of too much shell commands:

get_shed_cgroup_2() {
  awk '
        BEGIN {
                pid = ARGV[1];
                cmd = "ps ax -o pid,cgroup,cmd=CMD ";
                while (cmd | getline > 0) {
                        if ($0 ~ /grep/  ||  $0 !~ /shed/)
                                continue;
                        else if ($1 != pid)
                                continue;

                        sub(/^.*::\//, "", $2);
                        print $2;
                        }
                }' "$shed_pid"
        }

shed_pid=$$
get_shed_cgroup
get_shed_cgroup_2