tytso at mit.edu
Mon Feb 4 17:08:14 PST 2008
On Mon, Feb 04, 2008 at 02:37:22PM -0500, Jeff Licquia wrote:
> If we do this, then we essentially incorporate, by reference, the entire
> Sun spec, certification program, etc. into the LSB.
> This creates two problems:
> - Distributions can currently verify their compliance with the LSB for
> free. This would not be possible afterwards.
> - The LSB certification process becomes yoked to Sun's process.
Well, in practice distributions get certified JRE's from their various
JVM providers for free. So the distributions don't actually have to
certify the JRE's --- that's in practice usually done for them. Now
it is true that the official Sun Java certification is for a specific
Distribution release, and at least in theory, the Java certification
has to renewed for every single new errata kernel and service pack
release --- but very often, people don't bother --- and it's not the
end of the world when they don't.
So if we are willing to cheat a little, where we say something along
the lines of "as long as the JVM has been certified on some LSB
certified distribution, and it passes a basic "smoke test", that
that's our requirement, it doesn't necessarily require the
distributions have access to the Java TCK.
This is not that different from distribution vendors who claim CAPP
EAL 4 certification --- but the EAL 4 certification only applies to a
specific hardware, software, and system configuration. Change the
hardware or install a security errata RPM, and that invalidates the
certification unless you throw another $10k or so at the certification
lab. Or suppose IBM has end-of-lifed the LS-20 and replaced it with
the LS-21 blade. That invalidates the certification, too.
But that doesn't change the fact that the distribution has the
features and gone through the development discpline, and so the fact
that RHEL5 went through the LSPP EAL 4 certification process has
value, even if that certification was in theory invalidated by RHEL5
SP1, or because you are using an LS-21 blade while the certification
was for the LS-20 blade. So if I were working for a large financial
institution who was about to issue a RFQ for a Linux distribution, it
might perfect sense to require that the distribution had received an
EAL certification, even though that certification might not be valid
any more due to the original hardware no longer being available, and
the hardware vendor hasn't seen the business justification to send
more money to the certification vendor for every single new hardware
model and for every single new errata RPM issued by the vendor.
The same goes with the Java certification. In practice many customers
run with an uncertified configuration because they've installed some
security update, and so it's not clear to me that we should try to do
any better if we were to try to require the use of "some certified
JVM" for the LSB, even if it was't certified in that precise
configuration in question.
More information about the lsb-discuss