@bai4Iej2need: You are completely right. And thank you for posting the link. I'm just watching it and my favourite slide is shown at around 25:00. Spoiler alert "I just don't need ANY of this." Regarding the ship, we will immediately discuss which ship and where will it sail (or is it a steamboat?).

Ok, but what? That's your argument, blackhole? Come on that's weak. (I'm writing this from a Win 11 laptop) A better would have been that they are enforcing (buuh!) their proprietary (double buuh!) app image format (not enough buuhs available) on the community.

No, really, Canonical tried to give some impulses in the early 2010's (anyone remembering that they were sending installation CDs for free; that the had a netbook remix for the then popular devices or upstart?) - but (parts of) the community buuh'd them out of the room. So they turned away to doing business in the cloud (this is were they are big) and doing stuff with MIcrosoft. Why not? Ok, they could have left that to RedHat too. I think (but I don't know) that they have Debian devs on their payroll, so what?

Personally I think it's time to acknowledge that Linux is lost to the big corps but I still do not have Canonical on that list. Just wait, what RedHat is going to do. They already mentioned that they are going to an image-desktop. I also read that they think about an OS variant for AI (including agentic? but I don't remember) use. And the Debian folks will do what they ever did since they took systemd: repackage. Yes, I think that's the future.

The question is, what will small communities which don't like this approach do about that? I guess nothing because the saying "If it's not broken, don't fix it." But the part of the truth is that if you don't "fix" software while it's working it's very likley that something or someone else will break it for you. (Anyone thinking of systemd now? Or appimages?)

@blackhole: I would add RedHat to the list (why Canonical?) because there it all began. And I'm still impressed how well they hide in plain sight. I mean, check out who is behind the currrent developments in userland.

@kaiyel: You are comparing apples to 700 kg pumkins.

I have been using lxde and then lxqt on Debian / Devuan systems. The work very well with 2GB RAM. Since I do not really need an IDE I switched now to

• jwm an window manager

• dmenu_run as launcher; alternatives: rofi or xlunch (https://github.com/Tomas-M/xlunch)

• xmenu for an easier popup than jwm

Interesting. Let me follow up on that.

First, thank you, blackhole and greenjeans, for your reply. I noticed that you did not answer the question: What is an admin or user supposed to do if a service fails due to a transient error? How do they know that?

@greenjeans: No, this is not "incongruous thinking". When I get the story right it was like that (feel free to correct me): Around 2000 Linux was the new kid on at the table. HP-UX, IBM AIX, SCO, Sun and yes, Microsoft too were the established names for the server room. You had to persuade your manager to bring Linux. But was still a freaky and nerdy thing made by a group of coder led by some Finish guy. How could that possibly work? But you got the permission. Then the day came where the mail, print, file or web server (or all together) failed. That was clear from the beginning, wasn't it? I mean, what quality can you expect from a bunch of non-professional coders? With good luck they were working for a university (iow: an egghead). Can you even imagine how bad such an admin feels? He then turns to SysV for assistance and what he gets back is like: "Well, you know, the philosophy is that services don't fail". Now Linux does offer great opportunities for everyone, so the admin might have answererd: "Thank you, but I will fork off."

Another question for you:

How do you make the decision what is it important? Or let me ask that otherwise: There was a time before SysV init-style. That was changed (broken?) for SysV. What made this change so extremely good that it seem to hit some optimum, which cannot be enhanced by further changes? Oh, please @blackhole: you might also have suggestion on that. Please let me know.

Changing is not automatically breaking. There was I time when I asked myself: "How could I change SysV init into something with supervision with minimal (scriptable?) changes to the init scripts?" to have the best of both worlds. But that would things only on the surface.

Thank you, JCK, for mentioning other init-styles. It remembers that the init-space is totally fragmented. Changing / enhancing SysV would only increase that. I'm not suggesting anything like that and I'm really no longer care about init-styles. Instead I started to make my own pidN service controllers that could run with minimal impact below any init-system I find. (If I would have to choose, I think I would take runit: I like its concepts anbd ideas but not so much the implementation.) SysV, systemd, /sbin/init? I doesn't matter. It's pretty easy to configure a single service to whatever the system runs and from that I'm on my own. And in addition to the small footprint, I do not depend on others, their implementation or whatever.

But back to the question above, I would be really interested in how you (all) decide what to consinder to change or update and what not. Because there the difference between bloat and not-bloat starts.

I agree to that partly. What I think is wrong with Linux is that every program has to have address all (!) possible use cases. Even if they are only useful in years where Easter Monday is on Thursday.

This should be no big surprise. In the end it's all Redhat stuff, isn't? I mean as far as I understand they "own" systemd, Gnome, Wayland (?), flatpak, util-linux ... 80% of the relevant Linux user space?

I took a look at shed (version shed.v0.2.0-120-gd7af2d4) to see how you manage is processes are running. I guess I made something completely wrong due to my impatience or missing experience with gaming X sessions. Nevertheless, I got what I already suspected. shed was reporting that is was already running (line 142) when that was really not the case. It's because shed relies on pidfiles only. (If there is one single thing I should name that was giving me most issues with SysV init then it is the reliance on pidfiles in the "early"? init scripts.)

Instead you could use start-stop-daemon, and if that's not installed busybox start-stop-daemon (busybox is widely used in Linux installations because of its use in initrd) but (1) I have no idea about non-Linux UNIX systems and (2) I don't think that it would help in checking for the shed script.

Here is a suggestion for some "stuff" that might work too.

#!/bin/sh
#

is_running() {
    /usr/bin/awk '#

	function getarg(name,   p) {
		if (argi >= ARGC) {
			printf ("%s: missing arg: %s\n", program, name) >>"/dev/stderr";
			exit (1);
			}

		p = ARGV[argi];
		ARGV[argi++] = "";

		return (p);
		}

	BEGIN {
		program = "is-running";
		argi = 1;

		pidfile = getarg("pidfile");
		pid = getarg("pid");

		if (pidfile != ""  &&  pidfile != ".") {
			getline pid2 <pidfile;
			close(pidfile);
			if (pid == ""  ||  pid == ".")
				pid = pid2;
			else if (pid != pid2)
				exit (1);
			}

		fn = "/proc/" pid "/cmdline";
		FS = "\0";
		getline <fn;
		close (fn);
		for (i = 1; ARGV[argi] != ""; argi++) {
			if (ARGV[argi] == ""  ||  ARGV[argi] != $(i++))
				exit (1);
			}

		exit (0);
		}' "$@"

	return $?
    }

is_running "$@"
exit $?

is_running is a draft of a shell function *relying on /proc* (again: don't know about non-Linux) accepting 3 or more parameters:

• the name of the process' pidfile; this is optional

• the process' pid; optional: if pidfile is given its value is compared against pid and they are expected to match; if missing the pidfile's content is used as pid

• the process' executable (optional - if not set only pids would compared but that would not make much sense for this function)

• addtional optional parameter would be compared against the process' command line parameters.

• Arguments for process executable or parameter might be empty string to ignore the for comparison.

So, how could that been used in shed? Just guessing here, but testing for a running service should be

is_running $pidfile "" $EXEC

but that does not work for interpreted scripts (bad). Adding `$E_ARGS` should help

is_running $pidfile "" $EXEC $E_ARGS

but the script's `$EXEC` must be the interpreter (i.e. no use of `#!` here).
Also

is_running $startfile "" /bin/sh shed

should check if shed is running. You can replace `/bin/sh` with `""` if you are unsure about the shell interpreter.

@EDX-0, I really like what you are doing here and I think we should have more of that (to have alternatives to choose from or copy&paste code or ideas).  One of my projects is to work on a Raspberry Pi gadget where I combine system services into a "functional device".  I don't give a pfff about writing systemd units for them but instead I use my own process supervisor for that.  This too makes starting the relevant services pid1-agnostic.  That is easier to handle (you do not have to understand the 300+ unit options) and it is easier to port to other pid1's (SysV, systemd, s6, runit/nitro, you-name-it).

Having said that, I must admit that I'm not going to use your controller because I have my own pony on the lawn: https://codeberg.org/awk-scripting/pico-init.  It supervises the process but requires bash or busybox ash (or any other shell with `wait -n` which excludes dash) for that.  I'm just going to add runlevels to it which brings the script to approx. 1500 lines of code (comments and empty line count extra).

Thank you for posting this. Your app gave me the final push to create an X-version for a note format I'm using for years now in Linux terminals. It's written in Java and I understand it's not for everyone but in case you are looking for additional inspiration, the documentation is here: https://codeberg.org/awk-scripting/Note … ntation.md