My old laptop’s wifi went on the fritz, so I got a new Lenovo P50. Fedora 23 wouldn’t work with the Skylake architecture, so I had to jump headfirst into the Fedora 24 beta.

I’ve since hit one new issue: Yubikeys wouldn’t work for FIDO U2F authentication. Logging into a site using a Yubikey (inserting a Yubikey USB device and tapping the button when prompted) wouldn’t work. Attempting this on Github would display the error message, “Something went really wrong.” Nor would registering Yubikeys with sites work. On Github, attempting to register Yubikeys would give the error message, “This device cannot be registered.”

Interwebs sleuthing suggests that Yubikeys require special udev configuration to work on Linux. The problem is that udev doesn’t grant access to the Yubikey, so when the browser tries to access the key, things go Bad. A handful of resources pointed me toward a solution: tell udev to grant access to the device.

As root, go to the directory /etc/udev/rules.d. It contains files with names of the form *.rules, specifying rules for how to treat devices added and removed from the system. In that directory create the file 70-u2f.rules. Its contents should be those of 70-u2f.rules, from Yubico‘s libu2f-host repository. (Most of this file is just selecting various Yubikey devices to apply rules against. The important part of this file is the TAG+="uaccess" ending the various lines. This adds the “uaccess” tag to those devices; systemd-logind recognizes this tag and will grant access to the device to the current logged-in user.) Finally, run these two commands to refresh udev state:

udevadm control --reload
udevadm trigger

Yubikeys should now work for authentication.

These steps work for me, and they appear to me a sensible way to solve the problem. But I can’t say for sure that they’re the best way to solve it. (Nor am I sure why Fedora doesn’t handle this for me.) If anyone knows a better way, that doesn’t involve modifying the root file system, I’d love to hear it in comments.

Linus Torvalds recently wrote a long rant rejecting a patch. Read it now.

Fellow Mozillian Nick Nethercote commented on that rant. Now read that.

I began commenting on Nick’s post, but my thoughts spiraled. And I’ve been pondering this awhile, in the context of Linus and other topics. So I made it a full-blown post.

Ranting is sometimes funny

Linus’s rants are entertaining, in a certain sense: much the same sense that makes us laugh at a teacher’s statement (to a student, if an odd one) in Billy Madison:

What you’ve just said is one of the most insanely idiotic things I have ever heard. At no point in your rambling, incoherent response were you even close to anything that could be considered a rational thought. Everyone in this room is now dumber for having listened to it. I award you no points, and may God have mercy on your soul.

We’re entertained not because we approve of the teacher’s (or Linus’s) rants. We laugh because they’re creative. (Linus’s rants are creative, if not screenwriter-creative.) The flame can be an art form, even to flame war participants. My college dorm mailing list had regular flame wars (sometimes instigated or continued by regular trolls). I hated flame wars as a freshman. But eventually I grew to appreciate the art of the flame. In utter seriousness, that learning process was a valuable part of my college education, as it’s been for others.

(Yes, Billy Madison is low-brow humor. So are Linus’s flames, as entertainment. Not all humor must be high-brow.)

Even funny ranting is sometimes bad behavior

We also sometimes laugh because the behavior’s bad. (Humor’s core, I think, is a contradiction between expectation and reality. I highly recommend Stranger in a Strange Land for, among other things, its meditations on the nature of humor.) That’s one reason we laugh at the Billy Madison teacher-student interaction (allowing for its fictionality), and at Linus.

But somewhat pace Nick, I absolutely cannot equate laughing, or being entertained, with approval or celebration. This and this don’t celebrate ISIS, no matter ISIS appalls us. Naming Linus’s mail an “epic rant” doesn’t celebrate it. It’s just a description of five hundred over-the-top words when fewer words and less drama would have been better (as Nick observes). (At least one place calling the rant “epic” also linked this ironically-abusive decrial.)

Linux thrives despite Linus’s behavior, not because of it

Many of Linus’s rants are unacceptable. (I’ve seen a few that were overheated but not abusive.) Many developers weather them. But some developers have left the Linux community in response, when they wouldn’t have for gentler criticism. That’s a problem.

Linus gets away with bad behavior because: he’s abusive just infrequently enough; Linux has unusually high technical barriers to entry; it’s indispensable to many companies; and those companies fund development no matter Linus’s behavior. Linux led by Linus would have died already, absent these considerations. Linux is one of very, very few projects that can survive Linus’s abusiveness.

Linus is still very smart, and his rants can be right

I often recognize reasonable technical criticism beneath Linus’s rants. Regarding this patch, Linus is right. The proposed changes are harder to read than his suggestion — I’d reject them, too. I don’t agree with every Linus rant. But it’s normal to sometimes disagree even with smart developers.

What’s not normal, is being required to sift through abuse for usable feedback. It’s a skill worth having. If you can weather excess criticism from a coworker having an off day, you’ll be more productive. But it still shouldn’t be necessary (let alone routine), especially not for new open source contributors.

Conclusion

Linus is really, really smart. Because of that, and because Linux is really valuable, Linus unfortunately can keep being Linus. Barring a strongly-backed fork, nothing will change.

Spurred on by gps‘s recent mach blogging (and a blogging dry spell to rectify), I thought it’d be worth noting a new mach feature I landed in mozilla-inbound yesterday: build-complete notifications on Linux.

On OS X, mach build spawns a desktop notification when a build completes. It’s handy when the terminal where the build’s running is out of view — often the case given how long builds take. I learned about this feature when stuck on a loaner Mac for a few months due to laptop issues, and I found the notification quite handy. When I returned to Linux, I wanted the same thing there. evilpie had already filed bug 981146 with a patch using DBus notifications, but he didn’t have time to finish it. So I picked it up and did the last 5% to land it. Woo notifications!

(Minor caveat: you won’t get a notification if your build completes in under five minutes. Five minutes is probably too long; some systems build fast enough that you’d never get a notification. gps thinks this should be shorter and ideally configurable. I’m not aware of an existing bug for this.)

Mac OS X has the useful commands pbcopy and pbpaste. pbcopy reads the contents of standard input into the clipboard; pbpaste writes the contents of the clipboard to standard output. These commands aren’t part of the standard set of commands on Linux, but they’re easily added. Simply install the XSel program via a package management system or directly from source, then add these lines to ~/.bashrc. Voilà! Easy commandline access to the clipboard.

alias pbcopy='xsel --clipboard --input'
alias pbpaste='xsel --clipboard --output'

Via my friend Waseem Daher from my MIT days comes this awesome video promoting Linux and Ksplice, the new hotness in rebootless security updates:

See also the original page for the video while you’re at it.