[RULE] Spreadsheet/DB of the SW, part 2

[Eugene Wong]

>From: "M. Fioretti" <m.fioretti at inwind.it>
<snip>
>Looks like we are all converging on this, doesn't it? (see also
>Colin's thread)

Yeah, it does look like that. I find it ironic that people who are excited 
about "outdated" hardware are trying to produce user-friendly software, 
which happens to be top-notch & better than the companies that earn money 
doing it.

>The database, or whatever else, should ask: do you need
>IMAP email (not do you want Kmail or mutt) Do you need Javascript
>support (not : do you need mozilla or links) I've been saying this for
>years.

An interesting comparisson, is the script/whatever that helps us to 
configure the kernel, when we compile. It never asks us which driver we 
want. It just asks us if we want a TCP/IP driver, an ethernet driver, etc. 
We never find out who made it, or how efficient it is.

Perhaps the install should be broken down to 2 completely seperate packages: 
the configurator; & the installer. The configurator, probes hardware, asks 
questions, & selects software. It is just as you said: something that can be 
run anytime before the install. This will create a kickstart file, so that 
no matter what, the installer will be able to install by kickstart. If the 
user is a power user, he could edit the file to remove packages or edit this 
& that. With our install methods, Aunt Tilley & most power users both use 
the kickstart file. With the present Red Hat system, only some power users 
use the kickstart file.

Perhaps we could have 2 boot disks & an optional data disk. With the 1st 
boot disk, we could have the configurator, which has a lot good features to 
be flexible, robust, & easy to use. Maybe the data could be stored on the 
same disk. So, maybe it shouldn't have a compressed file system?  Does 
anybody know how to store data on a boot disk? With the 2nd boot disk, we 
could have the install which does everything that the other disk hasn't 
done, & interacts very little, if @ all. For the optional data disk, maybe 
that could contain any extra data. These disks are only options for the sake 
of physical portability: you could configure a little @ work during lunch, 
take home the disk, & configure some more @ home. There should be the option 
to run these scripts on the main system without the use of floppy disks. 
This would allow for the rebooting that we discussed, and/or simple 
upgrading, and/or whatever. I don't imagine that the scripts would be any 
different whether they are on floppies or not.

I think that this method is very powerful & covenient, @ the expense of user 
friendliness. However, good documentation, & decent error messages should be 
able to compensate.

Also, we could compile busybox for each disk to only contain the features 
that we need for that disk's tasks. For the install disk, I don't think that 
busybox will need very many features.

Also, we should try to remain open to using a FreeDOS boot disk for the 
configurator. It requires an extremely small amount of disk space, & we are 
only gathering information, & recording it as plain text, if I understand 
correctly.

Also, if this is done properly, it could make it easier to fix broken 
systems. Aunt Tilley could bring her kickstart file to Joe Hacker's house & 
he could look over the file to see what might need to be installed, as well 
as any hardware configurations that might need altering. I don't know; I'm 
just thinking out loud.

If there are no more suggestions, then maybe this weekend, we could start 
planning the steps that need to be taken.


Sincerely, and with thanks,
Eugene T.S. Wong

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online  
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963



_______________________________________________
Rule Project HOME PAGE:  http://www.rule-project.org/en/
Rule Development Site:   http://savannah.gnu.org/projects/rule/
Rule-list at nongnu.org
http://mail.nongnu.org/mailman/listinfo/rule-list