Seriously using virtualization clashes with our funding model
In a comment on my entry on us needing to get experience with Ubuntu 20.04, Miksa pointed out the advantages of investing heavily in virtualization. These definitely exist, but among other practical issues, heavy investment in virtualization clashes with our funding model, which you could describe as 'erratic' or 'nonexistent'. Our equipment funding is quite erratic and as a result we have to buy stuff mostly in bursts.
A significant commitment to and investment in virtualization really calls for big servers, ones that have a lot of memory and CPUs to support a lot of virtual machines at once (and possibly a lot of storage, or a very fast storage network). Big servers are expensive and you have to spend that money all at once, both the initial purchase and their replacement when they reach their (finite) sensible operating lifetime. Periodic big investments on big VM host servers may well cost less overall than a series of smaller but more spread out investments on physical servers, but they require you to have large sums of money available at predictable times. Unfortunately, we don't.
(There's an alternate model of lots of smaller virtualization hosts with fewer VMs on each host, but it's not what people talk about or recommend.)
This is the same effect I've seen before with network routers and switches, where buying a highly capable but expensive router doesn't make sense for us. With routers and switches we're better off with a bunch of smaller switches than trying to do everything in a few big units, because we can buy and replace them piece by piece. The same is true for us with virtualization servers, at least in the conventional model of them. Our funding model is mostly incompatible with periodic big purchases.
(We've been surprisingly good at turning over our fileserver infrastructure more or less on schedule, but that has traditionally had a natural forcing function because hard drives wear out. Even then we pushed one fileserver generation alarmingly far, to the point where we saw significant drive failure rates.)
PS: This funding issue isn't solved by using someone else's host infrastructure so that we pay this as an ongoing smaller operating cost instead of a periodic hardware purchase cost. We don't have reliable money for cloud operating costs either, and that can be a worse problem.
Getting the git tags that are before and after a commit (in simple cases)
When I investigate something in a code base, I often wind up wanting
to know when a particular change became available in a release, or
in general to know when it was made in terms not of time but of
releases. Using release dates is both not reliable (since a change
can land early in a side branch and then be merged into mainline
only much later) and a certain amount of pain (you have to look up
release dates somewhere). For git-based projects, my general approach
so far has been to fire up
gitk, put in the SHA1 of the commit I
care about, and see what gitk says it was Before and After.
As it turns out, there is a better way to do this with Git command
line tools, with '
(as I found out when I bothered to do some Internet searches). For
my future reference, the two commands I want to get the tag before
and after a commit are:
; git describe f3a7f6610f zfs-0.6.3-49-gf3a7f6610 ; git describe --contains f3a7f6610f zfs-0.6.4~197
I was already sort of familiar with the first form of 'git describe', because various projects I build use it to automatically generate identifiers for what I'm building. The second form is new to me, as is the '~<count>' that means 'so many commits before tag <X>'.
I imagine that there are all sorts of complex git tree states that can make this question harder to answer. Fortunately I don't think I deal with any projects that might give me that sort of heartburn; the ones where I care about this question like relatively linear git histories.
PS: I don't know how git is establishing what tag is the most recent before a commit or the first after one, but I trust it to basically work. This is where I start having to look up the difference between plain tags and annotated tags, and other stuff like that (cf).