Everything that uses configuration files should report where they're located

Here's something that I've come to strongly believe as a systemadministrator: if a program uses a configuration file (or several),it should have an obvious command line way to find out where itexpects to find that configuration file.

As a system administrator I deal with a lot of different programsthat use configuration files, most of which have their own normallocations for those files. Sometimes this is a system wide location,sometimes this is a per-user location, and some have both.


Go 1.21 will (probably) download newer toolchains on demand by default

For some time, Go modules have supportedspecifying the minimum version of Go required by the module in go.mod , through the go directive . Once you canhave modules that specify a minimum Go version, you have a designquestion of what should happen when an older version of Go triesto do something with a module that says it requires a newer versionof Go. Up through Go 1.20 (more or less), Go's answer was to goahead and try anyway. Starting in Go


I don't expect to see competitive RISC-V servers any time soon

Recently on the Fediverse, Dan Luu was dubious about a predictionthat RISC-V would take over in datacenters in the next 5 to 10 years ( here's theEETimes article being quoted from ).Much like Dan Luu, I was skeptical, considering that under nearlyideal circumstances AMD didn't make much of a dent . But let's takethis from the top, and ask what RISC-V would need and when if it'sgoing to do this.

(This is implicitly 6


Domination has a lead time

Suppose that someone makes a prediction like 'PCIE 5.0 will dominatethe datacenter in five years' (as a hypothetical example). If we'relooking at how likely this is and what would have to happen whenin order to get there, one important thing to remember is that domination has a lead time , and this lead time will shorten allof the timelines from what you might otherwise think. The ultimatecause of this lead time is the inertia of the installed base.

Let's take '


Having non-x86 machines makes your life harder, especially in a mixed setup

Here's a confession: while I like the idea of good non-x86 CPUs andmachines in theory, I don't really want to operate any of them inpractice. I especially don't want to operate them in a heterogeneousenvironment along side x86 machines.

The basic reason to avoid non-x86 if you have a choice is that x86is the dominant default, and today everything else is a relativeminority environment. My impression is that the 64


Failing to draw lines between 'script' and 'program'

A while back on the Fediverse April King ran a poll on 'script'versus 'program' .In a reply, I fumbled around with my vaguely formed views :

I voted complex/simple but I think it's more complicated for me inpractice. Something in a compiled language is always a 'program'; alarge or complex thing is always a 'program', even for interpretedlanguages in a single file. Maybe a script mostly needs to dependon/use outside Unix programs, not internal


Link: The Difference Between Root Certificate Authorities, Intermediates, and Resellers

Andrew Ayer's The Difference Between Root Certificate Authorities,Intermediates, and Resellers is about exactly that issue in much more detail than what I wroterecently . Although Iknew some of the information in this article, other pieces werenew to me.

Also very relevant to this area is Ayer's earlier The SSL CertificateIssuer Field is a Lie .This covers what it says in the title and is a fun read; the rabbit holegoes pretty deep.


One temptation of shell scripting is reusing other people's code

At one point I read Martin Tournoij's The shell scripting trap , and it sparkedsome thoughts in me about why shell scripting is forever temptingpeople. One of the reasons I see is the enduring appeal of codereuse, because as programmers we're often all lazy (and systemadministrators can be extra lazy because we have other things todo; programming is often a sideline).

Here I don't mean reusing code from other shell scripts, becauseyou can do that in any language. Where shell


Javascript modifying cut and paste can sometimes be a good thing in browsers

One of the famous problems of the Javascript enabled web is that peoplecan use Javascript to tamper with the behavior of cut and paste (whichis most commonly copy and paste). Even when people have relatively goodintentions, Javascript can mess this up in environments like 'smart'text editing ( and you can shoot yourselfin the foot with browser settings ).However, every so often people use this power to good effect. Recently,I had an illustration of this in Mastodon (the specific software that my Fediverse


CGIs combine well with Apache location-based access control

One of the things that we doevery so often is put together some little 'web application' thathas to be under some sort of access control or access restrictions.Even today, CGI scripts remain the easiest way to write and deploya simple web application ; you write a script inthe language of your choice and (with the right Apache configuration)put it in an appropriate place with an appropriate filename extension,and you're done. That leaves the access control.

For the access control, Apache (