RealTime IT News

OSDL Tackles Desktop Linux

The Open Source Development Labs (OSDL) wants to find out what's needed to make desktop Linux successful, so it launched an initiative on Monday to find out how to make that happen.

Originally drafted by OSDL members, the goal of the document, said Bill Weinberg, OSDL open source architecture specialist, is to attract the attention and feedback of independent software vendors (ISV), PC suppliers, end users and anyone else thinking about deploying or using Linux on the desktop.

"There's active debate around the desktop about whether choice is the best thing or unity is the best thing," he said. "Are multiple desktops good or bad for Linux and for open source? And there are diverging opinions there and it's all part of the healthy debate that's going on."

Desktop Linux Capabilities (DLC) v 1.0 is the culmination of a year's work at the OSDL's desktop Linux working group, which set out to create a specification to unify operating system client-side requirements.

The strategy of the working group, and its DLC, is to produce "a desktop system specification that stands on its own merits and exploits its own strengths," it states.

However, that doesn't mean it will try to emulate or replicate any existing desktop systems. While co-existence and interoperability is necessary, the group feels that focusing only on interoperability limits desktop Linux innovation.

"We made a conscious decision not to, let's say, assault the barricades front-on, the way other Linux desktop initiatives have tried to in the past," Weinberg said. "The problem is that if you go out and think that on day one you're going to have a Microsoft world and convert it on day two, you end up really just chasing Microsoft and chasing the legacy [operating systems] and not getting the chance to innovate on your own."

DLC 1.0 addresses some of the requirements a desktop Linux offering should include, broken down by category: hardware, operating system services, application services, system security, browser, installer, accessibility and basic network services. The document doesn't state which technologies are correct or incorrect, or make formal requirements; it only defines a target that will make desktop Linux successful.

Originally, the working group was focused on six end-user profiles: personal-desktop users, knowledge workers, client/server set-ups, point-of-sale, help desk and call center. Over time, however, that list changed to:

  • Basic office. The casual office worker, who needs basic browser functionality, e-mail and office productivity applications like word processing, spreadsheets and presentations, as well as compatibility with other formats like Microsoft Office.
  • Transactional worker. The enterprise user who typically uses customized business applications, as well as basic Web browsing and e-mail. Examples include travel agents, front office and banking personnel.
  • Technical workstation. Users, primarily on the Unix operating system, who run industry-specific applications like CAD/CAM, though they have access to basic Web, instant messaging and e-mail.
  • Fixed function. Workstations limited to one application, such as point-of-sale terminals, kiosks and ATM machines.

The document states that variety and choice are the Linux operating system's greatest strengths, as well as its greatest weaknesses. ISVs creating applications for the enterprise have to deal with multiple versions of a Linux distribution, as well as multiple Linux distributions.

ISVs only have to worry about several different versions of the Windows operating system. But if they want to port their applications to the Linux kernel, they have to ensure the application works with any number of Linux-based distributions, like Red Hat , Novell SUSE, Debian, MandrakeLinux, Gentoo, Slackware and many more, each with its own development tree.

Compounding the problem is the development cycle between ISVs and Linux-based operating systems. In the time it takes a company to update its application, a Linux distro has more than likely updated its own platform once or twice over. Weinberg said the typical enterprise can range between 500 and 1,000 different packages -- libraries, daemons, services, etc.

"If [ISVs] need a change, a patch, a fix, the time at which they request it on the version they request has already been superseded -- usually, in the project tree by a newer version -- so someone's always playing catch up."

Weinberg said the organization is working on a binary regression initiative to align the development cycles of ISVs and Linux distributions and that work is already under way. But he wouldn't comment on the release date.