Allocator Wrestling isa summary of Eben Freeman's talk from GopherCon 2018 on the Gomemory allocator ( via ,and see also )and its garbage collection system. The slides are here ( via )and have more details and elaborations on various things thanthe livebloged summary, although you probably want to read both(good talks are rarely entirely captured by their slides).

I love seeing under the hood of a complex system this way, and it'sprobably helped me move towards understanding some things

I've mentioned this in passing in a few places, so I might as wellsay it here: I've mostly given up on making Ubuntu bug reportsfor the simple reason that doing so seems to be useless . Everyso often I'll file one for no particularly strong reason ( eg ,which I'd actually forgotten I'd filed), but even when I do file abug I usually don't expect anything . When Isay that I don't expect anything, I

At this point, we've been running various versions of Ubuntu LTSfor over ten years. While we reinstall individual systems when wemove from LTS version to LTS version, we almost never rebuild ourlocal customizations from scratch unless we're forced to; insteadwe carry forward the customizations from the last LTS version, onlychanging what seems to need it. This is true both for the configurationof our systems and also for the configuration of things we buildon top of Ubuntu, such as our user-run

Go 1.11 comes with experimental support for modules , which are more or lessRuss Cox's 'vgo' proposal. Initial versions of this proposal werestrongly against Go's current feature of vendor directories and wanted tocompletely replace them. Later versions seem to have toned thatdown, but my impression is that the Go people still don't likevendoring very much.I've written before about my sysadmin's perspective on vendoringand vgo , where I wanted something that encapsulatedall of the

Our fileserver-based filesystems have a varying number of inodesin use on them, ranging from not very many (often on filesystemswith not a lot of space used) to over 5.7 million. Generally ourAmanda backups have no problems handling the filesystems with nottoo many inodes used, even when they're quite full, but the filesystemswith a lot of inodes used seem to periodically give our backups acertain amount of heartburn. This seems to be especially likelyif we're doing incremental backups instead

Sometimes, people show up with useful kernel-side things that wereoriginally written for other systems and try to put them into Linuxas (GPLv2) donations. Often these have been filesystems (SGI andXFS, IBM and JFS), but there have been other attempts at code drops.Most recently, Oracle made DTrace available under GPLv2 andintegrated it into their kernel . I've saidbefore that this is not an easy thing to do and can take years toactually get the code in to the

As an aside in yesterday's history of file type information beingavailable in Unix directories , Imentioned that it was possible for a filesystem to support thiseven though its Unix didn't. By supporting it, I mean that thefilesystem maintains this information in its on disk format fordirectories, even though the rest of the kernel will never ask forit. This is what ZFS does.

(One reason to do this in a filesystem is future-proofing it againsta day when your Unix might decide to

Once upon a time, Apple came very close to releasing ZFS as partof MacOS .Apple did this work in its own copy of the ZFS source base (as faras I know), but the people in Sun knew about it and it turns outthat even today there is one little lingering sign of this hoped-forand perhaps prepared-for ZFS port in the ZFS source code. Well,sort of, because it's not quite in code.

Lurking in the function that reads ZFS directories to

The two things that Unix directory entries absolutely have to haveare the name of the directory entry and its 'inode', by which wegenerically mean some stable kernel identifier for the file thatwill persist if it gets renamed, linked to other directories, andso on. Unsurprisingly, directory entries have had these since thedays when you read the raw bytes of directories with read() , and for a long time that was all they had; if youwanted more than the name and the inode number, you