[ale] Remove systemd network handling

[Steve Litt]

Solomon Peachy via Ale said on Thu, 23 Sep 2021 07:17:10 -0400

>On Thu, Sep 23, 2021 at 02:33:48AM -0400, Steve Litt via Ale wrote:
>> Handling things we don't need handled is what systemd is best known
>> for. Today it's networking. Tomorrow perhaps home directories. One
>> day it will grow its own package manager and systemd distros will
>> drop their own. In its five years, systemd has repeatedly solutioned
>> things that already had great solutions. As long as systemd is used
>> at all, one is constantly at risk of this kind of situation.  
>
>Oh, FFS.
>
>"Systemd" didn't sneak into Alex's RPi in the dead of night and take 
>over networking.
>
>Debian developers made the decision to use systemd networking
>features. Just like they made other decisions to avail themselves of
>other systemd features. 

OK, by all means: Systemd isn't a killer robot, it's just an
attractive nuisance. My original assertion, which you have not refuted
in the slightest, was "Handling things we don't need handled is what
systemd is best known for."

LOL, I hear systemd has its own method of doing home directories now.
It's a familiar refrain: Nobody was dissatisfied with the way home
directories worked, and now here comes systemd with a "solution" to the
home directory non-problem. Systemd has timers now, as if we haven't
had zillions of ways to do timers from the dawn of time. And they had
some replacement for xinetd, as if xinetd wasn't good enough, and also
as if having things start on need was a thing anymore (in most
situations), now that $600.00 computers have the power to run *a lot*
of processes.

And you just reminded me: All of these solutions to non-problems are
implemented in PID1. Yeah, that's my story and I'm sticking to it until
you show me a valid block diagram of systemd with both process boxes and
interaction lines. That's just what we need: An incredibly bloated PID1.

> (I might add that exactly *two* of systemd's
>features are mandatory [PID1 and journald]; the rest are *entirely
>optional* and up to the distributor/integrator to enable or otherwise
>utilize. or not)

Would you like a tickertape parade for solving an immense problem?
Publish a document on how to shut down all the systemd features the
distro decides to include, except PID1 and journald, without recompiling
everything. And without every package update requiring the user/admin to
do it again. Add in how to make journald logs text instead of binary.
Then we can all pick the distros we want without worrying about the init
system. Red Hat will thank you, Lennart will thank you, FreeDesktop.Org
will thank you, because if you do that effectively, all resistance to
systemd will vanish. I will thank you because the systemd PID1 will
spawn one process on my machine; the runit or s6 process supervisor. If
you make this document, you'll be famous as the guy who ended the
resistance to systemd and brought the Linux world back to harmony:
Something Lennart, Red Hat and FreeDesktop.Org haven't been able to do
in 5 years.

[snip]

>
>Meanwhile, I have a RPiZero on the shelf behind me running bone stock 
>raspbian, datalogging from an i2c-attached environmental sensor. it's 
>been running for well over a *year* (over wifi) 

Anecdotes are like garbage cans. We all have them, and they all stink.
I could talk about my beautiful runit initted Daily Driver Desktop, but
I doubt you'd be interested.

FFS,

SteveT

Steve Litt 
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques