The history of /sbin and /usr/sbin goes back well before Linux even existed, and a Linux-only filesystem hierarchy convention really does not provide an adequate guide to it and the really complex way, which is not the same from operating system to operating system, that the world reached the way that things are today. There's no clue there, for example, to the history such as the /usr/etc to /usr/sbin move in AT&T System 5, or the /etc to /usr/etc move that preceded that.
Fun fact: /usr/lbin was still to be found on HP-UX at the time of that edition of Frisch's book; although it had dropped out of official mention in AT&T System 5 between Release 3 and Release 4.
I have observed WWW browsers doing HTTPS lookups in my server logs, in 2025. Bad actors do them as well.
The sad thing is that the HTTPS resource record type will not upgrade HTTP directed to one domain into HTTPS directed to another domain. The RFC's examples (in section 10 and elsewhere) indicate that this should work. I made one of my WWW sites inaccessible to several modern WWW browsers for a day learning that in practice it does not.
One could view this as malicious compliance with section 9, as WWW browser writers have a decades long history, including the famous Chrome, Mozilla, and WebKit bugs, of fighting against DNS mechanisms that fix the apex problem.
A more charitable view is that, this being the 2020s, they simply did not give much attention to the case of HTTP. The idea exists on paper in the RFC, but in practice I wonder whether I am one of just a few people who has actually tried apex aliasing from HTTP to HTTPS (as opposed to aliasing from HTTPS to HTTPS).
See the PBS SpaceTime explanation hyperlinked-to elsethread and then the Physics StackExchange one. Gravity "pulling on" rock and water differently is a misleading explanation, and really an attempt to tweak an explanation that is bad to start with.
Tidal forces are fictitious forces that are what orbital mechanics look like in the accelerated frame of reference of the thing doing the orbiting. They are not a uniform "pull" in a single direction. That will get you to the idealized Waterworld explanation of PBS SpaceTime. What will get you further is the realization that PBS SpaceTime is almost on-point with the "assume a perfectly spherical cow" joke, which is where the Physics StackExchange explanation comes in, with the reality that the water is moving around and over the rock and that it's a lot more complex.
Which then gets you to Tom Scott and part of Cornwall rising and falling twice per day. (-:
There's a whole subculture for fonts smaller than 8 by 8, with real world uses for things such as small LED displays, for example. This is at the extreme end, though.
That’s really more of an encoding than a typeface. Like ASCII and Unicode.
But I guess if you can build fonts that generate barcodes, and fonts that have LLMs built in, then you could design a 1 pixel high font that uses Morse code to represent most ASCII characters.
I wonder if there are really tiny fonts that make use of color. For example, this 2-pixel wide Picket Right font could theoretically be even thinner if we were to use sub-pixel features.
At least, I think the 2-pixel high Two Slice font can be more legible with some anti-aliasing.
Don’t stop at colors. Just add a ligature for every string and support for animations and you have yourself a font that can render any alphanumeric string in a single pixel. I’ll need to brush up on Morse code though.
With the gap, it's effectively three pixels wide. Basically a 3x5 font with one pixel chopped off.
On some displays, you can also divide RGB into three subpixels (R, G, and B stripes). A 3x5 pixel font (9x5 subpixels) can be drawn as a 6x5 subpixel font instead (a 2x5 pixel font).
Not sure about one font vs the other, but that one seems easiest to read from a highly oblique angle since that makes it look more similar to what it would do if half wasn't missing... Unless I'm just gaslighting myself and find it easier to read that way because I was expecting that it would be easier!
Pad grid controllers like the Novation Launchpad, and its indie, open-source counterpart, Mystrix Pro, have an 8x8 grid. At first this style of controller didn't use any lights, but as the manufacturing and features progressed, they went towards one RGB LED per pad. So, of course, you end up doing some text and graphics on the resulting grid. Mystrix uses a scrolling marquee which isn't ideal, but does get the job done.
And yeah, you could throw on more hardware to have a display nearby and use that for text. That is not the problem being solved though.
By using the three available colors on my older model, I was able to render numbers up to 199 in a readable way. Two digits on the right are 8x3 and one on the left is 8x2. I quickly abandoned two pixels of width as impossible for making legible text for all digits, so seeing a full font at two pixels wide is a fun surprise.
In this case, they did communicate it, and the aforegiven Vogon reference is a mischaracterization. The naming convention is in the current IANA doco and Eggert copy.
Paul Eggert explained the continent/ocean plus largest city naming convention on a WWW page almost a quarter of a century ago. The WWW page was so well publicized that you can find its URL baked into at least four of the O'Reilly animal-cover books from the early 2000s.
You know, the tzdata people are quite haughty. They claim to store all that change, accurately, and yet here we are.
An example of this falsehood? Well, in the 70s my father convinced most of my hometown, at least the portions between Main St and Wharf, that DST was absurd.
For almost an entire year, this was observed.
Do you think they kept record in tzdata? I tried to convince them, but no! I still have some dateplanners my father had printed up, and even a picture of the sign that was out on the road (to alert visitors!).
But no!
Do not trust the tzdata people. As you can see, they are not so accurate.
Once upon a time I stumbled upon a small book of maps showing the time zones in Indiana each year in the mid-20th century. It was fascinating to see how various towns and cities would jump back and forth between Eastern and Central year to year, with little regard for the surrounding rural areas.
I frequently kick myself for losing track of that book.
You are just not providing sufficient proof. Think Wikipedia style proof. The fact that DST is or isn't observed should be published in a real book. A random dude printing some date planners or putting up a sign to be photographed isn't enough proof.
It seems like they're being pragmatic, not haughty:
> "The tz database is not authoritative, and it surely has errors. [...] Errors in the tz database arise from many sources: Sometimes, different people in the same city maintain clocks that differ significantly. [...] Even if the time is specified by law, locations sometimes deliberately flout the law. [...] Any attempt to pass the tz database off as the definition of time should be unacceptable to anybody who cares about the facts."
This does not trace things back far enough. The root is where IANA has long since segregated out a set of timezone file names into a "backward" collection:
If one traces references, one finds this connected bug on Launchpad. Amusingly to anyone who has ever seen these sweeping timezone database changes over the years, Launchpad marked it as "This bug affects 1 person.".
All of the US/* timezone names, such as US/Pacific here, have been backwards compatibility measures in place for the whole of the 21st century and some of the late 20th. The Olson database in the 1980s (mod.sources v08i085, comp.sources.unix v14i030) used these names. But the naming scheme changed somewhen in the 1990s to a continent/city and ocean/city form and backwards compatibility with the old names has been preserved ever since by the "backward" file.
reply