I’ve been reading a lot of good things about standing desks lately. It seems that we can burn up to an extra 50 calories every hour if we stand instead of sit. The entire Internet is also telling us that sitting can literally kill us.

I’m not sure how true either of those articles are, but I still figured I’d give it a try. Setting up a quick, makeshift standing desk was easy and free. I did a bit of measuring and started rummaging through our closets. We have a couple of these large faux-aluminum CD cases that hold 510 discs.

Putting one of those cases on my cocktail arcade cabinet raises my laptop up to about 43 inches. That’s just about elbow height for me. The case also happens to be just about the same length and width as my gigantor 18.4 inch laptop.

Using the standing desk for a few weeks

The first few days, my feet weren’t too happy about standing for such long periods of time. I started out using it for one or two hours each day. At some point during the first week my feet stopped being a problem.

I seem to be a bit more motivated when I’m standing. I think I actually do get a bit more work done, but I haven’t done any science to validate that.

My quick hack of a standing desk has a major flaw: the display is way too low. My shoulders and neck start to get pretty tired after a few hours from looking down all the time.

What can I do about it?

I’d like to continue using the laptop’s keyboard, but I’m not sure I can get the display up high enough without putting too steep of an angle on the keyboard. The display needs to be elevated at least another twelve inches, possibly a bit more.

I have a couple of designs knocking around in my head that I can build out of PVC. I’d like to throw something together soon, but it looks like I’m probably going to be out of town for a month or two. In the mean time, I will continue to make use of what I have set up.

The verdict

Setting up this simple standing desk was definitely worth the very small amount of effort that was required. If you think the idea of a standing desk is interesting, I would encourage you to give it a try for a few days.

I have no plans to convert to using a standing desk full time. My monitors are going to stay firmly attached to my regular desk and you’ll have to pry my Aeron chair out of my cold, dead hands. I think from now on, though, I will always make sure I have somewhere in my office where I can stand up and use my laptop.

I’ve been a very happy user of btrfs-snap for quite a while now. It is great for taking snapshots of a volume at regular intervals. In my opinion, this is a bit wasteful and cumbersome for the root volume. I don’t tend to change things on the root volume every hour, or even every day.

Ubuntu 11.10 now has apt-btrfs-snapshot available in the universe repository. This is an awesome little script that hooks into apt to create a snapshot right before packages are installed or upgraded.

The only thing I wasn’t too happy about was that apt-btrfs-snapshot doesn’t do any cleanup of old snapshots, so things were getting cluttered pretty quickly:

Cleaning things up a bit

I threw together my own little snapshot cleanup script to hook into apt. It automatically removes all but the five most recent snapshots. That should be enough history to keep me safe.

Still using btrfs-snap as a safety net

I’m still using btrfs-snap on my root volume, but I’m not keeping anywhere near as much history as I used to. I’m only keeping a few hourly snapshots and one weekly snapshot. I’ll probably end up dropping the weekly snapshot.

1
2
3
4
5
6
7
8
9
10
11
12
13

#! /bin/bash

DEVICE=/dev/sda2
KEEP=5
MP=`mktemp -d`

mount $DEVICE $MP

ls -dr $MP/@apt-snapshot-* | tail -n +$KEEP | while read snap ; do
  btrfs subvolume delete $snap
done

umount $MP

I also created a file called /etc/apt/apt.conf.d/81-btrfs-snapshot-cleanup containing this line:

1

DPkg::Pre-Invoke {"if [ -x /usr/bin/apt-btrfs-snapshot ] && apt-btrfs-snapshot supported; then /home/wonko/bin/sbin/apt-btrfs-snapshot-cleanup.sh; fi "; };

This will make apt run this script right after it takes a snapshot. Just tweak that line to match the location of your apt-btrfs-snapshot-cleanup.sh script.

I have probably been entertaining the idea of replacing top with htop for quite a few years now. I have even made the attempt a few times. Familiarity and muscle memory always brought me back to top. Until now.

