[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Linux Core Consortium



On Mon, Dec 13, 2004 at 05:07:12PM -0500, Ian Murdock wrote:
> On Sat, 2004-12-11 at 03:49 -0800, Steve Langasek wrote: 
> > On Thu, Dec 09, 2004 at 03:39:55PM -0500, Ian Murdock wrote:
> > > You've just described the way the LSB has done it for years, which thus
> > > far, hasn't worked--while there are numerous LSB-certified distros,
> > > there are exactly zero LSB-certified applications. The reason for this
> > > is that "substantially the same" isn't good enough--ISVs want *exactly
> > > the same*, and there's a good reason for that, as evidenced by the fact
> > > that while Debian is technically (very nearly) LSB compliant, there are
> > > still a lot of edge cases like file system and package namespace
> > > differences that fall outside the LSB that vastly complicate the
> > > "certify to an ABI, then support all distros that implement
> > > the ABI as defined by whether or not it passes a test kit" model.

> > Well, my first question is why, irrespective of how valuable the LSB itself
> > is to them, any ISV would choose to get their apps "LSB certified".  The
> > benefits of having one's distro LSB certified are clear, but what does an
> > LSB certification give an ISV that their own internal testing can't?

> In an ideal world, ISVs could certify once, to the LSB, and their
> applications would run the same on every LSB-certified distro. This
> dramatically reduces the amount of internal distro-specific work
> each has to do. The stronger the LSB, the closer the distro-specific
> work is to zero, and the closer they get to a single Linux port.

That wasn't my question.  My question was, why should any ISV care if
their product has been LSB-*certified*?  ISVs can test against, and
advertise support for, whatever they want to without getting the LSB's
imprimatur.  I cannot fathom why any ISV would go through the expense (money
or time) of getting some sort of LSB certification instead of simply making
this part of their in-house product QA; and therefore I don't see how the
absence of LSB-certified applications can be regarded as a failure of the
LSB process.

> > Secondly, is this merely conjecture about the needs of ISVs, or have you (or
> > someone else involved with the LCC) actually talked to people who've said
> > these things?  If this initiative is truly a response to the needs of ISVs,
> > it should be fairly easy to publically specify the LCC's scope up front so
> > that Debian can decide whether there's any sense in trying to get involved.

> We have absolutely been talking to ISVs about their needs--indeed, this
> has been a conversation that has been ongoing for years..

> What about the LCC's scope isn't clear?

Er, the fact that no actual scope has been stated?  What does "core" mean?
What packages (libraries) are included in this "core"?  If Debian is not
going to accept external binaries provided by the LCC into the archive, or
finds it necessary to patch the source during the course of a release, does
this mean Debian will not be a certified platform?  If so, and given that
these are very likely outcomes, what reason remains for Debian to get
involved in the LCC if it's not going to result in any ISVs supporting
Debian as a platform through the LCC effort?  (If you see ways that Progeny
would benefit from Debian's involvement in the LCC even if the official
Debian releases are not LCC-certified in the end, I think that's relevant
here; but I would like to know how you think it would benefit Progeny and
other companies building on Debian, and why you think that Debian itself
warrants representation at the table.)

I don't think any of the above questions are ones to be hashed out by the
distros participating in the LCC.  If the impetus for the LCC really comes
from ISVs, then the answers to these questions must be *their* answers; and
if we don't have those answers, inter-distro talks would be aimless and
futile.

-- 
Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature


Reply to: