[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SEUL: Ten proposals for a user friendly Linux (long).
Making Linux usable by end users is vital to its future because
hackers are in limited supply. Once Linux gets them all it will stop
growing unless than it can made usable by non-technical people.
Getting this will need additional software but a lot of progress could
be done now with better configurations and better use of the existing
software.
I see ten points of improvement.
1) Easier configurations, specially more realistic networking.
2) Getting rid of kernel compilings thanks to the use of modules.
3) Another boot manager than LILO.
4) Incorporating the newer apps in the distributions.
5) Tools for personalizing applications
6) Different setups according to the expertise level of the user.
7) KDE (Kool Desktop Environment).
8) Replacing VI as the default editor (the one called by apps).
9) Automagic updates
10) Linux must be beautiful.
I will develop now:
1) Easier configurations.
The distributions designed in 1996 and 1997 seem adequate at first
sight with their sophisticated package managers and their tools for
configuring the computer. Unfortunately first sight is wrong.
The people who really need help are the individual users: they cannot
get help of a colleague like people in universities or in companies.
The only way they have to get help is with mail and news so a PRIMARY
goal should be to make them able to send and get mail and news just a
few minutes after installing. Not after RTFMing for a week.
Morevoever end users would probably not understand.
Unfortunately authors of current distributions seem to think than
every Linux box will be in an Ethernet with a permanent and fixed IP
address. An Ethernet based networking for home users is useful mainly
in planet Mars.
If your link to Internet is by dialup IP (most of them with
floating address) the standard installations I know don't tell you
what to do. And for mail and news there is no provision for people
who get either with Uucp or with POP + Suck. Also there are providers
where you need to use masquerading for your mail.
So having distributions providing easy setup for network, mail and
news for realistic cases (UUCP, dialup IP) would be a big step
forward. The tools for doing that should be curses based not X based
because our end user is possibly needing help to setup X. They do not
need to cover everyone of the cases neded by an ISP. What they need is
to cover the typical cases of individual users.
As an aside I would like to see qmail as the standard in Linux.
Small, very fast, without the recurrent security problems of sendmail
and a LOT easier to configure than sendmail (and from distant memories
I think than it is also easier than smail).
2) Getting rid of kernel compilings.
This is definitely not a thing you would want an end user be
confronted with. And completely unnecessary in 2.0 where everything
is modular. At least if the installation kernel is built properly by
the distribution author.
Unfortunately no distribution is ideal in this aspect. The problem is
than installation kernels need some things (like root NFS) not needed
by production kernels. And than kernel for Pentiums are different
than for 386s.
So Debian and RedHat have opted for a single suboptimal kernel instead
of a small number of optimal kernels not needing recompiling. The
reason is than it makes installation (and testing) easier. Can you
live with the native Debian and RedHat kernels? For Redhat yes. It
is not much bigger than an optimal kernel and it starts fast. Debian
uses modules less intensively so the kernel is relatively big, no
problem in a 16 or 32 Megs box but the kernel is slow to start because
it needs to test the presence of a number of devices.
The biggest problem is sound. No distribution I know comes with sound
ready. And whatever is your sound card you get the same module:
sound.o (with differents contents of course). So distributions should
come with a set of sound modules and at install time the adequate one
is copied under the /lib/modules directory tree.
3) LILO:
Lilo is not a boot manager for end users. First of all installing a
new kernel can let your box unbootable. Second: if you screw up some
kernel parameters then perhaps your box will not reboot. You can
override them on the command line but you will be unable to see what
you did wrong. Third: Non US users need to type blind US-style in
their non US keyboards.
What is needed is a free version of the Linux-FT booter (unfortunately
not free). It finds kernels by their file name, not by their physical
addresses like LILO. So you don't need to run any command when
installing a kernel. And you can do an "ls" if you don't remmeber
where yo put it. You can before booting change the parameters of the
kernel, you can save them, and you SEE them. All of this with menus
and all of this with your national keyboard. No longer typing
qhq&(éx= for aha152x=
4) Putting the newer apps in distributions.
The trend in new apps is to be user friendlier than the older ones.
However distributions are slow to incorporate them, and still slower
to put them "under the spot lights". Sometimes people have software
who would made their life easier but they don't know about it.
5) Tools for personalizing apps.
Dotfiles is not ideal, however it is better than nothing.
Unfortunately it does not come in RedHat.
I am not fond of editres. You can configure every detail of an
application who supports the protocol, but: it is not intuitive, its
use is based on the knowledge of widgets ie a programming concept, it
does not save what you changed to a personal resource file, you don't
see what is the value the app is using before modifying it. And
sometimes knowing the old value would help for guessing the legal
range of values. I would prefer something more usable than editres
even if it does not allow you to configure as many things.
6) Different tools for different users:
Linux has nice filemanagers and tools who will made the life easier to
a beginner. But it is not enough they are on the CD. They have to be
put under his nose so he must get them when logging/starting X. But a
real power user will probably be happier with plain xterms and the
menus of the window manager. Best solution is than when creating a
userid the user is asked about the level of expertise and the person
gets different startups according to her level of expertise.
7) KDE:
Yes I know it is alpha and some people myself included have second
thoughts about the use of a non-GPLed library where the owners can
change policy at the worst possible time. However I fell in love with
it. First it really looks beautiful. It has drag and drop. Easy
configuration of the task bar and of the programs to be started when
KDE is fired. And you don't change the wall paper by editing resource
files but with a chooser very much alike the one in W95. Hypertext
doc at hand. They are even revisiting some classics like rxvt and
making them user friendlier.
My windows-using colleagues were really impressed with it.
KDE is important because it is the first time free software really
cares about being user friendly. Most of time it is made by
programmers for programmers.
IMHO for now KDE is the best candidate in free world :-) towards becoming
the standard environment for an end user distribution.
8) Replacing VI as the default editor.
I am not proposing eliminating it from the distributions. But one
time I was using knews and tried to post, it dropped into VI. As a
hardened emacs user I only know one thing in VI: how to exit. I
stopped using knews.
Confronting an end user with VI is a sure way to have him fleeing to
Windows95. The EDITOR environment variable must be set in order than
when a programm needs an editor it calls a user friendly one.
What are the qualities needed by this editor? First of all it does
NOT need to be powerful: writing mail and hacking a config file are
simple tasks who do not need the kind of editors needed for serious
programming. It must be small in case we are using it from a floppy
in an emergency. It must be usable outside X. Mouse support would be
nice but it must be possible to operate it without a mouse. Most
important it must put a list of the main commands on screen and have
doc online.
For now the two best candidates I know for this role are jed and joe
but I know nearly nothing about them. Of course it would be better if
authors of distributions agreed about a common editor: the LEESTD
(Linux easy editor Standard :-).
9) Automagic updates:
One of the things I like in Redhat is how daemons, crontabs and shell
profiles are managed. There is a script who scans a directory and
starts or sources the files with the right name it finds in the
directory. So adding a daemon is made by creating a new file. That
can be made automatically and this is not dangerous like an automated
edition. Yes I know the idea is not from redhat but from the SYSV
init. Redhat extended the trick to crontabs and profiles.
When you install an app it must show in the menus. When you uninstall
it must disappear from them. This is possible with FVWM95 +
TheNextLevel than you get in RedHat4. I would like to have it in
other WMs.
Another point is than the info dir file must be updated. For now this
requires automatic editing, a pretty dangerous thing.
10) Beauty.
I have played a bit with TGIF. Not bad. But it uses Athena widgets
and comes without any resouce setting: ie black text on write
background. So the first impression you get is than it must be a
piece of crap, with zillions of bugs.
Getting a good first impression is important, so we need to try to
make programs look good.
Athena applications can be made more attractive by using one of the
replacements to libXaw. The ones I like more are those with the
NextStep look. Really nice. But they are ugly if you don't modify
resources to the recommended settings.
Apps must be issued with resources designed to make them look good.
Compare Emacs on Debian and on RedHat. On Debian Emacs is awful. And
an end user does not have the proficiency needed to make the programs
look good.
Fortunately the new libraries like Qt, XForms, V and (soon) compiled TCL
will provide us with plenty of applications inherently more attractive
than the old ones who used Athena.
--
Jean Francois Martinez
==================== The Linux. Use the Linux, Luke! =======================
----------------------------------------------------------------------------
Simple End User Linux Mailing list
To be removed from this mailing list send a message to majordomo@txcc.net
with the line
unsubscribe seul-project
in the body of the letter.
----------------------------------------------------------------------------