Re: Linux Core Consortium
On Thu, Dec 09, 2004 at 12:40:29PM -0500, Ian Murdock wrote:
> I've been thinking about the "obstacles" for a long time, and I'm
> convinced they're not as large as they might appear at first glance.
> The end goal of the LCC is actually very simple: to create a single
> set of binaries that constitute an implementation of the LSB
> standard; to use that single set of binaries as a "common core"
> for as many Linux distributions as possible; and to develop the
> common core in an open and collaborative fashion, so the end result
> is owned by the community, not by one or two commercial players.
> There's only one preconceived notion: that we need a single set of
> binaries, because that's what ISVs and IHVs require for the result to be
> viable. The LCC doesn't mandate the use of RPM (only to the extent the
> LSB does, which Debian can already address). The LCC doesn't mandate
> what "compatibility" means as regards package naming or library
> versioning or anything else--it only says we need to agree on
> *something*, because agreeing on something buys us a lot, whereas
> continuing to differ on such minor things doesn't serve any purpose
> other than to divide us and set the stage for one or two companies
> to run away with commercial Linux via ISV/IHV certification lock-in.
Disclaimer: I have not gone looking for any information about the Linux
Core Consortium outside of this thread. It would have been nice to
include a link:
Of course, there's not much there. Oh, here's some more:
As one of the maintainers involved in Debian's toolchain, I think this
is a terrible idea. Our needs are different than other distributions,
we already know that from experience. The core needs are conceptually
the same - everyone needs working libraries and tools - but the details
we consider worth fixing are not.
Common binaries are only useful with fixed releases and versioning of
the common binaries, because otherwise you have a dozen different sets
of your "common" binaries running around. So during the sarge release
cycle, when we need to make updates to fix an RC bug in glibc that
doesn't affect any platform shipped by any other member of the LCC,
which has moved on to new development according to some other member's
release schedule, what would we do? We'd have to rebuild them anyway.
There goes our "common binaries" advantage.
>From the web site, I see that LCC has a limited set of architectures
targeted anyway. Debian will continue to use common source for all
architectures. That will make working with the LCC difficult.
Using binaries from LCC would also run against the Debian principle of
always building Debian packages from their source before uploading
them. That's a big deal.
I'm sure other members of the LCC have similar concerns - or will.
What are they doing about them?
Are the other companies listed as "supporting" the Linux Core
Consortium interested in this "common binaries" plan? Their support
quotes only explicitly support the Linux Standard Base.
I see primarily scheduling, maintenance, coordination, and change
> Technical details aside, it all comes down to the question: Is getting
> involved worthwhile? As I said at the outset, the LCC has a lot to
> offer Debian, and likewise, Debian has a lot to offer the LCC as well.
> How does Debian benefit from LCC? It's a route to the ISV and IHV
> certifications that Debian has always lacked, and it is the lack of
> these certifications that's preventing Debian from standing alongside
> Red Hat and Novell/SuSE in the commercial space despite comparable
> (and arguably greater) popularly. The industry simply doesn't know how
> to engage us, and LCC provides them with a vehicle for doing that.
We would never have a common kernel with these vendors anyway - they
don't even have a common kernel with each other. My experience tells
me that would be a big barrier to certification of any kind.
There's plenty more than certification keeping Debian from standing
along side enterprise distributions in the commercial space.
If there is merit to the common binaries, I think we would get more
mileage from it by supporting them as we do the LSB: with separate
packages on top of the Debian base system.