As part of writing yesterday's entry ,I wound up wanting to read the 4.3 BSD ifconfig manpage ,which is online as part of the 4.3 BSD source tree at tuhs.org . More exactly, I wanted to see more or lesshow it had originally looked in formatted form, because in sourceform the bit I was interested in wasn't too readable:

.TP 15.BI netmask " mask"(Inet only)Specify how much of the address to reserve for subdividing

If you've been involved in networking (well, Internet and IPnetworking at least), you've probably heard and used the term'subnet' and 'subnets'. As a term, subnet has a logical andcompletely sensible definition, and certainly the direct meaningis probably part of why we wound up with the term. If you've beenaround networking a while, you've probably also heard of 'CIDR'notation for networks, for example 192.168.

Yesterday I covered how on Illumos and Solaris, disks in ZFS poolshave three names ; the filesystem path,the 'physical path' ( a PCI device name , similar to the informationthat lspci gives), and a 'devid', with the vendor, model name,and serial number of the disk. While these are Solaris concepts,Linux has similar things and you could at least mock up equivalentsof them in the kernel.

ZFS on Linux doesn't try to do this. Instead of having three

I sort of mentioned yesterday that ZFS keepsinformation on several different ways of identifying disks in pools.To be specific, it keeps three different names or ways of identifyingeach disk. You can see this with ' zdb -C ' on a pool, so here'sa representative sample:

# zdb -C rpool

MOS Configuration:[...]  children[0]:    type: 'disk'    id: 0    guid: 155578534329725

If you import a ZFS pool explicitly, through ' zpool import ', theuser-mode side of the process normally searches through all of theavailable disks in order to find the component devices of the pool.Because it does this explicit search, it will find pool deviceseven if they've been shuffled around in a way that causes them tobe renamed, or even (I think) drastically transformed, for exampleby being dd 'd to a new disk. This is pretty much what you'd

When I wrote up imposing temporary CPU and memory limits on auser on Ubuntu 16.04 , I sort of discoveredthat I had turned on per-user fair share CPU scheduling as a sideeffect, although I didn't understand exactly how to do thisdeliberately. Armed with a deeper understanding of how to tellif fair share scheduling was on , I've nowdone a number of further experiments and I believe I have definitiveanswers. This applies only to Ubuntu 16.04 and

A couple of weeks ago, a reasonably popular Chrome extension wasstolen and infested with adware . If you're familiarwith Google, you know what happened next: nothing. As people sentup frantic smoke signals and attempted to recover or at leastde-adware a popular extension, Google was its usual black hole self.Eventually, sufficient publicity appears to havegotten Google to do something, and they even did the right thing.

In the process of reading about this, I discovered a couple ofthings. First

I've recently been writing some Go code that heavily uses and mutatesslices, mostly through append() , often slices passed as arguments tofunctions that then returned what were theoretically different, mutatedslices. This left me uncertain that both I and my code were doing theright thing or if I was creating hidden bear traps for myself.

So let's start out with some completely artificial example code:

func test1(h string, hl []string) []string {  return append(hl,

I wrote recently on putting temporary CPU and memory limits on auser , using cgroups and systemd's features tofiddle around with them on Ubuntu 16.04. In the process I wound upconfused about various aspects of how things work today. Since thenI've done a bit of digging and I want to write down what I've learnedbefore I forget it again.

The overall cgroup experience is currently a bit confusing on Linuxbecause there are now two versions of cgroups, the original (