Glenn, On Wed, Oct 20, 1999 at 02:34:43PM +1000, Glenn McGrath wrote: > Ive as yet not tried to compile with cpu specific options, i hadent > considered wether compiling with different CPU options would introduce > compile errors. I think that making it easy to compile for different cpu's should be given higher priority since from what I have read it can make a big (huge possibly in athlon's case does gcc have athlon optimizations yet?) in speed. > > >From what ive gathered from being on debian lists for a few days. > 1. One of debians main goals is to support the lowest level of available > hardware This is a good thing, although it shouldn't be only properly support the lowest level of available hardware. > 2. Distribution size is limited packages that have a low low utility/size > ratio are shunned.... archive bloat This is a good thing also, see below for my thoughts on a solution. > > So i guess the most acceptable way would be to make a tool that makes it > easy for the end user to recompile it themselves from the src. . I agree. > It could be done as a seperate distribution based on debian src packages, > but independent from debian org It could be a separate distribution but why does it really need to be, we don't need more fracturing of debian. It could be done fairly simply using source packages. > <RANT MODE> > Debian is the most altruistic distro there is however if my constructive > criticism is worth anything then i say. > > The strength of open source is that you CAN customise it to your needs, you > can optimise it for your specific CPU, so if users can't optimise there > binaries for there CPU, then open source is being used to its fullest > potential. > > Why let a whole new breed of distro's like (mandrake and enoch) pop up when > there one good feature could be implemented by debian. > > Archive bloat.... i thought debian was about giving the user the choice of > what they wanted rather them presenting them with subset of whats available. > I feel silly even sugesting this, but why not have official binaries for > other cpu's, its the only way they would get widespread use. There are official binaries for different architectures but having optimized packages for every different cpu type on x86 (and possibly other archs also?) would take immense amounts of space. > Possible reasons > 1) Archive bloat > Storage is cheap ($22 per GB where i am), mirrors should be able to handle > this, thats what there all about. > CD's are cheap, a coupla dollars I did a quick lookup on pricewatch for server quality drives (imho) IBM Ultrastar 18lzx 18.3GB $599 IBM Ultrastar 36zx 36.7GB $866 Seagate Cheetah 18lp 18.2GB $652 Seagate Cheetah 36 36.4GB $898 I think I read somewhere that the mirror is getting very close to taking 18GB so all the mirrors would have to upgrade their drives to at least 36GB or more if all the processor type builds were to be mirrored. Also remember these mirrors are all donated so if the space runs low there is no guarantee that they will/or can upgrade their drives. > 2) Bandwidth of mirrors > Mirrors could JUST mirror the 386 packages if they didnt consider others > worthy, its there choice I think that this would be a good solution. I think there could be a better solution though. I am not very familiar with the way FreeBSD works but I know that part of their packaging system involves the user compiling packages locally on their system and installing them. If it is possible to make a way to easily compile each package for different optimizations a program could be written to just download the source (like apt-get source does) and compile/install the packages. Then all you would need to store on the mirrors would be the main distribution (ie i386) and the source debs. A user could install using the i386 debs and then upgrade to their processor specific version with very little overhead to the mirrors. Most of the users who would want a processor specific distribution have fairly fast computers so the compile time *might* not be too bad (I don't have data to verify this). Sorry if I rambled too much. Thanks, Chris PS - Wichert I cc:'d you to see if this makes any sense or is doable...
Attachment:
pgpFHrMLv4lvi.pgp
Description: PGP signature