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.
I also created a file called /etc/apt/apt.conf.d/81-btrfs-snapshot-cleanup containing this line:
apt-btrfs-snapshot-cleanup.sh
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.
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.
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…
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’sGo 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’sgo 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).
go(){if[ -f "$1"]; then if[ -n "`file $1 | grep '\(text\|empty\|no magic\)'`"]; then if[ -w "$1"]; then$EDITOR"$1"elsesudo $EDITOR"$1"#$EDITOR /sudo::"$1" # For emacsclient+trampfi else if[ -e "`which xdg-open`"]; then if[ -n "$DISPLAY"]; thenxdg-open "$1" > /dev/null
elseecho"DISPLAY not set: xdg-open requires X11"fi elseecho"xdg-open not found: unable to open '$1'"fi fi elif[ -d "$1"]; thencd"$1"elif[""="$1"]; thencdelif[ -n "`declare -f | grep '^j ()'`"]; thenj "$1"elseecho"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.
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 VNCxstartup file:
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.
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:
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:
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:
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.
CyanogenMod 7-RC4 dropped just a few days ago and it is a very exciting release as far as the Nook Color is concerned. As of release candidate four, CyanogenMod is officially supporting the Nook Color, and hardware acceleration of video and OpenGL is now working.
CyanogenMod 7-RC4 is the first firmware I burned to the internal flash memory. Everything went pretty smoothly. I only made one mistake that slowed me down; I tried to use Clockwork Recover 3.0.0.6. You have to use 3.0.1.0 to install CyanogenMod.
It is probably one of the safest Android devices that we have. It always attempts to boot off of the microSD card first. If there is no boot loader there, it will attempt to boot off of the internal flash.
The tablet seems to run a bit smoother now. I’m not entirely certain if this is because the internal flash is more efficient than my microSD card or if it is due to improvements to the firmware.
It looks like the PowerVR 530 in the Nook Color can accelerate H.264 baseline profile video with a resolution up to 848x480. It would have been nice to be able to play back some pixel-perfect 1024x600 video, but this isn’t bad at all.
I’ve encoded a few videos with HandBrake. I started with the “Apple Universal” HandBrake preset and tweaked up the settings a bit to get better looking video with smaller file sizes. I exported my Nook Color presets just in case anyone wants to download them. I’m pretty happy with the results with the RF set to around 20 or 21.
My Galaxy S phone has no trouble playing back 720p H.264 high profile video files, not that it has that much resolution anyway. I’ll probably just encode all my portable videos for the Nook Color, since most of my devices can play those just fine.
