http://www.evolvingscientist.net/2011/12/someone-got-ahold-of-lines-full-letter.html

That is one awesome response letter. Hard to believe it came from a bureaucracy. I just hope the Board in Frankfort can exert more influence over the schools than Line the Hart County local.

One of the common use cases for laptops is to plug into an external display at a docking station or with a projector, and unplug and use the internal display, then plug into another external display, then later back to the internal display, and keep on cycling like this. Unfortunately, Linux distributions haven’t supported switching displays very easily.

Enter disper to save the day. This is a command-line (and so easily scriptable) tool to switch the display in use. For example, to make only the internal display active, run disper -s. For only the external display, disper -S. And to toggle between them, disper --cycle-stages='-s:-S' -C. So when I want to bind one of the special laptop function keys to alternate between external-display-active-only and internal-display-active-only in Gnome, I run gnome-keybinding-properties, add a custom shortcut to run disper --cycle-stages=-s:-S -C, and bind that to XF86LaunchA. Voilà, with one keypress I can switch between the laptop’s screen and the projector. Other flags to disper let you activate both displays, etc.

I’m staggered by the enormous discrepancy in news coverage here, with the media still eulogizing Steve Jobs after a week and a half, Dennis Ritchie passes away, and receives hardly a blip.

How can this be? The man was a giant in the field. He was one of the inventors of C, which became the most successful programming language, remains extremely popular after four decades, and was a direct ancestor to many of the most used languages of the present day. It’s difficult to overstate its impact; nearly all of the software you encounter today — on PCs, on servers, in embedded systems, or anywhere — was written in C or a language that traces back to C. It was Ritchie who decided on one of the keys to C’s success, its “portable assembly” aspect: It had to let you get close to the metal, while still abstracting away the architecture’s particulars. Another aspect to C’s success was its excellent manual written by Ritchie and Brian Kernighan, commonly called simply “K&R”: short, clear, and comprehensive; information rich yet simple writing; it set a standard that few computer texts come close to reaching.

He was a father of Unix, which has led to more of today’s operating systems than you can shake a stick at. The first great wave of webservers was on Solaris and other System V variants. There’s a BSD Unix sitting inside MacOSX and iPhoneOS. Richard Stallman modeled his GNU project on Unix, and Linus Torvalds’ Linux kernel was a clone of Unix’s — and the second great wave of webservers was build on these. Nearly all of the servers you encounter online run operating systems using Ritchie’s designs. And every Android smartphone as well. How is it that one OS family can span such a range? It was Ritchie who pushed for Unix to be rewritten to have a portable core for the bulk of the OS, with the hardware-specific bits isolated away for easy migration to new machines. No operating system had ever done this; it let Unix escape the PDP, and escape it did.

News media be damned. I feel Ritchie’s passing much more keenly than Jobs’. He wasn’t showy, but his influence was legion.

Java NIO’s Selector class is surprisingly difficult to use with multiple threads. Everyone that tries it encounters mysterious blocking, much of which is due to it sharing a lock with SelectableChannel.register. So, if you happen to try to register a channel in a thread other than the selector thread, it blocks that thread until the select is done. Boo.

So, this is a NIO rite of passage of sorts, finding this misfeature and then looking up how to work around it. The usual answer is to keep a ConcurrentQueue of pending registrations, and have your select loop process that queue between select calls. Uggggleeee. It occurred to me that using a synchronization lock, we can do better.

To register a channel and get the SelectionKey:

  synchronized(registerLock) {
      selector.wakeup();
      key = channel.register(selector, operations, attachment);
  }

And in the select loop:

  // before
  synchronized(registerLock) {}
  // between
  numEvents = selector.select(timeout);
  // after

If the loop is before or after when our registration block takes the registerLock, we’re fine, as having the registerLock prevents the loop from reaching select until we’ve registered and released the lock. If the loop is inside select(), then the wakeup() will cause it to exit select, and it won’t re-enter because we hold the registerLock, so we’re fine.

