Michael Brown wrote:
> Seconded.
Since (I think) we're up to 3 CDs anyway, IMHO all of the installer
should be *386* capable (ie come with floating point emu, even if
optimised for 486 or better) and enough of the fundamental utilities
(init, modprobe, depmod, bash, maybe a dozen or twenty other tools, none
of which with the possible exception of BASH are at all speed-critical)
486-compatible to actually boot and get to the point of rebuilding the
packages, plus bundle a 386-runnable kernel, compiler and basic
libraries on one of the extra CDs. If need be, some 486-compatible
tools, libraries and/or kernel can be borrowed from the installer image
by doing a last-minute (after all RPMs are on) overwrite of executable
files from the image to the installation, where a file exists in both
the installation and the installer.
The idea is that a Mandrake CD will boot and install and reboot on a
386, but without anything fancy. Even runlevel 3 would be optional,
since you only need runlevel 1 to rebuild packages. The many things for
which high speed is entirely a non-issue (uname, hostname, setserial,
ping, ...) would be shipped 386-capable and optimised for 486
architecture. Some of the more speed-sensitive ones ([bg](un)zip[2],
bash, perl, framebuffer-X) would be available from the second-stage
installer. The remainder could even be rebuilt and downgraded
automagically (estimated time to completion on this 386sx25: 8 days 3
hours 51 minutes) using a minimum of disk space, since the installer
already ``knows'' the package dependencies involved.
> Code execution speed during the installer is not really a major issue,
> since the majority of the time is spent doing disk or network I/O anyway.
> As far as I can see there's no drawback to having a 486-compatible
> installer - please correct me if this is not the case.
I would say that this is always so for many system utilities as well
(df, mount, cfdisk, mkreiserfs, alsactl, groupadd, ...) but not those
that sort (ls, sort), do heavy maths (bzip2, ssh) or run often/fast
(top, tcpdump) or may face performance bottlenecks (apache, X) so may as
well compile the first group for 486 anyway (AFAIK all 486 stuff runs on
386, only optimisation is different, and I'll live with that :-) and
save incompatibility for the bottlenecks, where it will make a difference.
As I understand it, 486-optimised code is slightly smaller than
586-optimized, and the results vary depending on the kind of 586 you
optimise for (some Pentium optimisations (inserted NOPs and the like)
actually run *slower* on some Cyrix and AMD CPUs, and many others are no
help).
It might be worthwhile putting up ISOs for 386, Intel-686 and AMD-686 on
the FTP site, in addition to the normal 586 set,
...and/or...
(a) script(s) to turn an SRPM mirror into any or all of the above so it
is easy to grab a normal ISO, install it, mirror the SRPMS (or with a
boxed set, insert the SRPM CD) and wave the pervasive Mandrake wand
(wave the disk heads lots as well, I imagine) to make a 386-capable or
AMD-optimised set of ISOs locally.
--
Don't put off for tomorrow what you can do today,
because if you enjoy it today you can do it again tomorrow.
