As some of you know, I run SUSE Linux Enterprise Desktop (SLED) on my CBC-issued desktop. CBC.ca also uses a combination of SUSE Linux Enterprise Server 9 and 10 systems to produce and host the website, and most of the corporate infrastructure is Novell-based (Novell Groupwise is the corporate e-mail system, the file servers are all Netware, etc.) I use SLED because it gives me the right balance of being a UNIX-like operating system, and giving me access to corporate file shares through eDirectory. But let me be clear: I use SLED because it’s UNIX-like, just as we use SLES on the servers because it’s UNIX-like. One element of SLED/SLES that is distinctly not UNIX-like is the package management toolchain, ZenWorks Linux Management (ZLM). And that really bothers me.
Let’s start off with a little history of ZLM, as I understand it. Back in the day, there was a little startup called Ximian, who created add-ons for Linux distributions (including Fedora Core‘s predecessor, Red Hat Linux) to make the desktop environment a little friendlier. They dubbed this line of products Ximian Desktop, and it included useful applications like Ximian Evolution, a product that I still use for my home e-mail. They also created a package management solution to go along with Ximian Desktop, called Red Carpet, because Red Hat’s package management/update program, up2date, only worked with Red Hat’s own servers. Plus, it was slow and lacked important features like the ability to roll back RPM transactions, etc. (I have also trashed many an rpmdb using up2date due to concurrency bugs.)
Eventually Ximian started selling Red Carpet (and Red Carpet Server) as an enterprise-scale RPM management solution supporting other Linux distributions, such as Red Hat Enterprise Linux, Red Hat Advanced Server, and SuSE Linux. Novell purchased Ximian on August 4, 2003, and eventually rebranded the Red Carpet line of products as ZENWorks Linux Management. Red Carpet was re-released under the Novell banner as ZLM 6.x., and is a PHP-based web interface backed by a PostgreSQL database, with client and server portions (rcd and rcserver respectively) written in Python.
ZLM 6.x is admittedly somewhat buggy, but its core functions, for the most part, work. It’s clear that the original implementation (under the Red Carpet name) was intended only for desktop deployment, and some of the features required in an enterprise package management solution were tacked on later and don’t scale or function so well. Still, the fact that it’s written in reasonably lightweight languages like PHP and Python means that it performs well, and also that it’s “UNIXy”.
In late 2005, Novell announced the release of ZENworks Linux Management 7, which was a ground-up rewrite of ZLM. Amazingly, they decided to rewrite it in Mono. Now remember what I said about UNIX admins choosing SLED/SLES because it’s “UNIXy”? Mono is most definitely not UNIXy. Writing a core system component in a non-UNIXy way on a UNIX system is a sure way to drive UNIX admins away. It leads me to question again whether Novell really actually gets Linux.
When Novell started down the open-source path and made announcements like “Linux is the future” and began to gobble up open-source companies like Ximian and SUSE AG, there was a lot of fear expressed in the Linux community about how Novell was going to wreck some perfectly good Linux products like they’ve wrecked WordPerfect, Quattro Pro and Caldera. Novell quelled some of these fears by putting their money where their mouth was; namely, by providing a decent migration path away from Netware and towards Linux with their Open Enterprise Server product. The acquisition of SUSE seemed to make particular sense. But then, out of nowhere, they create a core infrastructure component using .NET that is buggy, slow, and won’t even run on SLES 10! (at least the ZLM server end) What were they thinking?
As far as I can see it, Novell’s last chance to make a decent stab at the enterprise Linux market (and to compete against Red Hat) is to make SLES 10 a stable, standards-based Linux with a knowledgeable support team, with no Mono or .NET funny business. Otherwise, they’ll drive the UNIX admins away towards Red Hat, and SLES will end up being the platform of choice to… host Groupwise.