One reason why Unix quotas are generally not maintained and imposed by path is that it's a lot easier to update quotas as things are created, deleted, modified, and so on if the only thing that matters for who gets charged is some attribute of the inode, which you always have available. This was especially the case in the 1980s (when UCB added disk quotas), because that was before kernels tracked name to inode associations in RAM the way they generally do today. (But even today things like hardlinks raise questions.)
I've made a PDF of one of my bike club cue sheets from 2014 and put it at https://www.cs.toronto.edu/~cks/tbn/tbn-gatineau-gallop-2014... ; the GPS route that is more or less equivalent to it is https://ridewithgps.com/routes/28370340 (there may be minor differences because the route is more modern than the cue sheet, but it will give you orientation). The cue sheet is written for a group ride (where the group will stay together) and for people familiar with Toronto, so it might be challenging to follow solo unless you were already somewhat familiar with the ride (as the ride leader is expected to be).
The cue sheet is structured the way it is because it's expected it will be folded in half horizontally to fit in a map/cue sheet holder, and perhaps vertically as well (if people have a small holder; you fold vertically first, initially hiding the entire right column since you only need it after lunch, then horizontally). Cue sheet holders typically let you flip them up to see the back, so the exact division of a horizontal fold doesn't have to be perfect. Each numbered section covers a (relatively) distinct section of the ride to make it easier to keep track of where you are in the cue sheet overall.
Cue sheets for different circumstances need different sorts of structure. For example, for some cue sheets it would be quite important to include the distance (cumulative and/or from the previous cue). In others, such as this one, individually numbered cues and distances to them are mostly distractions.
(I'm the author of the linked-to blog entry, and as you can tell I have Opinions on cue sheet design.)
In 1989, the costs appear to have been significantly different, although on a casual search I don't see list prices for eg then-older Sun models like the 3/60. A brand new Sparcstation 1 (also 1989) was far more expensive than an NCD 16 or NCD 19, and a diskless Unix workstation would need more server support and disk space than an X terminal. Today is a different thing, but that's because PC prices have dropped so dramatically.
Pricing and charging for storage inside an organization is always ultimately a non-technical decision that has to balance who pays for it versus the consequences of it not being paid for. This is especially the case within organizations like universities, which have unusual funding and funding patterns (for instance, one time capex is usually much easier than guaranteed ongoing opex). We (the people providing the disk storage) know that there are ongoing costs to doing so, but the non-technical decision has been made to cover those costs in other ways than charging professors on a recurring basis.
The problem with allocating bit-packed storage is that then you are into the issue where types don't agree on where any pointers are. Interface values solve this today because they are always mono-typed (an interface value always stores two pointers), so the runtime is never forced to know the current pointer-containing shape of a specific interface value. And the values that interface values 'contain' are also always a fixed type, so they can be allocated and maintained with existing GC mechanisms (including special allocation pools for objects without pointers and etc etc).
I agree with you about the overall motivation for Rust-style enums. I just think it's surprisingly complex to get even the memory efficiency advantages, never mind anything more ambitious.
Interfaces aren't bit-packed and they force storing all values as a separate allocation that the interface contains a pointer to (escape analysis may allow this separate value to be on the stack, along with the interface itself). I believe that Go used to have an optimization where values that fit in a pointer were stored directly in the interface value, but abandoned it, perhaps partly because of the GC 'is it a pointer or not' issue. In my view, some of what people want union types for is exactly efficient bit-packing that uses little or no additional storage, and they'd be unhappy with a 'union values are just interface values' implementation.
Because of our (work) situation, I was thinking of an OOB network with its own dedicated connections between sites, instead of the situation where you can plug each site into a 'management' Internet link with protection for your management traffic. However, once your management network gets into each site, the physical management network at that site needs to worry about redundancy if it's the only way to manage critical things there. You don't want to be locked out of a site's router or firewall or the like because a cheap switch on the management network had its power supply fail (and they're likely to be inexpensive because the management network is usually low usage and low port count).
In a lot of environments, you can at least choose to restrict what networks can be used to manage equipment; sometimes this is forced on you because the equipment only has a single port it will use for management or must be set to be managed over a single VLAN. Even when it's not forced, you may want to restrict management access as a security measure. If you can't reach a piece of equipment with restricted management access over your management-enabled network or networks, for instance because a fiber link in the middle has failed, you can't manage it (well, remotely, you can usually go there physically to reset or reconfigure it).
You can cross-connect your out of band network to an in-band version of it (give it a VLAN tag, carry it across your regular infrastructure as a backup to its dedicated OOB links, have each location connect the VLAN to the dedicated OOB switches), but this gets increasingly complex as your OOB network itself gets complex (and you still need redundant OOB switches). As part of the complexity, this increases the chances an in-band failure affects your OOB network. For instance, if your OOB network is routed (because it's large), and you use your in-band routers as backup routing to the dedicated OOB routers, and you have an issue where the in-band routers start exporting a zillion routes to everyone they talk to (hi Rogers), you could crash your OOB network routers from the route flood. Oops. You can also do things like mis-configure switches and cross over VLANs, so that the VLAN'd version of your OOB network is suddenly being flooded with another VLAN's traffic.
The obvious advantage of using domain names and in general URLs as the package names is that the Go project doesn't have to run a registry for package names. Running a registry is both a technical and especially a political challenge, as you must deal with contention over names, people trying to recover access to their names, and so on. By using URLs, the Go project was able to avoid touching all of those issues; instead they're the problem of domain name registries, code hosting providers, and so on.
My badly communicated overall point is that I don't think it's right to say that Go started without any thought about dependency management. Instead, the Go developers had a theory for how it would work (with $GOPATH creating workspaces), but in practice their theory didn't work out (for various reasons). For me, this makes the evolution of Go modules much more interesting, because we can get a window into what didn't work.
(I'm the author of the linked-to entry. I wrote the entry because my impression is that a lot of modern Go programmers don't have this view of pre-module Go, and especially Go when you had to set $GOPATH and it was expected that you'd change it, instead of a default $HOME/go that you used almost all the time.)
Based on an extremely quick skim, this appears aimed only at projects that are using autoconf purely for portability across standard Unix environments. It admits up front that it drops features that people find valuable about configure, like --prefix et al and the entire feature selection cluster of options (now you have to edit Makefiles, which has various issues), and it appears to have nothing for projects that need their own checks for additional features of the environment (OpenZFS being an extreme example). If I was being unkind, I would say it's an autoconf replacement for people who don't need autoconf to start with (and don't care about --prefix et al).
There is an ecological niche for 'you don't need autoconf' (and don't care about aspects it gives you for free), just like there's an ecological niche for 'you don't need Javascript', but I don't think it's a significant one.
NFS v2 writes are all synchronous. NFS v3 added an option to make them asynchronous, along with an additional 'COMMIT' NFS operation that flushes them to storage. In theory how it works is an NFS v3 client sends some number of async writes, holding a copy of their data in its own memory, and then sends a COMMIT to flush them all. If the NFS server replies to the COMMIT with an error, the NFS client has to re-send those async writes and their data (possibly as sync writes this time around); otherwise, it can discard its copy of the written data. NFS v3 clients can still decide to send sync writes if they don't want to keep track of all of this on their end for some reason (including low memory to hold the write data locally). And an NFS v3 server can opt to immediately write out theoretically 'async' writes for similar reasons. All of this is still true in NFS v4, with I think even more elaborations on the theme.
(I'm the author of the linked-to article and I have a long-standing interest in weird NFS behavior, since we operate NFS servers.)
The publishing system takes some pains to provide an accurate last-modified value for HTTP caching purposes (and an ETag too); internally it tracks the most recent modification time of all components that go into the page as it's (dynamically) assembled from various pieces.
(I am the author of the linked-to article and also the author of the software it's running. Said software also has (on-disk) caching, but that's not why the last-modified is back in December of last year.)
The current directory is a long-standing Unix concept, so you'd have to trace its history back quite far to hear arguments about why it was there. One obvious reason is that relative paths are convenient for all sorts of reasons and they require a point to be relative to, which is basically 'the current directory' in some form.
The kernel knowing the name for the current directory is not specific to current directories; it is part of a general system of caching the name mappings for directory entries ('dnodes' in Linux, a 'name cache' in FreeBSD). Unix kernels added these caches because Unix programs spend a lot of time looking up names, making the operation worth optimizing in general. Once you have a general name cache, you might as well pin the entries for actively used entities like current directories and open files so that they don't get expired out of the cache and you always know (some) name for them.
(One useful complexity of name caches is that you can cache negative entries, ie that a given name is not present in a directory. In the modern Unix shared library environment where shared libraries may be probed for in a whole collection of directories every time a program starts up, I suspect this saves a nice chunk of kernel CPU time.)
In this case, one reason to use printenv is that it is an external command, and so it is clearly and unambiguously seeing (and reporting) whatever the Bourne shell would export into the environment for a real command. In this specific case, it appears that set does not report such single-command variables (whether or not they have a value, eg 'FRED=barney set | grep FRED').
Oops, my fallible memory bit me. We weren't specifically running into OOM, but into strict overcommit (which we had turned on on some machines). OOM will only kill big things, so it would be weird for bash (as /bin/sh) or small Python programs to get killed off. But strict overcommit favors already running things (who've already claimed their memory) over newly started cron jobs.
(You could criticize the shell for needing to do dynamic allocation in failure paths and so being exposed to malloc() failing, but this is a hard area and lots of code assumes it can malloc() on demand, some of it in the C library.)
We used to use this sort of locking in (frequently running) system cron jobs and the like. Then these jobs started getting killed off by Linux OOM on some systems and we ran into the downsides of locks that don't automatically clear if something goes wrong, and switched to flock(1) based locks (fortunately on the local system, so we're not affected by NFS issues there).
I think it's more that Linux root stores date from an era when everyone approached CA trust as a binary thing (even browsers), and there has never been enough pressure and coordination to evolve them into a more complex system, unlike browsers. My memory is that browsers added conditional distrust and conditional limits on CAs and various similar things when they became convinced that it would be too bad of a user experience to simply remove CAs but also too dangerous to retain them in fully empowered form. Having conditional distrust also gave browsers more power over CAs, because now browsers had more options for dealing with marginal but (semi-)popular ones.
Chrome and Safari require that TLS certificates include cryptographic promises of future log inclusion ('SCTs') from N trusted CT logs. As far as I know, neither of them actually contact the log's API endpoints to make sure that this has gone through, but in practice IMHO it's not much of a security gap for various reasons.
A multi-node Prometheus setup is significantly more complex to design and operate than a Linux software RAID mirror, especially once you throw in Grafana, Alertmanager, and so on. Distributed anything makes it harder. The layer 7 may 'support' this, but it's not a plug and play setup.
(I'm the author of the linked-to article.)