Some advantages of htop

The biggest advantage of htop for me is that it combines the functionality of top and iotop into a single screen, since iotop lets you add disk I/O columns to the output. This feature has saved me quite a bit of time and thought. I don’t have to crossireference processes between top and iotop now, and I also don’t have to fire up vmstat as often as I used to.

You can also highlight a process and hit l to get a list of open files for that process. I haven’t needed to use lsof very often since I learned about this feature.

There are some other small advantages to htop. You can scroll the display horizontally with your mouse, which makes it easy to see the entire command line of a command. You can also select multiple processes to kill or renice.

htop also lets you configure the header area and which columns are displayed in a much more visual manner than top.

Some minor problems with htop

I’m not really a fan of htop’s color schemes. It ships with a half dozen color schemes that are all either very colorful or completely monochromatic. The color schemes are hard coded, so there is no easy way to define your own.

There are top compatibile keys for sorting by memory and CPU usage, but there is no key to sort by I/O. To do that you have to hit F6 or > and use the arrow keys to select the I/O column. This is still better than reaching for iotop, but it isn’t exactly ideal. Setting CPU affinity has the same problem.

Update 2011-09-06: The fix worked great until yesterday. That’s probably about three and a half months. I solved the problem more permanently this time. I just unplugged the ribbon cable for the capacitive button bar. I now have fewer lights staring back at me and I no longer have dedicated buttons for volume control, but I am confident that my Wi-Fi won’t be turning itself off ever again.

I have had my HP dv8t laptop for a little over a year now. For the most part, I have been very pleased with this machine; it is an excellent quad core desktop replacement. It is a big, heavy laptop with an 18.4” screen. It usually spends most of its time living behind my desk plugged into a pair of external monitors.

A few weeks ago, I did a bit of traveling and I was using it in a hotel, connected to their Wi-Fi. Sometimes things were fine, other times it was disconnecting and reconnecting the Wi-Fi every few minutes.

I’ve had the Wi-Fi inexplicably turn off here at home a few times but I always assumed it was my own fault. The little blue capacitive button to toggle the Wi-Fi is just about a thumb’s length from the right side of the laptop, just above the keyboard. When I am sitting in a chair and I need to lift the laptop to adjust my position, that is precisely where I am most likely to grab a hold of it.

It usually took me a number of seconds to notice that I had inadvertently hit that switch. More and more often lately, though, I haven’t been so sure that I actually touched the switch…

The problem is ridiculously common

I asked my good friend Google about this problem and she showed me all sorts of pages with people complaining about the same problem. It looks like a design flaw. I found an excellent explanation of the problem and a description of the fix on Dave Miller’s blog!

There is a layer of foil that shields the cable that connects the capacitive button panel to the motherboard. It seems that if the laptop body is flexed ever so slightly, like when I pick it up by one side, the foil pulls away from the metal plate and becomes ungrounded. The problem also seems to occur more often when the laptop is hot. I imagine I’ve rarely experienced this problem because the laptop gets pretty good ventilation when I have it “docked” behind my desk.

I saw some forum posts that claimed it also helps to use some foil to shield the area around where the Wi-Fi antenna lead connects to the motherboard. I have no idea if this helps or if it is necessary, but I thought it was a pain in the neck unsnapping all the plastic bits to get the keyboard off. I figured it was best to do everything I might need to do while I was under there!

What I actually did

I ended up taping a piece of aluminum foil over the whole area where the Wi-Fi lead connects to the motherboard. I put some tape on the underside of the foil to make sure it wouldn’t accidentally short anything out.

I made sure that piece of foil was large enough so that it would extend over to the existing foil taped over the capacitive button cable. I know very little about electronics, but I assumed it couldn’t hurt to make sure the new foil shielding was also grounded.

Then I taped down my new foil and I taped down the capacitive panel’s lead.

So far, everything has been working just fine. I haven’t had my Wi-Fi turn off on its own even once. Hopefully the fix will hold up for a long time.

When I first saw Zachary Wasserman’s Go Command, I wasn’t entirely convinced that it was a good idea. I figured you could get similar functionality with less typing by enabling autocd, properly configuring binfmt_misc, and setting the execute bit on pretty much every single file…

Those three things would be quite convoluted, and setting the execute bit on every single file would make me a bit nervous… Alexy’s go command is safer, easier to implement, easier to carry along with you, and can give us much finer-grained control over the process.

To me, the go command feels like it could be called the dwim command. I wanted my own go command to do more than change directories and open files in my text editor.

I wanted to limit mine to only open appropriate files in my text editor. I didn’t want to be accidentally opening images or videos in Emacs. I also decided that if a file shouldn’t be opened with a text editor, that it should be handed off to xdg-open. That lets me open images, videos, office documents, and anything else I can think of with the same command.

I also felt it was important to integrate autojump because I am horribly addicted to it. So much so that my muscle memory always wants to type j instead of g… I’m sure if I can start remembering to correct myself, I will have that trained out of me in a week or two.

Here’s the current revision of my take on the go command. It works fine on botth zsh and bash. It fails gracefully if xdg-open or autojump are not found. If you would like to give it a try, you can just copy and paste it into your ~/.zshrc or ~/.bashrc (whichever is appropriate for your shell).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

go() {
   if [ -f "$1" ]; then
     if [ -n "`file $1 | grep '\(text\|empty\|no magic\)'`" ]; then
       if [ -w "$1" ]; then
         $EDITOR "$1"
       else
          sudo $EDITOR "$1"
          #$EDITOR /sudo::"$1" # For emacsclient+tramp
       fi
     else
       if [ -e "`which xdg-open`" ]; then
         if [ -n "$DISPLAY" ]; then
           xdg-open "$1" > /dev/null
         else
           echo "DISPLAY not set:  xdg-open requires X11"
         fi
       else
         echo "xdg-open not found:  unable to open '$1'"
       fi
     fi
   elif [ -d "$1" ]; then
     cd "$1"
   elif [ "" = "$1" ]; then
     cd
   elif [ -n "`declare -f | grep '^j ()'`" ]; then
     j "$1"
   else
     echo "Ran out of things to do with '$1'"
   fi
 }

 alias g=go

From my perspective, there isn’t any value in automatically running an ls every time I change directories. I prefer to see as many previously run commands on my screen at a time as possible, and an 80x24 terminal is already pretty cramped as it is. Even in the rare instances where I vertically maximize, my terminal I still don’t want to look at the noise of multiple extraneous directory listings staring back at me. You mileage will most likely vary, though.

The disadvantage of the go command

Using three separate commands provides the shell with context to help it provide better completion options to you. I don’t think this is a big loss if you don’t use autojump, though. I haven’t figured out how I want to set up the zsh completion settings for my go command yet. For now, I will just limp along with the basic completion settings.

This is the sort of problem we see with commands like oh-my-zsh’s x/extract command. It will perform a basic extraction for just about any archive you throw at it, but you lose the ability to complete on files inside the archive.

Happy Friday the 13th!

• Update 2010-05-18: I moved this code into an oh-my-zsh plugin and submitted a pull request a few days ago.
• Update 2010-05-20: Added a bit of functionality. If the file to edit is read only ,it will be opened using sudo.

I had my first btrfs file system failure this week. The root/home btrfs volume on the Intel X25-M SSD in my laptop became unmountable on Sunday night. It was functioning just fine with no signs of any problems, but it wouldn’t mount after a reboot. I’ve really been waiting for this sort of thing to happen. There has been quite a lot of improvement to btrfs with regards to stability since I formatted this partition.

I tried to run an fsck from the console of the Ubuntu installer, but it failed. I don’t recall the error message, but after the error came up, all CPU and disk activity ceased. I wasn’t terribly interested in recovering the file system anyway. I run a daily backup to an ext4 partition on my laptop’s second hard drive anyway.