The tricky case is when the loop has the registerLock or is between releasing the registerLock and entering select(). In these cases, the registration block takes the registerLock and races with the loop over select() and wakeup(). Fortunately, the NIO designers anticipated that programmers would have a desire to ensure a Selector wasn’t selecting, even if the wakeup was called in the window between checking it was okay to enter select and actually entering it. Selector.select() returns immediately if wakeup() had been called after that Selector’s prior select(). So, our race doesn’t matter, the select() always exits, and we’re safe.

This is so much simpler than building up a queue of registrations and processing them in the select loop, and we get the SelectionKey right away, I wonder if I’m missing something. Why is the textbook technique to use a ConcurrentQueue, instead of a synchronization lock like this?

Time to take a break from my break from blogging.
Today I found this video pretty interesting, a neuroscientist discovers his brain scan matches those of psychopaths.

[Update: link “http://wsf.tv/videos/embedded/1361” has died, sorry.]

I switched to OpenSuSE tonight.
PCLinuxOS had been grating on me for the last few months, since they decided to drop most of their man pages in favor of entering “man foo” into Google. But after an ordinary update, tonight I discovered that the new kernel hung on boot. To my distress, GRUB didn’t list any previous kernels when I intercepted its autoboot. After trying and failing to get grub to show me any files on the filesystem so I could select another kernel from /boot to boot from (why is this so hard?), I booted from a rescue disk… and discovered that there was only one kernel version in /boot, PCLinuxOS had been deleting the previous versions. This bad practice dismayed me, it’s standard for distributions to keep the previous one or two kernels around, in case of a case like this, where a kernel that doesn’t boot on someone’s hardware get pushed.
I’d been meaning to try out SuSE again for a while, and this pushed me over. I backed up my disk and did a clean install.
We’ll see how the new distribution goes.

When I read about someone putting the pin in a dropped grenade, I think “Why is he doing that? He’s going to die! No, this didn’t happen, it’s just made up by a hack who doesn’t know how grenades work.” Congratulations, you just destroyed the immersion in your story. Similarly for a grenade exploding while still held pending the throw, or a thrown grenade with the spoon still against it (for graphical media).

No need to trek through the snow to the library, research is now as simple as visiting http://en.wikipedia.org/wiki/Hand_grenade from the comfort of home, yet curiously, this seems to be a disease of newer works, despite older works having hand grenades in their stories if anything more often.

So, evidently there’s a need for a primer for writers. Here goes:
Anatomy of a hand grenade: The body of a grenade is a shell containing explosives and a timed fuze. Against the shell is a lever called the spoon, which is connected to a spring-loaded trigger called the striker, which starts the fuze. A safety pin holds the spoon in place.
Operation: Hold the grenade in your throwing arm, pressing the spoon against the body. Pull the pin. Throw the grenade at the enemy. With the pin removed, the spring will now push the spoon away and the striker starts the fuze, which in a short time will detonate the explosive.

Note that the fuze can’t be stopped, and it’s the spoon which triggers the grenade, not the pin. So a held grenade can be re-safed by replacing the pin, which might be the seed of the myth that the pin will deactivate a cooking grenade.

This dusk, some of the Pasadena peahens decided to go scampering around above my and my neighbors’ ceilings. They’re pretty large birds, so I could hear them up there clearly!

Daniel Huffman has produced some interesting maps of the US’s major river systems, done in the style of intracity rail line maps. I especially like the one of the Columbia’s system.
He talks about generating these river maps here.
Naturally, he has other interesting things to say about maps, such as a discussion on projection conformality.

Accidentally compare a character and an integer.
$ python -c 'print "\0" > 1024'
True

Wait, what? Any character is larger than any integer? Why are chars and ints intercomparable then? Shouldn’t I get either a type error or a meaningful comparison? This seems like it’s guaranteed to be wrong!