I've pretty much walked away from GNU/Linux for the time being, but reading about the DynamicUser and other new issues, only seems to further the fact the octopus is still far from growing new legs, or the mindflayer is still trying to spread it's will and influence to the other realms. Progress be praised, security be damned, and sanity be lost.

The software had matured and more or less stabilized to a point of viability as being somewhat in the realms now of sanity, but the problem yet again of feature-creep has re-raised the tentacles. As it stands, debugging systemd is downright nearly a bad project with poor management. See here: https://utcc.utoronto.ca/~cks/space/...AndItsIdealism

The problem seems to persist, nobody at the project gives a damn what they fudge up, the distributions using it could care less to help you at all, and really speaking, so few alternatives exist. I actually attribute systemd to Goku Black and Zamasu.

Systemd is here to stay. I would have preferred a less controversial solution myself but, something was/is needed beyond classic init. There are many times systemd makes me just furious, but it is what it is. That said, I don't really spend any more time sorting out systemd issues than I did sorting problems with init scripts in the past. I also custom build the package and turn off stuff I don't need or want.

I found two really good videos about the problems with classic init systems a few months ago. One was an Apple presentation from 2008, explaining why they created launchd. Another one was more recent, from the creator of S6. There are all kinds of problems that exist today that didn't when init only started like 5 daemons on every UNIX system in existence. Basically, it comes down to needing an OS layer between root space and user space... the system space. SUID is a hack that shows its age with the modern internet.

The problem of init was system developers got lazy and wanted an easy way out of writing effective scripts. It wasn't about system management, relaunching failed daemons, or solidifying a control set, it was about laziness.

The arguments for systemd have never held water. The only reason why it was wanted was because the problem was created to ensure systend was to be used.

S6, runit, daemontools, perp, etc. all provided the exact same thing as systemd while leaving the outlying functions to other projects.

"Write one program that does one thing, and does it well" was the standard UNIX philosophy. Why? It created allowances for project responsibility. Ever heard the term "less is more"? It applies to this. Less code to deal with, means less chances of screwing it up, and more chances of getting it right.

Init was just that. Init. Init is not the supervisor, manager, login agent, session manager, kernel loader, etc. It's just a tiny program that boots the system, then forks itself to another instance(s), then reaps child processes and shuts down the system. You don't even need sysvinit to boot a system. All you really need is bash. Sysvinit just gave a small set of tools to make it simpler for scripting.

You want XYZ, add another program and learn to write the scripts to use it. If all Linux needed was a system state manager for keeping daemons alive, we had it for years and never used it over pettiness and stupidity. Daemontools has been around since the late 1990s and did the work systemd promises. Why 10-20 years later reinvent the wheel for nothing? Ask lazy system developers who can't write simple bash shell scripts. Red Hat wanted to be the next Microsoft for years now. This just let them make Linux into their own clone of Windows.

3 members found this post helpful.

80 years ago... "Hand crank starters work fine. I don't need none of this new fangled electronic ignition stuff. Just adds complication to the car. Need a bigger battery, bigger cables, and one of those silonode thingamajigs. No thank you, my arm is good enough."

30 years ago... "I've got no use for this fuel injection stuff. My carburetor works fine! This fuel injection requires all kinds of new complicated stuff. Pump in the fuel tank, high pressure lines, wires and sensors everywhere and a computer! Now, who the hell needs a computer in a car. All just a buncha nonsense is what I say... Keep it simple... that's what I say."

Things change. No one can avoid it forever. Personally, I think systemd was the worst of the choices available. That said, so many have jumped on it is hard to avoid so I decided to go ahead an learn to live with it. I've almost dumped it a couple of times, but then I didn't want to back and update 2 dozen init scripts I archived 3 years ago. Perhaps we'll get lucky and something smaller will be introduced and takeoff, replacing both systemd and systemV.

Smaller is relative. The issue should be having a project that holds itself accountable for problems, addresses them in a timely fashion, and keeps sanity in coding practices like documentation, debugging, etc.

1 members found this post helpful.

Here is a nice talk about Systemd



https://www.bitchute.com/video/9uFQSOiJCqRf/