[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Independence's design goals




The following is what we could call an RFC for Indy design.  Or 10
commandments.  :-)


Preamble: Independence is a distribution made by Linux users working
not for profit.  Thay aim at making Linux easier to use and closer to
the reality faced by Linux users.

Goals:

1) Indy must be easy to use and administer. 

 Since Linux is affordable by individuals it is frequent that Linux
 users learn unassisted and in addition have to administer their
 computers from their first second.  This is very different from
 "University Unix" were you have a teacher, can ask questions to
 fellow students and you can rely on a system administrator to
 maintain the box in working condition at the time you don't even know
 how to copy a file.  Traditionel Unix could afford a steep learning
 curve, Linux cannot.


2) Indy must be optimized out of the box.

 Not only we assume the user could have to take his first steps in
 difficult conditions but we also assume the user has real work to do.
 We also asume that Linux gaining a reputation of a system were you
 have to spend days optimizing it instead of using it for real work
 can only harm it.  That means that if there is a way to make the
 distrib faster for some users who doesn't harm other users then it
 _must_ be done.  In particular we hate the "kernel compiling culture"
 were every month or so there is one of those silly articles telling
 you have to recompile your kernel.  While a custom kernel will ever
 be faster than a distribution one those articles fail to quantify the
 spped increase and discuss the reasons.  In case speedd increase is
 say 1% we assume non pedantic users would consider it is not worth
 the trouble.  In case it is substantially bigger then the question is
 why? Is it because it is impossible for distributions (who can only
 ship a limited number of kernels) to provide you a kernel who comes
 close in speed to a custom one or is it because the kernel you get is
 poorly compiled and is far slower than the ideal distribution kernel?
 In Indy believe that it is possible to ship a kernel good enough for
 users not needing to recompile it and that shipping an inferior
 kernel is a shooting offence.


3) Indy must be secure out of the box.

 Each time you connect to the Internet you are vulnerable.  If you
 don't ahve a permenent address that does not mean you are safe since
 you can be located through address scanning or through the attacker
 owning the web site you visited five minutes ago.  Since in Indy we
 assume the user could have strted with zero knowledge we can't
 abandon him at the end of installtion with a vulnerable machine: by
 the time he knows how to secure it his box could have been destroyed
 by an attacker or worse confidential information could have been
 stolen.  That means that at the end of Indy's installation the user
 should get a box where unneeded services are not started and who by
 default only accepts connections from internal network not from the
 outside specially for those services like NFS or Samba who have no
 business on the Internet.  If US legislation allows it we should
 replace telnet and rsh with crypted equivalents.


4) Info must go to the user instead of the opposite

When users start with zero knowledge and still have to miantain their
boxes it means that disaster can strike well before they know how to
deal with it, where is the info about it or even how to read this
info.  That means that booting screens should tell how to solve
booting problems, that loging in should display a tip about Linux
usage and so on.


5) Indy must be forgiving to user mistakes.

Many Linux distributions have features who make them unusable if root
makes the slightest mistake.  This could not be unreasonable if all
users were system adminstrators having years of Unix experience, it is
not if you think in a private user with zero Unix knowlegde who has
just instlled Linux.  That means that having X not starting in case
font server is not up or display manager has been changed is not
acceptable in Indy.


6) It is a terrible waste to use Linux as a web server.

Many distribution designers seem to act as if web or file serving were
the only activity Linux will be used for with the exciting work taking
place in Windows boxes.  While it was rational to restrict the
expensive Unix boxes to those activities requiring reliability or
sophisticated networking and keep word processing on the chepaer
Wintel boxes this is not valid for Linux.  Sure Linux can be the
fastest web serving platform of the moment (see benchmarks) but it is
economically rational to use it for word processing, games, graphic
creation or managing user's bank account.  But Linux is not being used
on the desktop and at home as much it is being in the server role.
While part of the reason is due to lack of software another part is
due to distribution deficiencies: either software is not shipped, or
they choose the wrong program for a given task or they configure it
poorly or they don't document it in the distribution manual.  In fact
because they don't take it seriously.  In Indy we dream that one day
litterature students will use a Wysywyg word processor running on
Linux for writing their thesis.  It means we are committed not only to
include a word processor in the distribution but also highlighting its
presencee in the doc and ensure printer configuration is painless or
that font configuration allows it to display right out of the box (we
have seen too often an otherwise superb Word processor made nearly
unusable due to poor font configuration in the distrib).  We also want
Indy being rich in desktop or multimedia software and software for
home users.  And the environment and peripherals required by this
softwre being properly set.


7)  User could have better uses of his time than reading HOWTOs.

Reading HOWTO after HOWTO is only possible if you are a student or a
system administrator in a large company.  In such companys being a
system adminitrators is a full time job so it is possible to read one
thousand page books just to configure sendmail, but doing so requires
there are hundreds of people around you making money for the company.
Small organizations cannot afford having an employee doing nothing
else than system amdinistration and that means that if some task
requires a level of expertise who can only be reached by a full time
system administrator then that company will have to choose NT.  Same
thing for private users who should want to use Linux as a productive
tool: siomething is wrong if the earning overhead precludes the use of
Linux as aproductive tool.


8) Linux users have a different set of problems.

If we look at a traditional distribution we see that they configure
Ethernet and then you are on your own.  But there are Linux users who
use Linux at home and want to acces our ISPs through modem, ISDN or
ADSL.  We pay connection time from our pockets so we need connections
being as short as possible, our access to the Net is intermittent so
mail solutions based on continuous acces are unadquate for us.  We
want to use it for games so tha means that we need working sound cards
and possibly working joysticks.  We want to use word processors and
that means printing in decent resolution and proper display in screen.
All of this and more should be provided out of the box.  


9) Sitting on traditions

For Linux becoming a mass system it must become a system were it is
relatively easy to learn it alone.  For those who earn alone many
traditional Unix utilities are unadequate becauise they were designed
on the hypothesis that their steep learning curve is softened by the
user's environment.  As an example there was a time wjere I tried to
help a Linuxer I had met at a store.  I was unable to help him despite
knowing the solution due to the simple fact I was unable to explain
him the use of VI and this was the only editor available in his
situation..  And that is why Indy will allow the use of an alternative
editor to VI in the direst situations (VI is alos available for
traditionalists): VI is not designed for people learning in isolation.
Neither is Emacs.  We should not allow traditions interfering in what
has to be done even if we have to keeep traditional utilities around
for compatibility.


10)  Not doing demagogics.

Impressing the user in order to increase sales is not needed by a not
for profit distribution like Indy.  Between the things we don't need
to do there is: a flashy installation (the only thing seen by
reviewers) on an otherwise frail and difficult to use distribution,
piling tons of redundant sofware like a dozen window managers or web
servers (ideally we would only ship one; the best) or optimizations
who aren't.  An example of the later is compiling for Pentium:
Pentiums are dead and on newer processors code optimized for Pentium
is far slower than code optimized for 386.  

-- 
			Jean Francois Martinez

Project Independence: Linux for the Masses
http://www.independence.seul.org