Projects in the works

By Jason Brooks  |  Posted 2007-07-19 Print this article Print

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, 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.

As Editor in Chief of eWEEK Labs, Jason Brooks manages the Labs team and is responsible for eWEEK's print edition. Brooks joined eWEEK in 1999, and has covered wireless networking, office productivity suites, mobile devices, Windows, virtualization, and desktops and notebooks. JasonÔÇÖs coverage is currently focused on Linux and Unix operating systems, open-source software and licensing, cloud computing and Software as a Service. Follow Jason on Twitter at jasonbrooks, or reach him by email at

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel