[Rule-list] THE RULE SITE IS UP!

[Devon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 13 February 2002 04:19 am, Marco Fioretti wrote:

> 1) Red Hat compatibility, at least in the sense that one can upgrade
>    our system with stock RPMs provided by them, is essential. The
>    reasons are that we have no resources to do a completely new thing,
>    and, much more important, that we want the developing country school
>    to enter Free Software world as a first class citizen: one that can
>    use the same SW/support forums/online documentation available to
>    people with 512 MB of RAM, not be relegated to some corner.

I couldn't agree more. Either way we go, I think we want to stick to 
RedHat compatible modifications.

> 2) We should start to distinguish between:
>
> 	a) Make today's RH base install fit in <32 MB of RAM.
> 		this might touch only anaconda, fit on one or
> 		more floppies, and be eventually adopted by RH
> 		because it's in their interest, and they got it for
> 		free.

I have managed to do this as well, just by rebuilding anaconda with a 
couple of patches, and booting with 'linux updates' and providing an 
updated anaconda. To be done properly, it would be good to create a new 
install class, "low-mem" or something similar, which defaults to a 
limited package set. In the testing I've done, 165MB of disk space are 
needed PLUS swap. So, it looks to me like ~200MB disk will be a minimum 
requirement. I'd also suggest 16MB of ram as a hard coded limit. Less may 
be possible, but I don't believe the system will be responsive enough to 
consider it truly functional.

I'll have to look some more, because I am not sure a new install class is 
possible unless we get redhat to adopt it. I don't believe that this 
could be done with an updates disk alone. The updates disk provides a new 
anaconda script only, and I'm not sure a new install class could be 
implemented in this way. It looks to me as though it would need to be 
contained in the stage1 and stage2 images on the install media. I'll 
spend some time tonight looking into the code some more for how this 
might work.

> 	b) Make *our* choice of packages,with comp files and all,
> 	   and that cannot be anything else than a separate ISO image,
> 	   as you did.
> 	   If RH sees it as valid for educating future customers to
> 	   buy their stuff later instead of MS's, they add the standard,
>  	   already existing RPMs we choose (Postfix, etc...) comp files,
> 	   etc..to their first disk, otherwise we just make it
> 	   available (still guaranteeing compatibility as stated above).

Personally, I see this as a more viable option, which gives us greater 
possibilities. The version I put together contains only RedHat provided 
RPM packages (fully updated), but it could include nearly anything. 
Custom rpm packages, a custom post install script, etc.
I was able to install a base system using my new disk, complete the 
install, and then insert official RedHat 7.2 disks, installing additional 
packages without conflict.
Additionally, after the base install, if an internet connection is 
present, the user would have access to up2date to get any additional 
packages desired.

> I was already thinking to post these thoughts to the list, but I'd
> really like your feedback first, since you have already done so much
> good work on the installation setup.

Anyway, like I said, I'll work on whichever we decide to do. I just want 
to make sure I am working on the same thing as everyone else. :)

- -D

(Which is a nickname I am stuck with, by the way. Long story...) 
My real name is Michael Fratoni.

- -- 

pgp key:  http://www.tuxfan.homeip.net:8080/pgpkey.txt

- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8aljReMAUbzJhSVcRAuKGAJ9ALziLwBJyOnwuWOwbXLOh2lhvRwCeJ+hB
EkhAPhdvBJ6lPN7FNU+0pJk=
=Q1zG
-----END PGP SIGNATURE-----