Was I Too Tough on RHEL?

In my recent review of Red Hat’s Red Hat Enterprise Linux 5 and its brand-new Xen virtualization features a bit of a hard time with regard to the limitations of its management tools. Relative to the products of VMware, the current market/mind share leader in x86 server virtualization, Red Hat’s Xen implementation has a decidedly do-it-yourself nature–less pointing and clicking and more configuration file editing and documentation digging. During an e-mail exchange about the review, a reader challenged me on whether it was fair to criticize RHEL 5’s graphical user interface limitations and remarked on his disgust at finding how many tasks in VMware are point-and-click-oriented. Disgust seems to me like a pretty extreme reaction to a software interface, but I think that people chafe at the idea that an inferior product with a newbie-oriented interface–the archetype of which being Windows–might trump an arguably technologically superior option that greets you instead with a blinking command-line cursor and a trove of config files. As the reader also pointed out, GUIs typically make things easy by limiting flexibility, and having your hands tied isn’t fun, even if the binding is being done by a friendly wizard. To be sure, I felt my own GUI-borne pain during my testing of VMware’s Virtual Infrastructure 3, which regresses significantly from VMware’s typically good cross-platform compatibility record by supporting only Windows for its VI3 management client. Along similar lines, while testing Virtual Iron 3.5, I felt the pinch of lacking direct control of the virtualization nodes that Virtual Iron governs instead through the graphical interface to its management server. However, the fact that GUIs come with their own limitations can’t completely eclipse the advantages that they can provide. For instance, I value the discoverability of GUIs–when I sit down in front of a new application, a nice GUI makes it much easier to poke around and figure out what the application is capable of and to try things out and get an idea of what works and what doesn’t. What’s more, using a well-designed GUI means not having to memorize commands and arguments and not having to worry about making config file syntax errors. Developing fluency in the command-line arcana that govern your applications of choice is a worthwhile goal, as such fluency enables you to speed, gurulike, through your tasks; to do so remotely just as easily as locally; and to script chains of operations for future use. There’s no denying, though, that a requirement for command-line gurudom presents a limitation on flexibility in its own way, as steep learning curves–be they for proprietary or free software–contribute to product lock-in. Rather than see a winner crowned in this age-old GUI vs. CLI (command-line interface) debate, I’m on the lookout for product interfaces that blend the benefits of the GUI and CLI approaches. For instance, I was impressed by the Web interface for the ZFS (Zettabyte File System) in Sun’s Solaris 10, update 6/06, with which I could point and click our way through ZFS operation while having the GUI helpfully display for me the CLI equivalent of the commands I executed. Another promising approach is that offered up by Microsoft’s new Windows PowerShell CLI, the object-oriented nature of which lends itself to the sort of discoverability I value in graphical interfaces. PowerShell’s Get-Member command made it easy for me to figure out what other commands could do for me and how I could use them. So, was I too tough on RHEL 5? Considering that the raison d’etre for Red Hat, as a company and a product, is to herd the best of the free software that’s available out there into easier-to-use, better-tested and more manageable configurations and considering the fact that users of server virtualization are almost certainly more interested in manipulating the contents of their virtual containers than in fussing with the containers themselves, I say no. What do you say?