[ale] Maddog’s take on recent Red Hat source distribution changes

[Steve Litt]

Jim Kinney via Ale said on Sun, 20 Aug 2023 14:26:53 -0400

>I've always been in near laughing hysterics when the "logs aren't in
>text anymore" argument gets made.

Laughter doesn't prove anything. It's just a subset of ad hominem
logical fallacy. https://en.wikipedia.org/wiki/Ad_hominem

>Um. Good luck reading anything off a hard drive without some kind of
>interpretation!!!!

Yes, and text is much easier to interpret, and is often possible for a
human to interpret without a custom program. When everything has gone
to hell in a handbasket and your hard drive is mounted as /dev/sdd or
whatever for examination, it's much easier to search for specific text
than for a bunch of numbers. This is why Linux has the strings and grep
commands.

>
>Used to be that data exchange was some hard-formatted string. Like
>8bits, a dot, 16 bits, a dot, 16 bytes, a closing sequence of 1011.
>Don't try finding that as I just made it up. But now we also have JSON
>apparently just because we have WAY more bandwidth and CPU time to
>parse 16kB just to extract the 2bytes we needs.

The preceding is a Straw Man Fallacy:
https://en.wikipedia.org/wiki/Fallacy#Straw_man_fallacy

Nobody made an argument in favor of JSON or any specific text
architecture, they merely argued in favor of text, which is easier to
search and browse, requiring no intermediate program other than strings
and grep. As opposed to binary, which requires another program.

>
>So crap changes. In the larger picture it gets better. 

The preceding is an example of the Appeal to Novelty fallacy:
https://en.wikipedia.org/wiki/Appeal_to_novelty

Being newer or older doesn't determine better or worse. Something a
month old can be great or trash. Something fifty years old can be great
or trash. Just as one counterexample to Appeal to Novelty, today's
refrigerators fail sooner than 20th century refrigerators, but don't do
any better job of refrigeration.

>In the close up
>it usually involves complaints from people with no personal experience
>related to the events that prompted a change.

Depending on how the preceding statement is interpreted, it might have
some truth to it. Take me as an anecdote: I'm have no personal
experience with per-seat operation, at least not in the 21st century. I
have no personal experience with the systemd way of doing home
directories or networking. I do, however, have plenty of personal
experience with the UNIX/Linux/BSD method of home directories, as well
as the Linux method and my own, homegrown method of networking. 

You know what else I have plenty of experience with? The costs of
complexity, where complexity is defined as either/or numerous
and gratuitous interactions between many components, inability to test
a component in isolation, or covering up of test points.

[snip]

>I kind of see systemd as a successor to whatever Canonical was cooking
>up as an init replacement (can't recall the name). 

The preceding isn't an accurate viewpoint, and in fact is an example of
the False Choice fallacy: https://en.wikipedia.org/wiki/False_dilemma

The competition was never limited to sysvinit, Upstart and systemd.
There were also OpenRC, runit, s6, and Busybox init, with minor league
players such as Perp. There were also hybrids using sysvinit's PID1
combined with process supervisor/managers from s6, runit, Daemontools,
OpenRC and others. Later came alternatives such as Epoch, Shepherd,
and Dinit.

Back in 2012-2014, the systemd fanboiz got a lot of mileage comparing
systemd to sysvinit and systemd, totally ignoring all the alternatives.
When people brought up the alternatives, the fanboiz piled on with "not
ready for prime time", which wasn't true, and Poettering's favorate
insult: "Well, I mean, if you want to use something that simple." Yes,
Lennart, I do: Simple is a good thing, you just don't realize it.

[snip]

>Maybe someday some new pile of smart folks will figure out how design a
>filesystem that can handle any size file with the same efficiency so
>the only visible difference is really big files take the same
>resources as the same size in small files.

Once again, nobody suggested huge behemoth file constructions: A line
with date/timestamp, info warning or error number, and a little
descriptive text is sufficient. Log rotation and old log
deletion prevents excessive consumption of disk space.

I spoze it's theoretically possible that a big server that's hit
constantly could lose significant performance in logging, assuming
either the logs were info level or the software spewed tons of buggy
warnings like gvim. This is no reason to inconvenience everybody for
those very few.

By the way, I've heard rumors that you can install some sort of systemd
thing which enables logging to produce text logs, and if that's true
that minimizes the importance of the whole binary logging thing.


[snip]

>Systems. I found out having a common set of rich tools to manage
>startup, daemons, processes, etc., made my sysadmin life easier than
>having to dig into 65 different startup scripts for basic boot up
>understanding. 

There you go again. Runit and s6 have startup scripts usually less than
10 lines, including the shebang, so you don't have to "dig into"
anything. I'd say runit and s6 run scripts require less "digging in"
than systemd Unit Files. All the init systems give you a common set of
tools to manage startup, daemons, processes, etc.

Give s6 with its complete init system a try. You'll be pleased with its
features and completeness.

>The fact that it can also better handle things like
>cloud junk, and groups, and virtual systems has been icing on a very
>large cake. Perfect? Nope! Better than what I started with in 1992?
>YES! Better than Irix? Oh, hell yeah!

Wow. You have to go back to 1992 for systemd to be an improvement? Have
to go back to Irix? Runit was created in 2004, Daemontools in 2001, 

SteveT