SEUL: Re: Weekends posts

[jmunoz@nospam.mho.net]

Luka (Peter) wrote:
snip
> stage 0: (done by us, not the user)
>    define the target user.  this allows other stages to make
>    some base assumptions about our user.  also make any other preliminary
>    design decisions for the installer overall.

This will include thing like at least 40x80 term (maybe we should
modernize to vga?-terminals still around though not too many linux
novices will use them), 101 key kbd?, mouse?, HD or ethernet, floppy,
cd-rom,etc.  Define min. target hardware. Install assumes these are
present to do step 1 and 2 at least.

> 
> stages of linux use: (user is central to these)
> 1. system preparation:  drive partitioning, getting linux, etc.
> 2. hardware config:  telling the installer what hw you have
>    (this includes auto-detection routines).
> 3. "function" config:  tell the installer what the function of the
>    machine will be.  can be specific or general, but should affect
>    what sorts of packages get installed.
> 4. "form" config: what UI do you want?  win95 lookalike?  mac lookalike?

-Thomas Molesworth <thomas@bass.almac.co.uk> wrote
-please, let's stick with one UI until it's working! win95 is better
simply

This can still be part of requirements- ie do design so that we can do
this later if we get that far and it is still a priority...

> 5. operation:  everything that happens after installation.
>    there should be notable changes to things like app error spewage.
>    users need to know what to do about an error, not just its name.
>    also, expandability is important here.
> 
> stage 1: system preparation.
>   pulling together a general purpose hardware detector would
> be useful.  it should be modularized so that support for some
> hardware can be cut out to fit it on an install disk.  does
> anyone know if something like this exists? (under gpl, hopefully)

A shortcut might be to steal or parse existing OS configuration info
from '95 or 3.1 config files to minimise the probing or guessing.  We'd
have to write a dos/win program to save this info for linux on the new 
partition or diskette.

> 
> stage 3: "function" config
snip
  if anything goes wrong, it should do something
>   incredibly new and innovative: save the install config so far!
>   then tell the user something like:
>   so.... opinions on this?

the one downer is that many packages/fixes to problems will be released
after the SEUL distribution is chiseled into the Cd-Rom.  There should
be 
a contingency plan- point your browser (in that other
os)at"http://www.seul.com", where some kind of script could provide more
up to date info.  ie. have an error and description ready for user
inmediately, but have seul mini-install-howto's for specific problems. 
Whadda ya think?

> stage 4: "form" config
4. "form" config: what UI do you want?  win95 lookalike?  mac lookalike?
>please, let's stick with one UI until it's working!
snip
> which window manager to install.  i would like to add a new aspect:
> shell.  dos users will type "dir" and not guess "ls".

Mtools sort of does this with the mdir, mformat, etc.  No mounting, etc.
I agree about the man-pages. They need some common examples, and some 
commands need smarter defaults or better aliasing.  ex. < find . .config
 -print > is not intuitive. (IMHO).  I Think there are many things to be
learned from M$.  One nice feature is the '95 start-up window.  A tip of
the day, with hypertext leading to more detail. 
 
> stage 5: operation
>  for synch'ing
>   changes to work properly, the system will probably have to keep
>   a seul-specific database of user's preferences.  the user should
>   be able to completely punt the database at some point, once
>   he is confident enough to make decisions without it looking over
>   his shoulder.
>    i will now go check out debian, as i have been promising, and see
>   if all my problems are solved, before thinking more deeply about
>   implementation details.

Excellent Plan.  This one is going in the useful basket.  I think we
need to focus on defining a set of requirements that we can all agree
with before we make too many implementation decisions. Once we have all
the requirements in place we can see what solutions accomplish the most
and the most important ones and decide then.

Brian Bruns <camber@umcc.umcc.umich.edu> wrote:
>[ ]  Foo             0K     [Details]
>[X]  Bar             190K   [Details]
>[X]  Mail Services   1.5M   [Details] 
> ^ Text Checkbox             ^ Button
>
>      [Next]  [Previous]  [Stop]
>(of course this should be colorized and have appropriate keyboard 
>shortcuts, etc...)

Like the idea.  Another M$ design worth taking. A big shortcoming of
some older installs was no previous button, and no indication of
inter-dependencies of packages.  I expect the details would show libs,
programs, config files? Or just packages to include within the class of
Mail services? (fax, mail, etc.)

I think we need to spend some time redesigning things to get rid of
"dead ends".  I am sure you all have spent some time trying to figure
out what some show-stopping error's message meant.  Took me a while to
figure out what to do about "VFS: kernel panic: unable to mount roof fs,
remount sda3 read only".  There were many others, too.  Some suggested
fixes, but were often wrong.  These errors need to be informational, but
not try to guess too much.  I think everyone involved should start a
notebook of confusing errors to be adressed.  VMS has a nice error
format: severity:error originator,error message.  I think context for
the messages is the most common problem.  What program is having the
error, and with what sub-system?

I am logging man pages that need to be updated in my little notebook. 
We need to post these to a web site, check them in and out (RCS or
something) to work on them.  We may need to vote on to decide which are
best.

I just bought two LAN cards, and must say, it was tough finding info on
what I wanted (100tx PCI and EISA  or VL-bus).  The Hardware howto's are
somewhat out of date.  This area needs work. A database of current
installations, probs getting them to work, and work-arounds would be a
good starting point for install planning.  This could be a separate
project (Linux Doc project?)

I agree that we need a suite.  IMHO, this would be browser/word
processor, spreadsheet, and database.  I have been meaning to get Msql
to see how it is.  SQL is standard, the other two are more difficult to
pin down for a 'Simple End User'.

sorry this was so long, trying to post once this weekend.
PS: CL, email me to summarize (remove all but what I wrote and shorten
for repost)
-- 
John Munoz:  jmunoz@nospam.mho.net.  No unsolicited ads please remove
nospam
abuse@mho.net a@b.net bill@whitehouse.com postmaster@fbi.gov 
Support the Anti-Spam bill.  Join at http:/www/cauce.org/
---------------------------hm.fsfjgh@win.bright.net>
Lines: 19
X-Mailer: Gnus v5.3/Emacs 19.34
Sender: owner-seul-project@mail.txcc.net
Precedence: bulk
Reply-To: seul-project@mail.txcc.net
Status: RO
X-Status: 

Leslie M. Barstow writes:

> To create a bulletproof package we need:

> 1) A package tool capable of:
>   * un-insta