The tangled problems of asking for people's '(full) legal name'
One response to my entry on the problems with 'first' and 'last'name data fields isthat one should make forms that (only) ask for someone's legallyrecognized name, which should be unambiguous and complete. Whilesuperficially appealing, this is a terrible minefield that youshould never step into unless you absolutely have to, which isgenerally because you are legally required to collect this information.
The first question is what you mean by legally recognized name or'legal name'. I have several pieces
Getting my backup Internet connection through BlueTooth on Linux
Suppose, not entirely hypothetically , that your normalDSL Internet connection is down (for example, because the localphone company did something to your line and hasn't fixed it yet),and you need to get Internet by tethering your Linux desktopmachine to your smartphone . The easiest way to do this is to beusing a modern Linux desktop along with NetworkManager and so on;at that point you can basically click through the various GUIs toconnect to your phone's hotspot through wifi, a direct USB connection
Some problems with 'first name' and 'last name' fields in data
Over on the Fediverse, I said something :
This is my sad face that here in AD 2023, there are greenfieldprojects using 'first name' and 'last name' fields instead of 'givenname'.
(My use of 'given name' is a bit ambiguous here; you might say'normal name', or just 'name'.)
Patrick McKenzie's justly famous Falsehoods Programmers BelieveAbout Names is the obvious starting point for people who are new to these issuesin general
Browsers barely care what HTTP status code your web pages are served with
Back when I wrote an entry on issues around the HTTP status codefor a web server's default front page ,I said in passing that the HTTP status code mostlydoesn't matter to browsers. More exactly, the status code for a webpage mostly doesn't matter to people looking at web pages in abrowser ( this has come up before ). Thisis well known in some circles and probably surprising in others.
Certain HTTP status codes cause web browsers to do specific things;there are the
A program's (effective) log messages can have many sources
One of the things you could say about log messages from programsis that even a program doesn't want to commit to long term stabilityof its log messages ( which I think it shouldn't ),it should be able to document a list of the messages for anyparticular release. Then system administrators and other parties couldgo through the documentation with some confidence to build log parsingand matching rules for the current version.
(You can imagine plausible ways of collecting such a list, sincewe've already
Programs shouldn't commit to fixed and predictable log messages
When I wrote that monitoring your logs is mostly a tarpit , I said that logs are functionallyunstructured. I didn't mean this just in the sense that many programlogs are either unstructured text messages or custom formats; Imeant it in a deeper sense that the log messages and other informationis unpredictable. As peculiar as it might be for a system administratorto say this, I think that this unpredictability is a good thing andprograms should make at most very limited promises otherwise.
The simple problem with making promises
Good RPC systems versus basic 'RPC systems'
In my entry on how HTTP has become the default, universalcommunication protocol , I mentionedthat HTTP's conceptual model was simple enough that it was easy toview it (plus JSON) as an RPC (Remote Procedure Call) system. I sawsome reactions that took issue with this ( eg comments here ),because HTTP (plus JSON) lacks a lot of features of real RPC systems.This is true, but I maintain that it's incomplete, because there'sa difference between a good
Monitoring your logs is mostly a tarpit
One of the reactions to my entry on how systemd's auto-restartingof units can hide problems was a suggestion that we should monitor our logs to detect thingslike this. As it happens, one of my potentially unpopular views isthat monitoring your logs is generally a tarpit that isn't worthit. Much of the time you'll spend a great deal of effort to getvery little of worth.
The fundamental problem with general log monitoring is that logsare functionally unstructured. Anything can appear in them
How the rc shell handles whitespace in various contexts
I recently read Mark Jason Dominus's The shell and its crappyhandling of whitespace ,which is about the Bourne shell and its many issues with whitespacein various places. I'm a long time user of (a version of) TomDuff's rc shell ( here's why Iswitched ), which was written for Research UnixVersion 10 and then Plan 9 to (in part) fix various issues with theBourne shell. You might ask if rc solves these whitespace issues;my answer is
On Linux, NFS v4 mounts are a different filesystem type than NFS (v3) mounts
For more or less historical reasons, we currently use NFS v3 tomount filesystems from our fileservers .We're likely going to (slowly) move over to NFS v4 ( after successfulexperiments ), so I've been working on variouspreparations for that, such as making sure our automounter system doesn't specifically force NFS v3but instead leaves it up to the system to pick a version. In theprocess of this, I've discovered a surprise.
On Linux, NFS v4