[lsb-discuss] LSB conf call notes for 2008-07-30

Alan Cox alan at lxorguk.ukuu.org.uk
Tue Aug 12 09:51:49 PDT 2008

>    "An engineer takes a large, intractable problem, and by dividing it up
>    into small problems and solving each small problem, solves the larger
>    problem.
>    A bureaucrat takes a bunch of small, tractable problems, and entagles
>    them altogether into one, large, hairy mess, thus stopping all
>    progress."

(As an aside you are rather out of date with scientific theory - pure
deconstructionalism went out long ago. System modelling and emergent
properties rather did for it. I defy you for example to deconstruct the
problem of "where is 95% of the mass of a proton" or "why was google a
success" and get a sane answer.)

> We've already had one person claim that this probably doesn't extend
> to the pathname /usr/bin/java, with one Sun employee being involved
> with Kaffe.

That needs Sun to sort out and its really a side issue to the main points

> Yes, one possibility is that we specify something that adheres to the
> Sun JVM standards, without using the TCK and without requring a
> certified JVM.  But then we would need to provide our own tests, which
> is a very large, expensive, problem which would require re-inventing
> the wheel.
> In the worst case where the TCK becomes unavailable, say because Sun
> goes out of business or gets purchased by Microsoft, we could at that
> point replace the TCK with some other set of tests.  And we could do
> that without harming the LSB specification per se.  The better
> solution would be to work with Sun to make sure the TCK won't
> disappear even in the Worst Case solution.

If you assume that this path is the right one, which is the bit I

Clearly it would be a huge job for the LSB as a project to re-implement
the entire TCK. It would also be a big loss for the LSB to end up with a
non free certification suite. I don't think either of these are good
answers, so with an engineering hat on you prune those subtrees and see
what is left to search.

That is why I take the view that the Java and LSB don't belong
intertangled. A good engineer doesn't nail two conflicting objects
together and pray the result stands up if enough glue and armwaving is
used. Perl and python are somewhat different in that it doesn't create a
dependency on a non-free test suite.

I think the more useful discussion therefore is how to build a meaningful
LSB/Java co-branding for distributions and as you point out for
application vendors.

On the CentOS side you are I think missing a key point.

Right now I can run test suites against my distro and to a good extent
say whether LSB compliant apps will run on my distro. It's not certified
it might not be 100% in all cases but for a project like CentOS that is
important. For the LSB it is also a big deal as it means LSB apps run on
most "not formally LSB" distributions and makes the market rather more

The TCK changes that. I don't have a test set for Java where I can say
'seems to work ok' and not use the trademark.

Now it could be there is a model for Sun to permit the TCK to be used for
testing 'not-java' implementations but the current licensing model
doesn't really work there.


More information about the lsb-discuss mailing list