By Brian Proffitt
Managing Editor
I am becoming increasingly concerned with the Linux on the
desktop movement that’s innundating the community of late.
Vendors, developers, users–even Linus Torvalds is touting that
the future of Linux is in the desktop. Initially, this seems to be
a good thing. After all, who wouldn’t want to see the penguin
dancing merrily away on the desktops of the world?
But where I have the problem is this: I am not sure that the
people who are driving all of these desktop products really know
what the end result needs to be. And the result, I fear, will be a
chaotic mess that still won’t be ready for the business or home
desktop.
When I was in NY last week, I had dinner with a bunch of
reporters, analysts, and execs who inevitiably got into the “is
Linux ready for the desktop?” discussion. The conversation was
genteel enough, though it did tend towards the raucous near the
end. The problem was not that there were two sides each locking
horns with the other–the crux of the argument was that there were,
like the Linux community, several points of view on how the Linux
desktop would succeed (or not). There were nine people at my table
and eight points of view (the two Red Hat staffers were unified in
their position).
My position is the one I usually have for this topic: before you
can ask if Linux is ready for the desktop, you’d better have a darn
good idea of what you mean by “desktop.” This rather Socratic
question is supposed to make people pause and think. But during
this conversation, it was just another voice in the cacaphony.
This cacaphony is prevelant throughout the Linux community. The
very existence of so many distributions, desktops, and projects is
testament to that. When people think they have a better idea, they
can take off and work on it themselves in a whole new project.
That’s the beauty of the GPL.
But while I am always applauding the diversity of the Linux and
open source community, I am starting to wonder if we may not have
too much of a good thing. Choice is good, but if it is not tempered
with a little common sense, it may not be beneficial.
For instance, this week I decided to upgrade to Mozilla 1.6. I
have been patiently waiting for RHN to upgrade me from 1.4, but
that’s a long wait, since the Red Hat Network only sends upgrades
when something is broke and even then, only a minor point release
to fix the problem. Eventually, I decided to do this on my own. So,
I downloaded the binary, cracked open the tarball, and ran the
install script.
A hop, skip, and a jump later, and I had Mozilla 1.6 running on
my machine and all was right with the world, right?
Not quite. Apparently, xft wasn’t included in this binary,
because all of my fonts weren’t anti-aliased anymore. In layman’s
terms, the letters were jaggy and I was irked.
Now, by GNOME 2.4, I really expect this kind of thing not to
happen anymore. I have anti-alias capability in this environment
and I should expect all the apps I run within it have that same
capability. Apparently not.
After a quick Google, I discovered it was the xft issue and
began the procedure to get the Mozilla source and compile it with
xft enabled, thanks to some great
instructions from Jeff Sauer I found on Linux Journal. After a
basically uneventful compile session, I have smooth fonts once
more.
But the nonchalance in which I write that last statement is a
conceit. Essentially Mozilla is asking users who want smooth fonts
to compile from source rather than expect it to be included in the
binary. Initially, I was pretty ticked off by this realization,
since I can’t think of anyone who would want to opt out of having
smoother fonts. Why can’t Mozilla just include this in their
binaries?
Because there may be dependency issues, that’s why. To compile
this, I needed the right versions of gtk+-devel and libIDL-devel,
two library collections that not everyone may have. I didn’t–I
yum’ed them down. And those were just the libraries I
needed. Who knows what another machine might need?
From that persepective, it makes sense why xft is not
pre-compiled in every release of Mozilla. But the diversity of
Linux is clearly working against the Mozilla developers here… a
problem that reaches me, the end user, pretty quickly.
I am not one of those journalists that sees one problem in Linux
and says “that’s it, the whole thing sucks” just because I had a
minor glitch.
But I will say that there needs to be a better set of standards
amongst the Linux distros. Mozilla’s developers should be able to
point to a Linux distro and say, okay, that distro follows standard
1.whatever, so we can expect this, that, and the other libraries in
its toolset.
The call for standards has been made by many more influential
than I, but I really think the need for them, as Linux gets ever
closer to the desktop, is stronger than ever. It’s 2004, and I
think open source projects should be able to deliver certain
features without resorting to source compilation.
This won’t be easy. We not only have to agree on technical
standards, but also on feature standards. After all, anti-aliased
fonts in every application seems a basic need to me, but
there may be people out there who think such a feature is
frivolous. Fine, I can accept that. But the point is, such
standards need to made.
If users and developers want to keep having a strong say in how
Linux is put together, then they need to start working towards a
common well-defined goal. It’s one thing to say “we want
Linux on the desktop”–it’s a whole other animal to say “we want
Linux on the desktop to have these features and applications” and
list them.
This lack of well-defined goals is hurting Linux and open
source, I think. Different projects are winding through the forest
along different paths towards a nebulous spot somewhere “out there,
thataway.” I don’t think all of the projects should stay on the
same path–instead, they should be taking different paths though
the forest as before, only now towards a specific set of goals. A
single place in the forest.
No one would be limited in how they get to that place–thus, our
valued diversity is maintained. But knowing exactly where to go
will make Linux much stronger, much faster.
Some are trying to limit the chaos by removing the number of
paths. Bruce Perens has chosen just one desktop for the proposed
UserLinux. He doesn’t want to divide his resources in managing two
or more desktops. While I can’t take away his right to do that on
his project, I am concerned that such decisions are hurting the
diversity of projects as a whole.
What really sends a chill down my spine is what I keep hearing
various influential people in the community say lately when the
subject of the desktop comes up: that there is only going to be
room for one desktop as a successful commercial venture in the
future.
And that is something I don’t think any of us want to see.