Installing a fresh copy of Ubuntu and restoring my data and configuration only took about two hours. That includes the time it took to download and burn a Xubuntu 11.04 installation disc.

I also keep a backup of the output of dpkg --get-selections. You can pretty much just feed that back into dpkg --set-selections, but on this restore I chose not to do that. I’ve been accumulating a lot of package cruft of the last few years and I figured this was a good excuse to do some spring-cleaning.

The state of btrfs support in Ubuntu’s installer

I am very impressed with the way Ubuntu is handling btrfs. I was worried that they were still going to be mounting the primary volume as root; they don’t do this! They create @ and @home subvolumes and mount these as / and /home. I like this convention of using the @ sign. I was previously using a subvolume called root for / and home for /home.

This saved me a lot of recovery time. I was expecting to have to play a game of “musical snapshots” to get things organized like this. Organizing things this way makes it easier to boot off of a previous snapshot.

I did not let the installer format my btrfs partition, though. I wanted to correct a mistake I felt I made the last time I formatted that partition. mkfs.btrfs defaults to using mirrored metadata. I’ve been thinking that that is just a waste of performance and write cycles on an SSD. I’ve already had two instant total failures of my SSD and that seems to be a very common failure mode for solid state drives. I don’t think I’m likely to have to deal with bad sectors inside the metadata areas.

I don’t know if the Ubuntu installer would have created the file system with mirrored metadata. I didn’t think it was worth taking the time to find out.

I’m not giving up on btrfs

I don’t think I have had a complete and total non-hardware related file system failure in over ten years. That failure was with a reiserfs file system and it almost completely put me off of ever using reiserfs again. I only used reiserfs one single time since then and it was to save space with tail packing.

I knew what I was getting into with btrfs, and I know things will continue to get better. I’m not willing to give up on having regular snapshots to pull files out of. I’ve gotten into the habit of just editing my “only” copy of config files without making a quick backup copy first. It is just easier to yank a copy out of a recent snapshot on the times I actually do screw things up than it is to make backups that I don’t end up needing.

I’m also extremely happy that I can boot off of snapshots of previous installs. I wasn’t terribly happy with my upgrade to Ubuntu 11.04. I always take a manual snapshot before big updates like that, so it was trivial to boot off of my 10.10 snapshot. I was then able to chroot into the 11.04 volume and run some apt-get upgrades in there so I could watch for an update to a package relevant to the issues I was having.

I have had my old HTC Dream sitting around collecting dust for months. I have been trying to come up with a cool use for it for months. After all that time, I think I finally may have come up with a good use: running a small Conky status display on it via VNC.

How to do it

Install a VNC server and Conky:

1

apt-get install vnc4server conky-all

I am running Ubuntu and chose to install the VNC version 4 server. This ought to work on Debian as well.

Download and install my Conky configuration file and VNC xstartup file:

1
2
3
4

wget https://blog.patshead.com/Assets/conky-phone/conkyrc-phone -O ~/.conkyrc
mkdir ~/.vnc
wget https://blog.patshead.com/Assets/conky-phone/xstartup ~/.vnc/xstartup
chmod +x ~/.xstartup

Then fire up the VNC server:

1

vnc4server -geometry 480x320 :10

If all goes well, there should be a VNC server waiting for a connection on port 5910. I am currently using the Mocha Lite VNC client on my phone. It is the second client I tried and I am not very happy with it. If I end up finding this hack useful, I will probably try to hunt down a better client. I’d like one that will let me disable the status bar and hide the mouse pointer.

My Conky configuration is rather boring. I just trimmed, condensed, and slightly expanded on an old configuration I used to use a long time ago. It is quite utilitarian.

How useful is this?

I am not entirely sure how useful this is going to be; I haven’t been running this for very long. It has already kept me from having to fire up htop a few times already.

