As I mentioned in my last post, I managed to erase my hard drive and ruin my productivity for a week all in one fell swoop. Since I didn’t have a Vista install disk handy, I had to make do with Ubuntu Linux for over a week while I waited for Microsoft to send me a replacement. Obviously life doesn’t just pause and wait for my computer to catch up, so I was literally forced to use Linux on a daily basis for exactly the same things that I would normally use Windows. This gave me quite a unique opportunity: A chance to test out an alternate OS under identical circumstances to its competitor.
The first thing on my list to try was enabling Compiz. Yes, I know it’s mostly eye-candy, but there’s also some very useful stuff in there. 3D compositing is extremely useful in a WS if for no other reason than the UI always feels sprightly and responsive, rather than a constant frustrating shade of low-performance. For example, if you drag a window in vanilla Gnome, there’s repaint lag. Imperceptible though it may be on most modern systems, it’s still there. If you drag a Window with Compiz enabled, the lag virtually goes away. Also, if a window stops responding, Compiz drops its color saturation (similar to Vista’s white overlay), whereas on a non-composited WS, the app would just freeze and stop painting. Other Compiz treats like subtle shadows (which really help the eye to differentiate windows quickly), a slicker workspace switcher and a really nice expose clone all combine to produce a very competitive environment for those of us coming from the likes of Vista and Leopard.
The downside is it’s very difficult to get working. As with all things Linux: if you want it done right, you have to do it yourself. Actually, with Linux it’s more like: If you want it done, you have to do it yourself without documentation. One of Ubuntu Gutsy Gibbon’s big selling points is that it’s so easy to get working out of the box. One of the hot new features being pushed by Canonical is that Compiz is now enabled by default on installations. This is supposed to mean that you don’t have to do anything to get it working. Unfortunately, it didn’t work out of the box for me (I have an ATI video card). The error message I got when trying to configure the “Desktop Effects” was utterly unhelpful, and I had to actually figure out for myself that I needed to manually install xserver-xgl (no documentation, no “helpful hints”, nothing). Even then, it still took a manual kick-in-the-pants to actually get Compiz running for the first time. And even then things still weren’t a hundred percent. Setting changes took a logout/login to apply (without any notice). Key combos conflicted and didn’t work half the time. All in all, it was a mess.
The second thing was to try to get Eclipse, jEdit and gnome-terminal into a usable state so that I could actually do real work with them. Fortunately, gnome-terminal is quite amenable to the effort. I daresay it’s probably the most polished app on the whole OS; everyone should be using it! So 30 seconds after I opened up gnome-terminal for the first time, I had disabled that oh-so-annoying terminal bell, set the colors to something a bit easier on the eyes and appended ~/.bin to my PATH. I figured the next easiest would probably be Eclipse. After all, Linux GTK is supposed to be SWT’s second most stable WS, and Eclipse itself has been running on Linux practically from version 1.0. Unfortunately, it wasn’t quite so simple…
Oh I didn’t have any real trouble getting Eclipse to start on my Linux system, but starting was about all it could do for a while. For one thing, it took me nearly three hours to get all of the Europa plugins I use installed again. Granted, it might have something to do with the major fall release coinciding with the day I was trying to configure my setup, but OSU’s servers are faster than that. I’m guessing there was something weird going on within the update manager that doesn’t normally happen on Windows (it usually takes me about 10 minutes to configure a fresh Eclipse install). Once I had gotten everything installed, I tried to open up my old workspaces. It was about this point that I started to run into trouble.
Everyone should know better than to try to open up a workspace from another system unmodified on a completely different one; especially when crossing OSes. That’s not to say that I haven’t successfully performed such a procedure in the past, but I didn’t want to take any chances with another three hour wait. I did the “right thing” and deleted the .metadata directory and open the workspace afresh. First thing, I used the handy “Import Preferences” wizard to grab all of my saved syntax highlighting, font sizes and classpath variables from a previously exported .epf file. I sucked the preferences into my workspace, looked around, and everything seemed dandy.
At least, it did until I hit the “User Libraries” preference pane. Here, Eclipse gave me an error (something about absolute paths and IClasspath) and refused to show the pane. This was a situation where something was wrong with the underlying preference for the user libraries and Eclipse wasn’t even allowing me to dig in and fix it! After messing around with the internal structure of the .metadata directory for an hour or so, trying to erase just that particular preference set, I gave up in disgust, deleted the .metadata directory and started again.
This time, I ran the .epf file through sed (one of the many advantages of once again having a Linux shell at my disposal) and got rid of all the “C:” instances throughout the file. Eclipse seemed to like this a lot better, and actually deigned to show me the preference pane this time, without the annoying error. I was able to change all of the paths for the libraries, and once again things compiled nicely.
Unfortunately, not every user is going to have the know-how to do what I did. I hate to sound immodest, but I do have a bit more Eclipse experience than the average Joe trying to switch his environment from Windows to Linux (a common occurrence these days). If a problem arising from a common operation leaves me scratching my head for over an hour, it’s probably something which should be addressed. This sort of complete blocker of a problem which necessitates manual hacking of auto-generated files is really a big no-no. I may have gotten it working in the end, but the point is that it wasn’t easy. All it happened to be was yet another source of stress to load onto my already bursting plyurethane sphere.
Tools and the Environment
Ironically, configuring jEdit was a walk in the park, especially compared to Eclipse. All I needed to do was download the .deb package from jedit.org, provide my user password, copy over my modified JAR (some things just can’t be fixed in the preferences) and away I went. Ten minutes later I had all my favorite plugins installed and I was developing with pleasure random bash scripts on remote servers. It still took a little Linux foo to get the warm start working, but compared to what I had been through with the Eclipse setup, it was a walk in the park.
After this, there were no more “big things” to get setup. I had more-or-less everything I needed to be productive once more, so I turned my attention to the smaller things (yes, I do count 3D compisiting as a “big thing”). My first task was to disable the track pad and enable center button scrolling on my ThinkPad. As it turns out, center button scrolling is as easy as telling xserver to emulate a 3-button mouse. Unfortunately, it seems that disabling the track pad was a bit more complex. I discovered (to my surprise) that there is actually no way to do this in Linux itself. I had to go into the BIOS and completely deactivate the device, just to keep it from randomly firing when I brushed it with my palm.
Here I also started to look into things like fonts. Unfortunately, even installing the Windows fonts package didn’t improve the situation. Linux has an excellent renderer if all you want to display is Monospace 10pt (which it renders quite nicely), but anything else looks terrible at low sizes and “not quite relaxing” when larger. Unfortunately, fonts are like the wind: sometimes pleasant, sometimes annoying as hell, always unfixable.
So I decided to set my sights on a more attainable goal and focused on the mouse acceleration curve. Windows Vista has a very nice feature which adaptively adjusts the mouse curve based on speed, making the mouse more precise at low speeds and more responsive at high speeds. This leads to a general feeling of greater ease in mousing. You don’t really notice what a difference this makes until you try to wrestle the mouse from point A to point B on a system which doesn’t have such a nice curvature.
Anyway, adjusting the mouse curve seems like a pretty normal thing to want to do, right? Linux is supposed to be an incredibly configurable operating system, so I figured I shouldn’t have a problem. Well as it turns out, there is no way to do this in xserver. I couldn’t find any tool, any how-to anywhere which gave instruction on how to rectify this glaring lack of control. After wasting quite a bit of time Googling around and browsing “man xorg.conf”, I threw in the towel and decided to put up with the sore mouse-finger for a week.
Linux is great. (what, not the conclusion you were expecting?) I absolutely love Linux’s terminal, startup times (roughly 3x faster than Vista) and file systems (with ReiserFS managing /home, my perceived FS speeds were in the range of 2x better than NTFS on the same drive). Unfortunately, Linux just doesn’t have what it takes to be a desktop operating system for the average user. What I mean by this is it just takes too much manual tweaking and fussing to get things to work right. As a developer, I may have the ability to fix little glitches that arise in my environment, but that doesn’t mean I have the time or inclination. I want something that works…now; and I don’t want to lose hair over whether or not the graphical environment is even going to start on the next boot. I guess it’s back to Vista for me! *sigh*