[lsb-discuss] Multi-lib standards

[Bruce Dubbs]

tytso at mit.edu wrote:

> And given that there are some Atom chips which are 32-bit only, and a
> number of people who tend to run 32-bit VM's (because they want to
> conserve memory), there will be many ISV's who may very well decide
> they only want to ship 32-bit products, just to simplify their
> build/test matrices.

Of course there should be continued support for 32-bit systems.  The 
vast majority of computer users don't *need* 64-bit capability, but many 
think they do.

I wonder how much memory users actually save by running in 32-bit mode 
on 64-bit systems.  Memeory is pretty cheap, but there are also many who 
persist on running on 512M when memory is under $40/G.

> This actually brings up a problem for the LSB, which we've largely
> been ignoring for some time, which is the statement we can make about
> a 32-bit certified LSB platform working on a 64-bit distribution.  We
> currently don't have a good way of certifying a bi-arch distribution
> to be LSB compliant on 32-bit and 64-bit side of the world
> simultaneously, and part of this is due to a short-coming in our test
> tools, and part of this is a spec issue.

Precisely.  What *is* the standard.

> In practice, a 32-bit LSB compliant application will very likely run
> on a LSB-certified 64-bit version of RHEL and SLES, and less likely to
> run on Debian/Ubuntu, because of their historical approach to
> biarch/multiarch.  At the moment we're waving our hands on this issue,
> and I don't think a realistic solution is to assume that 64-bit "pure"
> systems are the wave of the future, and that 32-bit applications will
> disappear.  That potential future would be convenient for
> Debian/Ubuntu systems, certainly, but I don't think it's likely one.

Just because something can be done and has been done doesn't mean that 
it should be supported forever.  After all, IIRC, the reason Linus chose 
the 386 was that he didn't want to support the 16-bit segmented memory 
model.

Mixed models are really a clever hack, but not something the standards 
should encourage.  Still, I do think that user's should have a choice.

To me, the standard for multi-arch should be an add-on capability that 
can be removed as easily as a package.  It is up to a distro to ship 
that capability as default or not, but the user should be able to easily 
remove it if it is not appropriate for their system.

   -- Bruce