Nice catch. :-) When I read over the item - in HTML on web page, in the context, I was expecting rather to quite competent code ... so my brain autocorrected what I read to what I'd expect, rather than what it actually was (competent code slightly broken by HTML conversion). On the other hand, when I'm much more skeptical of the code, I'm much more likely to notice errors (or encoding mess ups, etc.) ... in fact I'll often, in such cases where it's not already in text/script file, copy & paste or otherwise copy into file ... or often just into editor (vi(1), or more precisely nvi(1), of course) buffer, and have a look at it there ... and things like that tend to then quite jump out at me (like Microsoft automangling of code that introduces non-ASCII bytes and other issues). Hope Cabal is going well - I was seriously tempted - it's been a while - but rather long trek via public transportation from Berkeley ... and besides, I'm still working on BALUG list migration bits ... more on that soon.

From: "Rick Moen" <rick@linuxmafia.com> Subject: Re: [BALUG-Admin] DreamHost.com - yes, others (besides BALUG) also notice issues Date: Sat, 8 Jul 2017 15:19:39 -0700

Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):

...

Yes, we're certainly not the only ones to notice DreamHost.com having issues, e.g.: https://catless.ncl.ac.uk/Risks/30/36#subj22

HTMLisation for purposes of presentation in the https://catless.ncl.ac.uk/ digest version messes up the cron job a bit (eliminating semantically vital spaces). The correct version can be seen on the underlying comp.risks newsgroup, and I find it delightful and useful:

# This gives me a whole week (expr 60 \* 60 \* 24 \* 7 : 604800) # after reboot to figure out which process was the memory hog: * * * * * if test $(sed 's/\..*//' /proc/uptime) -gt 604800; then set -e -- $(date +\%M); COLUMNS=500 top -b -n 1 -c > TOP.${1#[0-9]}; fi # Yes, need to run once a minute, as Dreamhost takes no snapshots of # the system before rebooting it.