[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Indy updated
I have taken our guidelines web page and crystalized all its thoughts and
notions into standard English. Here is the new code in HTML which we should
now adopt for the guidelines page :
Linux will remain a niche operating system until the majority of operating
system end users learn to utilize its many advantages. To date, near
universal use of Linux hinges on the future availability of less expensive
hardware support and software packages for multilingual documented programs
for the occasional end user.
Manufacturers' incentive to contribute to the critical mass chain reaction
snow ball effect of compatibility will nudge our deficiencies into a self
resolving stage of development as the industry rushes to maintain sales by
updating to the fast growing Linux trend.
A well executed Indy distribution of Linux can hasten such an accelerating
exponential growth of the proverbial snow ball which should provide drivers,
translation of documentation, and applications eventually.
<BR>
<H3>
I) Forget about Unix tradition: Linux is NOT Unix.</H3>
<H4>
a) Two different ways of life: Unix and Linux.</H4>
Unix was used in universities and medium-to-large sized companies which were
big
enough to buy the expensive Unix computers. Unix was seldom used as a cost
effective solution for simple tasks that were easily accomplished using Macs
or Wintel machines. The tasks reserved for Unix required a highly trained
and educated network of system administrators and their professors. Unix
users could afford a non-intuitive obscure interface between its expensive
hardware and its 'elite' operatives who were trained within a highly
structured highly maintained academic milieu. Although Linux now follows in
the narrow path of Unix footsteps, it has the suddenly apparent tendency to
break out of the narrow Unix path and into enough directions for the
majority of computer end users. It will no longer beat funeral marches to
the Unix grave but will repopulate the growing empty space of world wide
computer storage devices and random access memory.
Whereas expensive Unix is collapsing into a neutron star Linux as the new
red giant is expanding into our laptops and desktops at home and within
small companies.
The needs, constraints, and training of Unix and Linux are
vastly different.
<BR>
<H4>
b) Linux at home</H4>
The home computer system administrator is the end user of the box from
installation day to the day of obsolescence. We will configure our box
first, then learn how to copy a file single handed. Problem solving will be
a Neil Armstrong adventure in isolated space. Of course, we should have a
book, which will fall short of hands-on experience. Previous such books
have assumed Linus to be just another Unix, but have failed to address the
home-user's problems or adequately address software for dial-up IP and
access to the net. A mac user cannot be expected to rise to the occasion as
a de novo power use hacker. Most of Mac users want to be productive from
day one and never accumulate weeks of training. Obviously the Unix shell is
not a tool to attract mac people to Linux. We must provide an alternative
intuitive shell containing help files.
<BR>
<P><B>c) Linux in small companies</B>
<P>Although Linux could rapidly assume the server role for small companies
where the computer operator has direct contact with the cost conscious
proprietor, here are 3 potentially overriding factors :
<UL>
<LI>
A small company might use fewer or perhaps only one server computer, and
only one license. Economy of scale might be achieved more easily with NT.
An employee RTFMing costs $200.00 a day.</LI>
<LI>
Small companies which cannot afford a full time guru can either externalize
their system administration or retain a part time employee using a simple
system.</LI>
<LI>
Classic Unix servers
like Sendmail and INN are overkill for such a small business. Unix was
designed with the
needs of big organizations built in. </LI>
<BR> </UL>
<H4>
d) Linux in the desktop: </H4>
Just because Unix never made significant inroads into the desk-ware lap-ware
market does not mean that Linux needs to be restricted to the server,
programmer's work station role. A secretary could just as easily write memos
on a cheap Wintel machine as on an expensive Unix work station so she was
handed a Wintel. Such an argument against Unix does not hold water as an
argument against Linux which is cheaper than Windows and can be administered
from a distance, is not subject to virus attacks, and doesn't crash five
times a day. The choice is clear. But we have to include a good GUI and get
rid of the "real men use TeX" mind set. TeX is great in the hands
of certain people and for certain documents. Here what is needed is X-based
Wysiwyg word processors, spreadsheets and presentation software. When we
cannot find a good, free tool, we should ensure that the user knows about
commercial ones.
<H4>
e) Separating Linux from Unix: </H4>
Linux can go where no Unix has gone before, but not simply by blindly
following Unix tradition. Unix has not been designed for the mass market.
Before someone burns me for heresy, let's keep in mind that this, in fact,
is the real Unix spirit. Ken Thompson never said that Unix had to be user
hostile. In fact he separated the shell from the kernel in order to allow
different users to get different user interfaces. Linux must keep the
classic Unix interface for power users, but there is no reason other people
cannot get a different one. <BR> <H3> II) Design
guidelines.</H3> <H4>
a) Mind set.</H4>
If a feature is useful for 10% of cases but makes no difference for the
remainder, then add it. If a feature helps 90% of users and annoys the
remaining 10%, then add it (providing the benefits outweigh the losses). If
a feature would annoys a hacker but helps a beginner then add it. A newbie
end user cannot add a feature but a hacker can easily remove anything he
likes. You have to forget about yourself and your tastes: you must be able
to think like someone who knows nothing, is not a hacker and is learning
Linux without assistance.
<BR>
<H4>
b) A superb installation is... relatively unimportant.</H4>
The best installation would simply be to get PC manufacturers to do their
jobs. They will do it-- if Linux market share reaches critical mass. But if
the user only gets unfriendly programs, software which was not designed for
the job, or cryptic docs, then even that ideal installation will have
achieved nothing. The RedHat's 5.2 that we use as base has an install which
is not so bad: it detects hardware, can handle partitioning without user
intervention,
and package selection is reasonably terse. Its two main drawbacks are
scarcity of on-line help and the fact that it acts as if PPP didn't exist;
the latter meaning that after install the PPP user has to configure his
networking without the same kind of hand holding the LAN user gets during
install. But to a home user, no PPP means no access to help. Another point
of improvement
would be to boot directly into XDM if X is configured (we can allow
ourselves to do this now that LILO tells the user how to re boot no X in
case of
problems).
<H4>
c) Docs: the "Now what?" syndrome</H4>
After install, many users find themselves completely lost. Read the news
groups and you will see postings like "I typed X and only got a grey
screen". In addition, there is a risk that many of the nice programs we
include end up never being used because of advice in books or new groups
like "Use VI, elm, tin". To avoid our efforts being wasted, it is important
to have a small guide pointing the user to the correct tools and detailing
how to get out of some common pitfalls. Of primary importance is making the
.doc attractive, readable and easy to navigate for the appropriate
information. If we look at a How-To collection, we will find most to be
reference rather than pedagogical works; in addition there is no hierarchy:
important .docs and obscure ones, .docs for advanced users and for beginners
are all at the same level and it is difficult to find what you are looking
for. I have seen people using Windows or NT because they didn't know about a
Linux program: we will have to ship one of the databases of Linux software
like the LSM. Woven Goods could be a good choice: it includes all the LDP
documents, an LSM, plenty of info about Linux software, all in very nice
HTML. Caldera used to include it but doesn't anymore. I don't know why;
perhaps because of its size and the fact it has not been translated AFAIK.
Speaking of translations, Linux could afford to have docs available only in
English as long as its users were 'computer nerds', but 'normal people' are
not good at foreign languages. Man pages and most How-Tos have been
translated, but only a few programs have been internationalized. This also
goes for special manuals like the GIMP manual or doc in info format.
<H4>
d) Learning from Microsoft.</H4>
<I>"Learn from your enemy and you will ever be victorious"<BR> -Sun Tzu
<BR><BR>
"Microsoft makes crappy operating systems but they make good user
interfaces"<BR>
-Linus.</I><BR><BR>
Look at the last versions of DOS before Windows 95. They made a file manager
(DosShell) to be the default, and forced experienced users to edit the
AUTOEXEC.BAT. In Linux we make the power-user get his favorite interface out
of the box and the defenseless new user is supposed to discover about "mc"
and then the way to make it his default shell. This illustrates what is
wrong in Linux designer's thinking: design for Linux the same way as for
University
Unix. It would be a good idea to provide an option at user creation: <BR>
"advanced user" or "beginner" with the latter being dropped into 'mc'
instead of the shell. Of course in most cases this would be a moot point
because we hope to make XDM the default root level, but it is still
worthwhile to implement. In Microsoft products like Windows 95 and MS Word,
the user gets a tip each time he starts it. This ensures the user learns the
main tricks and ways to get out of problems. In fact, Microsoft software's
frequent crashes are not due to bugs. This is a feature to ensure that the
user will read many messages and learn fast. :-) This a trick (also used in
GIMP) we should
take advantage of: display a tip each time the user logs in.
<BR>
<H4>
e) What is wrong with RTFM</H4>
There was a time the Matrox Mystique was the most popular card.
Unfortunately it wasn't supported by Xfree, and for months after it was
supported there were people with old versions asking why it didn't work. Of
course they were
mercilessly flamed. Nobody pointed out that the X configurator could have
said flatly: "This card is unsupported". Nobody pointed out that the X
configurator could have said: "This version is 11 months old, you should
look
for an upgrade". "RTFM in case of problem" is the answer you give a user who
knows how to get
to the doc, how to look through it, and has only one problem to solve (like
when trying to add a service to a working box For the user who Instead has
half a dozen problems (like right after finishing installation) it helps if
he isn't forced to look at the book to know how to display a file. If the
user doesn't meet these requisites then the program should point at what is
wrong. It is astonishing how often the simple principle of "Put the
information under the user's nose" is forgotten in Linux world. The
existence of an FAQ in news groups that doesn't mean that users are lazy; it
just means we did something wrong. <BR><BR><BR><B>
f) Networking: the road to help<BR><BR></B>Commercial Unix users have hot
lines. University users can go to friends or teachers but Linux needs to
spread at home, and the Net is very often the only way to get help for a
home user. This means that we should introduce PPP configuration in
installation. We also need a good curses-based PPP configurator in case the
user does not configure at install time. KDE has a very good configurator
but we can't rely on it: What happens if the user needs help about X? In
many countries phone time is billed at extortionist
rates; therefore, we should optimize to make the connection be as short as
possible. Mail and news clients should allow off line reading. Some small
organizations could have net access through PPP, but for them small mail and
news servers would be better than off line readers. That means we have to
design a mechanism ensuring that traffic is routed when the PPP link is up,
and that mechanism should not require the user to hack files. With small
mail and news servers there is the problem that they don't have Linuxconf
modules like send mail. For mail IBM's "postfix" could be a good compromise
because it is able to use either sendmail configuration files or a native
(and simpler) mode, but we have to carefully check its copyright A proxy
server can allow substantially faster (and thus cheaper) web surfing;
however, the batch retrieving allowed by wwwoffle is more important for
small organizations and home users than the proxy interconnection allowed by
Squid (the proxy shipped by RedHat). Again the problem is that wwwoffle has
no Linuxconf module while squid has one. Another interesting proxy is
"junkbuster" which removes the ads from web pages. If we ship two proxies we
have to design a clean and transparent mechanism for chaining them. Finally,
UUCP is sorely neglected in Linux distributions. It is dead in America but
its speed and low requirements makes it still useful in Europe,
ex-communist,and Third World countries.
<H4><BR>
g) Replace cron</H4>
We can no longer live with the absurd paradigm that the user will keep his
box turned on for 24 hours a day. The replacement for cron should accept
regular crontabs for compatibility, be self-tuning (use cron mechanisms if
the machine
is turned on when the task is programmed and alternative mechanisms if a
task was not run at the programmed time) and unobtrusive (try to run tasks
when load is low). AFAIK "anacron" falls short on the unobtrusive part.
<BR>
<H4>
h) Get a better booter than LILO</H4>
LILO is a hacker's booter. You have to perform a special operation when
installing a new kernel, don't get menus at boot time, support for national
keyboards is tricky, and you can do nothing until you reboot. Other booters
should be investigated. The one I like most is the booter which used to come
with the now defunct Linux Universe. You got menus, could add a kernel at
boot time, explore the file system in case you didn't remember where it was,
change booter parms at boot time and could change the keyboard on the fly.
It seems there will not be copyright problems but there are parts which need
a Microsoft or Borland assembler unless someone translates them into gas
syntax.
<H4><BR>
i) Pushing aside the "mother of all Unix haters".</H4>
Every time I find a Unix hater I ask him why. So far no one has told me
about the shell or the cryptic commands as the main reason. <B>ALL
</B>of
them pointed to VI as the culprit. (Emacs does not seem to cause this kind
of allergic
:-). "VI is the editor you will find in all Unixes". Well, in most jobs you
could down load another editor even if you are using another Unix; and in
addition, we hope Linux will crush other Unixes, so to hell with their
editor.
VI has made Unix lose many users; don't let the same happen to Linux. We
don't plan to remove VI, but:<UL><LI> Never force it on an unwilling user.
The Editor environment variable must be set so that programs needing an
editor don't call VI. It is simple to set it differently according to
whether or not we are using X. Never place the user in a situation where VI
is the only editor: ensure that there is another editor in /bin with all
needed shared
libs in /lib so the user can resort to it in case he cannot mount /usr. In
the same way, place an alternative in rescue disks. Unfortunately we cannot
remove sentences like "edit this file with VI" from standard docs but we
should never use mention VI in docs written for this project. We don't want
to frighten new users. Don't ask yourself if VI is good for you, ask
yourself if VI is good for Linux.
<H4><BR></UL></LI>
j) The user should not have to recompile the kernel.</H4>
It is our duty to ship kernels complete and good enough so the user will
never need to recompile them except for sport and <B>very</B> experimental
features. In 2.0 the performance increase you get by recompiling the kernel
(if the distribution editor did a half decent work) is nearly nil, despite
what vulgata could say. See my analysis in the Independence-features RPM.
About the only case in which it's necessary is if you are using a multi
processor box. This could change in 2.2, especially when using better
compilers than gcc 2.7 so perhaps we will be forced to ship several kernels
and have the
installation choose one according to processor type and chip set.
<H4><BR>
k) X should be the default mode.</H4>
Nowadays the memory and CPU frugality of curses-based applications is not
important. People accustomed to windows will dislike this
kind of apps and in addition they will find themselves clueless in front of
the command line. We should make XDM the default boot mode (with LILO
telling how to boot non X).
<P><B>l) Consistent GUIs</B><BR>
Traditional X has had nearly every application having its own look and feel.
This is disconcerting to the user. Fortunately Linux now has complete GUIs
where every application shares the same look and feel and in addition have
richer intercommunication protocols than when using different tool kits. We
should keep neutrality in KDE-Gnome rivalry, ie ship both.
<P><B>m) Selecting application program</B>s
<P>Programs must be user-friendly (of course) and good looking (to an
inexperienced user, ugly programs cause an instinctive interpretation of
being buggy and of poor quality). ). If they need to have resources set to
make them attractive then it is up to us-- not to the user, to do the job.
Having easy programs is not enough; they need to cover a need for the user,
so shipping only hackers software will attract only hackers. This is not
what we want. For that reason we should look for programs which are fun,
allow artistic expression (I would like to ship a GIMP with every plug in
available)
and are useful for real life. We don't want the user needing to boot DOS
just to manage his check book. Agreed, some of the free programs we can
include are not as attractive as their Windows commercial counterparts, but
by providing Linux alternatives there is a chance the user will be annoyed
at having to boot DOS and be still more reluctant to buy them. Many editors
don't port to Linux, many hardware manufacturers don't provide drivers
because they expect the Linux user will accept to reboot Windows. Providing
software for everyday life will make Linux users more likely to refuse
playing this game.
<H4>
n) Games</H4>SVGAlib games must run setuid root so everyone is a security
risk. In addition a number of cards are not supported in SVGAlib. We should
avoid them. We can make exceptions in rare occasions because, unfortunately,
X is
not adequate for action games (not without GLX who is not supported in
XFree). Net worked games can be played in America and in Universities but
in Europe the telephone is too expensive and this restricts their use to
people having
several computers in the same home. <BR>
<H4>
o) Delivering ready to use applications</H4>We must try to get installations
requiring as little user intervention as possible. X apps must get their way
into menus, resource files provide good looks out of the box, parms who can
be deduced automatically must find their
way in config files (think in a networking client who needs the machine host
name) and so on. Whenever possible we should avoid automatic edition because
it is relatively dangerous, especially in case the user has manually
edited the file. Instead, we should use file inclusion or directory scanning
(look at /etc/profile.d for examples) if at all possible.
<BR>
<H4>
p) Plug and play cards</H4>
Using the isapnp tools is very difficult, and this makes using most sound
cards a daunting ordeal. The Turbo Linux distribution has a GPLed tool whose
main drawback is being curses based. There is also a Gnome front end to
isapnp but, for one part it is unfinished work, and in addition this lets
KDE or classic X ers out.
<H4>
q ) Samba</H4>
Having Linux sharing disk space with Windows boxes is not uncommon, whether
in
the server or client role. Linuxconf allows to configure Samba, so unless
there is a significantly easier configurator, I think we could leave the
things the way they are. What wbut last time I checked it had a very
primitive setup. Of course we could modify it.
<H4>
r) Printing</H4>
We ship ghostscript 5.10 and we should introduce in the printer
configuration database the additional printers respective to the ghostscript
4 shipped in plain RedHat.
<H4>
s) Linuxconf</H4>
Having a central program like Linuxconf for configuring everything is a
great plus, but the drawback is that it tends to freeze situations. The most
popular or traditional programs have Linuxconf modules and that makes it
more
difficult for newer and easier programs to gain the upper hand. Sendmail,
for instance, is difficult to configure even with Linuxconf but the user
would tend to try his luck with Sendmail even when not requiring as powerful
MTA. Therefore it would be great if we were able to provide Linuxconf
modules when
shipping alternatives to classic servers.
<BR>
</BODY>
</HTML>