When Microsofts Windows XP went gold back in the fall of 2001, the platform was, practically speaking, the only desktop operating system game in town. But is this town now big enough for Windows and Linux?
When XP first appeared, Microsoft Office had won the productivity suite wars, Internet Explorer had driven Netscape out of the Web browser market it had pioneered, and Linux, while beginning to gain steam as a server platform, was a desktop platform that only a true geek could love.
Today, OpenOffice.org has grown into a viable competitor to Microsoft Office, with enough clout to have forced Microsoft toward a dramatically more open file format strategy. Firefox has risen from the ashes of Netscape and—along with Opera, Safari and other smaller browser players—is steadily dismantling Internet Explorers market share. And the Linux desktop now boasts two major desktop environment options, GNOME and KDE, that have grown slick enough to deny Microsofts newest client operating system, Windows Vista, anything near the prima facie usability advantage that Windows enjoyed against the circa-2001 Linux desktop. Linux has certainly been a worthy competitor to Windows on the server side, but can Linux really challenge Windows as an enterprise desktop alternative? The definitive answer is, it depends.
The suitability of Linux as a desktop alternative to Windows depends on your applications, your hardware and your attachment to Microsoft applications, formats and protocols.
While Linux can serve very well today as a developer workstation or as a host through which to access Web or terminal server-based applications, Linux cannot yet be considered a drop-in replacement for Microsoft Windows on the mainstream enterprise desktop.
For Linux to make the mainstream enterprise desktop leap, the projects and providers that back the open-source operating system must do more to address the outstanding interoperability issues that stem from working in an environment in which Microsoft has made most of the rules—and has kept the rules close to its vest.
More importantly, however, the projects and vendors that have yoked their futures to Linux must get to work arranging and integrating the various components and capabilities that are available in the open-source world into a form that will enable companies to act on their displeasure with Microsoft. And they must do this without requiring the significant Linux integration resources currently required to roll out a Linux desktop that not only matches the Windows desktop, but that showcases the unique capabilities of the platform.
Windows Without a Phrasebook
One of the most apparent challenges in achieving drop-in status for desktop Linux is that posed by migrating Windows-only applications to Linux. Windows mighty desktop market share means that most desktop applications are written to run on Windows, with support for Linux and other platforms as an afterthought.
Wine, the open-source implementation of the Windows API for Linux and other Unix-based platforms, enables companies to run certain unmodified Windows applications directly on Linux. Wine can work acceptably in some cases (CodeWeavers CrossOver product supports Office 2003 and a handful of other Windows applications), and it can be made to work in others (Google Earth and Picassa for Linux are both powered by Wine). For most Windows applications, however, Wines application support is much too spotty to be relied on as the answer for Windows/Linux application support.
A more reliable route to running Windows software on a Linux desktop involves making the required Windows applications available to Linux clients through an application delivery product such as Terminal Services, although the network dependency inherent in this solution makes it a limited option in many situations.
Running a virtual copy of Windows within a Linux desktop is another alternative, but the complexity, management, hardware overhead and added costs of such a solution limits its attractiveness.
Office Formats
A better solution for working around Windows-only software is choosing Linux-native applications that consume and produce services and files in Microsoft formats and protocols. The trouble here is that key Microsoft formats and protocols are undocumented or otherwise closed off to open-source software.
One prominent example is Microsoft Office, the binary formats for which OpenOffice.org, Gnome Office, KOffice and Google Docs and Spreadsheets, among others, offer support that falls short of 100 percent compatibility.
The Office format filters for these applications handle simple documents rather well but can introduce small formatting errors in the sorts of complex documents that Microsoft Office users often produce.
The best way for companies interested in carving out a compatibility zone for Linux and other non-Windows platforms is to stick to creating formatting-heavy documents with applications that run on multiple platforms, such as OpenOffice.org.
Alternatively, companies that now collaborate on rich documents by shuttling formatting-rich files back and forth can reorient their workflows such that contributors work in a format no more complex than whats required to get their work done. For instance, it makes sense to contribute wording changes in plain text format, and leave desktop publishing tasks to a limited group of collaborators whore running the best software for the task at hand.
This way, your document creation processes will be able to handle contributions from any platform, be it a Web browser kiosk or home PC, a smart phone or a thick Windows Vista/Office 2007 rig.
Fortunately, the cross-application document support issue appears to be growing clearer, as Microsoft has moved to a new, XML-based document format (Office Open XML) in Office 2007 and has made available plug-ins to add OOXML support to previous versions of Office. Novell has added support for Office 2007s new OOXML-based .DOCX format in Novells version of OpenOffice.org, and this functionality will likely eventually make its way into the upstream version of OpenOffice.org.
Next Page: Projects in the works
Projects in the works
In addition, there are now three projects in the works for adding support for OpenOffice.orgs ODF file format to Office.
Got Mail?
Another major Windows interoperability challenge that Linux backers have not yet completely addressed is full support for Microsofts Exchange Server.
While IBMs Lotus Domino and Novells GroupWise each support Linux clients, the big name in enterprise groupware is Microsoft Exchange Server, and Exchange support on the Linux desktop leaves much to be desired.
Evolution, the most prominent groupware application for the Linux desktop, has shipped with a plug-in for accessing Exchanges mail and scheduling functionality since 2002, but the plug-in, called the Exchange Connector, has been dogged by performance and compatibility issues from the get-go.
The connector never supported Exchange 5.5, and eWeek Labs has had mixed results using the software with Exchange Server 2000, depending on the version of Evolution with which we were testing. In addition, the Exchange Connector does not currently support Exchange Server 2007. Finally, when the Connector does work, its performance falls short of Outlook running on Windows.
The problem with the Connector boils down to the fact that the software communicates with Exchange across the servers Outlook Web Access protocol, rather than with the MAPI (Messaging API) that Outlook uses to talk to Exchange. Theres an open-source project, called OpenChange, thats working on an Exchange MAPI plug-in for Evolution, but the code currently is in a rather immature state.
Its possible to access Exchange e-mail through any mail client via IMAP or POP mail, but this means leaving behind the additional groupware functionality, such as scheduling and access to contacts via the directory—in other words, the very features that have made Exchange a popular option for enterprise e-mail.
Its possible to make the Evolution Connector work with some finessing of your Exchange installation, and some intervention on the part of your Linux distributor. Novell officials told me, for instance, that their engineers offer hot fixes for customers to address Exchange Connector issues. However, the all-too-uncertain status of Exchange mail and scheduling access on Linux remains a real challenge for enterprises looking to roll out Linux on their desktops.
Connecting the Dots
For all the obvious application, protocol and document format challenges that Linux-backing vendors and Linux-deploying companies face attempting to fit the open-source operating system into the desktop mold that Windows has defined, the biggest hurdles lie just beyond the surface of the desktop.
Despite the quick progress toward—and, in some cases, beyond—usability and performance parity with Windows that desktop Linux has achieved, and despite the successes that Linux has achieved on enterprise servers, the link between the desktop and server remains too tenuous for desktop Linux acceptance to reach a tipping point. While packaged Linux management options, such as Novells Zenworks Linux Management and Centeris Likewise Management Suite, do exist, the Linux desktop lacks a client management framework that provides a coherent answer to Microsofts duo of Active Directory and Group Policy.
A large portion of the usability, management and performance gains that desktop Linux has accrued during the past several years has come as a result of Linux and open-source developers scratching the itches that directly affect these developers and their largely stand-alone workstation machines.
This is why the Linux desktop now boasts three-dimensional desktop effects that outstrip Windows Vista both in terms of variety and in hardware support, while projects devoted to desktop lockdown and profile management that predate 3-D efforts have moved very slowly by comparison.
The GNOME desktop environment, to which the enterprise Linux distributions from Red Hat and Novell default—and that also forms the default face of the popular Ubuntu Linux—provides a framework, called Gconf, for storing users application settings and for assigning mandatory settings defaults.
On its own, however, Gconf does not push out application settings, as Group Policy does, and the applications that Gconf manages are limited, for the most part, to those that ship with GNOME by default.
The GNOME environment ships with two other software components, called Sabayon and Pessulus, that allow, respectively, for defining user profiles and for locking down desktop settings. However, both of these components are still under development, and neither yet plays a significant role in GNOME-based Linux distributions.
According to the road map for GNOME Version 2.20 (which is slated to ship in September), the project plans to add lockdown support for OpenOffice.org, and provide a pluggable add-on framework through which developers could extend GNOME lockdown support to their own applications. However, the document also notes that the project is still in search of a volunteer to implement this key feature.
For the 2.22 release of GNOME, which should arrive roughly six months after 2.20, the road map lists lockdown support for the Evolution groupware application and the Gaim (now known as Pidgin) instant messaging client—both of which currently play a central role in the desktop releases of Red Hat, Novell and Ubuntu Linux, among others.
Beyond the interface and application lockdown control work thats left to be conquered by the GNOME project (and, separately, the KDE project, in the form of its Kiosktool) lies a deeper stratum of lockdown tasks. These tasks are located at the points where unprivileged user-space code interfaces with privileged system-level tasks, such as those related to hardware access. Red Hat has been at work building out this control layer in the form of a framework called Policy_Kit that should make its way into Fedora 8.
The pieces of the desktop Linux puzzle are within reach, but it may be some time before the picture is complete enough for the enterprise.
Check out eWEEK.coms for the latest open-source news, reviews and analysis.