Plan of action for dev-install

[jfm2@club-internet.fr]

The following is only a draft, subject to the approval of SEUL leaders.
So don't consider this as definitive or official.

Headers:

-Delimiting boundaries
-Strategic issues: no revolution but removing bottlenecks.
-Kernel matters
-Partitionning
-Internationalization
-Crontabs.
-Networking
-X setup


1) Delimiting boundaries.

When the install is ended?  For many distributions it is when the
software has been loaded on disk.  IMHO this is not enough.  A Linux
without a functional X is severely hampered in the applications it can
run so without X is not completed.  I also consider of the utmost
importance to allow the user to get help: mail and news must be
functionnal for the install be considered complete.  That does not
means than I consider than the dev-install group has to develop tools
for configuring X or news just than I want than the tool be called as
part of the installation or automatically at first reboot.


2) Strategic issues: No wild dreams just removing bottlenecks.

I have already exposed the theory of the weakest link in a chain.  The
users we can expect attract must be able to use our apps, so at this
time it is useless to make an ambitious install procedure than even
people having never touched a computer could use if the Linux software
is not user friendly enough for them.  Even when including commercial
software present Linux with its multiple toolkit-dependent UI is not
as easy and coherent as a Mac.  So my intention is instead of an
ambitious installation, who would be very long to develop, simply
remove some critical bottlenecks.  When applicative software will
allow Linux use by a wider population then it will be time to design a
better install.  About bottlenecks a preliminary analysis shows some
of them: kernel recompilings, partitionning, better
internationalization, the crontab issue, enabling the user to ask for
help and some easy improvements to the X configuration.


3) Kernel recompiling:

Our users should NEVER _have_ to recompile their kernels.  SEUL cannot
allow itself to ship fat and underpowered kernels like some
distributions do.  This can be valid for their users, it is not valid
for ours.  Our users cannot fix unadequate kernels by recompiling
them.  So we must use modules to the most in order to ship kernels
being both lean (vital in 8 M machines) and powerful.  However the
limits in 2.0 modularization (most networkings features and IDE
support are not modular) make than no single kernel can satisfy all
needs and at the same time be near optimal so we will ship more than
one.  My intention is not however to have the user painfully choosing
his kernel like in Slackware.  We will have one and ONLY one kernel
for installation.  This kernel must be able to cope with the most
exotic needs but my tests made me find some areas of improvement in
present distributions so I have good hopes for it being leaner and as
powerful than the best kernels included in present distributions.
During the installation we will ask the user about his networking
needs.  The answer to this single question crossed with the hardware
detected will determine which, in a series of nearly optimal kernels,
will be installed.  In case we guess wrong or the user gets new
hardware we will _also_ install the universal kernel.  About the
optimized kernels I intend them to be limited in number about half a
dozen, too many would a nightmare to maintain.  We will concentrate in
giving maximum flexibility to the users really unable to recompile:
SCSI use is rare between unexperienced people so most of the optimized
kernels will for IDE while SCSI users will get fewer choices and
perhaps will have to content themselves with the universal kernel.  I
nearly forgot: the user would not have to recompile to get sound
support.  Sound is necessary for games and no end user system is
complete without games.

About kernel recompilings I think Omega posted the propositions (mail
me if you want  a repost) I made in another list for a cut down kernel
recompilation procedure unable to cope with all cases but far simpler
and less dangerous than the present ones.  That would aim at
intermediate users.  However this is not part of Install so I just
submit the idea.


3) Partitionning.

This is one of the most critical issues because in addition to the
risks the user will have to live with his errors and a newbie will be
unable to make sensible choices.  We will have to provide him with a
beter user interface for partitionning than the raw fdisk.  And the
software will give advice in partitionning given the available space:
for instance only one partition for people with < 500 megs to maximize
disk usage, with more space it would advice more partitions and
suggest sizes.

At DOS level I want a front end for the preliminary phases so the FIPS
phase and the Linux booting are fully integrated.

Another idea than I want to implement if time is available is a
partitionless install.  No, I don't want to use UMSDOS.  I want we
create big DOS files and use the loopback interface to access them.
This should be far more efficient than UMSDOS both in speed (specially
if the user defrags before) and in disk usage.


4)  Internationalization.

This does not concern Americans but to us, aliens :-), present
distribs are not satisfactory.  I want than if the user chooses a
foreign keyboard then he will not have to type blind at LILO prompt
(LILO 20 supports national keyboards) and than environment variables
get set so the user will get error messages in his native language and
the doc software will be able to know which of the translations to
install and display.


5) Crontabs.

Many distributions perform cleaning tasks at some time between 00am
and 04am.  This is only valid for computers powered on 24 hours a day.
Home users pay the power bills so they power off their computers when
not using them.  Any scheme based on doing chores at fixed times of
the day will not work with home users computers.  I think Omega posted
my propositions for a scheme based on batch (batch only releases jobs
when the load is low) who would be more adequate for personal users.
Because the classic cron based method is better for computers
continuously powered on we will ask during install how the machine
will be used and choose the mechanism accordingly


6) Networking.

If you don't have a LAN card and a permanent connection to the net
nearly all distributions leave you with only the most minimal
networking: 127.0.0.1 localhost.  The correct solution is having the
hostname pointing to a non-routable address and that address
ifconfiged to the dummy interface.

If the user has a problem he will want to ask for help.  The road to
help must be something who is provided out of the box no something who
will work after hours or days of RTFMing.  The installation should not
let the user with an unconfigured PPP.  Online mail and news reading
is very expensive in many countries so we have to set up and configure
mail and news servers for offline reading.  While some distributions
prompt the user and set up adequate parms, none will set up the PPP
scripts in a way than mail and news are shipped and fetched
automatically: the habitual schemes for transfer are based on
_permanent_ access to the outside world..  I have seen cases where the
user had configured his software correctly but the failure point was
the transfer.  This must not happen in SEUL.

I would like to help UUCP users.  In some countries with expensive
phone rates, and in third world countries UUCP with its high speed is
much better than PPP (can be the only protocol available in third
world) for transferring mail and news.  However because few ISPs use
it, UUCP is useful for few people.  Therefore we will work on UUCP
only if we are ready before other parts of this project while we wait
for them.


7)  X setup.

I want to imitate RedHat who is resorting to automatic hardware
detection.  Unless there is something better in the interim we would
use their software (it is GPLed).  I think we have better to do than
to reinvent the wheel.  There is a thing where we can improve on them:
people getting only VGA16 (as good as unsupported) will be told why.
I am tired of seeing posts in news groups of people who have fought
for days getting only 16 colors, low res and slowness when the problem
is than their card is not supported.

If the card is unknown we will tell them, if the version of XFree is
old we will advise to upgrade (there are still people fighting Matrox
Mystiques with XFree 3.2), if the card is from a manufacturer who does
not release the doc (and the version is not old) we will tell about it
to the user and, perhaps, we should tell him where to send flames.
Angry _customers_ can do wonders for making a company change policy.
:-)


Conclusion:

This is a sketch of what I propose for the install part.  While I can
have forgotten some points it gives an idea of the general policy.
Concentrate on critical areas.  Give the maximum help to people really
needing it.  Don't be sidetracked on problems affecting few users at
the expense of the problems of the majority.  Use existent components
whenever possible.  Don't reinvent the wheel.