|
 |
|
By Brian Proffitt 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.  
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
|
|
| All times are recorded in UTC. Linux is a trademark of Linus Torvalds. Powered by Linux, Apache and PHP
| |||||||||||||||||||||||||||||
