Hi everyone, Let me first say unequivocally that the LCC is very interested in getting Debian involved. The question has always been: How do we do that? It's one thing for a bunch of companies that can push down decisions from the top and that already have a great deal in common (Red Hat lineage, RPM-based package management, etc.) to join forces to address a common problem; it's quite another for a decentralized community project that evolved very differently over the years. Still, I contend Debian shares those common problems (most notably, lack of support from ISVs and IHVs), and furthermore, that the "common cause" is much more achievable with Debian's support than without it.
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. If you're having trouble picturing how Debian might engage the LCC, here's my ideal scenario: the source packages at the core of Debian are maintained in collaboration with the other LCC members, and the resulting binaries built from those source packages are made available in both RPM and .deb format. Care would have to be taken to ensure that the resulting RPM- and Debian-based versions of the common core are compatible. The two main problems I anticipate here are package namespace and file system differences--the RPM-based distros might call the package that contains /lib/libacl.so.1.1.0 "acl", whereas the Debian-based distros might call it "libacl1", both for reasons of historical compatibility; and differences in such things as network configuration (Debian's /etc/network vs. RH's /etc/sysconfig/network) would need to be addressed as well. Furthermore, both sets of binary packages would need to understand what the other expects for compatibility between the two sets--e.g., the Debian packages would need to understand that "acl" == "libacl1", and the RPM packages would need to be able to deal with programs that want to configure the network via /etc/network/interfaces. I see many of these issues as being addressed in a "compatibility layer" of sorts. Note that this last set of issues is not unique to the RPM vs. Debian question--it also exists within the RPM world as well. The RPM distros have evolved in different directions as well, albeit for a shorter period of time--Conectiva does things differently than Mandrakesoft, and Mandrakesoft does things differently than Turbolinux, etc. etc.. Of course, my ideal scenario is a huge step, and it can't be taken all at once. As Bruce points out, though, it doesn't *have* to be taken all at once. The LCC is in the early stages, and many of the decisions that will affect the ultimate ability to reach the ideal scenario are being made now; furthermore, the vast majority (if not all) of these decisions will happen at the "compatibility layer" level. Finally, because the LCC is a collaborative effort, the groups involved will ultimately determine the direction of the effort as a whole. With more Debian voices at the table, who knows what that direction might be... 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. I can imagine many of you are thinking, "What difference does it make if Debian has the support of proprietary software vendors?" Ok. If attracting ISV and IHV support to Debian isn't a worthwhile goal in itself, how about helping ensure that Linux remains open and free in the face of increased commercialization (this was, after all, Debian's founding goal)? I've long argued that, as the Linux world's leading non-commercial, community-driven free software distributor, Debian can and should lead the way against the elements of our community that seek to own Linux all to themselves. -- Ian Murdock 317-578-8882 (office) http://www.progeny.com/ http://ianmurdock.com/ "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
