Re: SEUL: Documentation: info & postscript

[Erik Walthinsen <omega@aracnet.com>]

> > Dave Wreski <dave@nic.com>
> Peter Luka <luka@mit.edu>

> >2.  With all the talk about GUI apps, etc, has anyone thought about simply
> >using a web browser?  Whats wrong with having httpd running on all boxes,
> >and using this as a backend for all configuration applications?  You could
> >even use it as a replacement for GNUs 'info', and possibly a replacement
> >for man pages as well..
> 
> see omega's reponse about discussion that's been going on about this.
> this is roughly what we are planning on doing, though for various reasons
> we want to use an extended html format and a custom hacked browser.
> you will hear much more about this really soon.

It sounds from the way Dave's message is worded, that he's suggesting that 
all the apps we develop fit into the browser.  Now, I hope I'm just reading 
it wrong... ;-)

What I'm thinking currently with the help browser thing is to possibly write 
a version of both the main shell and the primary plugin (that uses HTML or 
similar) that will work under various environments.  This will basically mean 
having help-X, help-curses, help-win, help-etc...  If we do it right, these 
can be built with only minor differences in the makefile targets, simply 
linking in a different .a from the build tree to the bulk of the code.

If things are done correctly, we could have a help browser that runs under 
all the environments we'd be interested in (curses, X, GGI/Berlin 
eventually, and Win), and with active pages that can actually do stuff, we 
can even write the installer into a set of 'help pages' that can be viewed 
and used under Win.  This allows a 'seamless migration' from doze* to Linux, 
and allows us to read the doze* config files to grab hardware information.

On that thread for a sec, IIRC someone said that we shouldn't read the config 
files from doze*, we should always autodetect.  I say if we have access to
them, read them.  In fact, we might even seek them out.  If someone has a DOS 
partition in their table, try to mount it and see what we can gather.  Why 
spend the cycles to try to autoprobe the hardware if doze* has done it for us 
already?  We can even grab things like printer model and monitor specs...


> >3.  How many of us are kernel programmers?  If there aren't that many/any,
> >should we be so concerned with modifing the auto-detection mechanism of
> >the kernel, to probe for devices?
> nod. i know kernel.  but that doesn't mean i should hack it for seul, or that
> anyone else should.  question is: who will support kernel-based modifications?

I don't think we want to do any kernel mods.  If we have need for any 
changes, we e-mail linux-kernel.  The 'project' for the kernel is already 
well-established.  We shouldn't try to do something that isn't our job, 
because it will create headaches later on.

RedHat apparently shipped a hacked version of 2.0.31pre2 with their 2.0.30 
kernel sources.  I haven't verified this, but to be on the safe side I 
installed the kernel-sources rpm before building an SMP for the quad at work. 
Normally I simply go to ftp.kernel.org and snarf the latest.

OK, </ramble>, dunno what my point was with the last para... ;)


> also, we should exploit modules.  modules are great.  they are what will keep
> kernel rebuilds and failures from happening for our users, imho.

As I explained to luka ~hr ago in talk, there are some cases where modules 
won't do it.  The primary reason is the list of things that aren't modular, 
or must be configured at build time.  Things that aren't modular include what 
proc the kernel is built for (RedHat's default is built for a 386sx...), 
various networking options like firewalling, * cookies, etc.

Things that can't be configured except at build time include the sound driver.
If someone wants to create the equiv of XFree's link-kit for the stock 2.0.x 
OSSlite sound driver, that'd prob solve our problems, but it still has to be 
built.  The problem is that there's only one driver, not one per card, and 
things like IRQ and I/O port are currently inserted into some .h file and 
hard-coded into the binary.

        Erik Walthinsen - Webmaster and infrastructure for SEUL    __
  __                                                              / /\
 /  \           omega@sequent.com         Work: (503)578-5314    / /  \
|    | M E G A  omega@aracnet.com         Home: (503)281-4281   / / /\ \
_\  /_          psu12113@odin.cc.pdx.edu  Majoring in CS       / / /\ \ \
                                                              / /_/__\ \ \
SEUL: Simple End-User Linux - creating a Linux distribution  /________\ \ \
http://www.seul.org/       for the average home/office user  \___________\/



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