Click the Monkey

Often when I'm typing at the computer, like right now, my three-year old will come up to me and tell me to, "click on the monkey!" It took me a while, but I finally figured out what he was talking about: *click* For some reason he finds that to be pretty darn funny. Three years old and already a greasemonkey fan.

Vmware Server on Ubuntu 5.10

This was originally posted on my family blog on 4/28/06. I will be slowly moving the geeky stuff from there to this blog.

I decided to try VMware Server instead of just VMware Player on my new system. Installing either seems to be a little tricky on Ubuntu. The reason is, they've worked hard to make Ubuntu installable with only one CD image, and in order to do so they've left of a lot off the developer tools. Apparently you need these to install teh vmwarez. Ubuntu users seem to take good notes, here's some help for installing vmware on Ubuntu. Worked for me.

Server is pretty slick. It looks like you can use it to create your own vmware images, install the vmware tools in an image, and do snapshots too. Very nice.

Lane Has a Blog

While I'm pointing out new interesting blogs (because what blog that doesn't mention blogging is complete?), I should point out that my long-time friend, Lane has an important new blog. So important, that I'll let him explain it. Now go join the crucial debates taking place there.

Dr. K Has a Blog

I just found out that Dr. K has a blog. Dr. Knutsen, or Dr. K, for short, was by far my favorite professor over in the CS department (I just realized that all my favorite professors had knick names. Hmmm, I mean, knick names they knew about and were OK with. Ahem...anyway...). He taught my introduction to C++ class, which was also supposed to have a smattering of "Software Engineering" thrown in. Dr. K gave us more than a smattering. He spent many a lecture telling us story after story from his industry experience in order to expound on this topic. He was not only very interesting, but hilarious. His blog looks to be the same.

CVS to Mercurial

I decided to convert my simple .emacs cvs repository to mercurial. The instructions for converting repositories on the mercurial wiki were a little confusing, but here’s what I got to work on my Ubuntu Edgy Eft box:

aptitude install mercurial
aptitude install tailor

Then, in the directory where I wanted my mercurial repository (make sure there isn’t a cvs checkout of the module you are converting there!):

mkdir hg-temp
cd hg-temp
tailor -v --source-kind cvs --target-kind hg --repository /home/bryan/cvsrepositories/dot-emacs --module dot-emacs -r INITIAL > dot-emacs.tailor
emacs dot-emacs.tailor

In the dot-emacs.tailor file, change subdir from . to MODULENAME (which is dot-emacs, in my case), and remove /MODULENAME from root-directory, like the wiki says. Then add the line:

patch-name-format =

at the end of the “project” section¹. Then:

tailor --configfile dot-emacs.tailor

This creates three files, tailor.state.old, tailor.state, and project.log² in the parent directory, as well as a directory called, dot-emacs. This new directory is your hg repository. Change to that directory and type hg log, and then hg log -v to see the preserved cvs history and checkin comments.

Footnotes

¹ At least, that’s what I liked best, ‘man tailor’ and search for ‘patch-name-format’ for more info on this.

² As far as I know you can blow these files away when you’re done.

Random Reading

This morning I somehow ended up on a string of random readings on the good ol' world wide web. It was one of those times where I can't even remember how I got started, but I ended up reading a few blog posts on some blogs that I've never really come across before, but were totally awesome. And I guess that's how this whole web logging thing got started. People finding cool stuff and feeling the need to write it down, because it was just so cool. So, as best as I can retrace my steps, I was looking for something emacs related, or maybe just reading the Planet Emacsen feed, but I found this wonderful emacs blog that I hadn't really noticed before. Specifically I found the imenu feature. Wow, that's just so handy. Especially when you bind it to your right mouse button. Somehow I also ended up on this googler's blog. I realized I had been there before because of Joel's story on Windows XP shutdown craziness. But what was more interesting was his becoming a better programmer entry. The quote at the end really sums it up, that's just fantastic (and I have a lot to learn). That really reminded me of Mr. Graham's latest entry, which bothered me more than anything he's ever written. I really have a weakness for these geek philosophers (you know, Paul, Joel, Stevey), but this essay of Paul's was the first I just couldn't even finish. I just thought he'd gone too far out of his expertise, or something, I don't know. But then I did finish it. And I liked it more than any of his other essays, and I completely agreed that there is a distinction between smarts and wisdom, because I remembered a favorite scripture of mine that makes the same distinction. Paul basically derived that verse, how impressive is that? Well, except he missed the important part, the danger of confusing intelligence for wisdom. Anyway, the post from Moishe really reiterated the wisdom over intelligence thing for me and I like it. There were other interesting things I found and I bookmarked them on delicious (or scroll all the way down to the bottom of this blog to see them). And that's enough for now really, I just needed to write all that down.

