Re: SEUL: Installation steps

[Michael Peck <mjpeck@mailhost.rsn.hp.com>]

jfm2@club-internet.fr wrote:

[This response posted after Randy Heineke's well-put summary]

>    I'm not talking about kernel hackers and weekend Radio Shack warriors.
>    I'm talking about people (like myself) who have a new Intel 10/100Mbps
>    ethernet card and need an experimental driver just to use it. I'm
>    talking about people (like myself) who need to add sixteen characters to
>    one specific line in the ne.c driver to make it autodetect their Linksys
>    PCI NE/2000 card. I'm talking about people who have hardware that
>    doesn't work with a stock Linux distribution, but could otherwise work
>    fine.
> 
> But you work at Hewlett Packard and I do not think you work as a
> lawyer or an accountant.  Sorry but I think you are not the kind of
> people needing help.

Heh heh. I need plenty of help, but not the kind you're talking about.

Like I said before, ease-of-use is not something I feel should be
limited to the uninitiated. Nor do I believe that the uninitiated
should, themselves, be limited to ease-of-use. They are not mutually
congruent domains.

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.

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.

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.

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

> 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 think the screen configurator in Win95 is a good thing.  And one of
> the reasons I like KDE is than it provides us with a screen
> configurator, while being nicer than Win95 and allowing us to run
> Linux with Linux power.  And I do not think than forcing people to
> edit resource files (and finding these files) just to choose their
> screen saver, adds power to Linux.  It justs restricts the people
> competent enough to run Linux.

I am definitely agreed with this. Having the ability to edit resource
files individually is a strength, but that doesn't mean you can't layer
on top of it to improve it for a certain demographic. Make a generic
"Resource Settings" control panel, or something, that lets you set up
standard X resources as well as resources for individual apps.

> God forbids it!  Linux is better.  The goal is to KILL Win95 (a very
> long term dream I know :).  One of the steps in this path is to make
> Linux usable by 14 years old nieces.  And yes, we have some apps who
> could interest her because the equivalents in Windows are expensive
> and inferior.

Agreed.

MJP
-- 
Michael J. Peck
Hewlett-Packard, Convex Division
mjpeck@convex.com
Opinions expressed above are not necessarily those of my employer.
----------------------------------------------------------------------------
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.
----------------------------------------------------------------------------