About a year ago I wrote about my email mistake of minglingpersonal and work email together and how it made taking breaks from work rather harder. It may notsurprise you to hear that I have done nothing to remedy that situationsince then. Splitting out email is a slog and I'm probably nevergoing to get around to it. However, there are a couple of cheaptricks that I've decided to do for breaks and vacations (in fact Idecided on them last year, but never got around

I recently actually startedusing a pair of SSDs on my home machine, and as part of that I setup a ZFS pool for my $HOME and other data that I want to be fast( as planned ). Unfortunately, I recentlyrealized that when I set that pool up I made a mistake of omission.Some people who know ZFS can guess my mistake: I didn't force an ashift setting , unlike what I did with my work ZFS pools .

(I half-fumbled several aspects of my

Generally, ' zfs send ' and ' zfs receive ' are a great thing aboutZFS. They give you easy, efficient, and reliable replication of ZFSfilesystems, which is good for both backups and transfers ( andtesting ). The combination is among my favoriteways of shuffling filesystems around, right up there with dump and restore and ahead of rsync . But there is an important caveatabout zfs receive that deserves to be more widely known, and thatis that zfs receive makes no attempt to recover from a partially

My office workstation is the same hardware build as my currenthome machine , which means that it's alsomore than five years old by now. I was not necessarily expectingto replace it soon, but this week things have started to happen toit. First there was an unexpected system lockup and reboot and thentoday my CPU reporting thermal throttling , with thealways fun kernel messages of:

CPU1: Core temperature above threshold, cpu clock throttledCPU3: Package temperature above threshold, cpu clock throttledCPU2

I have to eat some humble pie here. In comments on my entry onan interesting chmod failure , Greg A.Woods pointed out that FreeBSD's behavior of creating everythinginside a directory with the group of the directory is actuallytraditional BSD behavior (it dates all the way back to the 1980s),not some odd new invention by FreeBSD. As traditional behavior itmakes sense that it's explicitly allowed by the standards , butI've also come to think that it makes sense

In a comment on my entry about perhaps standardizing the size ofour server root filesystems , Goozbachasked a good question:

Any reason not to put LVM on top of raid for OS partitions? (it's savedmy bacon more than once both resizing and moving disks)

First, let's be clear what we're talking about here. This is thechoice between putting your root filesystem directly into a softwareRAID array (such as /dev/md0 ) or creating a LVM volume group ontop

I'll start by presenting this rather interesting and puzzling failurein illustrated form:

; mkdir /tmp/newdir; chmod g+s /tmp/newdirchmod: /tmp/newdir: Operation not permitted

How can I not be able to make this chmod change when I just made thedirectory and I own it? For extra fun, some people on this particularsystem won't experience this problem, and in fact many of them are thepeople you might report this problem to, namely the sysadmins.

Everyone knows that TLS servers have certificates and TLS clientscheck those certificates when they connect to the server. What isprobably less well know is that TLS clients can have certificatesas well, and the server can ask a client for a certificate as partof the TLS handshake. As the result of a Twitter conversationtoday ,I wound up wondering and guessing if TLSclient certificates get sent to the server after the connectionbecomes encrypted.

The short answer: they don't. The TLS 1.2 RFC's

We install many of our Linux servers with mirrored system disks,and at the moment our standard partitioning is to have a 1 GB swappartition and then give the rest of the space to the root filesystem.In light of the complexity of shrinking even a RAID-1 swap partition , whose contents I could casually destroy,an obvious question came to me: did we want to switch to having ourroot filesystems normally being a standard size, say 80 GB, withthe rest of the disk space left unused?