Ubuntu--It's the Little Things

This was originally posted on my family blog on 5/10/06. I will be slowly moving the geeky stuff from there to this blog.

Real quick, two nice little things about Ubuntu that I have neglected to mention, but that show just how fine a Linux distribution it is.

I installed it on a second hard drive, along side my Mandriva install on the first hard drive. Ubuntu actually detected Mandriva there, and copied the grub entries into the Ubuntu grub.conf, so I could still boot Mandriva after installing Ubuntu. I could have done that my self easily enough, but that just made life that much easier.

The other I just noticed this morning. After all my messing around with mondo (which I have working quite nicely now, by the way), Ubuntu includes a Simple Backup Suite (nice write-up here). It's a nice little GUI app and the default settings are exactly what I would want. How cool is that?

Cutting Edge Revision Control

I have to admit that I’m kind of a tools guy. Every now and then I get this hankering to try out new tools and see if there is a better way to work. For the past few weeks I’ve been researching the latest and greatest revision control tools that are available Free and Open Source. I’ve done some quick comparisons of what appear to be the front-runners as of this third month of 2007.

Background

Before this adventure of mine I had only used three revision control systems. At work I have used CVS on a couple projects, and currently my team uses Clearcase. At home I’ve used CVS and Subversion (svn) for my various little bits of code. All are annoying in their own special ways. You’ve probably heard the annoyances before: CVS doesn’t keep history of renaming files; Clearcase is complicated, slow, completely reliant on the LAN, and complicated; and Subversion, well, I’ll get to that in a second. First I need to talk about their good points.

All of these systems I’ve used did have good points. CVS is simple, fast, and well documented. Subversion has all that, and adds rename support and a cool web server interface. Clearcase’s good point is that it introduced me to the real fun of branching. Branching is handy in that when you need to develop a tricky new feature, you can create a branch, work on your feature and check minor changes in as you go with no regard to breaking the build or disturbing other developers, and then when you are done you simply merge the new feature back into the main branch. Other changes and bugfixes can be done at the same time on other branches. It’s very nice.

So back to Subversion’s annoyances. This may or may not be something Subversion inherited from CVS, I never looked into it, but Subversion does do branching. I tried to use a branch with Subversion for a big change on a home project of mine, and it actually went pretty well. I learned something quite disconcerting though. Subversion doesn’t track merges automatically. The hassle of tracking merged revisions manually was just too much to ask. I was discouraged from branching with Subversion ever again. There had to be a better way.

Turns out there is a better way in the world of open source revision control. About a million better ways, in fact. Check out this comparison chart.

After reading a lot of comparisons like the above, I concluded that of all those revision control choices, the ones that are being actively developed and used by fairly big and/or prominent projects are Bazaar (AKA bazaar-ng), Mercurial, Darcs, and git. And actually I’ll state right here that it’s somewhat questionable whether Darcs meets my criteria (though I wanted it to, really). What follows is my comparison of these four systems. I compared them for speed and ease of use, the two things I cared about most. I also briefly looked at how they work over a network and their windoze support, but not to a great amount of detail. That would be a good sequel to this review.

Speed

By performance, I mean that I used the UNIX time command to see how long various basic operations took. Performing the various basic operations gave me some insight into the usability of each as well. For this test I used a directory with 266 MB of files, 258 KB of which were text files, with the rest being image files. I know, kind of weird to version all those binary files, but that was the project I was interested in testing this out on. Your mileage may vary and all that. Here’s a table summarizing the real times reported by time(1):

Tool	initialize repository	initial file import	initial commit	branch/clone repository	non-conflicting merge	total
bzr	0m1.144s	0m0.839s	1m7.836s	0m31.145s	0m1.154s	1m42.118s
darcs	0m0.429s	12m50.321s	0m0.164s	0m5.691s	0m6.717s	13m3.322s
git	0m0.081s	1m1.918s	0m6.679s	1m37.630s	0m1.910s	2m48.218s
hg	0m0.781s	0m0.377s	0m49.015s	0m8.831s	0m0.342s	59.356s

As you can see, Mercurial (hg) was the fastest. I was a little disappointed in git, who’s whole purpose in life (depending on what you read) is to be fast. I’m thinking maybe it just doesn’t handle the binary files as well. Whatever. In the end I decided performance wasn’t that important of a feature for me. (But it still totally rocks that an app written in Python (well most of hg is python) kicked the pants off an app written in bare-metal, hard-core, “efficient” C. OK, I’ll stop being juvenile now.)

Usability

General Usage

The general workflow and command set for each is very similar. Darcs is the only outlier here, having chosen to diverge from familiar cvs-like commands in favor of “record” instead of “commit,” and “changes” instead of “log” or “history,” and “whatsnew” instead of “diff.”

The other area where they are slightly different is in handling merges. For both git and darcs, it’s a one-command operation, as long as there are no conflicts. For hg you do an hg pull from one branch to the other, and then there is an hg merge command, followed by an hg commit to finalize the merge. With bzr it’s similar, except you use bzr pull only if the branches haven’t diverged, if they have it will tell you you need to use bzr merge instead (let’s all shake our heads at that one together…if it knows, and can tell you about it, why doesn’t it just do it?). Then after your merge you have to do a bzr commit. Bazaar also throws in a few extra steps when resolving conflicts that the others don’t have. It tells you all about those when the need arises, similar to the pull vs. merge issue.

I should also mention the nefarious and notorious git index. Technically, when you make a change to a file, you can’t just commit it, you need to add it to “the index” first. I never dug deep enough to fully understand what that really was and why it was needed, because you can just add a -a to the git commit command, and then it automatically add changed files to the index and works just like everything else. But before I figured that out it was pretty annoying.

Lastly on the topic of general usability, I had a strange thing happen amidst all this version control software testing. I’d get this really happy feeling when I was using mercurial, even though it was doing some weird things like requiring three steps to merge something and having difficulty with file and directory renames (more on this later). I’d get a similar happy feeling when using git, even though it has some UI oddities of its own (namely, the index). Upon further consideration, pondering, and meta-cognition, I believe it’s because hg and git are so dang easy to type, and bzr and darcs are one-handed contortions to type. Try it:

hg st
hg ci
hg
hg
hg

git
git
git
git

bzr
bzr

darcs
darcs

Weird, but it made a difference. Pondering a little further, I realized that git and hg are just so dang fast compared to bzr and darcs as well. That makes a big difference as well, at least when running these little test cases in rapid succession one after another. There’s a software usability lesson to be learned here somewhere.

Renames

The other part of my evaluation was to see how each of these tools handled file and directory renaming. I came up with some scenarios that may seem pathological, but I’m pretty sure I’ve seen, or at least come close to seeing each one of these in my Clearcase usage (and usually it’s quite impressive in it’s handling of them).

In each case I created a repository and made a branch of that repository. I refer to the initial repository as the parent branch, or just parent, and the branch as the child branch, or just child. Read on to see how it all came out.

Scenario 1

1. renamed a file in parent
2. edited same file in child
3. merged from parent to child

It was expected that the merge would preserve the edits made in child and the file would be renamed properly. That would be, “the right thing.”

How they did

bzr did the right thing. It has a bzr mv command to rename files or directories. When you do the rename and then diff it just tells you that the file was renamed. In the child branch the merge worked flawlessly.

hg started asking me confusing questions on the merge that I didn’t want to have to think about, and we both got confused. I ended up with two copies of the file in the child, one with the old name and one with the new. At least the default version that apt-get installed on Ubuntu Edgy Eft, 0.9.1, did this. I downloaded and installed the latest version, 0.9.3, and repeated the exercise. It did the right thing that time. One complaint though, is that when you hg mv a file and then do hg status it shows you a delete of the original file name and an add of the new one. An hg diff shows you the entire contents of the file, twice, once for the deleted one, once for the added one.

