Re: Linux Core Consortium
On Tue, 2004-12-14 at 06:16 -0800, Steve Langasek wrote:
> 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:
> > > 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.
My point was this: *If* getting their products LSB-certified would allow
them to support those products on any LSB-certified distro
without the major investment necessary to deal with the edge cases the
LSB doesn't currently cover, they would do it. That isn't the case
now, which is why none of them are LSB-certifying their products today.
Certification should mean "it works". That's not the case as
regards LSB certification today, so the ISVs put the investment
into supporting each distro separately. If "certify to LSB,
run on any LSB-certified distro" was a reality, they could put that
investment into the LSB and end up with a longer list of supported
distros to boot--smaller cost, larger benefit, i.e., it's a win-win.
> > 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"?
"Core" means "implemention of LSB", and the packages/libraries that will
constitute that are being determined now, as a collaborative process. I
assumed Debian would want to be involved in this process too, rather
than being presented with a more well-defined scope as a fait accompli..
> 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?
At the very least, the differences would be smaller than they
otherwise would be, and that can only be a good thing for
LCC, Debian, and the Linux world as a whole. And, who
knows, with Debian participation, perhaps the differences would end
up being small enough and the processes, methods, and
mechanisms defined such that it's no longer a "very likely outcome".
> (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.)
As I said at the very outset, one possible way forward is to simply
produce a Debian-packaged version of the LCC core independently,
and to make sure that core is 100% compatible with Debian (i.e., you
can take any Debian package and install it on the LCC Debian core
and get the same results as if you'd installed it on Debian itself).
I'm truly hoping that's not the only way forward though, which is
why I'm trying to engage the Debian community to find another way.
One thing is clear: No matter how we end up approaching the ideal of
"common core that can form the basis of both RPM- and Debian-based
distros", it'll clearly be better for all involved that the
differences between Debian and LCC remain small. The smaller the
differences, the closer the LCC Debian core is to Debian itself,
which in turn benefits Debian because those folks are more
closely working with Debian rather than working on "LCC Debian".
> 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
The ISVs have spoken. They want to support as few ports as possible,
because those ports cost money. They also want to support as much
of the market as possible, and the current reality is that many of
those markets are out of reach today. Beyond that, they don't care. If
there's an open standard they can certify to and reach a broader
market, they'll be very happy with that. If commercial Linux
ends up being owned by Red Hat, they'll be fine with that too. I
for one am hoping it doesn't come to that. The current reality seems
like a pretty big opportunity to me to define a different future.
"All men dream: but not equally. Those who dream by night in
the dusty recesses of their minds wake in the day to find that it was
vanity: but the dreamers of the day are dangerous men, for they may
act their dreams with open eyes, to make it possible." -T.E. Lawrence