For some reason, the suggested drive type when create a new virtual image is SCSI. I found a discussion that suggested that SCSI was slower to emulate than IDE, because it was more complex. Admittedly that discussion was for Microsoft’s offering. At any rate, couldn’t find anything for SCSI as a default.

For my purposes, however, performance isn’t that important. Lacking a reason not to, I went with the default. I then discovered a reason not to use the default.

I run Ubuntu as my host OS, and the VM in question is a vanilla Debian install. Burning a CD (i.e. using cdrecord) seems to affect the virtual machine in some odd fashion. I know cdrecord accesses the burner as if it was a SCSI device, and the error message that shows up in the virtual machine’s console was something to the effect of “SCSI device reset…”.

The net effect, however, is that running cdrecord in the host OS puts the virtual machine’s SCSI hard drive offline. After running cdrecord in the host, it was no longer possible to log in, via console or ssh - presumably because the disk was gone, as console echoing worked, as did ping.

Fortunately, I was able to transfer the entire system in-kind to a new virtual IDE disk I created. I tried to file a bug with VMWare, but gave up trying to find a place to file a bug that didn’t require me to have paid support.

I prefer not to write GUIs.  GUI programming can be fun in its own right, but GUI libraries tend to be particularly “quirky”.  I don’t like learning a style that can sometimes be very arbitrary.  Also, “everyone’s an expert” when it comes to evaluating a GUI, which can be frustrating at times.

So when I needed to write a small tool to assist with testing, I thought to use NetBeans and its “Project Matisse” GUI builder to avoid forgotten Swing APIs.

From a GUI perspective, the application called for some simple text fields, lists, and buttons.  Nothing fancy at all, perhaps a half-dozen widgets, discounting panels and labels.

Having completed the application (a day or two’s work), I conclude that NetBeans as an IDE isn’t a replacement for Eclipse.  The advantage of Eclipse’s rich plugin community and general first-mover advantage aside, NetBeans is deficient in a at least a few ways that are readily apparent.  I offer the caveat that it’s possible I simply don’t know my way around NetBeans, rather than it being that NetBeans is deficient.

The auto-completion is case sensitive.  This is seemingly minor, but frustrating.  For instance, typing in setv yields no results, but typing in setV shows setValue().  I usually type around 90%+ accuracy, but coming from the less picky Eclipse makes NetBeans’ behaviour unpleasant.

I couldn’t find an equivalent to Eclipse’s Quickfix ability (Ctrl+1).  While NetBeans could correct missing imports as part of its Organize Imports ability, uncaught exceptions had to be manually addressed, rather than being able to auto-generate a skeleton try-catch block.

In order to add a library dependency to the project, I had to define the library and point to its binaries (and optional Javadocs).  That part is fine, but NetBeans would store the path reference absolutely rather than relative to the project root.  That works for a single developer on a single machine, but for multiple machines accessing a shared code repository, it doesn’t make any sense.  The project definition has to be checked in, yet by design it stores information in such a way that makes it unlikely to work on any other machine.  I tried editing the XML directly to use relative paths, but that didn’t work.

As a GUI builder, however, NetBeans is pretty good.  There’s the typical drag-and-drop of components onto the panel.  More notably, as you move and resize the widgets, the builder provide visual hints for alignment with a small dotted line that appears when you reach an “alignment point”.

I don’t know how the NetBeans documentation describes it, but the application will notice that the widget above is left aligned at a certain position, and so will hint when you’re at the same alignment.  It also correctly guesses that if you stretch the widget to the edge of the panel, you’re expecting it to resize with the window (e.g maximization).

There are similar visual cues for horizontal alignment.

The GUI builder did sometimes incorrectly guess how the widget should resize with the window.  It also occasionally would change the overall widget layout in a drastically incorrect manner if I dragged widgets in certain ways, e.g. tried to move to the far left an existing text field that was “locked in alignment” with some other widgets, and NetBeans shifted all the other widgets far to the right.  In all the cases I experienced, however, it was a matter of learning how NetBeans “thinks”, and working with the designer to do operations “in the right order”.  The “right order” wasn’t particularly odious to follow.

NetBeans also provided other typical GUI builder functionality, like displaying all the possible event handlers for a widget, property tables, and auto-generating the boilerplate skeleton for the method.  However, at this point I started to run into NetBeans’ shortcoming as an IDE again.

Renaming widget instance variables is possible from the designer, but it does not refactor any of the existing uses of that variable name.  One essentially has to name the widget correctly the first time it’s brought from the palette.

I also found it a little frustrating I couldn’t remove methods very easily.  When flipping from Design to Source mode, it appears that you get a text editing screen.  However, certain areas can’t be edited, such as the method signature of event handlers and the instance fields.  Unable to remove the method of a handler I was no longer interested in, I left it blank.  Unable to add my own instance fields, I didn’t bother reusing HttpConnection instances (it’s a test tool, so that’s okay from a quality perspective).

In the future, I’ll use NetBeans to do quick and dirty GUI applications, but for significant work, I can’t see myself using it.  The penalty in the IDE is too great.  Perhaps a hybrid approach, where the heavy lifting is done in a library written with Eclipse, and then create the GUI to call the library via NetBeans? 

I’d like to try an Eclipse/SWT GUI designer some time to compare, but the main drawback is that Swing is in the core Java runtime, while SWT is not.  However, the look of SWT, to compare Eclipse and NetBeans anyway, is much better than Swing; it might be worth the trouble in that respect.

I’ve been on a lengthy virtualization experiment, originally prompted by a desire to retire my old PCs to reduce noise and heat.  I tried out VMWare (Player 1.0, Workstation 5.5, Server 1.0 Beta, Server 1.0 Release), Parallels Workstation 2.1, and Virtual PC 2003 SP1.

Along the way, I also got in my head the notion that I could run most of my apps inside virtual machines, thereby better resisting driver problems and hardware upgrades.

I had a mediocre experience with Virtual PC.  The RedHat Fedora Core 5 install CD didn’t boot at all; it halted somewhere early in the kernel loading.  Debian Woody successfully installed, though.  Even using Windows, however, I found that on my desktop the VPC bootup sequence stalled my UI (mouse motion, etc.).  Other than that, it seemed acceptable.  While I have no real interest in RedHat, the inability (either in RedHat’s driver support or VPC’s support for RedHat) to run a Linux distro was disconcerting.  This was on a Windows host.

Parallels Workstation handled the previously mentioned three operating systems.  The price for Parallels is very good, too, virtually (ha) a two-for-one deal for the Windows and Linux versions.  Overall it seemed smooth, but as I intended to also do some development and deployment testing, I looked to VMWare’s snapshot ability with longing.  Regularly zipping up the virtual machine images is inconvenient and doesn’t scale very well - the disk space consumption would be enormous.  I was using the Windows version of Parallels.

VMWare Workstation, although expensive, works beautifully.  I really couldn’t find something I didn’t like about it: device support, snapshots, etc.  VMWare Player is essentially a light version of VMWare Workstation.  I initially tried Virtual Server while it was in Beta (it recently became a full release), but found Workstation easier and better to use.

Near the tail end of these experiments, I swapped over to a Linux host OS.  I figured if I was going to run everything inside a virtual machine, I should choose the fastest and most stable host OS.  While the performance difference may be arguable, Debian’s package management system definitely preserves stability over a long period of installing and uninstalling software.  I ran on Ubuntu, which is based on Debian.

I eventually settled on VMWare Server.  While VMWare Workstation has more advanced features, VMWare Server has many of the key characteristics I was looking for: ability to run headless VMs, snapshots, a good user interface to the VM desktops.  I only noticed Workstation’s Shared Folders and Team VMs (i.e. groups of VMs) missing.

In trying to pile all my activities into virtual machines, I learned of a couple serious limitations that ultimately led me back to using the host OS for desktop/workstation activities.

Sustained video and audio doesn’t work well.  While I could play movies and audio in a Linux VM and Windows VM, via the rich client VMWare GUI, it tended to be choppy, even with the VMtools acceleration utilities.

I had hoped to be able to connect to the Linux VM from the Linux host via the typical network based connectivity of X, but most movie players didn’t play at all. Performance also seemed sluggish. While VMWare successfully propagated USB devices to the VMs, the DVD burner wasn’t accessible.

Using the Shared Folders capability of VMWare Workstation, or a network file share in VMWare Server, was the biggest problem.  For raw computation or local activity, running inside a VM works really well.  Writing out of the VM, via the Shared Folders or a network share on a “fake” subnet shared with the host, was really slow.  I noticed that the speed of the network share improved from the beta to release of VMWare Server, but it was still about half the speed as running on a local hard drive and registered as a heavier load on the host system. It may not be a virtualization issue - even if it’s communication between a VM and its host, the network stack still has to be simulated, which probably eats up a lot of CPU at local disk bandwidths.

I’ve pretty happy with VMWare Server, and am in the midst of decommissioning my old K7 server.  I boot up Windows for key Windows-only software (like corporate remote access software).  It works really well.  I still cringe a little whenever I need to do sustained I/O, but as most of my workstation activities are done with the host OS, the VM-based workloads are infrequent and can often be sent to the background.

I’m a little annoyed that I spent so much time trying out virtualization this way and that.  Still, it’s useful to know the pros and cons of virtualization firsthand.  To recap: virtualization works better when headless, when used for bursty workloads, when I/O load is a small component, and when engaged in server-class activities rather than workstation activities.