altoid via Dng said on Sat, 01 Jun 2024 18:16:37 -0300

>There is and will always be a lot of moolah behind the use of systemd
>in Linux and Debian has been the Trojan Horse used to achieve the
>first part of that goal.
>
>Now, the system has been infected and the infection is growing fast.
>
>With the aid of Poettering and his crew of MS/IBM/RH misfits, the
>pustch against the Linux ecosystem continues while within Linux the
>few that care are talking about/discussing multiple init softwares
>instead of investing their time and efforts to make dead sure that at
>least 'one' works without needing systemd.
>
>No matter *which* one. Just one that works and can use all the
>available packages.
>
>Sooner than later, not *one* package in the Debian repositories will
>have an initscript and as a result absolutely *everything* Devuan
>will be dead in the water.
>
>I'm sure that everyone will then be very happy to have the *choice*
>of only one Linux-like (if you may call it that) OS to choose from.
>
>And that day, Microsoft's wet dream will have become a reality.
>
>Unbelievable.
>But close but with every day that goes by closer to being the truth.

Altoid, you can fix this, by yourself, with 80 hours of work. If you
do, even though I'm busier that a 1 legged man in a butt kicking
contest, I'll help you with design, documentation and publicity.

All you need to do is provide a tarball of runit, stage 2, including
run directories most of the daemons you need, in a single directory
tree. A lot of this is simply copying the material from
https://smarden.org/runit/runscripts . You can also grab and modify
slightly the Void Linux' run directories and run scripts.

Why a tarball of a singular directory tree? Because it's an end run
around the packaging system, meaning a systemd sycophant can't package
your solution out of their distro. By the way, the top level of the
tree would look something like the following:

altoid_runit
src
sv_all
sv_active

sv_all would be every single run directory that can be discovered by
any means, whether or not its daemon is installed on the computer. This
separates the run script from the upstream author so he doesn't need to
create the run script.

sv_active would be a bunch of symlinks to directories in sv_all,
because each of these symlinks enables runit to supervise the daemon
for the symlink.

The user could put this tree anywhere. It could be owned by root, or
perhaps a properly crafted user/group named runit. A few symlinks can
be used to adjust it to the distro or the user's principles and
prejudices.

Why a single tree? Because you can then install simply by laying down
the tree, setting a few environment variables, and compiling the (very
simple and easy to compile) runit executables, for which there are
already make files at runit-2.1.2.tar.gz , or if you want to include
upgrades since 2014, perhaps get it from the Void Linux project, at
github.com/void-linux/runit , because Void are the official maintainers
now. Remember, the reason for packages is the "we include 40
dependencies you don't need but must have for our package" take it or
leave it. Other than the C standard library, I don't think runit
includes anything not part of the runit software's source code.

Why do it yourself? Because invariably if you suggest a project, others
will give you a million reasons why it won't work and bikeshed it to
death. Here are some of the objections you'll hear, and how to counter
them:

* This doesn't stop the systemd mafia from getting their dependencies
  put into programs.
    - True, but when Altoid Runit gets popular, convincing
      distros to contaminate perfectly good programs with systemd
      dependencies will get harder to do. And besides, a person can
      always compile those few softwares that they really need and have
      systemd dependencies.

* The systemd mafia will just sabotage Altoid Runit just like they do
  with everything else. 
    - True, but Altoid Runit is so dam simple it's easy for one person
      to comfortably keep up with systemd obstruction code. I mean all
      that needs to be done is to compile 9 small executables and
      maintain a tree with a few symlinks and environment variables.

* I like my [sysvinit | OpenRC | Suckless Init | Busybox Init |
  systemd] !
    - No problem, Altoid Runit can easily be bolted on to any of those
      init systems. Yep, even systemd.

* Distributions won't create Altoid Runit packages.
    - Good, I hope they don't. Altoid Runit is intended to go into any
      distribution (probably even BSD), and what little compiling is
      necessary has no dependencies. This makes it distro independent
      and less subject to sabotage by distros.

* Runit supervisor's daemon startup is indeterminent.
    - So what? In my ten years of using runit its indeterminancy has
      never caused me a problem. But if they SIMPLY MUST have
      determinancy, see Littkit at
      http://troubleshooters.com/linux/diy/suckless_init_on_plop.htm#littkit_introduction
      Littkit is a whacky kludge, but it's less kludgy than systemd.
      And once again, it's not really necessary. NOTE: Runit already
      has process dependency abilities on startup, by testing for
      correct performance of whatever was supposed to start before a
      daemon.

* I don't want a project headed by one person.
    - Well, I guess you don't want the Linux kernel either.

* Runit's not ready for prime time.
    - There's not much of a counter to this, because the person making
      the assertion thinks he's smart but he's profoundly stupid.

* Runit is not innovative.
    - Precisely right. If you get it exactly right the first time,
      then in the absence of changes in the environment, innovation is
      unnecessary and counterproductive. 

* Runit is unsupported.
    - This is a falsehood. The Void Linux project maintains the
      upstream source code, available at github.com/void-linux/runit .
      So if there's ever a security problem discovered with runit
      (there hasn't been in the last 10 years), then the Void folks can
      fix it immediately.

SteveT

Steve Litt

Autumn 2023 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21