posted by John Munsch on Mon 30th Dec 2002 19:05 UTC

"How?"
How?

The how is covered in dozens of points below. They cover areas of Linux that need lots of work to meet the needs of both new computer users and existing computer users who are only new to Linux. They also cover ways to better think about the task in order to get better results than what we have in the existing distributions which are all variations on a theme: KDE and GNOME on top of the Linux kernel w/ various GNU tools included in the package (though unlikely to be run by the typical home user).

Realize that the operating system is not a goal unto itself.

Users have programs they want to run and the operating system is nothing more than a means to an end. Other portions of the OS may support activities that the user will perform outside of any application (e.g. setting sound volume or backing up files) but these activities are still only conducted to facilitate the main goal of running their programs.

Corollary: The user does not care what operating system they run as long as it runs the applications they want to run. All other things being equal they will and should make choices based on support, price, ease of use, etc.

apt-get and rpm are not installation systems for real world software.

Uninstall needs to be easy and natural.

Guessing about what packages are needed is not helpful. Most people see a given piece of software as a unity. If it has options, they expect the installation software to explain those options and offer installation choices.

End users should not have to pick between more than 70 different distributions in order to know what to install.

There should be basically be Main Street (home desktop), Wall Street (business desktop), and Server distributions. Since it is completely impractical to force companies, groups, and even individuals to stop churning out new distributions as quickly as they can beg a cute logo out of a friend, these could each be like the Linux Standard Base (LSB) is now. Each one would be a complete set of minimal requirements. A set of applications, menu items, directory layouts, etc. that are specified quite rigorously. Distributions could enhance from there in specific areas that are already set aside for areas of improvement and innovation without confusing a new user who just wants to buy "Linux For Dummies" and sit down with his new "Linux" machine to start using it. If the user knows it's a distribution based on "Main Street" he/she can count on finding certain things in certain places and being able to get started with minimal pain.

Unified base requirements could get a lot of distributions to consider the idea of joining together just as United Linux is doing now. You can say what you like about the motives behind United Linux but they are going to have advantages by doing security patches and upgrades only once (already a difficult thing to keep track of). After all, isn't that what we all got by having GNU do the utilities for us and Linus build the Linux kernel? There was a base we could build on to get something that was actually useful. Let's extend that base.

Basic system functions and settings should be a substrate supported by both KDE and Gnome (as well as any other GUIs that might come along).

That includes but is not limited to:

  • The menu items on the "Start" menu
  • File extension/application associations
  • Mime type associations
  • Clipboard handling
  • Printing
  • Control panel items
  • Event sounds
  • A way to display notification icons in the "system tray" and associate actions taken on them with actions in programs
  • Registration of keyboard shortcuts that cut across all applications (i.e. Ctrl+Shift+I means "get the next instant message" no matter what application I happen to be running at that moment)
  • A standardized notification mechanism the user can set up to connect to email, IM, etc.
  • Standardized themes (both visual and audio)
  • Drag and drop of file names and data that would otherwise be directed through the clipboard (i.e. as an alternate mechanism to the clipboard)
  • A shared "trash can" where deleted files are placed. It should also have a shared mechanism for specifying where the deleted files came from and where they should be restored to if the user desires to do so.
  • Program install/uninstall

All of the above must be documented and ideally available via APIs so that the desktops use them as well as install programs and languages like Perl, Python, and Java can make use of the functions to more fully integrate themselves into whatever GUI environment they are run under.

If the configuration method for a piece of software is "find this configuration file and edit it" then it might as well not have options.

Most users just won't do it or couldn't do it properly if they tried.

Whether it really is or not, the shell prompt is going to be viewed as evil by the vast majority of users. Many did not use MS-DOS and if they did, did not enjoy the experience. At this point you are better off avoiding it any way you can.

That doesn't mean it has to be removed, just deprecated. Power users (and all users become power users given long enough) can start to make use of the power of the command line eventually.

Don't let a program suffer from sprawl if you don't have to.

Ask yourself if the application you are creating really needs items copied to multiple directories, followed by editing multiple files, followed by running multiple configuration programs.

A perfect example of this is configuration of a desktop Linux system. On Mandrake I have a configuration program that comes from Mandrake that lets me set up many things. But then there's another one for KDE or GNOME (whichever I happen to be running) and amazingly neither of them really covers all the configuration I expect to be covered.

Table of contents
  1. "Why?"
  2. "How?"
  3. "Pretty Does Count"
  4. "What Brand?"
  5. "Conclusion"
e p (0)    180 Comment(s)

Technology White Papers

See More