Linux For The Masses

"If you could produce an OS with all the benefits of Linux (ie. stability and performance) and the nobrainer-attitude of Windows... Wow. Maybe people would actually use it." -- Kristian Nybo


Linux For the Masses intends to take the good idealogy that Linus has put into the design and implementation of the Linux kernel further. It intends to continue where the improvements over traditional Un*x which have been made stop (in the kernel) by improving the overall filesystem layout and system service configuration methods.


Many people in the press, in forums, in newsgroups, and on mailing lists have hummed and hawed about making Linux a viable solution for the mass computer user. Terms like 'Linux ready for the desktop' have sprung up, and many projects have arisen to tackle the challenge. However, just making a useable desktop interface is not enough to make Linux viable in the average home.

There remain at least two critical barriers:

  1. Installation/Package Management
  2. Configuration/Administration
Nearly every PC purchased for the home, be it a Mac or a Wintel box, comes preinstalled and preconfigured. The consumer needs to do nothing save plug it in, and sometimes configure the dial-up settings.

Contrast this to what is demanded in a business setting. First of all, the most important factor concerning a business desktop is software. Does it have the applications needed to do the job? Will they interoperate with files from other companies? Installation and administration is not as key an issue. Many white-collar businessmen could care less how to install software. If they have a problem, they put in a call to their company's IS who take care of it. This means, that as long as the software is adequate, Linux is ready for the corporate desktop. Just get IS to set up KDE, give them a login, and away they go.

Shortcomings of Current Distributions

The major Linux distributions have come a very long way in making Linux more accessible. They have made excellent inroads to the problems of package management and system configuration. However, the complexity of the Un*x model requires a great deal of work to be done yet in these tools to make it truely appear uniform and easy to configure from a user standpoint. The average home user of a PC can still not be expected to manage their home machine with the available tools. The tools still require far too much knowledge about the underlying system and of computers in general.

This is not their fault. They are jumping through all kinds of hoops to give the package installations and configurations a uniform look and feel to minimize the required learning to use them. The real trouble is that these tools are patching symptoms and not tackling the underlying root cause.

Shortcomings of Un*x Packages

Installation/Package Management

The typical unix package, be it bundled as a tar.gz, rpm, deb, or whatever, spews files all over the filesystem. The typical Un*x filesystem layout is truly a patchwork of different thought on where to put things. Typical package managers try to resolve these issues by keeping a database that contains every file for each package, each files' location, as well as the package versions and their dependencies. This becomes similar to the registry used in Windows. The principal difficulty arises from the fact that for the placement of a package and its files in the filesystem there is no standard, and thus no two distributions place each package in the exact same place.

This means, that there are thousands of places for something to go wrong. The average household user would not even know the first place to look if it did.

There exists the Filesystem Heirarchy Standard (FHS), which attempts to standardize what types of files go where, but that is all. And the FHS in itself leaves some gaping ambiguities. This is fine for IT--it is flexible for those who know what they want and how to do it.

There also exists the Linux Standard Base (LSB), which is attempting to further define where things should go, but as it is design by committee, it will likely both take a long time to progress, and suffer from compromises that benefit no one.


The other great bane to administrating a Un*x machine, is the fact that no two applications use the same configuration file format. Each application in effect creates a brand new language to define its operating parameters, which an admin must learn and master in order to configure it.

Programs like LinuxConf attempt to create a unified interface to all of the system services by creating a general interface with a plugin architecture allowing separate modules to handle the many different configuration file formats. This is a good aproach to solving the problem given the underlying system, but does have a drawback--that is that anytime an application alters its own configuration file format (ie changes the language) the plugin must also be updated to properly configure the application. This causes much duplicated effort.

Remedy Proposal

We'd like to think that there was a magic, easy solution to all of this. It has become apparent, however, that none of the current distributions have really made any headway towards allowing the common household PC user to use Linux. The current methodology is not progressing in that direction, and unless changed, it seems as though Linux will forever remain only useable by the technically competent and computer savvy people.

We think we can fix this by steering in a different direction.

Installation/Package Management

We've decided that to reduce package management to an extremely trivial problem, each package must be located in only one possible location, and that all of its files must be located in a directory heirarchy beneath that principle location. Also, each package will be responsible for defining its own dependencies on other packages via a standardized dependency file.


We've also concluded, that to reduce duplicated effort, although difficult at first, the best approach would be to modify the packages themselves to understand a new, common configuration language. This language will be very extensible, self-defining, and most likely done with XML. The straight-forward approach will be to create a shared configuration API library and modify all programs to fetch their configuration data from it. Then, admin tools will also be written to only go through it. Since the data will be self-defining, when an application alters its configuration data format, the admin tool will be updated simultaneously since the data itself defines the possible configuration parameters.


LFM project on
Proposed LFM FileSystem Layout
Proposed LFM System Components
Designing Linux For The Masses - an article that details many good points.