[Semibug] SystemD is literally the kitchen sink of Linux ; Linux starting to feel more and more alien as the years go on

[Steve Litt]

Nick Holland said on Thu, 7 Dec 2023 13:04:24 -0500


>so... systemd has issues.  So lets create something new to deal with
>those issues!  Out Of Memory killers are just a bad idea. "Hey, my
>system is out of memory (due to bad applications leaking memory), let's
>start  killing processes!" -- this can't reliably end well.  Sometimes,
>it is best to just let your system wedge and stop doing damage, than to
>let the system continue to inflict more damage, "but uptime is great!".

>And that's a classic Linuxism.

I sure wish we could avoid having the Linux bashing, from BSD
advocates, that infested the last three years of the 20th century. Even
though we might not agree on everything, we're close cousins. GoLUG
(Greater Orlando Linux User Group) is very BSD friendly with several
BSD users, and if any Linux user on GoLUG's list insulted BSD, I'd jump
down their throat in a New York second. Please understand, I'm not
against expressing disapproval with things done by Linux. Read on.

>Rather than fixing the actual problem,
>make the system more complex, introduce three problems for every one
>solved, and call it progress, and if you are opposed, you are standing
>in the way of progress.

The preceding is a horrible problem. I've been fighting it for years.
For years I've argued for simplicity and modularity and a-la-carte
programs: Do one thing and do it well. There are plenty more like me.

>  
>>> All Unix users know what a PID is it is universal but Linux has to
>>> be different.  

I have a suggestion. If running out of PIDs is a problem, why not
#ifdef so that on 32 bit computers it's a 32 bit unsigned integer. I
dare them to run through 4 billion PIDs., On 64 bit computers make it
64 bits. I dare them to run through 18 trillion PIDs. At this stage of
the game, 16 and less bits are relegated to appliances, so 65535 PIDs
should be plenty between reboots. 

[snip]

>
>I do believe AIX does as well.  Seemed to tag the parent's
>PID as part of child PIDs, and a really big PID space.  Very
>simple, really, other than a lot of digits in the PID.

Today we have lots of RAM, pretty fast processors and lots of cores and
threads. Why not have 64 bit PIDs?

>  
>> With OpenBSD & NetBSD, good luck, I guess?  
>
>Or perhaps people writing for OpenBSD and NetBSD understand that
>process IDs get reused, and if that matters to you, you are Doing
>It Wrong.

Well, I don't know. In today's "power user" computers, I envision 65535
PIDs getting used up. 4 billion or 18 trillion, not so much. Hey, we
used to have 2 digit years, and we increased it to 4 digits, and we're
still alive to tell about it.

[snip]

>Sounds like they are addressing problems created by systemd to me.

Yes, as I predicted would happen in the summer of 2014.

>This is exactly what I see going on with Linux.  A bunch of
>Frustrated Windows Users jumping over to the "superior" Linux
>platform...and reinventing Windows there...badly.  I'm quite
>convinced if they could make changes to Windows willy-nilly like
>they do in Linux, they would have stayed there.

I've been preaching about the preceding on every Linux list I'm on. Why
win the "desktop wars" if you lose the heart and sole of Linux in the
process? What, to save a few thousand dollars? If those windows weenies
want to do nothing but drag and drop, let them stay with windows. And
the prettyboys loving the look of Apple stuff, let em stay on the mac.
I just want my good old DIYable OS, and resent those who destroy it to
attract windows weenies (and truth be told, to vendor-lock, monopolize,
and make money at our expense).


>I'm not saying Unix should be unchanging -- the world has changed
>a lot since 1970, it does need to be evolved to fit.

You're right. The fonts in Linux and BSD were pixellated messes back in
2000. Now they're ultimately readable. And truth be told, I sure wish
Linux and BSD used the same cut/copy and paste that windows does, even
if it means having only one paste buffer.

But if you add a feature, add it right, don't tear up all sorts of
excellent existing stuff to add the feature.

[Snip anti-Linux paragraph]

>This is a general Open Source problem -- it's far more fun to add
>a whole new feature than to make existing features suck less (or
>even work), and REMOVING a bad idea is entirely forbidden, it
>might offend someone!

The preceding is quoted for truth. It's EXACTLY right.

SteveT

Steve Litt 

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