UNIX/Linux Usability Ideas
From jeske@... Thu Nov 5 17:17:46 1998
Date: Thu, 5 Nov 1998 17:17:46 -0800
From: David Jeske
To: omega@seul.org
Cc: seul@seul.org
Subject: seul comments...
Message-ID: <19981105171746.G3277@home.chat.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.94.13i
Status: RO
Content-Length: 9560
Lines: 186
Hey Erik,
I got your email address from the seul pages.
I was attracted to the seul pages as a very technical developer who is
tired of the administration overhead of UNIX, Windows, and just about
everything out there. I see the solution to the 'end user usability'
problem and the 'lower cost of ownership/administration' problem as
one in the same.
In my opinion, layering yet another set of unix scripts and tools on
top of Linux is not going to be the right step toward the above
goal. There are many pieces of the Linux infrastructure, inherited
from UNIX, which are diametrically opposed with the above goals. I
believe that Linux could be made much easier to use with much less
work by making small, but well placed, infrastructure improvements to
existing programs and tools.
In addition, I see these kinds of improvements helping both technical
users and beginning users alike.
As just a few small examples of what I'm talking about:
I. Stop confusing physical and logical naming in the path space
A. Script Program Redirection
Currently the #! syntax for identifying the program used to run
a script encodes a physical path into a script. This means that
if the script interpreter is not installed in exactly the same
location on all machines, the script will fail to find the
interpreter.
This may be fine for technical users because they will merely
edit the script to have the correct path. However, this is an
administration headache which technical and non-technical users
alike should be freed from.
One method to fix this would be to change the #! execution convention,
or invent a new convention to act as an analog. This new convention
would allow the script interpreter dependencies to be spelled out
in local form and mapped to a specific script interpreter.
For example, instead of using #!/usr/local/bin/perl, one might use:
#$perl // signifying any version of perl
#$perl5 // signifying any perl5
#$perl5{.003|.005+} // signifying perl5.003, perl5.005 or greater
#$perl5[gd,mysql] // signifying perl5 w/gd and mysql modules
This allows the target system to do redirection without modifying the
script. This is not the ultimate solution, in my opinion, but it is
a good compromise of ease and usefulness. We could optionally create
this as a backward compatible standard which would utililize the
traditional #! solution to run a script redirector. For example:
#!/bin/script_redirector
#$perl5
print "my perl program";
This would allow the redirection to work across all UNIX. This
script_redirector would handle running the proper application.
B. Stop using absolute program paths to launch tools
Currently many programs (during their autoconf and compile phazes)
go out and find the install locations of certain applications on
your machine. For example, lynx, the text mode web browser, goes out
and finds the location of "cp" on your machine. It then hard-codes this
path into the lynx executable for use in copying data around.
Most people can admit that this is poor practice. However, UNIX offers
no cut and dry solution to this problem. If lynx simply relies on "cp"
being in the path, it might not be.
C. Allow applications to be installed in arbitary 'physical' locations
Currently much of the UNIX/Linux system dictates the physical location
of application installation. For example, most RPMs must install into
/usr/local/bin. This means you can not:
- organize your disk the way you want
- have multiple versions of the same package installed
- install applications privately in your home directory
This is largly caused not by RPM, but instead by confusion of
physical and logical namespaces in the UNIX design itself. Applications
are compiled from source to live in a particular location on a users
system. UNIX has no standard mechanism to shoebox applications
into their own private spaces. This creates maintaniance headaches
for system administrators and simple end users alike.
A convention can be established for allowing an application to find
it's install location. This can be combined with the power of RPM to
allow a user to choose an installation location for the entire
application. Furthermore, an application's datafiles can be encapsulated
into a single subdirectory, preventing the kinds of conflicts which
can occur between multiple apps in shared trees like /usr/local/{etc,lib}.
Possible models are the Nextstep and Acorn/RISCOS models for application
wrappers. Both systems work well and can do so on top of a standard
UNIX filesystem.
II. Stop perpetuating the 'multiple-metadata' maintaniance nightmare
A. Promote a rigid separation of "mutable" and "non-mutable" data
Currently anything which ships with an application is mutable data.
A 'template' configuration file is shipped, but is often modified during
installation. This model is very unfriendly to automatic reading and
writing of configuration files. It's also very unfriendly for
tracking site specific configuration.
Configuration of applications could be simplified greatly by
helping applications adopt a multi-level configuration scheme
based on a tool like libPropList. The most important part of a
flexible configuration scheme is that it not allow the application
to specify absolutes or deal directly with files. For example,
if an implementation of a configuration API support "user" and
"sitewide" configuration, but does not expose the levels to the
application itself, it can later easily be extended to
"user", "group" and "sitewide" without affecting the application
code at all.
B. Stop building static configuration files for every layer of software
This is probably the opinion of mine which is most difficult to
explain. I apologize for this, if you don't understand, please
ask, don't dismiss it.
UNIX has always been a file oriented system. Because of this, layers
of software in UNIX rely on creating another layer of static
configuration data. This configuration data must then be maintained to
stay consistant with the configuration data below it. This creates
an administration nightmare.
Consider the above proposal for creating a 'script interpreter
redirector'. The UNIX philosophy for doing this would likely involve
creating "/etc/scripttab". Then, every time applications were installed,
this file would have to be modified to be kept up to date. If there was
only a private scripttab, then users could not customize their own
settings. So then another developer might pick an environment variable
like SCRIPTPATH to signifiy a search order for the scripttab files.
Then there would be a plithora of scripttab files around which would
need to be kept up to date.
I propose a different model for storing this kind of configuration data.
Instead of manually propagated static data, I'd like to see
automatic propagation of config data, where every level/tool has a chance
to store it's own information and tie into the information around it.
That sounds much more complex than it is. I'll describe it in terms of
one of the most common problems, application installation and the
associated information.
In the UNIX, Windows, etc model of software installation, application
installation is an 'active' process. Many things on the system must be
updated to have an application installation take effect. For example,
if it is an X application, it needs to have it's icon and path
registered with your window manager in it's custom configuration file.
If it depends on other tools, then it may have it's own configuration
file for you to specify the location of those tools. If there is
some type of file/mimetypes registry, the application types need to
be installed there too.
In my alternate model, application installation would be a "passive"
process. An application would passively publish any and all
information it came with. It's installation path, icon, filetypes,
etc would be piece of data within it, which any tool could query.
An application like a window-manager would then ask the higher-level
'application manager' for a list of all applications. If it needed
an icon for one of them, it would ask. It could keep a local cache of
this data if it needed. An application like a filesystem explorer would
ask for a list of all the mimetype information. It could, again, keep
a _cache_ of this data. At any time, all the configuration 'caches'
below can be destroyed and recreated only from the passive application
information. (i.e. some form of export file) This model is based
somewhat on systems like NeXT, MacOS, and BeOS.
As I've explained above, I believe these, and other issues in
usability and ease of administration can be better served by carefully
placed tweaks to the existing infrastructure than by yet another layer
of configuration tools and scripts.
--
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@...