Re: SEUL: Installation steps

[jfm2@club-internet.fr]

   From: Michael Peck <mjpeck@mailhost.rsn.hp.com>
   Organization: Hewlett-Packard
   > 2) A minimule linux should be loaded onto a ram disk (the kernel should
   > have modules enabled).//Example Slackware install//

   This may be a no-brainer, but we should be sure to compile the default
   kernel for 386 processors. My AMD machines have fits over
   Pentium-targeted kernels, and the 386 kernels don't give much of a
   performance disadvantage.

But they are a poor choice for BiProcessors.  And you do not need FPU
support on Pentiums.  Well, except if you got an early model :-))

We could have an universal kernel for installation and the
installation software would choose an optimal kernel for production.
The universal kernel would also be iinstalled for use as a backup.
Using modules would allow to have a small number of production
kernels.

   > 4)Add needed drivers

   How does SEUL handle drivers? Suppose the user wants to use an
   experimental driver, that we have not prepackaged. How would they go
   about doing this?

Not by recompiling.  All official Linux must be in the kernel or in
modules.  People trying experimental things are not our public.  And
they are good enough to be able to recompile the kernel without help.

   One thought is that we might have a generic "kernel compiler" interface
   program. It would let the user configure a kernel safely, then compile
   it with some sort of GUI front-end and install it (a la make zlilo).

No!!!  Modules is the way to go.

   Another idea might be to have a totally generic compiler interface.
   Instead of Makefiles/Imakefiles/autoconf, we could have a simple API
   that allows developers to specify simplistic compile-time options. Many
   portability problems come from not knowing the specific configuration of
   a particular box; with SEUL, we could (in a limited sense) control that,
   and at least keep track of it. This would be a rather ambitious
   undertaking, but it's worth looking into. Compiling programs is a Linux
   way of life; can we make that more understandable to end users?

There are people who do not want lose time compiling kernels.  What
they want is WORK with Linux.  Why spend so much effort on making a
kernel compiling interface aimed to end users when it is so easy to
provide a few lean kernels with modules for everything and write a
simple program for configuring kerneld?

   > 5)install kernel & modules (install lilo???)

   My vote on LILO is simply to make it standard. Until a better boot
   loader comes along, I say simplify matters and just use LILO. I've never
   done it any other way; can someone point out the potential pitfalls?

My vote is to aproach Sandro Rubini (he wrote an article about Linux
booting in LJ) and ask him writing a better booter, or help us to find
someone for this task.  I exposed in this list the reasons for
replacing LILO: dangerous to use, no foreing keyboards (a BIG pain for
poor aliens like me), unability to display boot parameters if you
can't boot.  I also exposed the beauties of the (non-free) booter of
Linux-FT.

   > 7) personnelize linux (i.e. fonts, colors, etc., etc.)

   How much of this might we do? Are we talking about some sort of
   interface to setterm, stty, xterm, etc.? Or just X Windows stuff? And if
   just X Windows, how can we do this before we know a) The video
   specifics, and b) The window manager in use?

Certainly not the WM.  Part of our public probably will not know the
WMs and we would just confuse them.  We must pick a good one.  For
advanced users we could provide them with a little piece of sotware
allowing them to choose the WM.  It just needs to make a symbolic link
between .xinitrc and, for instance, .xinitrc.kde or .xinitrc.afterstep

-- 
			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.
----------------------------------------------------------------------------