On Wed, Sep 04, 2002 at 01:21:07PM -0400, Michael Poole wrote: > Install-time checks let you do as much pondering as you want. Using > the alternatives system lets you override the system's current choice; > it provides a superset of the functionality that run-time selection > does, and only incurs extra cost for uncommon operations (such as > upgrading a CPU without reinstalling or installing a disk image -- > either of which already requires intervention or automated fixups). Why does the fact that you need to change your hostname & such make the possibility of having to fix a lot of surprising library dependencies a good thing? Forcing an effective reinstall on upgrade is popular for some OS's, but not this one. > What makes this so different than autoconf vs imake, which is based on > similar in-system-test versus platform-detection selections? There > are about as many x86 CPU variants as there are *nix OSes, Because those differences involve header files and libraries and *cannot* be sanely done except at build-time. > well. How much extra code and single-use data will go into the shared > libraries to do CPU detection and run-time code selection? Almost none. The optimized sections are typically tiny (you don't find people writing 10M libraries in assembler) and the code to select a particular branch is also fairly small (typically a few instructions at most to get a cpu to spit out its vital stats.) -- Mike Stone
Attachment:
pgpZWx4DauSBF.pgp
Description: PGP signature