The most high and most honorable Ian Murdock wrote:
> Hi everyone,
Hi Back at you.
> 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.
ISVs and IHVs want Binary, mainly that is because Microsoft and Apple
have been dealing binary for decades. Binary is not what Debian is all
about. For myself I will strongly oppose any shared binaries. I don;t
want any RPM shoved down my throat. I would like to use see a shared
usage of the same Source Core, built on the apropos systems for those
supported archs. Debian Might be okay with that. But to demand Binary?
Pfeh!
> 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.
Let us change this somewhat and see what you may think.
The end goal of the LCC is actually very simple: to create a
single set of source-packages that constitute an implementation
of the LSB standard(with or without RPM) and strict policies; to
use that single set of source-packages as a "common core" for as
many Linux distributions as possible, again with a strict set of
policies; to produce a implementation test kit to verify these
"common cores"; and to develop the common core in an open and
collaborative fashion, so the end result is owned by the
community, not by any 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.
PUT THE BRAKES ON. Single set of Binaries, right there I'll be 110%
opposed to this. As I am sure many in the Gentoo crowd and perhaps even
some others (Linux From Scratch is another) will be against this.
Repeat after me:
Binary is not the way. Binary is not the way.
> The LCC doesn't mandate the use of RPM (only to the extent the
> LSB does, which Debian can already address).
Which is exactly why Debian is not REALLY considered an LSB Distro. RPM
and the "big players" policies are so inadequate thereby removing RPM as
a viable alternative to package management for the LCC. My gosh tar.gz
or tar.bz2 binaryballs would be immensely better than RPM in that
regard. But let me keep saying Binary is not the way. Source for the
core-packages, with an ABI/API/OTHER Test Kit to test compliance, should
be what happens.
> 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.
ISV/IHV don't quite understand what it really means to use these
standards, they THINK they want these standards... but in reality they
want thing mandated into the systems. That in and of itself hampers what
really Debian, for that matter Linux is all about. It stifles
revolutionary disruptive evolution. Debian is all about Stifling on
Stable, but not elsewhere. Where you are leading Microsoft has already
gone down that path. Look at how much of a NIGHTMARE it is to deal with
different versions of the same Libraries with the same interfaces... but
reacting differently and breaking many things.
> 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.
Okay, he we are as Debian, with strict policies about packaging. If we
could get the RPM based Distros to "get that" we could get along much
much better as well. Smaller more numerous packages (Like for Samba:
samba-common, smbclient, smbfs, swat, winbind, samba, samba-doc,
libsmbclient, libsmbclient-dev... etc), not just samba and samba-devel.
Many reasons people come to Debian... Distributed Binaries is not one of
them.
> 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.
Of course, we know where the money folks will want to go. Not that I am
unhappy with the attempt to feign interest in getting everybody to
play... If we are so sure we want interoperability, why not Invite the
BSDs as well. I know I'd like to see that. Some of the BSDs already
provide much of the compatibility right now.
> 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..
If the RPM based distros did the smaller packages from source... this
would almost be a moot point. As the deps and names would nearly fall
into place like a lockset.
> 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...
I'd be glad to help on any front to get more applications from
Commercial Entities for Linux and BSD, even down to the negotiations
about how this. I for one use Linux 99.95% of the time. I'd like to see
that at 100%. If this LCC would be something that even RedHat and Novell
would Follow as well as the packaging and policy (even for just the Core
pieces) and as long as source for these and a test kit is made available
and improved by a technical committee/task-force, I'd like to see more
of this.
> 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.
Debian has Policy and packaging constraints, if more Linux Distros at
least experienced those and really, how easy it is to just do it... I
think Debian could help tremendously.
> 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.
Those Certifications would be given to the CORE, right? If a given
Distro proves, through the Testing Kit, that it complies, Certification
is inherited?
It isn't because of effort expended, Debian would bowl over nearly any
other distro there. The reason the industry doesn't know how to engage
us, We are not a For-Profit Organization. Therefore no-one person to be
beholden to. Never should be ever.
> 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.
Debian is by far the best (IMNSHO) Engineered Distribution by far. That
is because of the DFSG, DSC, the Debian Archive and its mirrors, many
many many Developers, the set of check and balances, Buildd-s,
security.debian.org, alioth.qa.debian.org, lists.debian.org,
bugs.debian.org, APT... these are just the ones I can think of off hand.
If those other Distros took a serious look, they would shudder in fear.
Contact me privately, if you feel the need to. But please do not confuse
me with someone that is against Commercial software, especially with the
signature block I am using.
--
greg@gregfolkert.net
REMEMBER ED CURRY! http://www.iwethey.org/ed_curry
Novell's Directory Services is a competitive product to Microsoft's
Active Directory in much the same way that the Saturn V is a competitive
product to those dinky little model rockets that kids light off down at
the playfield. -- Thane Walkup
Attachment:
signature.asc
Description: This is a digitally signed message part