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

Sun Aug 20 14:26:53 EDT 2023

I've always been in near laughing hysterics when the "logs aren't in text
anymore" argument gets made.
Um. Good luck reading anything off a hard drive without some kind of
interpretation!!!!

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.

So crap changes. In the larger picture it gets better. In the close up it
usually involves complaints from people with no personal experience related
to the events that prompted a change.

Now, in the US, we all drove on the right. At a point in the past, that was
not the situation and something happened that instigated the formality
change. Probably a tragedy given the history of our law makers being far
more reactionary than visionary.

I kind of see systemd as a successor to whatever Canonical was cooking up
as an init replacement (can't recall the name). It had problems and lots of
traffic was generated with discussions about those problems. Now it's
abandoned. Kind of like the old a.out binary format getting replaced with
elf.

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.

Maybe someday Wayland will finally surpass the old X. Maybe someday we'll
all look back and argue over "That was the year of the Linux desktop (No.
Not Enlightenment 4527 :).

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. 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!

On Sun, Aug 20, 2023, 11:04 AM Solomon Peachy via Ale <ale at ale.org> wrote:

> On Sun, Aug 20, 2023 at 08:58:37AM -0500, Leam Hall via Ale wrote:
> > I disagree with the "value" of systemd. It may offer a solution, but
> > as was said elsewhere, how it works invalidates what value it may
> > bring.
>
> ..value it brings to YOU perhaps.
>
> ...But I find your statement a bit wtf.  There's nothing sacrosanct
> about UNIX from 20-30 years ago, which was itself an organic pile of
> historical baggage in its own right. Its authors thought nothing of
> breaking the way things had been "always been done" if there was a
> logical reason/benefit for it.
>
> See also this:
>
>
> https://drmarjorieblum.com/2013/08/16/the-pot-roast-story-a-leadership-tale/
>
> > losing text based logs
>
> At worst you install a classic sylog daemon, and still end up with
> *better* logging than what syslog on its own provided.  Next.
>
> > ease of queries
>
> WTF does this even mean?  Querying what?
>
> I find 'systemctl status bla' easier to type than '/etc/init.d/bla
> status'.
> If I don't just use the 'service foo status' wrapper that's been there
> since before systemd existed.
>
> If anything, systemd makes this _easier_ because systemd also shows you
> the last 10 lines the damon logged, if it's actively running, its pid
> (and the number of children, how long it's been running, memory and CPU
> usage, and if it's actually set to automatically start or not:
>
> $ systemctl status httpd
> ● httpd.service - The Apache HTTP Server
>      Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled;
> preset: disabled)
>     Drop-In: /usr/lib/systemd/system/httpd.service.d
>              └─php-fpm.conf
>      Active: active (running) since Mon 2023-08-07 20:19:33 EDT; 1 week 5
> days ago
>        Docs: man:httpd.service(8)
>     Process: 2245695 ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
> (code=exited, status=0/SUCCESS)
>    Main PID: 1464 (httpd)
>      Status: "Total requests: 648540; Idle/Busy workers 99/1;Requests/sec:
> 0.595; Bytes served/sec: 6.1KB/sec"
>       Tasks: 230 (limit: 154594)
>      Memory: 350.0M
>         CPU: 47min 38.502s
>      CGroup: /system.slice/httpd.service
>              ├─   1464 /usr/sbin/httpd -DFOREGROUND
>              ├─2245700 /usr/sbin/httpd -DFOREGROUND
>              ├─2245701 /usr/sbin/httpd -DFOREGROUND
>              ├─2245702 /usr/sbin/httpd -DFOREGROUND
>              ├─2245894 /usr/sbin/httpd -DFOREGROUND
>              └─2245951 /usr/sbin/httpd -DFOREGROUND
>
> Aug 20 00:00:00 pineapple.shaftnet.org systemd[1]: Reloading
> httpd.service - The Apache HTTP Server...
> Aug 20 00:00:00 pineapple.shaftnet.org systemd[1]: Reloaded httpd.service
> - The Apache HTTP Server.
> Aug 20 00:00:00 pineapple.shaftnet.org httpd[1464]: Server configured,
> listening on: port 443, port 80
>
> But no, you're saying this functionality isn't worth it because of "how
> it was put together."
>
> > and clear output,
>
> My pre-systemd boot/shutdown log is indisinguishable from post-systemd
> boot log, the startup script shows nice pretty-printed 'Starting foo...
> [OK|Failed]' either way.  Anything more detailed always required
> additional manual steps.  If something failed, I find systemd's journal
> a lot more beneficial here as it captures *all* daemon output (including
> stdout/stderr) in the same place, plus has its own consistent logging
> that is vastly superior to what came before.  And oddly enough, truly
> pathological daemons are just as pathological no matter what was used to
> launch them.
>
> > I'd run Windows. That's what systemd is to me.
>
> That's funny, as systemd is vastly superior to Windows' service runner,
> no matter what measuring stick you use.
>
> > I'm writing this on a Fedora box, oddly enough. I used to log bugs for
> > Fedora, but got tired of them ageing out instead of getting fixed.
> > Soon enough I'll be off Fedora again, and onto something better.
>
> Were these bugs with "Fedora" itself, or bugs in the upstream software
> that is merely packaged in Fedora?  (And how is this any different than
> any other non-commercial distribution?)
>
> (I log every issue I run into, and anectdotally, I've found F38 to be
>  the buggiest release in several years, or at least I've been bitten by
>  a lot more bugs than is typical.  But every one of those bugs was/is an
>  upstream problem.  Once upstream lands fixes, Fedora usually pulls in
>  the fixes pretty rapidly.  They joy of trying to track the bleeding
>  edge.  And yes, many age out, and that's almost always a good thing..x)
>
> > Red Hat started as an open source company, and I bought their Linux
> > before they had RHEL.
>
> And they still are.  Every one of their offerings is upstream-first
> F/OSS, without any of that "open core" proprietary BS that is increasingly
> common these days.  Nobody else comes remotely close.
>
>  - Solomon
> --
> Solomon Peachy                        pizza at shaftnet dot org
> (email&xmpp)
>                                       @pizza:shaftnet dot org   (matrix)
> Dowling Park, FL                      speachy (libra.chat)
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> https://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20230820/bd26cb71/attachment.htm>