git did the right thing. The interesting thing about git is that you can either use the git mv command to do this operation, just like any other version control tool, or you can use the regular old UNIX ‘mv’ command. After renaming the file with mv, git will notice that you have a new file which you can then ‘git add’. It will then figure out that it’s really just a renamed version of the original file. When you go do the merge in the child directory it does the right thing, either way you do it. I should note that using just the UNIX ‘mv’ command you get the full file when you do a git diff, similar to hg. If you use ‘git mv’ then ‘git diff’ will just say the file was renamed.

darcs did the right thing, very similar to bzr but with fewer commands needed.

Scenario 2

1. rename a directory in parent
2. edit a file in that directory in child
3. merge from parent to child

It was expected that the merge would rename the directory, and preserve the changes made in the file under that directory. That would be the right thing.

How they did

bzr did the right thing.

hg did the right thing (using 0.9.3 from here on out), but the child directory had two copies of the renamed the directory, the original name and the new name. If I clone the child though, it comes out with just the newly renamed directory and the correctly edited file. Kinda weird, but I would be surprised if it’s not fixed soon.

git did the right thing, using ‘git mv’ or just ‘mv’ to rename the directory. That’s just so cool how it figures these renames out like that.

darcs did it just fine.

Scenario 3

1. move a file from one directory to another in parent
2. edit that file in the child
3. merge from parent to child

It was expected that the file would be moved in the child while preserving the edits made to that file in the parent.

How they did

bzr handled it just fine.

hg handled it just fine.

git handled it just fine

darcs handled it just fine

Scenario 4

1. rename file in parent
2. edit same file in parent
3. make a conflicting edit of same file in child (no rename)

It was expected that on the merge, the file would be renamed with some sort of conflict resolution taking place.

How they did

A few more details this time, to try and give a feel for how working with each one is.

bzr I remembered to merge, not pull, and it informed me there was a conflict in the file, with the new filename. I then manually opened the file, found the cvs-like conflict markers it had inserted in the file, and resolved the conflict. Then I couldn’t just commit after resolving the conflict, I had to ‘bzr resolve FILE’, then ‘bzr commit’. A lot of steps , but at least it was helpful and walked me through it. It could have been even more helpful and just done it for me!

hg it said it was merging the oldfilename with the newfilename, and then popped up my three-way diff tool that I had configured (emacs ediff, awesome tool, by the way). After resolving the conflicts with that (no manual editing or cvs-like conflict markers needed) the diff showed the whole freaking file, twice. Not very helpful. Then I checked in and everything was fine.

git told me there was a conflict in the newly renamed file. I then manually opened the file, found the cvs-like conflict markers, and resolved the conflict. After resolving the conflict the diff just listed the new filename, twice, which is kinda weird. Then it just needed a ‘git commit -a’.

darcs informed me there was a conflict in the file, with the new filename. I then manually opened the file, found the cvs-like conflict markers, and resolved the conflict. Then it just needed a ‘darcs record’. Very straightforward.

Conclusion

All four of these revision control tools handle merging as well as Clearcase, without the need for a dedicated IT professional supporting a specialized server. They also do renames, as well as all the other basics you expect from a revision control tool. They also have some innovative new features beyond branching and renaming that I haven’t talked about, things like emailed patches, bisect, tarball exports, hooks, plugins, and so forth. You really should try one of them out.

But which one? All seem to be reasonably usable. Darcs still reportedly has a deep, serious bug. Don’t use it (though it is nice). The other three have slight differences. Git supports easiest renaming and moving of files, because you can just use the UNIX commands to do it all, then a single ‘git add’ to pick up all the changes. However its diffs don’t show you want happened with all the renaming as well as bzr’s. Hg’s diffs are just as unhelpful as gits, maybe even less helpful. So for a project where I expect to do a lot of renaming and moving of files, hg probably isn’t the way to go for now. I’m leaning slightly toward bzr because of the more straightforward diff output. For a project where files are pretty much going to stay put I’ll probably use hg because its so fun to type, and it’s just so dang fast. In the end you are a big boy or girl. You can decide for yourself.

