Ron via Talk said on Wed, 27 Aug 2025 01:30:03 -0700
Steve Litt via Talk wrote on 2025-08-26 19:21:
Does anyone know of a work-around?
LOL
Anything starting with that is almost guaranteed to be dumb.
Let's see...
Dump * system * D
Switch from Debian to Devuan,
Yep, the record remains unbroken.
Como se dice "Yep, the record remains unbroken" en Englais? Wie sagt man "Yep, the record remains unbroken" in English? In other words, "huh?"
and all the systemd overcomplexifications will be history for you.
I never hear complaints about the complexity of bash,
Bash does one thing and does it well: It serves as a great *interactive* shell. It doesn't have tentacles into the entire software system. As far as a shell scripting language, why would anybody use bash when ksh and dash are available?
nor postfix
Once again, postfix doesn't influence anything except for email, whereas systemd influences over 50% of the computer's software systems. To answer your question about why I don't complain about the complexity of postfix, it's because I don't use it. If I needed a full SMPT server, I'd use one of the others as a substitute, just like I use runit as a substitute for systemd and sysvinit.
(over 1000 options!), nor X11 - which even Xorg thinks is no longer maintainable and is also insecure.
X11 is a hypercomplexificated junkpile, and I look forward to the day when we have a *real* improvement on it. I don't think Wayland fits the bill, at least not yet. In the same way, sysvinit had/has real problems, but systemd is not a solution. Systemd is more like falling out of the pan and into the fire.
Never a word about those.
Apparently "hypercomplexifications" pertaining to systemd means "I'm old, I refuse to learn anything new for at least the last decade".
I learned Rust. I'm in the process of learning Go. I just added the superior (and fairly new) uv Python package manager to some of my Python programs. Hypercomplexifications doesn't mean unwillingness to learn, it means just what it says: https://www.troubleshooters.com/linux/systemd/lol_systemd.htm
First you complain that systemd is too complex and therefore a security problem.
True, but I care more about the difficulty of troubleshooting tightly welded systems, and the lack of DIYability such systems bring.
Then we see a clear example where a simple directive like "ProtectHome" can be used to harden any server on the system with a single line of readable text and now you advocate for ... discarding the security advantages and going back to old tech.
Which can't provide this protection.
I spent 10 minutes researching "ProtectHome". It's an excellent idea. A per-daemon barrier to /home, /root, and /run/user. My research showed it seems to cause problems for a lot of people. It's a great idea. I suspect it could be made more general (why just those three directories, and why those three as a package deal) and can also be done using a separate software component with a thin linkage to runit's runsv command. If I needed this, I'd do it myself.
If anyone wants some background, here's a turdnugget from Steve's GOLUG just last week with Steve, me, and Steve quoted:
there was absolutely nothing wrong with sysvinit's PID1 in the 00's
And yet multiple teams of Linux experts at Canonical, RedHat, etc. were looking to replace it.
OK, perhaps I misspoke. What I meant is there's nothing wrong with sysvinit's pre-daemon-handling code. Sysvinit's problem was its process handling. Canonical, RedHat etc could have easily plugged in Daemontools, which existed since 2001, to get rid of those awful init scripts *and* do parallel instantiation. But that's not their style: Daemontools was just sooooo NIH (Not Invented Here). They could have just added the following line to /etc/inittab: SV:12345:respawn:/command/svscanboot No need for Upstart or systemd. But noooooo! I was using daemontools for some of my processes since about 2006, and it worked great. SteveT Steve Litt http://444domains.com