"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
Intro
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.
Rationale
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:
- Installation/Package Management
- 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.
Configuration/Administration
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.
Configuration/Administration
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.
Links
LFM project on sourceforge.net
Proposed LFM FileSystem Layout
Proposed LFM System Components
Designing Linux For The Masses
- an article that details many good points.