Triumphs of the Worse

I know I seem like an irrelevant dinosaur to you node.js hipsters, but there are some valuable lessons floating around there that the next+1 new hotness would be wise to consider.  They all stem from the questions: what were the popular web languages?  And why?

Language Driven

If templates weren’t languages, we wouldn’t call them template languages, nor have so many of them: HAML, HTML::Mason, TemplateToolkit, PHP, Smarty, pagelib and Output, and so forth.

(This is essentially a repost of something that used to be on my old blog.)

An interesting recovery scenario

My computer didn't boot last night.  It failed waiting for the root filesystem, and dropped to a busybox (initramfs) prompt.  After nosing around a bit, trying to figure out what to do to make the "regular" boot process happen, I noticed that the root device was present, so I figured it couldn't hurt to try Ctrl-D.

It promptly booted up into recovery mode on the failure of a filesystem to mount, so I panicked and backed up /home as long as it was there.  However, this made even less sense as to why sda was missing, because that's where the active MBR, grub, and /boot are: the latter holding the kernel and initramfs image that were now running.  If the disk was gone, how did I boot from it?

Long, boring story short: the disk didn't vanish until something triggered a read of the whole structure of the disk.  grub only needs the first few sectors to get started booting, so it wasn't until the later search of filesystem UUIDs that the kernel somehow wedged the disk so hard that it needed a cold reboot to re-appear.  A warm reboot would hang the POST at drive detection.

It turns out that libata knows how to hard-reset a SATA drive, and this also works, but it never fell back to using it until I was booting with libata.force=nosrst included on the kernel command line.  (This also happened to be with a USB stick, so that I could have a functional linux to examine the damage with.)  That let me get it working enough to do a fsck, which restored it to fully operational.

Now I have a backup of the "more reliable so I don't need to back it up, besides it'd take forever to dribble 15 GB out over usb2" volume.  I want to say that's the worst 15-minute savings ever, but OTOH, not having the backup meant it was worth trying to fix the problem instead of writing off the drive and its data as a loss.

Update: this happened again, so I added a drive, fixed the dying drive again, and migrated everything to the new disk.  I'm glad I set up lvm ages ago, because pvmove made it 95% easy.

UI Consistency: vim and emacs

I was adding a little more vim customization this morning, to work around the fact that the vim setup on the ec2 instance is completely silly about editing php code (php.vim includes html.vim, which acts like it owns the entire file, and thus calls set matchpairs+=<:> and set comments=…; this is okay for actual html, but php.vim doesn’t restore these settings, so you get error bells when writing $foo->bar() from the unbalanced ‘>’, and you can’t format your PHP comments anymore because they’re completely unrecognized.)

Anyway, this led to the realization that my vim setup, as large as it is growing, is built on a large batch of external code, which is in turn dependent on both vim version and the distribution.  Due to subtle changes to hundreds of defaults—especially complex values like the aforementioned matchpairs and comments settings—it’s impractical to predict how a given vimrc will behave in a random environment.

Thanks to site-lisp, I am guessing that emacs has essentially the same issue: your initialization may interact in with site-lisp code to produce per-host variation in behavior.

For something I’m going to spend my day in, that’s a painful situation.  The variation interrupts the flow of expected results, pushing the editor back up into my consciousness.  But would I want an editor I couldn’t customize?

Notes on Sharing a Unix Account

After accidentally breaking an ec2 instance while trying to set up a separate user account with admin rights, I decided to keep using ec2-user and set it up to coexist with any other people who logged in on the account.  I don't expect my boss wants all my shell/vim/etc. customizations.

To achieve this, I took advantage of openssh's environment support (which required enabling PermitUserEnvironment yes in /etc/ssh/sshd_config) to set a variable when I log into the server with my key pair:

environment="VUSER=sapphirepaw" ssh-rsa ...

Next, a one-line change to ~/.bashrc:

[ -n "$VUSER" -a -r "$HOME/.$VUSER/bashrc" ] && . "$HOME/.$VUSER/bashrc"

That newly-sourced bashrc then takes care of setting up the rest of the world, with code like:

mydir="$HOME/.$VUSER"
export SCREENRC="$mydir/screenrc"
export VIMINIT="source $mydir/ec2init.vim"
alias st="svn status -q"

Notice that vim doesn't support any sort of "find the vimrc here" environment variable, but it does allow for arbitrary Ex commands to run, so I used that instead.  (Hat tip to this helpful message.)  ec2init.vim then reads:

let s:rdir="/home/ec2-user/.sapphirepaw"
let &rtp=s:rdir . "/vimfiles," . &rtp . "," . s:rdir . "/vimfiles/after"
exec "source " . s:rdir . "/vimrc"

This expands all the variables soon enough to be useful, and also means that if I ever move/reconfigure the root directory name, I will have only one place to change it in vim.  And from there, all my settings are loaded.  Life is good again.