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.
