I saw an article about Stealing from Padre for Vim and I got a bit jealous that this functionality wasn't already available for Emacs. I guess I lucked out because it was very easy to make use of App::EditorTools in Emacs.

It probably took about a half hour to an hour to get this all up and running. The hardest part was actually tracking down the elisp functions that would return the current row and column of the beginning and end of a region. The terminology was just not easy to search for.

I did not include any default bindings in the package. I am still not entirely sure where their permanent home will be within my own config. For now I am using these:

(define-key cperl-mode-map (kbd "C-c e r") 'editortools-vim-renamevariable)
(define-key cperl-mode-map (kbd "C-c e t") 'editortools-vim-introducetemporaryvariable)

I don't think I want a binding for the renamepackage/renamepackagefrompath functions. I think I might set it up to call one of those automatically when I create a new file.

The elisp file can be found at:

http://rcs.patshead.com/dists/editortools-vim-el/

A Darcs repository is also available at http://rcs.patshead.com.

My Intel 80 GB X25-M G2 in my laptop died recently. Everything was running smoothly when I shut down but when I powered back up the BIOS couldn't see the drive any longer. Fortunately, I keep pretty good backups and I was up and running on a spare platter drive relatively quickly.

The RMA process was pretty disappointing. Phoning Intel was the only option.

I called in the afternoon on Monday, February 1, since they are only available during business hours. My time on hold was pretty short, probably about five minutes and it took less than 10 minutes to get the RMA rolling. I was told I'd receive an email shortly with RMA instructions.

I didn't receive an email. At that point it was after business hours so I used their web based form to submit a question. I included my RMA and case numbers, and I never heard back from them.

At this point there is a delay that is completely my fault. I didn't get a chance to call back until a week later on Monday, February 8. It turned out they got my email address wrong. I pronounced my email address and I spelled it to them letter for letter. They didn't only have it wrong, they were short on characters...

I was happy with the turn around time on the package. I had the drive at the post office on Tuesday, February 9 and the new drive arrived at my door on Tuesday, February 16.

The night of my second call to Intel I realized there was a pretty good chance they also didn't get my address correct. They do not include your shipping address in the RMA email. This time I sent an email to the address listed in the RMA email which is rma@mailbox.intel.com. I never heard anything back.

My Overall Opinion

I was happy with the service once I was able to get to the point where I was able to ship the drive out. I'm generally unhappy with their telephone support, and I am extremely disappointed with their email communications.

I Sure Did Miss the SSD

Certain tasks were noticeably slower. Most of the time the performance difference isn't something you can feel but some disk intensive tasks are significantly faster with the SSD. Things like booting, installing and updating a large number of packages with apt, and importing photos into F-Spot are at least twice as fast with the X25.

The thing I noticed most was the heat. When I first moved from the old hot platter drive to the X25 I didn't think the difference was so dramatic. Running on the SSD for months sure made the platter drive feel scary hot. The SSD is warm underneath the laptop where there is only piece of plastic covering and physically touching the drive.

The platter drive even made the top of the laptop very warm to the touch. The difference is in temperature is huge.

I've been running Home++ for most of the past week and I have to say it is a nice improvement over the stock home application. For the most part it acts just like the stock home application, but with a number of nice improvements.

There are three features in particular that I am enjoying.

The "Power Strip"

The "Power Strip" is a set of small icons across the bottom that stay the same on across each launcher screen. It sits where the usually drawer-puller icon normally is. There seems to be room for six icons on the screen and you can scroll to the side if you need more than six.

I have mine pared down to only six icons so they all fit. The two most useful icons for me are the Bookmarks and Tasks List buttons.

Built-in Task Manager

I've been wasting time and memory ever since I got my phone running Taskiller or, more recently, Estrongs Task Manager. I've been wondering why such a simple feature couldn't just be tacked onto the home application. There's nothing fancy about Home++'s built in task killer, but it should does pop up nice and fast.

Access to Bookmarks Without Opening the Browser

I've been wanting this feature for a while and it is definitely a time saver. It might not be as noticeable on a Droid or Nexus One, but the browser sure takes quite a while to open up.

The old way was to open the browser, wait until I can even click on the bookmarks menu option, then wait again for the page to load. Now I can just choose the bookmark and wait once. It feels so much faster because I don't have to look at the phone between the browser opening and the page loading.

Hack to Make Dolphin Bookmarks Show Up

There seems to be a small bug in Home++ that keeps it from displaying bookmarks from the Dolphin browser even though it has an option to do so. It seems as though a SQLite query is failing due to some missing columns in Dolphin's database. I was able to fix it by adding those (empty) columns to the database:

$ su
# sqlite3 /data/data/com.mgeek.android.DolphinBrowser/databases/browser.db
SQLite version 3.5.9
Enter ".help" for instructions
sqlite> alter table bookmarks add column thumbnail;
sqlite> alter table bookmarks add column touch_icon;
sqlite> .exit
# exit
$ exit

This is not necessary if you aren't running Dolphin. If you are this may eventually break something, so you're on your own.

Home++ Shortcomings

For me, Home++ has a few small shortcomings. It is a fork of the stock home application and I wish it were open source. I'm pretty certain I would fix the rest of my "problems" instead of just complaining about them if it were... Fortunately my complaints are very, very minor.

Power Strip Shortcuts Aren't Configurable Enough

Many of the buttons on the "Power Strip" have two functions attached to them. On a long press the "voice command" button activates Android's "voice search". I have no use for "voice command" and I really wish "voice search" were the long press alternative for the regular "search" button. The long press on "search" is a shortcut to Android's search settings. I've only ever gone in there one time, I don't need a shortcut to take me there.

It would probably be nice if you could choose your own command to run on the long press for all the buttons.

Enabling the Notification Bar Can be Tricky

If you remove the "notification" button from the "Power Strip" there is no way to turn the stock notification bar back on. This is not a big deal at all. If you want the notification bar to always be visible you only have to add the button back long enough to turn it on.

The Verdict

I'm very happy with Home++ so far. It does everything the stock application launcher does and a little bit extra.

I recently upgraded to Mozilla Thunderbird 3.0. That got me thinking that now might be a good time to clean up my local mail folders. All of my mail from the past few years is stored on my IMAP server. I still have a few gigabytes of old mail from my old POP3 days stored in Thunderbird's Local Folders.

I decided that now might be a good time to do some spring cleaning and not carry around my old POP3 mail anymore. I figured it is also a good time to store this current copy of my old mail with my long term backups.

My Old Friend rzip

I have been using rzip for quite a few years. Its job is to find and encode large chunks of duplicated data over very large distances, up to 900 MB. Once that is completes it runs the resulting data through bzip2. For large datasets I've found it to be much faster than bzip2](http://en.wikipedia.org/wiki/Bzip2) and it usually results in an archive that is about 30% smaller than just using [bzip2`.

Unfortunately, rzip can not operate on pipes. All of my automated backup scripts run along pipelines, usually from tar to bzip2 to gpg. They never touch the disk unencrypted, which probably isn't always helpful.

My New Friend lrzip

I recently discovered Con Kolivas' lrzip. lrzip takes rzip a couple steps further. It lets you choose a compressor other than `bzip2 for the second stage of compression. It can also be used in a pipe.

Unfortunately, when used in a pipe it generates a large temp file. This can be a problem if you are trying to generate a large archive and don't have a lot of free disk space, or if you don't want unencrypted data being written to the disk.

Some Benchmarks

I compressed the tarball of my .thunderbird directory every way I could think of that made sense. The default settings for lrzip kept erroring out on me at about 30%. I had to use the -w switch to reduce the window size from 20. I chose 12, which should be about 30% higher than rzip's window.

              Size    Minutes    Ratio
              (MB)
uncompressed  5761         na    1.0:1
lrzip zpaq    1207        265    4.7:1
lrzip lzma    1262         60    4.5:1
lrzip bzip2   1401         27    4.1:1
rzip          1362         20    4.2:1
lzma          1441         97    4.0:1
bzip2         1748         38    3.3:1

Both rzip and lrzip achieved a smaller file size in less time than bzip2. lrzip with zpaq is over 13 times slower than rzip for a savings of 155 MB, or about 12%.

Why Would Anyone Wait for zpaq to Finish?

Most of the time it isn't worth the wait. I'm a huge fan of smaller backups. Backups become significantly more expensive every time a single backup has to span a second (or third, or fourth...) piece of media. It's another floppy, CD, DVD, Blu-ray, tape, hard drive, or flash drive to have to manually swap around and keep safe.

I like flash drives for my personal backups. I have too many CDs and DVDs that are unreadable. I've accidentally run an old compact flash drive through the laundry and it still worked. I'm sure all flash drives won't survive that, but they do tend to be very durable.

Unfortunately, lrzip with zpaq did not get the file size down for enough for the archive to fit on the backup flash drive that I keep around the house. Another 100 MB or so would have done the trick and would save me quite a bit of effort.

Which One Should You Use?

For most archives I would probably just choose bzip2. It does a very good job and a decompressor is always very readily available.

For almost every very large archive I will definitely be sticking with rzip. It is faster and more space efficient than bzip2. It is also easier to find than lrzip, my Ubuntu machine has an rzip package available in apt.

I will be sure to keep lrzip with zpaq in mind, though. Sometimes an extra couple hundred MB will save the time, effort, and cost of a second piece of media. The other downside to zpaq is that decompression is also very slow as well.

The wiper.sh script that ships with hdparm 9.27 does not work well with the Intel X25 drives. The call to hdparm will fail if it is passed in more than 512 ranges of sectors. I made a quick and dirty modification to the wiper.sh script so that it makes multiple calls to hdparm with 500 ranges each. I've only been running it for a few days, but it seems to be working just fine so far.

I also added a --yes command line switch so that I could more easily call it from cron.

wonko@zaphod:~$ sudo ./wiper-dangerous.sh --commit --yes /

wiper-dangerous.sh: Linux SATA SSD TRIM utility, version 2.5-dangerous, by Mark Lord.
Preparing for online TRIM of free space on /dev/sda2 (ext4 mounted read-write at /).
Creating temporary file (3091782 KB).. 
Syncing disks.. 
Beginning TRIM operations..

/dev/sda:
trimming 6183568 sectors from 159 ranges
succeeded
Removing temporary file..
Syncing disks.. 
Done.

The script also now has a dependency on Perl. Feel free to download a copy of my wiper-dangerous.sh, but I make no promise that it won't eat your data!