siebenmann

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'm the author of the linked-to article.)

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.

(I'm the author of the linked-to entry.)

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.

(I'm the author of the linked to article.)

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.

(I am the author of the original article.)

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.

(I am the author of the linked-to article.)

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').

(I am the author of the linked-to entry.)