At first glance, Novell’s SUSE Linux Enterprise Desktop 11 (SLED 11) isvirtually indistinguishable from the company’s Free/Open Source and community supported Linux distribution, openSUSE 11.1. But does SLED 11 have the extra polish and the value add to justify its position as Novell’s premier enterprise desktop OS?
Back in December of last year, I gave out some tough criticism on Novell’s openSUSE project for what I thought was a premature and unpolished community Linux distribution in their openSUSE 11.1 release. With community supported distributions, however, you have to be willing to give these projects a great deal of slack, as they aren’t expected to be used and treated like commercial software products.
That being said, knowing that Novell’s first enterprise product completely based on the openSUSE codebase was due in Q1 of 2009, just around the corner, I expected much of this to be resolved in upcoming openSUSE bugfixes and the SLE 11 release for Desktop and Server.
Unfortunately, I could not have been more optimistic and wrong about my expectations.
Over the last two weeks I’ve had the uh, <cough> pleasure of evaluating a very recent release candidate for SUSE Linux Enterprise Desktop 11. To bring some perspective into this review I’d like to revive an analogy I’ve made in the past with affection about SUSE being like a German-engineered high-performance luxury touring sedan. However in the case of SLED 11, I’d say Novell has released the Linux distribution equivalent of the 2002 BMW 7-Series. Deluxe and feature-packed, but so frustratingly flawed, unrefined and overly complicated it makes it excruciatingly difficult to love.
Novell has a lot riding on the SLE 11 release. The company has been suffering a number of financial setbacks due to the retreating economyand has had to lay off some critical members of staff, some of who have been programmers directly involved in the development of SUSE in Germany and in the US. This I believe has created a number of resource constraints on the company which has caused SLE to be rushed through development yielding an unpolished and largely untested product by previous SUSE standards which were extremely methodical by comparison.
Admittedly, Novell told me in a recent briefing that no end-user acceptance testing or usability studies were performed other than regular beta releases to partners and technical testers because the results of the usability studies that they commissioned for the previous release, SLED 10, were so overwhelmingly positive.
I’m sorry Novell, but you don’t change your entire base distribution development model from a completely closed and internalized process to one that is largely community-oriented and then introduce four years of software improvements in an enterprise desktop operating system without completely re-doing your usability studies. Your alliance with Microsoft and their experiences with rolling out Windows Vista should have least yielded that much useful advice.
Essentially, to produce SLED 11, Novell repackaged openSUSE 11.1 with new backgrounds and artwork and slapped a number of commercially licensed enhancements on top of it with twelve months of technical support for $120 per copy. If this product had six months of total development time and quality assurance invested by Novell I think it would be a generous estimate given the deliverable product that they’ve produced. Whatever creds Novell had for extensive regression testing their enterprise releases has completely fallen on its ass with SLED 11 as far as I am concerned.
First, let’s start with the good. Since SLED 11 is heavily based on openSUSE 11, which is a modern and completely up-to-date Linux distribution. it has all the features of that product along with a number of commercial enhancements:
* Commercial fonts have been licensed from AGFA Monotype Imagingwhich match the same typefaces that in in Windows and Microsoft Office, so that documents imported into Novell’s enhanced OpenOffice.org build in SLED 11 render in a more native fashion than with the basicOpenOffice.org build.
* SLED 11 includes the commercial Citrix Presentation Server (XenApp)ICA client for remote access to Windows and Linux applications on servers.
* Sun Java JRE 1.6 is included along with the java web start plugin for Firefox
* Adobe Flash Player 10 commercial license plug in included
* Commercial Fluendo Gstreamer codec for AAC has been included for compatability with iPod m4a files in the Banshee media player.
* Post General Availability, free copies of Likewise Enterprise will be available for download for enhanced Active Directory integration (In other words, Novell’s own basic Winbind integration in SLED is still insufficient for widespread enterprise deployment, this despite several years into their interoperability alliance with Microsoft)
* The Evolution mail client now supports Exchange 2007 mail and calendaring and Novell’s own GroupWise 8 enterprise messaging platform via native MAPI.
Various improvements which were initially introduced with prior versions of openSUSE are also included in SLED 11:
* Clone installations and network deployments of SLED 11 and SLES 11 can be accomplished thru AutoYaST (a process similar to Redhat’s Kickstart) or via image distribution with Novell’s ZENWorks Linux Management product version 7.3.
* Support for Microsoft .NET API with Mono, which is showcased the integrated Beagle desktop search, the Banshee media player, Tomboynote taker and F-Spot photo manager applications included with the release.
* Initial Silverlight and Microsoft WMA support with Moonlight 1.0 release.
* Support for enhanced power managment and CPU throttling
* A new PolicyKit GUI that allows for fine tuned User Access Control — restrict use of devices and desktop/OS privileges.
* “Technology Previews” of the Xen and KVM virtualization hypervisors.
* “One-Click Install” of applications from the openSUSE build service website.
And now, the gory details.
For my evaluation of SLED 11, Novell provided me with an HP mini-notebook with 3GB of RAM with the release candidate software pre-loaded. Despite Novell’s best intentions the keyboard on this device was too small for extended evaluation, so I burned a DVD from the ISO image that was included with the system and installed it on a Dell Inspiron 530 with 4GB of RAM, 500GB hard disk, Intel Q6600 quad-core processor and a nVidia 8500 card with integrated Intel audio chipset. This is the standard system I had been using for Windows Vista and Windows 7 testing.
The installation process itself was uneventful and straightforward, and is nearly identical to openSUSE’s. The main difference is that you have less package selection choice as SLED is a subset of openSUSE in terms of functionality, so certain things like legacy KDE 3.5 desktop support and more comprehensive developer packages are not included. The lack of developer packages or at least an option to include a package feed during install time is an omission I take serious issue with, as the environment should be self-hosting as a development platform. Additionally, the system prompts you to accept licenses for the various commercially licensed add-ons listed above.
The first problem I ran into was that the automatic nVidia driver install during the second stage installation process yielded a completely unusable system with an X Window server that refused to start. I had to go into the Xorg.conf file and revert the driver back to Xorg’s “nv” driver instead of the proprietary “nvidia” driver modules to get the GUI to start up again. According to Novell, this was a known issue due to a bad nVidia repository at the time the release candidate was issued and should be resolved on general release, but I have to question why they wouldn’t warn me about this or just disable this routine in the installer until it was resolved.
The next issue I had was a repeat performance of what happened to me with openSUSE 11.1 back in December — the default firewall settings are too aggressive and block SMB filesharing, and SLED’s samba services aren’t started by default, so Windows networking is broken out of the box. Again, “We’ll have it fixed in release, we promise” was Novell’s response. How they did not catch this through beta testing absolutely bewilders me, because this is very basic functionality for an enterprise desktop, particularly one which is geared towards being a drop-in Windows replacement. Did I fix it? Yeah, all it required was disabling the firewall and turning the samba services on as the superuser, but your typical end-user in an enterprise environment would have no clue how as how to do this, let alone your typical openSUSE user. If Novell is assuming the enterprise or the OEM would do this during image or scripted install deployment, it’s a stupid assumption because not everyone is going to deploy desktops this way.
My next major problem was installing 3rd-party applications written for SUSE. I tried installing Sun’s xVM VirtualBox by double-clicking on the downloaded RPM file, only to discover that there were unresolvable package dependencies because the “pango-devel” pre-requisite package was not installed. Okay, so I attempted to do a “zypper install pango-devel” from the command line while logged in as the superuser. BZZT! “no such package“. Wha? Not even on the SLED 11 DVD? I was able to resolve this by adding the openSUSE base repository using “zypper ar http://download.opensuse.org/distribution/11.1/repo/oss/ opensuse111” , installed the update repository with “zypper ar http://download.opensuse.org/update/11.1/ opensuse111-updates” and then issuing the “zypper install pango-devel” command to resolve the dependency. After installing the pre-requisite package, I was able to double-click on the VirtualBox RPM file to install it on the system and run the program.
Cluetrain to Novell: MAKE THE DEVELOPER PACKAGE REPOSITORIES AVAILABLE ON THE DVD.
The openSUSE repository came in handy later because I kept getting various errors about the Intel audio chipset sound device not working. A “zypper update” yielded several hundred megabytes of package updates and fixed the sound problem. Hooray for openSUSE and the community, but raspberries to Novell’s SLED 11 QA and UAT. Novell has also included an automated GUI-based update manager with SLED 11 but I was not supplied with a support entitlement for the purposes of my evaluation and the support repositories were not ready during the time of testing, so I have no feedback as to how well they work.
My gripes with SLED 11 are also not just related to Novell’s insufficient QA, although clearly this is the product’s biggest problem. I also have design issues as to how they laid out the interface for their updated “Slab” enhancements to GNOME. In both openSUSE 11.1 and SLED 11, there are 3 distinct “views” by which programs and settings can be accessed — a “Control Center”, an “Applications Browser” and then “Yast2″. Each of these views contains a large amounts of icons, particularly the “Applications Browser” which is several pages long.
This is so overwhelming that it takes a long time to figure out which interface a particular program or configuration option is actually located. This problem, which is a disease I shall refer to as “Iconitis” is also a design element I also take issue with in Windows Vista and Windows 7’s Control Panel, but Novell’s implementation is much more confusing and counter-intuitive. Ideally, I’d like to see ONE Control Panel/Applications Browser with organizational tabs or tree drill-downs so that you don’t have to switch between UIs to find what you need. Access to the Administrative icons should require super-user or authenticated user privileges. Can OEMs and Enterprises address the overwhelming amount of presented apps in the Application Browser using imaging and scripted installs? Yes, but Novell should not assume everyone is going to do this. The default install and menu configuration should not be this unweildy for an end-user.
While the technology itself in SLED 11 is impressive, Novell clearly has a lot of work to do before I can recommend deployment of SLED 11 as an enterprise desktop. Are these issues fixable? Yes, but I recommend that the openSUSE and SLE developer teams work much more closely together and rationalize their development processes, and that new usability studies be commissioned in order to flush out problems that might emerge in typical usage scenarios, and not usage by geeks or Linux enthusiasts.
by Jason Perlow