[Beowulf] hpl size problems

[Mark Hahn]

On Sat, 1 Oct 2005, Robert [UTF-8] G. Brown wrote:
...
> Seriously, how hard is it to move a code TOWARDS e.g. posix compliance?

I think that unfortunately several separate issues are being conflated:

- package format.  as far as I can see, there is no real disagreement
about what metadata needs to be attached to a package.  this means that 
differences are just petty turf issues, and that it's a SMOP to write 
a generic installer.  more importantly, to the app-vendor, any format will do.

- dependency-registry.  this is a bit sticky, since it requires a universal
language/catalog of _capabilities_, that is a set of canonical names for 
some standard of interface and behavior.  this is easy when there's a single 
implementation (eg kde), but tougher for something like MTAs, where any
number of implementations will do.

- interface/behavior spec.  typically an ABI, but will also include
command-level things ("newaliases" works for both sendmail and postfix).

I think that efforts like LSB have not taken this approach mainly because
it seems too intensive.  basically, every ABI function would have a 
<capability, version, provider> entry, but traditionally it's whole 
packages, not individual functions that are versioned.  (consider installing
atlas, which does not provide full lapack).

obviously, there is also resistance to this because it inherently unifies
interfaces, and makes it harder for vendors to distinguish themselves.
(or, for the pessimists out there, to lock in apps/users to a particular 
distro.)  I don't really see any reason in principle why Linux vendors 
couldn't agree on this sort of standardization.  LSB might even be able 
to do it, though I don't really see the point of mandating a particular 
package format.  (the capability names, behavior, interface and versioning
have to be agreed on, but as long as there is some ABI for querying the 
per-machine capability registry, any packaging format could be used.)

imagine if there was a standard way to enumerate whether a machine has an 
implementation of <daxpy,2.3.0,x86-64>, and to not only get the answer,
but the name of the library to link with.  (libtool is related to this,
but I think it's mainly a workaround for the lack of dependency-registry,
and is probably crippled by lack of canonical capabilities (standard).)