[lsb-discuss] LSB conf call notes for 2008-07-30
tytso at mit.edu
Tue Aug 12 09:43:48 PDT 2008
On Tue, Aug 12, 2008 at 08:59:59AM +0100, Alan Cox wrote:
> > issues you have and the issues that Mr. Herrold have are quite
> > different, as near as I can tell.
> 'divide and conquer'
"An engineer takes a large, intractable problem, and by dividing it up
into small problems and solving each small problem, solves the larger
A bureaucrat takes a bunch of small, tractable problems, and entagles
them altogether into one, large, hairy mess, thus stopping all
So yes, I am trying to separate out the arguments so they can be
addressed rationally, one by one. I much prefer to be an engineer
rather than bureaucrat.
> The examples you give are bogus. Firstly the LSB trademark determines if
> you can call your system "LSB compliant" not if you can make it so.
And the Java trademark determins whether you can call something
"Java(tm)". It's exactly the same thing.
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
> There are distinct marketing advantages in two marks and in co-branding
> products and your claims don't appear to match what I've heard from
> marketing people.
The reason why we are doing this has nothing to do with marketing.
The primary problem is that there are very large number of applications
that are not just C/C++ applications, but which also involve the use
of Java. We would like for these applications to be able to say that
they are LSB compliant. (LSB compliance is not just a matter for
distributions, but also applications).
For similar reasons, in LSB 3.2, we added Perl and Python to the LSB.
Adding Java is no different.
The reason why we are exploring the use of the Java TCK is because (a)
we don't want to re-invent the very large set of tests that Sun has
already written, and (b) all or most of the distributions that have
LSB certified in the past are already shipping a certified Java VM.
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
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.
More information about the lsb-discuss