Two reasons why Unix traditionally requires mount points to exist
Recently on the Fediverse, argv minus one asked a good question :
Why does #Linux require #mount points to exist?
And are there any circumstances where a mount can be done without apre-existing mount point (i.e. a mount point appears out of thin air)?
I think there is one answer for why this is a good idea in generaland otherwise complex to do, although you can argue about it, andthen a second historical answer based on how mount points wereinitially implemented.
We can't really do progressive rollouts of disruptive things
In a comment on my entry on how we reboot our machines right afterupdating their kernels ,Jukka asked a good question:
While I do not know how many machines there are in your fleet, Iwonder whether you do incremental rolling, using a small snapshot forverification before rolling out to the whole fleet?
We do this to some extent but we can't really do it very much. Thecore problem is that the state of almost all of our machines isdirectly visible and exposed to people . Thisis
We don't update kernels without immediately rebooting the machine
I've mentioned this before in passing ( cf , also ) but today I feel like saying itexplicitly: our habit with allof our machines is to never apply a kernel update without immediatelyrebooting the machine into the new kernel. On our Ubuntu machinesthis is done by holding the relevant kernel packages; on my Fedoradesktops I normally run 'dnf update --exclude "kernel*"' unless I'mwilling to reboot on the spot.
The obvious reason for this is that we want to switch
We (I) need a long range calendar reminder system
About four years ago I wrote an entry about how your SMART drivedatabase of attribute meanings needs regular updates . That entry was written on theoccasion of updating the database we use locally on our Ubuntu servers, and at the time we were using amix of Ubuntu 18.04 and Ubuntu 20.04 servers, both of which hadolder drive databases that probably dated from early 2018 and early2020 respectively. It is now late 2025 and we use
We need to start doing web blocking for non-technical reasons
My sense is that for a long time, technical people (systemadministrators, programmers, and so on) have seen the web as somethingthat should be open by default and by extension, a place where weshould only block things for 'technical' reasons. Common technicalreasons are a harmful volume of requests or clear evidence of malignintentions, such as probing for known vulnerabilities. Otherwise,if it wasn't harming your website and wasn't showing any intentionto do so, you should let it pass
I wish SSDs gave you CPU performance style metrics about their activity
Modern CPUs have an impressive collection of performance countersfor detailed, low level information on things like cache misses,branch mispredictions, various sorts of stalls, and so on; on Linuxyou can use 'perf list' to see them all. Modern SSDs (NVMe, SATA,and SAS) are all internally quite complex, and their behavior underload depends on a lot of internal state. It would be nice to haveCPU performance counter style metrics to expose some of thosedetails. For a relevant example that'
A (filesystem) journal can be a serialization point for durable writes
Suppose that you have a filesystem that uses some form of a journalto provide durability (as many do these days) and you have a bunchof people (or processes) writing and updating things all over thefilesystem that they want to be durable, so these processes are allfsync()'ing their work on a regular basis (or the equivalent systemcall or synchronous write operation). In a number of filesystemdesigns, this creates a serialization point on the filesystem'sjournal.
This is related to
NVMe SSDs and the question of how fast they can flush writes to flash
Over on the Fediverse, I had a question I've been wondering about :
Disk drive people, sysadmins, etc: would you expect NVMe SSDs to beappreciably faster than SATA SSDs for a relatively low bandwidthfsync() workload (eg 40 Mbytes/sec + lots of fsyncs)?
My naive thinking is that AFAIK the slow bit is writing to the flashchips to make things actually durable when you ask, and it's basicallythe same underlying flash chips, so I'd expect NVMe to
The strange case of 'mouse action traps' in GNU Emacs with (slower) remote X
Some time back over on the Fediverse, I groused about GNU Emacstooltips . Thatgrouse was a little imprecise; the situation I usually see problemswith is specifically running GNU Emacs in SSH-forwarded X fromhome , which has a somewhathigh latency. This high latency caused me to change how I openedURLs from GNU Emacs , and itseems to be the root of the issues I'm seeing.
The direct experience I was having with tooltips was that being ina situation where Emacs might want to show a
Staring at code can change what I see (a story from long ago)
I recently read Hillel Wayne's Sapir-Whorf does not apply toProgramming Languages ( via , which Iwill characterize as being about how programming can change how yousee things even though the Sapir-Whorf hypothesis doesn't apply(Hillel Wayne points to the Tetris Effect ). As it happens, longago I experienced a particular form of this that still sticks in mymemory.
Many years ago, I was recruited to be a TA for the university'supper year Operating Systems course, despite being an