Re: SEUL: Installation steps

[jfm2@club-internet.fr]

   Two points on this will summarize my position:

   1) Ease-of-use and ease-of-configuration/maintenance/administration is
   beneficial to everyone. I know how to do difficult things and I'm
   willing to spend time doing them. That doesn't make it desirable. I
   estimate that at the rate I bill my employer, the time it took me to
   build my PC from scratch and configure it to satisfactory condition
   under Linux was worth more money than I saved by not having it done by,
   say, VA Research. I want to change that. I think SEUL is poised to do
   it.

This is a good point.  In my idea is than we must issue a SEUL 1 not
overly ambitious (so it can be done fast) but significantly simpler to
use than present distributions for two reasons: we have not enough
manpower and the application software for end users does not exist.
Then capitalize on two facts: we will get more man (brain) power and
we will attract new users to Linux.  They will not be 14 years old
nieces but their arrival will carry the production of software (free
and commercial) adapted to them.

With this new software we will be able to produce SEUL 2 and think in
our nieces.


   2) Compiling a kernel is a staggeringly trivial thing to do. At the
   fundamental level, it is literally nothing more than setting some
   switches and executing a compile. Envision this: a window with a list
   box of checkmark choices. Clicking on a choice's text item brings up a
   separate window full of text describing the choice. Recommended choices
   are already selected. There is a big fat "GO" button below all of this
   in the window. When the user is done selecting choices, he/she puts the
   mouse over "GO" and clicks once. When the compile is finished, the
   front-end puts up a little window saying "Reboot to use your new kernel.
   If something goes wrong, type "linux.old" at the LILO prompt to return
   to the current kernel." There is a big fat "Reboot" button at the bottom
   of this window.

   Please explain which part of this your 14-year-old niece would not
   understand.

I can envision a good interface for kernel compiling.  Better than the
one we get with make xconfig in 2.0.  One in which the user is not
really aware than his kernel is being recompiled during installation.
And I would not object if we were still in 1.2 times.  But we can get
a still simpler to use interface by using modules.  And it will
require far less programming effort.  In fact all we have to do is
write a simple front end for kerneld.

That is one of the reasons I oppose to recompiling.

With 2.0 it is possible to build a SMALL set of kernels being both a)
optimal and b) covering all needs.  The loss is than a kernel with its
modules is 2K bigger per module than the equivalent monolitical
kernel.  So in the very unlikely case you have twenty modules you lose
40K and that if you use permenent modules.  This makes very little
difference in performance and fortunately we have no 640K bareer
limit.

   If you have time, please also explain why this wouldn't work for
   compilation of any number of source packages. Even something as trivial
   as a GUI front-end to RPM, DPKG, and GNU TAR would be an improvement.
   Better than that would be some sort of description file that developers
   could include with their projects that would tell our front end how to
   compile the program. Because SEUL is keeping track of the configuration
   of the box (it is, right?), it could automatically adjust the most
   common of compile-time errors, namely, library and include-file
   locations. Other problems would be relatively easy to solve this way.

RPM has a GUI front end.  Unfortunately it sucks.  I do not know in
Debian but in RedHat making rpm -ba SPECS_FILE will rebuild the
package.  At least if you have installed all the necessary development
packages where the include and libraries are installed.

   > The person I am thinking is my niece.  She is 14 years old,
   > intelligent, not a computer illiterate but she is not a hacker, not
   > even a programmer.  She lives at 400 km from my help.  I want her
   > becoming a Linuxer.  Making her recompile the kernel is out of the
   > question.  I want Linux becoming usable by people like her (a long
   > term dream), because if Linux remains in the hacker's niche soon or
   > later it will stop growing.

   Agreed. But we do not have to castrate the system for users to make
   broad acceptance possible. It's not a matter of bringing the system down
   to end-user level; it's a matter of improving the interface to
   accomodate the system. The interface is the bridge between the system
   and the user. If the user can't understand the system, it's the
   interface's fault. Simply limiting the scope of what parts of the system
   the interface addresses is a quick-fix, not a solution.

But I think we can provide all he neeeds without recompilations.
Except perhaps, upgrades see below.

   > So they have to download the patch, apply it, recompile the kernel,
   > install it, run LILO.  Wouldn't it be simpler to provide them with a
   > compiled kernel or module for people having hardware not supported in
   > the stable version of Linux?

   Not under SEUL, they don't have to do all that. All they have to do is
   make some kernel-build choices and press GO. The rest is done by our
   front-end. I mean, 'make zlilo', a standard component of the kernel,
   already does compiling, installation, and LILO! All we have to do is get
   and apply the patches. This is trivial. Automation of such downloading
   is already under way with automatic distribution updaters and such.
   Simply provide a standard place on a well-known server, from which
   patches can be obtained. The front-end can get and install them.

I give you this point.  This does not have to ber complicated.  And it
is perhaps the better solution for upgrading.  But people upgrading
have a few flying hours behind them.  I still think than this is not a
good idea for a first install.  In part because a first time user does
not know if its software is working and prone to get nervous when
something does not work the first time he tries.  He will not know if
he misconfigured it, is broken or did something wrong when
recompiling.  And he is likely to believe it was the thing he did ie
the recompiling so he will hack his kernel beyond recognition.

The less human intervention in the critical first installation the
best.

   MJP
   -- 
   Michael J. Peck
   Hewlett-Packard, Convex Division
   mjpeck@convex.com

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