---

P.S. O CSS wizards, my table is too wide for my blogger template. I tried really hard to get Google to tell me how to fix it. I thought maybe I could use the overflow property to make it scroll horizontally, like my preformmated text, but to no avail. Any help would be greatly appreciated.

UPDATE: Thanks for the css tips in the comments! Wrapping the table with a div and then adding the overflow:auto for the div was what finally worked. Well, at least on Firefox. Who cares about anything else, right? ;-)

Why the Switch to Ubuntu?

This was originally posted on my family blog on 4/26/06. I will be slowly moving the geeky stuff from there to this blog.

My good friend Nolan asked why I switched to Ubuntu, or more general, how did I choose my linux distribution? Easy, I just used the linux distribution chooser!

OK, not really. Here's the long story. I first used Caldera OpenLinux, mainly because the company was practically just down the street from where I lived. Then I switched to RedHat because there was a lot more help online, since way more people used it. Then I found Mandrake. I didn't need any online help, most everything just worked, and it has this fabulous control center with fairly intuitive GUIs for configuring more advanced stuff that I had never tried, like firewalls and internet connection sharing and the like. It also made installing rpms much much easier because it had this awesome tool called urpmi that automatically downloaded dependencies and installed them for you. There was even a urpmi repository that had all the really good stuff like windoze media player and quicktime codecs, libdvdcss, and some mozilla plugins. Ahhh, life was good with Mandrake, even after they changed their name to Mandriva.

However, lately everyone on the internet has been talking about this new distribution called Ubuntu. I checked out the website, and gave it a try on my old laptop. I liked it, and the online documentation was very thorough--it more than made up for Mandriva's flashy GUIs. Any question I had was answered there. I was impressed...

... and here's where I should mention the one nagging thing about Mandriva that bothered me. It was that it was difficult and scary to upgrade from one release to the next. The upgrade option on the CDs never quite worked, so I'd have to back everything up, and do a fresh install, and then restore from the backup, and reconfigure all my config files, and it was a pain. I've always been jealous of the Debian users. Debian has the original packaging tool that automatically downloads and install dependencies, apt. Apt is so awesome, I've always read, that to upgrade from one Debian release to the next you just change your repositories from your current release to the next one, type 'apt-get upgrade' (or something like that), and like magic it brings you up to the next release. This is what I want. Plus, Debian was created by a fellow Murdock. How cool is that? I never switched to Debian though, because it was so rough around the user experience edges and notorious for being difficult to install (the joke is, since apt is so great, you only ever have to install Debian once. Why bother to make a nice installer?).

So back to Ubuntu. Ubuntu is based on Debian, it has an easy installer, a real focus on home desktop usability, great online docs, and the famous apt packaging tool. As long as it does everything else that Mandriva has always done for me, the switch should only be positive.

I was having trouble however, getting Ubuntu to do the firefox plugins and media codecs like Mandriva could do. The killer test was always the quicktime movie trailers. I couldn't get Ubuntu to play them, until I found Automatix. Automatix is by far the coolest Linux utility ever. It takes a fresh Ubuntu install and automatically adds all the firefox plugins you need: java, codecs, media players, acrobat reader, flash, etc.; plus dvd players and rippers, cd and dvd burning software, mp3 players, Nvidia drivers, torrent clients, windoze fonts, and everything else a Linux distribution needs but isn't quite licensed to distribute. All of it. You just run it, reboot, and you are there. It is so sweet. It only works on Ubuntu, and it finally made up my mind.

Well, there you go, Nolan. If you ever have time to read all that, I hope it helps you decide (and remember, usually your best friend's favorite distro is the one you can most easily get help with).

Easy File Sharing with Samba

This was originally posted on my family blog on 4/23/06. I will be slowly moving the geeky stuff from there to this blog.

Setting up file sharing on my new Ubuntu install was super easy, I just followed these samba instructions. Now I can access my files from my windoze work laptop when I'm on my home network.