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