| |
 |
|
| home | faq | discussion |
|
|
Tearing down roadblocks to Linux on the desktop!by David Jeske <jeske@chat.net>Linux has come a long way since the early days of multi-step floppy installs and compiling even the simplest tools from scratch. Today one can go out and buy one of several distributions on CD, and in a few hours have a full functioning system up and running, with a graphical desktop and web browsing capabilities. This progress is truly great. However, this article is not about praising Linux. Any of us backing Linux in the fight to become a desktop rival for MSWindows should recognize it still has a long way to go. In fact, there are so many perils out there on the road to Linux becoming a viable desktop alternative to MSWindows that they are hard to list, so I won't even try. In this article I'm only going to discuss one such roadblock, the one that I find most important to Linux today. Today I'm going to talk about the difficulty of distributing and installing third party desktop applications. What is third-party Linux software?First, lets figure out what third party software is. OpenSource has blurred the lines by allowing companies such as RedHat to include hundreds of megabytes of useful software, nearly all written by a third-party, in their initial installation. As a result, for some Linux users, all the software they ever need comes in a single distribution from Slackware or RedHat. However, for the large majority of computer users worldwide, the Operating System they choose is just a start, and it's the applications they install to meet their needs which define their user experience. In the context of open-source, lets define third-party software as any software which does not come preinstalled in the initial distribution/installation. It might be developed by a company and sold for profit, or might just be the latest new open-source email client. Either way, the Linux user needs to download and install it. Anyone who agrees that Linux has a chance to become a desktop rival for Windows should acknowledge the importance of making it easy to distribute and install third-party software, whether it is open-source or not. For the purpose of this article, I'm going to limit my scope even further by discussing only graphical third party apps. I presume that all existing UNIX command-line savvy users can handle RPMs, tarballs, and the like. New users that Linux will get when it is truly a rival for Windows will be primarily using graphical applications as they do on Windows today. How should distributing and installing third-party software work?This is the easy part.Distributors of third-party software should be able to build one install package which works on all Linux systems. Linux desktop users should be able to easily download and install applications from this single install package and locate that application wherever they like on their machine. How is graphical software installed on Linux today?In order for a desktop-Linux user to install a graphical application on Linux today, the third-party application developer must provide a pre-compiled package. The trouble is they have to provide a package for every distribution. In some cases, they have to provide a package for every version of every distribution. Furthermore, in order for the application to work properly with Gnome and KDE, they have to correctly include icons and mimetype handling information for two different app-registration systems.This is an enormous amount of work for those trying to just get their software out into the Linux world. They also need to support two different relocatable install systems, neither of which meets the goal of letting the user relocate individual applications at install time. This often means that the only graphical applications which truly work correctly are those which come pre-installed with your Gnome or KDE installation.How does Windows solve these problems?First off, Windows does not have two competing desktop solutions, as we have with KDE and Gnome. I'm _not_ advocating that we get rid of one of them, as competition and choice is healthy. However, we have to make them work together before this crack in the hull sinks the whole ship.Secondly, in order to solve the reloctable install problem, Windows has the registry. When applications are installed, the registry gets an entry telling the world (and the application) where those files went. However, you can wipe that disconcerning look off your face. I'm certainly not advocating that we build a Windows registry like system. Those of us who have worked with Windows know that the registry turns into a big dirty confused pile of half-working information as a Windows system ages.
Tearing down roadblocks to Linux on the desktop... by learning from NeXTSTep!It should be clear that I'm not fond of the way Microsoft achieves the goals at hand. However, Linux does not achieve any of them. We need to make changes if we want Linux to compete with Windows on the desktop. Fortunatly, there is an OS out there which solved these problems far better than Windows, which did it on top of UNIX, which shipped to hundreds of thousands of customers, and which soon will ship to millions more. That system was NeXTStep, the core of MacOS X.NeXTStep solved the application distribution and installation problems I've been talking about with a system I call 'app-wrappers'. (Some also refer to it as "bundles") With app-wrappers, one can drop an application anywhere on a machine, double-click on it, and be off an running. The technique nicely fits into the UNIX world and allows us to support the following with a single package:
How do app-wrappers work?An "app-wrapper" is a directory, labeled with the extension ".app". Inside it, you'll find a binary, possibly for multiple architectures, all application icons, and mimetype information. All files inside the app-wrapper are the immutable application datafiles. That's it.Whenever a graphical file-manager sees an app-wrapper, it transparently hides the contents of the app-wrapper directory. A filemanager, ANY filemaneger, can find mimetype information for all installed applications by scanning for app-wrappers and looking inside. This means it can transparently work with both Gnome and KDE. When that graphical file-manager launches the application, it merely needs to assure that it sets argv[0] to the full path of the executable, so the application can find it's own datafiles in the same place as the executable. Of course applications also need to be taught to find their datafiles relative to the app-wrapper, instead of relative to some system-wide environment variable. What else did NeXT do with app-wrappers?NeXT also allowed shared-libraries with associated data-files to be wrapped up into a similar directory wrapper called a "bundle". Bundles allowed shared library modules such as as screensavers, image format handlers, and other plug-in code to have all the same wonderful features as applications. They are location independent, can contain binaries for multiple platforms, and neatly have their icons and other datafiles available.A few OS releases later, NeXT even extended wrappers to the installation of "library plus header" development kits by making a wrappered item called a "framework". If it had existed at the time, all you would have to do was drop "Gnome.framework" into the right directory, and all the necessary development headers and libraries would be found by the compiler. Seems somewhat anti-climactic dosn't it? Seems like we should just rip this concept off right now. Seems like it would pave the way for applications to work easily with both KDE and Gnome, by having their filetypes and icons inside themselves in a standard format. Seems like it would pave the way for third parties to ship GUI applications for Linux without worrying about whether you're RedHat or SUSE, Gnome or KDE. Seems like we should all follow Linus' example, clone something that already demonstrated how to make this stuff work, so we can move onto the next problem. We should. For more information about app-wrappers, or how we could start having KDE and Gnome use them right now, check out:
|
|