|| ||Ian Murdock <imurdock-AT-progeny.com>|
|| ||Re: Linux Core Consortium|
|| ||Thu, 09 Dec 2004 12:40:29 -0500|
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.
"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
to post comments)