One Wild Week with Ubuntu Linux

29
Oct
2007

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.

Compiz

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…

Eclipse

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.

Conclusion

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*

Filed in Linux, Eclipse | Comments (19)

Apple Blows Another Great Opportunity

27
Oct
2007

I hate to be yet another blogger taking a potshot at Apple in the wake of the Leopard release, but I just have to say it: Apple, WTF are you thinking?! There, I said it, now we can be rational about things.

For those of you living in very cramped fox-holes for the past two years, MacOS X 10.5 (Leopard) is Apple’s latest incarnation of the cult-classic OS, MacOS X. It’s got multiple workspaces, file system versioning, read-only ZFS support and eye-twisting shadows which make your desktop look about half a mile thick. It’s got a totally redesigned Finder (which coincidentally looks just like iTunes) and added eye candy for both the Dock and the menu bar. What it doesn’t have is Java 6.

Sun released Java 6 back in what, last November? Apple’s had quite a while to get their act in gear and bring the latest major release to the table. In fact, they’ve had even longer than a year, since Java 6 was in open development long before its release. Apple did release a few developer previous of Java 6 to ADC members, but they discontinued the practice several months ago and haven’t made anything available since. It’s not as bad as all that though, the preview releases weren’t too much more than a renamed Java 5 with a few new generic APIs. Either way, Apple really has no excuse for not having Java 6 ready at least to coincide with the latest version of its OS, if not sooner.

To be totally honest, I don’t see how Apple is even justifying this decision to itself and its stockholders. Consider how many Java developers have switched to Macintosh over the last few years. I can count on one hand the number of developers I know and respect who still use Windows or Linux as their primary development machine. It’s startling the shift in the market which has taken place, partially driven by Rails’s major push of TextMate and the waves it caused throughout the rest of the development community, but also caused by the fact that MacOS X really is a very slick, very stable BSD incarnation which can run smoothly as a desktop. Well, that and the fact that the Apple hardware just looks so cool.

The thing is, all of these Java developers who’ve switched to Mac recently are going to start second guessing that decision. Java 6 is now a year overdue for the Mac platform, and Apple is giving no indication of rectifying the situation any time soon. What’s worse, is the version of Java 5 which does come pre-installed on Leopard seems buggy and unstable (disclaimer: I haven’t actually tested this myself, I just have it on good authority). Without a modern, stable Java, many developers will be simply unable to use the platform as their primary system. And guess where these developers will turn? Either to Linux and all the headaches thereof, or back into Microsoft’s waiting (and well-patented) arms. Is Apple really so big that it can just give the finger to such a large market segment?

Consider too, what this is going to mean for the future of the Mac platform. In the last couple years, we’ve seen a vast increase in the quality and quantity of applications available for Macintosh. I don’t think that it’s a coincidence that this has correlated directly with the up-surge in developers switching their primary platform to OS X. Think about it, developers who use a certain platform are going to write software with that platform in mind. It’s only natural. With more and more developers focusing on Macintosh, the quality of applications for the platform increases, as well as number of new projects focusing exclusively or primarily on the platform for final deployment. In short, it’s exactly what Apple needs to make the platform a dominant player in the market 5 years from now. By flipping off the developers, Apple is basically saying “Yes, we know you want to write state-of-the-art applications that run exclusively on our platform, bringing more customers to our outlet stores, but the fact is that we don’t want you writing applications for our platform. Have you heard of Linux?”

Now I know that speaking out against Apple is like blaspheming a divinity, people have been stoned for less, but it still needs to be said. For the record, I like Macintosh. I like the Apple products, and I’ve always loved the Mac OS (ever since my first computer running OS 7). That said, I have never liked Apple as a company, and this latest fiasco is reminding me why not. Hopefully Apple will see the error of their ways and offer Java 6 as an update sooner rather than later. And if not, there’s always Windows!

Filed in Java | Comments (14)

WTP’s Crazy (and undocumented) Setting Change

12
Oct
2007

I’ve been working recently on a Wicket-based project for a company called Teachscape. Not only is it based on Wicket, but the project is also designed to be run within Jetty, as opposed to the traditional Tomcat or Glassfish deployment. This makes local development a lot easier to handle, since you just fire a main-class (which instantiates and starts Jetty) and away you go. Well, theoretically anyway…

Since it’s a Wicket-based project, all of the HTML files are thrown in with the Java sources and must be on the classpath along with the compiled classes. The problem is, lately my copy of Eclipse wasn’t doing that properly. Other Wicket projects on my system (using WTP) still seemed to work fine, but the Jetty-based project just didn’t want to run. It kept complaining about not being able to find the markup for a specific page. This is Wicket’s way of telling the developer that they probably forgot a HTML file somewhere.

Now I was able to manually verify that the file did exist in the appropriate directory, named correctly. It was in an Eclipse source dir which had no exclusion or inclusion rule which would exclude it (either explicitly or implicitly). In short, it should be on the classpath. Being savvy to Eclipse’s occasional classpath oddities, I fired a quick clean of the project and tried again. No luck. My next step was to do a clean checkout, re-gen the project meta files using Maven, and finally build and run. Once again, no dice. This was when I decided to spelunke a bit into the actual build output directory for the project. When in doubt, check it out by hand, right?

It turns out that none of the HTML files for any of the pages were being copied to the target directory. I found this more than a little odd, since I knew it was working before and (as I said) none of the source filters should have excluded anything. So I went in and changed the filters so that only **/*.html files should be included in the build. The result? An empty target directory. Not encouraging.

I tried copying over configurations, editing the .classpath file directly, even looking at the help documentation for JDT, still no luck. It was the first problem I’ve had with Eclipse in years which I haven’t been able to solve reasonably quickly or work-around. In short, I was stuck.

Out of sheer desperation, I started browsing through some of the Eclipse JDT and WTP preferences. I figured that WTP had to have something to do with all of this, since the builder was obviously treating HTML files in a special way and WTP is the only plugin I have installed which might do that. I came up empty on the WTP front, but when looking through the JDT builder prefs, I found this nugget:

wtp-screwup

What?! I honestly cannot think of any valid reason why I would want those resources excluded. WTP doesn’t require it. After removing these two lines (SVG files probably should be included in the build too), all of my WTP projects still run fine. In fact, since this preference was obviously added by WTP, it got me thinking: all of this worked fine not two days ago, what happened?

The answer is: I updated WTP. It seems the latest update of Eclipse WTP adds this preference into your JDT settings whether you want it or not. Not only that, but there seems to be no warnings, no documentation of any kind which would indicate its purpose or that it even made the change! I ask you: why was this necessary?

I lost literally hours of time trying to track this down. Granted, if I was more familiar with the “Output folder” preferences in the JDT compiler settings, maybe I would have figured it out sooner. But the point is not my less-than-perfect familiarity, the point is that this change seems to require the developer to have advanced knowledge of the Eclipse preference system, just to track down an apparent bug in their own project config. Bad move, WTP, very bad.

…now that the flames have died down: what is the purpose behind the exclusion of these resources anyway? If they don’t hurt anything in a WTP project, and they certainly wouldn’t mess with anything in a Java project, why exclude them? Also, in all fairness I really don’t know for certain that it was WTP that made the change. I updated the entire Europa train at the same time. Theoretically, any one of the projects could have made the undesirable modification. WTP just seemed the most likely since one of the exclusions was *.html, though PDT would be an equally valid guess.

Filed in Eclipse | Comments (4)

Is Windows Really the Best Development OS?

8
Oct
2007

I realize that the stated topic is a classic example of flame-bait, but it’s still a question which deserves some serious consideration. Is Windows really the best OS for a developer to use? And when I say developer, I mean someone like me who does a nice assortment of Java, Ruby, C++, etc. Obviously, someone who does .NET is probably using Windows (see my previous post), and someone writing Objective-C applications will nine-times-out-of-ten use MacOS X.

Java’s a bet less OS specific though. By it’s very nature, it’s cross-platform. Not only the language itself (like C++ is cross-platform), but the compiled binaries. I don’t have to worry about having a Mac handy to compile a snapshot of an application for my boss, I can just send him a JAR I assembled on my laptop running Vista. In this respect, I can consider myself completely liberated from OS-level concerns.

Tools are also not really an issue. After all, the three best Java development tools (Eclipse, NetBeans and IntelliJ, in that order) are all based on Java. I don’t have to worry about learning a new application to do development, or concern myself with rebuilding all my settings in an unfamiliar environment. I can setup a fresh machine running any OS with Eclipse and my favorite formatting and syntax highlighting configuration in under an hour (download time included). In fact, I’ve availed myself of this fact many times.

So if tools and language aren’t a concern, what is? Well, it turns out that tools really are worth examining, and I mean deeper than face-value IDE. For example, MacOS X supports the fantastic editor TextMate. jEdit is a worthy substitute which runs on any platform, but it’s just not as polished as TextMate. Also worthy of consideration, and indeed a far larger issue for me, is the non-existence of a decent shell on Windows. PowerShell isn’t bad, but I’m sorry, it’s no bash. I had to make some (reasonably) generic changes to a set of config files on my server the other day. Since I was on Linux, all it took was a simple for loop, a couple greps piped to sed and then back into the files, and I was home free. If I was on Windows, it would have taken me at least ten minutes of tedious open-file, copy/paste/reshuffle, save, close, open next file, etc. In short, Linux saved me quite a bit of time out of my day, just by having a superior shell. Mac offers the same advantage, though its version of the GNU utils isn’t as up-to-date as my Gentoo Linux server.

Another thing to consider is space-efficiency. I have a reasonably high-resolution screen, but even with such a dazzlingly large workspace, I hate to waste even a single 1px line. This includes things like fonts and how legibly they render at low sizes. I save literally inches of space in Eclipse by setting the editor font size to 10pt, and that’s just a single application. Scaling the issue up to an entire WS just compounds both the benefits and the consequences. In both of these areas, Windows (especially Vista) seems to excel beyond the competition. I hate to say it, but I think Windows got something right on which Mac and Gnome (Linux) are missing the mark. Just consider the following screenshots:

vista

gnome

Notice how even though the Vista window title bars are a bit larger, the fonts are a shade smaller. In Gnome, I have to leave the font-size that high, because the window titles become unreadable and ugly at any lower level. Also notice how the menu height on Gnome is significantly larger than Vista. Even more importantly, the tab size within Eclipse is almost a third larger than the corresponding tab in Windows (due to the larger font size). The toolbar is taller, and the fonts are just a shade larger for the same size and DPI (Consolas vs Monospace). All in all, there are almost 20-30 pixels of height wasted in Gnome vs Windows. Granted, Mac doesn’t waste quite as much space, but in my experience, most things are just a shade less compact than on Windows.

The larger issue I have with Mac is extreme mouse-oriented nature. This makes it great for beginners, but even with Quicksilver, I still find myself reaching for the mouse more often than I’d like. Gnome isn’t bad for this, having most of the same keyboard features as Windows (especially with Deskbar), but it’s just not as slick as Vista with the QuickSearch. And yes, I do know the shortcuts for both Mac and Linux as well as I do for Windows, as I’ve been using both platforms for years. In fact, my first computer was a Mac, and that was all I used for a long time.

So all in all, the question is: how do the pros and cons match up? I would love to have the real shell, real gcc and real permissions system that Linux offers, but I would hate to give up the font renderer and slick power-user features of Windows. I could go with a Mac, but the keyboard is important. And on top of that, so many cross-platform applications just aren’t up to snuff on Mac, failing to do things “the Mac way”.

So with great disappointment, I’m afraid I’ll have to stick with Windows for the time being. However, as my friend Lowell points out, I can just as easily build myself a second machine which runs Linux primarily. This way, I can get all of the benefits of Linux as a primary machine, but still retaining the power and application support of Windows. Maybe this is the best way to go. Hopefully this will work out as the best balance overall.

Filed in Java, Eclipse | Comments (26)

MonoDevelop: The .NET Developer’s Linux Outlet

4
Oct
2007

I’ve done my fair share of .NET development. I’ve never actually enjoyed it, nor would I want to make a living out of it, but I have done some. Every time, I’ve been forced to work on Windows to do any serious project. Granted, jEdit can get you awfully far in terms of source editing, but unfortunately (?) it’s no IDE. Really, the only way to do serious .NET development is to use VisualStudio.

Now, for a number of reasons (none of which are important right now), I’m already using Windows as my primary OS. However, I don’t like being boxed into one OS or another. I try to keep my options open. If I ever could cut those final ties to Windows, I’d love to switch to Linux or Mac. Also, I just don’t like feeling forced to do something in a certain way. With Java, I can write the code in Eclipse, NetBeans, jEdit or Notepad for all my employer cares, just as long as it gets done. With .NET, I really don’t have any choice but to use Windows.

Well, until nowish. MonoDevelop recently announced the release of 1.0 beta 1. From what I’ve read, things are still comparatively unstable, but the features are all there and bug fixing is proceeding apace. Also, for the first time it seems that they’re offering some binary packages, allowing users to install easily rather than wrestling with the sources for hours and hours (which is what happened to me last time I tried MonoDevelop).

Actually, the bigger news for me is the addition of all of the “serious coding” features. Things like content assist, searching, error-underlining, etc. These are huge when working on a non-trivial project. In fact, these are precisely the reason I tied myself to Windows and VisualStudio for .NET development rather than just using jEdit or VIM on Linux. Last time I tried MonoDevelop (back in like, 0.2), it really wasn’t more than a glorified text editor with syntax highlighting. Now, it’s a full-fledged IDE.

As far as I’m concerned, MonoDevelop has reached the point where it can be considered as a serious VisualStudio on Linux. In fact, from what I’ve seen it’s at a level where .NET developers need no longer consider themselves tied to Windows just for the tools.

Of course, the big problem is MonoDevelop is a tool to write code that runs in Mono (hence the name), not really .NET. Technically, the two platforms are very very close, but .NET has some libraries and provides certain functionality that Mono just doesn’t emulate yet (things like the win32 API). Also, Mono is a black-box port, so there are bound to be some inconsistencies in behavior here and there. As a result, you can probably write your .NET application on Linux using Mono, but you had better test it running on Windows and the CLR. Otherwise you can never really be sure that your app is doing what you want it to on Windows.

But on the whole, I think this is great news! MonoDevelop gives .NET developers a nice (and free) alternative to VisualStudio, not to mention the benefit of unfettering these developers from the Windows platform. Just one more way to thumb your nose at the boys in Redmond and support FOSS.

Update: The How-To Geek has some excellent instructions on how to install the latest version of MonoDevelop on Ubuntu.

Filed in .NET | Comments (2)