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: http://www.mandrakesoft.com/lcc Of course, there's not much there. Oh, here's some more: http://componentizedlinux.org/lsb 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 control problems. > 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. -- Daniel Jacobowitz