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

Solomon Peachy pizza at shaftnet.org
Sun Aug 20 11:04:26 EDT 2023


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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://mail.ale.org/pipermail/ale/attachments/20230820/34c0b4e6/attachment.sig>


More information about the Ale mailing list