I follow a number of projects written in Go that are hosted onGithub. Many of these projects enable Github's "Dependabot" feature ( also ). This use of Dependabot,coupled with the overall Go ecology's habit of relatively frequentsmall updates to packages, creates a constant stream of Dependabotcommits that update the project's go.mod and go.sum files with smallversion updates of some dependency, sometimes intermixed with peoplemerging those commits (for example, the Cloudflare eBPF Prometheusexporter ).

In the comments of my entry on the general problem of losingnetwork based locks , an interestingside discussion has happened between commentator abel and me overNFS servers (not) supporting the Unix O_APPEND feature. Themore I think about it, the more I think it's non-trivial to supportwell in an NFS server and that there are some subtle complications(and probably more than I haven't realized). I'm mostly going torestrict this to something like NFS v3, which

NFS is a network filesystem that famously also has a network lockingprotocol associated with it (or part of it, for NFSv4). This meansthat NFS has to consider the issue of the NFS client losing alock that it thinks it holds .In NFS, clients losing locks normally happens as part of NFS(v3)lock recovery , triggered when a NFS serverreboots. On server reboot, clients are told to re-acquire all oftheir locks, and this re-acquisition can explicitly fail (

There are many situations and protocols where you want to hold some sortof lock across a network between, generically, a client (who 'owns'the lock) and a server (who manages the locks on behalf of clients andmaintains the locking rules). Because a network is involved, one of thebroad problems that can happen in such a protocol is that the client canhave a lock abruptly taken away from it by the server. This can happenbecause the server was instructed to break the lock, or

Physical machines can generally be set in their BIOS so that ifpower is lost and then comes back, the machine returns to itsprevious state (either powered on or powered off). The actualmechanics of this are complicated ( also ), but the idealizedversion is easily understood and convenient. These days I have arevolving collection of libvirt based virtual machines running ona virtualization host that I periodically reboot due to things likekernel updates, and for a while I have quietly wished for some sortof similar libvirt setting

One of the somewhat obscure features of Unix is that the kernel hasa specific interface to get (and set) the 'window size' of yourterminal, and can also send a Unix signal to your process when thatsize changes. The official POSIX interface for the former is tcgetwinsize() ,but in practice actual Unixes have a standard tty ioctl for this, TIOCGWINSZ (seeeg Linux ioctl_tty(2) ( also ) or FreeBSD tty(4) ). Thesignal is officially standardized by POSIX

Over on the Fediverse, I said something unpopular about IPv6 and NAT :

Hot take: NAT is good even in IPv6, because otherwise you get intorecursive routing and allocation problems that have been made quitethorny by the insistence of so many things that a /64 is the smallestblock they will work with (SLAAC, I'm looking at you).

Consider someone's laptop running multiple VMs and/or containers onmultiple virtual subnets, maybe playing around with (virtual) IPv6routers

For years now, all sorts of Unixes have been able to support betterpassword 'encryption' schemes than the basic old crypt(3) salted-mutant-DES approach that Unix started with (these days it'susually called 'password hashing'). However, the support for specificalternate schemes varies from Unix to Unix, and has for many years.Back in 2010 I wrote some notes on the situation at the time ; today I want to look at the situationagain, since password

The Linux login passwords that wind up in /etc/shadow can beencrypted (well, hashed) with a variety of algorithms, which youcan find listed (and sort of documented) in places like Debian'scrypt(5) manual page .Generally the choice of which algorithm is used to hash (new)passwords (for example, when people change them) is determined byan option to the pam_unix PAMmodule.

You might innocently think, as I did, that all of the algorithms