posted by Ernesto Garbarino on Tue 27th Jul 2004 06:17 UTC
IconFirst of all, we should agree on what the definition of "ready for the desktop" stands for. For some of us it refers to a graphical user interface in which applications have icons and can be launched in an intuitive manner without the need of complex commands. Even a Commodore 64 running Geos could be "ready for the desktop" by this definition, but the fact is that when we read "ready for the desktop" we understand "ready to replace Microsoft Windows".


But this definition alone is not enough, most of the people and the mass media understands that replacing Windows is just not about booting something different than the Microsoft's operating system, it refers to some conceptions such as commercial support, document compatibility, availability of office tools and other mainstream applications.

Above all, an operating system aspiring to replace the Microsoft's product must able to provide at least the same commitment to the end user as Windows in political and software terms. This may sound like a contradiction in these days of security flaws but I'll develop the idea further in this article. We all agree that we can teach our parents how to browse the Web or write a "Word" document with Linux or, better yet, we can use some Windows theme that may fool the eyes of more than one Microsoft veteran at the first glance. This is not the point though. By "ready for the desktop" we refer to a system that can be used by someone without the help of a geek-relative or a specialized magazine. More than that, we want to see Linux preinstalled by default by most of the top PC manufacturers. We want the latest games and hardware to be compatible with Linux. We want device drivers written by the same companies that produce hardware and not by computer science students in their free time.

We know what "ready for the desktop" means, but what is Linux?

A kernel. Repeat after me, a kernel. No, it's not Suse and neither RedHat. Those are products that use the Linux kernel. But they are flavors of Linux, aren't they?. No, they are products that use specific Linux kernels. This means that an application compiled with one kernel in mind may not work with another one. For example, at the moment some distributions use the 2.4.x while others the 2.6.x kernel. An application targeting Suse Linux is thus not necessarily compatible with RedHat Linux even though we read the word Linux in both products. Each distributor compiles and re-packs the mainstream applications for their implementations.

The truth is that we don't have Oracle or Java for "Linux" but for some "certified" distributions, in essence, conceptually "different Windows contenders". So, at the end of the day, a "Linux application" is source code that you expect to compile on most distributions, and the kernel alone is not granted to make it compile, the host will probably need a concrete shell and a precise set of shell utilities. It's not uncommon to find out that a make script calls some shell utility that our distribution of choice doesn't happen to have. When we refer to a "Windows" application, we refer to a program that we expect to run in any kind of "Windows" flavour (unless it is a specialized software that needs some special feature of the NT kernel series such certain server applications). If I have a CD-ROM Encyclopedia for Windows I expect to run it without problems on Windows 95, 98, ME, XP, 2000, etc. If I have the same product for Linux, it will be compatible with very specific distributions and if the software is in binary form it will probably brake after some years because we all know that binary longevity in Linux is not granted. I'm not talking about the ELF format, I speak in a generic way, meaning that binaries relay on too many dynamic libraries that are usually related to the target kernel release. Linux binaries usually don't work out of the box, they often cry complaining about the lack of dynamic libraries or worse yet, glibc.

KDE & Gnome

The point here is not which one is better. There are countless articles on the matter, the problem is that we have two of them. Please, let's not talk about personal taste and freedom of choice. Let's talk instead of incongruity, incompatibility and development effort. Should car drivers choose whether the gas pedal must be at the left or the right?. No, they may want different colors or seats. We expect to apply the lessons we have learned when we have obtained a driver's license in all cars. Could we say the same about Linux?. Are our private lessons on Lindows be of help to our parents when they receive their new computer running Suse or Mandrake?. If an old relative calls you from a long distance telling you that he runs Linux and that he can't get into the Internet, can you give him instructions as clear as "Press Start, choose Run..., type cmd and then ipconfig"?. No, because a Linux desktop doesn't have a precise way to open the command prompt. The most elemental tool, the shell, changes icon location according to the Window manager . Pressing some strange Alt+Ctrl combination to obtain the console mode is not a option, many LCD monitors don't even support this text mode specially when it's not the standard 80x25.

There are struggling efforts to integrate these two desktops, to make a Gnome application look like a KDE application and vice versa. It's a good start, but if we intend to make both environments look the same, why should we have two different graphical APIs? There should be one "official" desktop for the end-user. The remaining toolkits don't need to die, they can be used for academic or hobby purposes.

Table of contents
  1. "Desktop Linux, Page 1/3"
  2. "Desktop Linux, Page 2/3"
  3. "Desktop Linux, Page 3/3"
e p (0)    258 Comment(s)

Technology White Papers

See More