I would like to come up with a good way to attach the phone to my monitor stand if I actually end up finding it useful.

I upgraded my laptop from Ubuntu 10.10 to 11.04 a little over a week before it was scheduled to be released. I ran into three problems:

• X.org would crash on me about one hour after booting
• The Shadowgrounds games from the Humble Frozenbyte Bundle stopped working
• All my gtk applications grew an ugly, useless, window resize gripper. Even my terminals…

Update 2011-05-10:

• X.org was still crashing… Upgrading using the xorg-edgers ppa repository seems to have fixed it.
• After reinstalling due to my recent btrfs crash, the Shadowgrounds games are now working fine. I know I was using Pulseaudio before the upgrade; Xubuntu installed Pulseaudio but it is not running. I am assuming this is the only difference.

The first problem was a showstopper, and I didn’t have the time to investigate the issue at the time so I just booted using the btrfs snapshot of 10.10 that I took before the upgrade. I’ve been running on that snapshot until this morning. I haven’t crashed yet, so hopefully that bug has been squashed…

That left me with these annoying grippers on my terminal and chat windows. They obscure a bit of text in the corner of terminals and they don’t fit quite right over the text input areas in my Pidgin windows. I’m sure they look out of place in other windows as well.

Some searching turned up a simple fix in one of the answers on askubuntu.com. At the time I am writing this, the answer has no up votes and I don’t have enough reputation on the site to place a vote. If you have reputation please go give it a vote!

To remove the resize handles you just have to add the following to your ~/.gtkrc-2.0 file:

1
2
3
4
5
6
7

style "default-style"
{
  GtkWindow::resize-grip-height = 0
  GtkWindow::resize-grip-width = 0
}

class "GtkWidget" style "default-style"

Disable the grips in Gnome 3 / Ubuntu 11.10

I was surprised and disappointed to see the window grips return to my Gnome Terminal windows after upgrading to Ubuntu 10.10. A bit of searching gave me the “fix” for Gnome 3.

Just add this to your ~/.config/gtk-3.0/gtk.css file:

1
2
3

* {
  -GtkWindow-resize-grip-default: false;
}

Cave Story is a platform game for the PC that was released back in 2004, it was also recently ported to the Nintendo Wii and DS. It is an excellent game that has a very old school feel to it and it is a perfect fit for an arcade cabinet.

The controls

The controls mapped pretty well to my six-button layout. I used the Cave Story configuration tool to set the game’s keys to something more convenient, and then I used xmodmap to match up the keys to my arcade table’s player-three controls. I was able to fit all the important keys onto the six buttons—things like “jump,” “shoot,” and the keys to switch weapons.

Like I do with most native games, I mapped the “start” button to the escape key. I also ended up mapping two keys, the first two buttons on my player-one control panel to “F1” and “F2.” Cave Story uses these keys for confirmation when exiting.

The Game

I had a lot of fun playing through Cave Story. It reminded me of the many hours I spent playing Metroid when I was younger. The controls feel crisp, the game play mechanics are fun, and the variety of weapons is pretty good.

Cave Story isn’t the kind of game you can just sit down with and play for five or ten minutes, like you can with something like the shooters from ABA Games. You have to explore and fight your way forward far enough to get to a save point with this one.

I played through the majority of the game in a few long sittings, and I am pretty sure I’m down to the final boss battle. I just happened to get distracted with real life for a week or so at that point and just haven’t gotten back to it yet.

Update 2012-10-17: The slow start up with the newer zsh package was my own fault. In my transition to Prezto, I unintentionally removed the skip_global_compinit=1 from my .zshenv file. The global start up scripts for zsh-beta don’t call compinit, but the newer ones in the zsh package do.

Update 2012-10-16: I’m using Prezto now, but I did notice something interesting today that probably still applies to oh-my-zsh. Ubuntu 12.04 has zsh and zsh-beta packages. Oddly, the zsh package is a more recent version than the zsh-beta package.

The older zsh-beta starts up almost five times faster:

1
2
3
4
5
6
7
8
9

$ /usr/bin/time /bin/zsh-beta -i -c exit
0.07user 0.04system 0:00.13elapsed 89%CPU
$ /bin/zsh-beta --version
zsh 4.3.12-dev-1-cvs (x86_64-unknown-linux-gnu)

$ /usr/bin/time /bin/zsh -i -c exit
0.47user 0.12system 0:00.64elapsed 92%CPU
$ /bin/zsh --version
zsh 4.3.17 (x86_64-unknown-linux-gnu)

For now I’m using zsh-beta, but I will have to investigate this further.

Update 2010-04-29: All of my changes to oh-my-zsh that are listed here were pulled into the master repository last night. Just about everything here can be ignored now except for the part about adding skip_global_compinit=1 to your ~/.zshenv if you are running Ubuntu (and possibly other distros). Adding that line still saves me almost a half second of startup time.

I’ve been very happy with zsh and oh-my-zsh except for one thing: the slow startup time. I’ve been putting up with a huge delay every time I open a new terminal, and I open terminals quite often. I did manage to solve the problem even with a total failure of my google-fu. To find the cause of the problem, I was in need of some sort of benchmark.

End of Updates

The benchmark

This turned out to be easy. I just ran /usr/bin/time zsh -i -c exit and took note of the elapsed time. The time to beat was an abysmal 1.65 seconds. That was 0.6 seconds slower than bash!

My first failure

First I tried to compile everything in my .oh-my-zsh directory using zcompile. It was a complete waste of time; there was no improvement what so ever.

My second failure

I started removing files from ~/.oh-my-zsh/lib and ~/.oh-my-zsh/custom. I couldn’t manage to get the startup time down below 1.2 seconds, and I was losing huge pieces of functionality. I was hoping I could pinpoint one or two particularly slow files to investigate, but that wasn’t the case.

Grasping at straws

I even tried moving my ~/.oh-my-zsh directory to a tmpfs partition. Of course this made no difference. The files were already cached anyway.

Getting to 0.49 seconds

I almost gave up. OK, I did give up. I didn’t find the solution until the next day…

The biggest slow down was in the system-wide zshrc file in /etc/zsh. On my Ubuntu 10.10 system the slow down is the call to compinit on the second-to-last line. Following the advice of the comment and adding skip_global_compinit=1 to my ~/.zshenv bought me over one full second.

Squeezing out a little more

There are calls to compinit in a few files in ~/.oh-my-zsh/lib and ~/.oh-my-zsh/plugins. I already have a call to compinit in one of my own scripts in ~/.oh-my-zsh/custom, so I tried commenting out the calls in the two occurrences in ~/.oh-my-zsh/lib (I don’t have any plugins enabled). Each one saved me about 0.07 seconds. That brings me down to 0.35 seconds, about 0.7 seconds faster than bash!

I’m not sure why oh-my-zsh has so many calls to compinit. I’m pretty sure every plugin calls it once. I haven’t noticed any changes in the way completion works, and I don’t think I will. As far as I can tell, compinit should only need to be called once.

Getting a bit more invasive

I removed all the calls to compinit, including the one in my own script in ~/.oh-my-zsh/custom. Then I added a single call to compinit to the end of the `~/.oh-my-zsh/oh-my-zsh.sh’ script. This shaved off another 0.12 seconds, bringing my total down to 0.23 seconds. I don’t think there is any need for me to push things any more than this.

• Update 2010-04-19: I have included this code along with some better (and more invasive) changes in a branch on github that have my startup time down to about 0.20 seconds even with a few extra plugins enabled! There have been quite a few excellent recommendations in the comments on my pull request. I hope to see the code pulled into the trunk soon.
• Update 2010-04-24: Antonio Santos Velasco wrote an article explaining precisely how to pull down my changes from github. Thank you Antonio!