Notices by Chris Siebenmann (cks@mastodon.social)

@ireneista @awb I suspect that one reason POSIX never standardized troff is that AT&T was busy unbundling troff as an extra-cost option by the time POSIX started up (which AT&T called 'DWB', apparently officially short for 'Documenter's Workbench').

You might wonder how this affected Unix manual pages, especially for third party stuff. 'Badly' is the general answer ; people had to distribute preformatted manpages or resort to sometimes extreme measures, such as https://doc.cat-v.org/henry_spencer/awf/

I don't often say our servers are haunted, but I think one of our servers is haunted. Specifically, haunted by the ghosts of NFS v4 mounts that are no longer there.

NFS v4 in Ubuntu 22.04: apparently the gift that keeps giving. (Or my instrumentation is wrong but I more or less trust my instrumentation, as janky as it is.)

A little wish: new Linux init system projects should re-use the definite good ideas from systemd:
* put every separate service in its own cgroup and use that for process tracking
* capture output from the service's cgroup and log it (syslog is fine).
* start and restart services in a controlled environment; no more leaking things from your session into the service on '/etc/init.d/whatever restart'.
* optional non-daemonization mode
* reliable 'is it running' status information for shell scripts.

As far as I can tell, /sbin appeared first in SunOS 4.0, where the hier(7) and filesystems(7) manual pages describe it as 'executable programs that are needed in the boot process before /usr is mounted'. They both claim that the SunOS 4.0 /sbin contained only hostname, ifconfig, init, mount, and sh.

According to these manual pages, SunOS 4.0 did not have a /usr/sbin. SunOS 3.5 doesn't seem to have had a /sbin.

(I'm so happy I finally found private copies of this SunOS 4.0 & 3.5 stuff.)

Blog post: Why I have a little C program to filter a $PATH (more or less) https://utcc.utoronto.ca/~cks/space/blog/unix/MyPATHFilteringProgram
tl;dr: because at one point I had a universal set of dotfiles where I listed every possible thing that could be in $PATH on every system I had an account on, and then filtered it down to only the (unique) directories that actually existed on the current system I was on.

It's a C program because in the old days this was faster than (limited) shell builtins.

Blog post: The profusion of things that could be in your $PATH on old Unixes https://utcc.utoronto.ca/~cks/space/blog/unix/OldPATHProfusion

Disclaimer: some modern Unix environments also have a lot of things on $PATH, but I think they tend to be things in $HOME (or other personal work areas). Unless your system goes wild with /opt/* or the like.

@lanodan @grawity I've traditionally considered that part of my 'architecture' name, which is really sort of 'ABI'. In the old days it mostly didn't matter since CPUs mapped pretty closely to Unix ABI variants, but these days I can have eg 'bin.i386-linux' versus 'bin.i386-freebsd'. (And even in the old days I tended to call it things like 'bin.ultrix-mips', although that one is unfair since I had non-MIPS Ultrix machines too at one point so I'd had to deal with that issue early on.)

@lanodan @grawity To this day my $PATH has both ~/bin and ~/bin/bin.<arch>/ directories, even though in practice all of our systems are single-architecture.

Hot take: that tools want you to have ~/.local/bin and ~/.cargo/bin on your $PATH is a sign that these shouldn't have been hidden dot-directories in the first place (or at least the <dir>/bin shouldn't be in a dot-directory). Go had the right idea with ~/go/bin.

@gnomon @mos_8502 I think one issue is that Linux doesn't have a central coordination point the way the BSDs do; instead all of the pieces are distinct. When each project is making dependency decisions separately, without central coordination, the motivation to avoid a common-in-practice tool is much lower (and then you get a big dependency base).

(Even if you avoid <X>, some other core project may require it and then you've made your own life harder for no overall gain.)

@gnomon I have many opinions on this (see: techblog, at length) and I agree with you overall. People keep pushing the rock uphill and it keeps rolling back down on them while the rest of us get out of the way to avoid being crushed.

(I will also question the value of SELinux in practice, because it's also only ever been unlikely insurance, except maybe on Android.)

My fun Linux kernel patch story from the early 00s is sending in what I thought was a carefully worked out patch to deal with a somewhat tricky 32-bit/64-bit NFS client compatibility issue, which vanished into the void of no comments. Some months later, Linus Torvalds made a change to fix the same problem except it was incomplete, missing one case my patch had dealt with.

(I assume Torvalds never even saw my patch in the mailing list volume, and probably no one else looked at it either.)

@mhoye There are reasons why I don't follow Linux kernel developments any more and will never try to make a patch. It's not entirely dissimilar to my views on interacting with OpenBSD.

(In the early 00s I followed LKML and tried a few patches and bug reports, but I drifted away after basically nothing worked and I got some fun stories.)

@lanodan Also I would never have noticed this enough if I hadn't put together a desktop tool to pop up to show me the state of our alerts, and the tool showed me pending alerts too, so every so often the tool's check lined up with the metric system's ping check that had failed and a little window flickered irritatingly into existence on my desktop.

@lanodan The automated ping check is infrequent (~30s) so a failure had to line up with the check, but it turned out actual ping flakes were common enough that mtr in strip mode running from another machine on the same network showed me some '?' markers (which was entirely too many on a local network where other things were fine).

It has been '0' days since a periodically flaky alert check that flickered very briefly every so often and tempted me to disable it was actually a sign of a real problem (intermittent packet loss, causing ping checks to flake briefly).

A sysadmin opinion: one reason I close the tab on programs that only officially install and run as a Docker container is that I want to at least pretend that I'm not dealing with an opaque, sealed black box that I'm in no way expected to understand or fiddle with.

@rk I'm sure Motif was the nicest and most rounded toolkit, but I'm still scarred from commercial Unix vendors not giving it to us unless we wanted to pay extra. So Athena for me, it was the easiest to deal with.

(For years I had to get the otherwise open source CD player I used in binary form so it could be statically linked against Motif by the person building it, since we didn't have Motif dynamic libraries. Am I still bitter about what commercial Unix vendors did with extra-cost bits? Yes.)

@xssfox @isomer This is also very common behavior in all sorts of BTLE based sensors involved in bicycling (and I think often running). You can typically roll up beside a cyclist and pair with their heart rate monitor or whatever, with the only limit being that some cheap HRMs only talk to one BT device at a time and their HRM is probably already talking to their phone or GPS device.

(I sometimes wonder if this actually happens in pro cycling, where knowing competitor stats could be useful.)

@ben @dwenius How obsessed were the people running undergrad computing? Well, at least in first year undergrad you got a shell that didn't support running things in the background. (I can't remember if later years got '&' plus (small) process limits or if the no-background stuff stayed.)