One of the long standing with ZFS on Linux has been its integration with the generalLinux kernel memory allocation system. In particular, back inDecember I wrote about my problem of memory competition betweenthe ZFS ARC and the general Linux page cache ,where my much smaller ext4 root filesystem wound up with a lot ofdata cached and the ARC was much too small. The good news is thata lot can change in seven months.

As of some recent updates to the development version of ZFS onLinux, this problem

One of the little problems of ZFS is that scrubs and resilversare random IO . I've always known this, but fora long time it hasn't really been important to us; things ran fastenough. As you might guess from me writing an entry about it, thissituation is now changing.

We do periodic scrubs of each of our poolsfor safety, as everyone should; this has historically beenreasonably important . Because of their impact onuser IO, we only want to do them on weekends

One of the things that makes me hesitant to whole heartedly embracetwo factor authentication for system administration is how to dealwith emergency system access in an exceptional situation. A lot of2FA systems seem to involve daemons and central services and otherthings with a lot of moving parts that are potentially breakable,especially in extreme situations like partial network failures ormachine failures. If you require all of this to be working beforeyou can get in as a sysadmin or as root, you may have seriousproblems in emergencies. But

Locally, we don't currently use two factor authentication foranything (for reasons that in large part boil down to 'no one hasmoney to fund it'). I don't know if we can change that, but I'dlike to at least move in that direction, and one part of any suchmove is trying to think about what I want out of a two factorauthentication system. Since this is a broad area, I'm focusingon my own use today.

Right off

For quixotic reasons, I recently updated my own local version of dmenu to the upstream version, which hadmoved on since I last did this (most importantly, it gained supportfor Xft fonts ). Well, the upstream versionplus my collection of bugfixes and improvements .In the process of doing this I have (re)learned a valuable lessonabout how I want to organize my local changes to upstream software.

My modifications to dmenu predate my recent decision to commitlocal changes instead of just carrying them uncommitted on top

If you're me, you've probably done this at some point:

# dnf clean metadata[...]# dnf check-update[... lists some available updates ...]

Then in another window, running as myself:

; dnf updateinfo info[... doesn't report anything ...]

Wait, what?

What's going on here is that dnf maintains separate packagedatabases for root and for individual users . When you run dnf as root, it

Partly due to the impending release of iOS 9, a certain amount ofangst has been written lately about the potential increasing futureof adblocking on the web. One of the things often written in sucharticles is more or less 'how will you like it if widespreadadblocking kills the ad-supported web?' Well, it's funny you shouldmention that.

I'm sure that in the short term I would hate the decline of thead supported web. Like pretty much everyone, I visit plenty of

Ubuntu just sent out USN-2700-1 ,a 14.04 LTS announcement about a kernel update for CVE-2015-3290,CVE-2015-3291, and CVE-2015-5157. People with good memories may atthis point remember USN-2688-1 ,a 14.04 LTS announcement about a kernel update for CVE-2015

Firefox Electrolysis ('e10s'for short) is a project to push Firefox towards a multiprocess model likeChrome's. This is both a daunting amount of work and a praiseworthy goalwith a number of benefits, but there is a problem lurking in the futureand that is Firefox addons.

The direct problem is that any number of addons are not Electrolysiscompatible for technical reasons .Firefox developers have partly worked around this with shims ,but shims are an incomplete solution and can't make all addons