The limitations on find's -exec option and implementation convenience
In my entry on how find mostly doesn't need xargs nowadays , I noted that in '-exec ... {} +', the '{}'(for the filenames find was generating) had to come at the end.In a comment on that entry, an anonymous commentator noted thatthis didn't apply to the -exec version that runs a separate commandfor each filename; with it, you can put the substituted filenameanywhere in the command. This appears to be not just
I wish every program that wanted 'a SQL database' would let me use SQLite
There are, out in the (open source) world, a lot of programs thatwant to use a SQL database but aren't all that picky about whichone; for instance, there are a lot of programs that will work witheither MySQL or PostgreSQL (which one they recommend can vary). Asa sysadmin, I wish all of these programs would also let me use SQLite . Frankly, everythingshould have an option to use SQLite as its SQL database if at allpossible.
Why I want this
Illustrating the importance of fully multi-core program building today
I have an enduring interest in comparing the from scratch Firefox buildtime on my office AMD machine and my homeIntel machine , which are from the same era andhave very similar configurations but drastically different Firefox buildtimes . One ofthe things that I have noticed about the difference, and about buildingFirefox in general, is, well, I will quote my tweet :
One major area where the Firefox Nightly build takes longer on my AMDmachine than on my Intel one is the end stage of building the Rustwebrender,
Forecasting drive failures is not always as useful as it sounds
Recently, I said that we've found a SMART attribute that canpredict SSD failures in our environment (and it later did predict the failure of one more SSD ). Thissounds great, but in practice it's turned out to be less usefulthan it might seem. The reason for this is pretty simple; supposingthat we have a good indication that a drive is going to fail atsome time in the future, but not when, what should we do about it?
(I'm going
Making tracking upstream Git repositories a bit quieter
I track a bunch of upstream Git repositories, where by 'track' Imean that I keep a local copy and update it periodically. By now Ihave enough of these tracking repositories that updating them allwith a straightforward ' git pull --ff-only ' ( sometimes throughan alias ) is increasingly noisy, with too muchoutput. This is especially so for the most active repositories,such as my copy of the Linux kernel; a normal ' git pull ' on theLinux kernel can easily produce more
find mostly doesn't need xargs today on modern Unixes
I've been using Unix for long enough that 'find | xargs' is a reflex.When I started and for a long time afterward, xargs was your onlychoice for efficiently executing a command over a bunch of find results. If you didn't want to run one grep or rm or whateverper file (which was generally reasonably slow in those days), youreached for ' find ... -print | xargs ... '. There were somegotchas in traditional xargs usage , and
Time for Python 2 users to make sure we have a copy of Pip and other pieces
The news of the time period is that as the Pip developers said theywould, the just released Pip 21.0 has dropped support for Python2 ( via ). Intheory this doesn't matter for modern users of Python 2.7, becausePython itself should ship with a bundled version of pip so that youdon't have to install one from scratch. In practice, some Linuxdistributions split the pip command off into a separate sub-packageand no longer make a Python 2 version available
Thinking through what can go badly with databases on ZFS
Famously, if you're running a database with its storage on ZFS andyou care about performance, you need to tune various ZFS parametersfor the filesystem (or filesystems) that the database is on. Youespecially need to tune the ZFS recordsize property; generallypeople will say that if you change only one thing, you should changethis to be either the same size as your database's block size orperhaps twice its size. But this raises a question for a certainsort of person, namely what goes
Your monitoring and alerts remember things for you
On Twitter, I said :
Sure, this TLS certificate expires in 2030, and we might well not evenbe using the service it's for in five years. But that just makes itmore important to monitor its expiry time; a decade is easily longenough for us to completely forget about the issue.
( There's a story behind my action .)
Just like scripts remember things for you , so doalerts and monitoring in general. It's vaguely possible that we'd
SMART Threshold numbers turn out to not be useful for us in practice
I was recently reading Rachel Wenzel's Predicting Hard DriveFailure with Machine Learning ,and one of the things it taught me is that drive vendors, as partof their drive SMART data, provide a magical 'threshold' number that is supposed toindicate when a SMART attribute has reached a bad value. This isnot compared to the raw SMART value, but instead a normalized 'value'that is between 253 (best) and 1 (worst). We collect SMART data forall of our drives