LWN.net Logo

The Linux Core Consortium courts Debian

The Linux Core Consortium is an effort by Conectiva, Mandrakesoft, Progeny and Turbolinux to create a single, Linux Standard Base-compliant core distribution which each distributor can then use as a base for their products. The idea is to share some of the distribution engineering work and, simultaneously, to create a widely distributed, standard platform which independent software vendors can target for their products. See this LWN article for more information on the LCC.

Bruce Perens has recently proposed to the Debian project that it work with the LCC. There are, according to Bruce, a few reasons why Debian would want to do that:

The first is that we should be influencing this group to do things the Debian way, where that is important. The second is that the group plans to lower the overhead of hardware and application vendor certification for all of its participants, and we could really use that sort of support. The third is that the group would make certification by LSB and other standards bodies easier for all of the participants.

Ian Murdock, the founder of the Debian project, has his own reasons for encouraging Debian to join:

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.

Appealing to vendors of proprietary software has never been high on the Debian Project's list of priorities. Ian claims that vendor support is important, however, if Linux is to remain an open, free platform in the increasingly commercial context in which it operates.

Working with the LCC would, essentially, require Debian to help develop, and then distribute, a set of standard binaries used by all LCC-based distributions. All of these distributions would use the same (binary) kernel, the same libraries, and many of the same configuration mechanisms. The use of identical binaries goes beyond the requirements of the LSB, which only requires that the same binary interface (ABI) be available. Ian claims that the LSB approach has proved to be insufficient:

...while there are numerous LSB-certified distros, there are exactly zero LSB-certified applications. The reason for this is that "substantially the same" isn't good enough--ISVs want *exactly the same*, and there's a good reason for that, as evidenced by the fact that while Debian is technically (very nearly) LSB compliant, there are still a lot of edge cases like file system and package namespace differences that fall outside the LSB that vastly complicate the "certify to an ABI, then support all distros that implement the ABI as defined by whether or not it passes a test kit" model.

As one might imagine, there is some resistance within the Debian Project to distributing a set of binaries (including the kernel) provided by an outside organization. It will be a hard sell; from your editor's reading of the debate, the early signs are that the Debian developers aren't buying it. Debian users like to have a great deal of control over their systems, and the LCC looks like a way of giving up some of that control with no immediate benefits in sight.


(Log in to post comments)

There are benefits

Posted Dec 16, 2004 9:52 UTC (Thu) by NAR (subscriber, #1313) [Link]

the LCC looks like a way of giving up some of that control with no immediate benefits in sight.

I, for one, would welcome the ClearCase kernel module for Debian. Unfortunately the company policy forces me to use ClearCase and the lack of the kernel module makes the dynamic views unavailable for Debian clients (they are available for SuSE and RedHat clients).

Bye,NAR

ClearCase

Posted Dec 16, 2004 20:31 UTC (Thu) by jvotaw (subscriber, #3678) [Link]

I supported ClearCase at one point, and I'm actually glad that it is not available for Debian. My opinion:

1. Binary-only kernel modules are not fun to support

2. It's an over-designed, clunky tool; the NIS+ of source code control

3. They have an over-broad software patent for their filesystem, which makes me angry. (Although, since IBM bought Rational, perhaps there's hope that it will be more open source friendly.)

Personally I'd rather see a free alternative to ClearCase than see ClearCase work on Debian.

This is a long conversation and I don't want to start a flame war on it. Just my two cents,

-Joel

The Linux Core Consortium courts Debian

Posted Dec 16, 2004 11:00 UTC (Thu) by nix (subscriber, #2304) [Link]

Note also that the people who are complaining the most are the toolchain developers.

The kernel and glibc in particular are hellish to standardize; the kernel has massive numbers of architecture dependencies that only Debian encounters and also can't be installed in a chroot, and both have rather a lot of local patches installed by every distro.

The chances of centralizing this, well, you'd need a bunch of new free software projects whose only job was to merge things, and what if a patch is critical for one vendor but unacceptable for another?

Sorry, this idea won't fly. I don't think it'll fly for the original proposers, either. Oracle will just have to start removing gratituous nonportabilities and start testing its software on more than one distribution like everyone else.

The Linux Core Consortium courts Debian

Posted Dec 16, 2004 13:37 UTC (Thu) by Duncan (guest, #6647) [Link]

What a difference a year can make in one's viewpoint!

A year ago, I was just converting to Mandrake (cooker) for AMD64, from
Mandrake (cooker) for i586. A few months later, and I realized that they
weren't committed to leading edge at all with their AMD64 distrib, where
even cooker tended to be behind even i586 stable, so even the "beta"
cooker version was six months out of date! As it happened, Gentoo 2004.0
was just out, with support for AMD64, INCLUDING all the stuff (like the
latest KDE 3.3.1 at that point, while Mandrake was stuck on 3.2.x still,
not even having 3.3.0) Mandrake was stuck in yesteryear on.

So... I switched to Gentoo.

Now, I see the article's mention of sharing single binary packages even
for stuff like glibc and the kernel, and my gut reaction is one of horror
and repulsion, almost as bad as if it were closed source stuff! With
Gentoo, the binaries vary from installation to installation, due to
individual choice of what optional functionality should be included (USE
flags), and where one wants to run in the stable vs optimized space
(CFLAGS and the like). While I can see the logical trade-off for most
libraries and applications between standardized binaries (and locations)
against the individuality of Gentoo's usual
compile-your-own-to-your-own-requirements stance, for core system
components such as the kernel and glibc, to not only force blanding the
binary to a single distribution-wide level, but to /multiple/
distributions... is simply repulsive to me, now.

Of course, while I hadn't yet messed with glibc, and didn't yet know much
about optimizations, I was compiling my own custom kernels back on
Mandrake. In fact, I was doing that before I'd even chosen all the apps I
was going to use on Linux, as I switched from MSWormOS, only a couple
months after I'd initiated the switch. Further, even on MSWormOS, my
installation was so customized I had Linux and MSWormOS folks alike
wondering if it was even MSWormOS! Thus, I've always been a bit more of a
power user than most.

As far as Debian not ever having appealing to proprietaryware developers
and vendors high on the agenda, it's been interesting seeing the response
of Gentoo developers to the LSB as well. While the general policy is to
go with it where it makes sense, in no small part because doing so
simplifies the support tasks for any distribution, a large part of the LSB
really only makes sense for a binary distribution, and then, not one
likely to have multiple versions of some packages (such as KDE and gcc)
installed at the same time. Every once in awhile, someone comes up with
the "great" (not!) idea of making Gentoo conform to the LSB. They
generally shut up equally quickly when it's pointed out to them that for
Gentoo to do so, it'd have to give up the empowered user/admin qualities
that make it what it is, and, if LSB compatibility is what they /really/
want, perhaps looking to another more appropriate less local sysadmin
empowering binary distribution.

Gentoo has borrowed a lot of its general attitude and spirit from Debian,
and it's nice to see Debian isn't interested in compromise without
benefit, too. Perhaps if they /do/ decide to go lose their identity in
the LCC, many of those developers will switch to Gentoo. <g>

Duncan

The Linux Core Consortium courts Debian

Posted Dec 16, 2004 14:36 UTC (Thu) by syntaxis (subscriber, #18897) [Link]

"if LSB compatibility is what they /really/ want, perhaps looking to another more appropriate less local sysadmin empowering binary distribution.

Gentoo has borrowed a lot of its general attitude and spirit from Debian,
and it's nice to see Debian isn't interested in compromise without
benefit, too."

I think you're a little confused. LCC != LSB.

Nor is Debian's current stance towards the LSB anything like Gentoo's. As one can see in http://release.debian.org/sarge_rc_policy.txt, Debian packages must not conflict with the requirements of the LSB v1.3 and those that do so will have Release-Critical bugs filed against them.

The Linux Core Consortium courts Debian

Posted Dec 16, 2004 17:03 UTC (Thu) by ballombe (subscriber, #9523) [Link]

If you in a good mood, you should read http://greenfly.org/mes.html

The Linux Core Consortium courts Debian

Posted Dec 20, 2004 1:31 UTC (Mon) by dberkholz (subscriber, #23346) [Link]

What you say about the LSB is actually more similar to the Gentoo attitude on the FHS.

The Linux Core Consortium

Posted Dec 30, 2004 1:01 UTC (Thu) by turpie (guest, #5219) [Link]

Do you really need to refer to MSWindows as MSWormOS?
Because it sure is a pain in the ass to read.
It also makes you look a little immature, and your opinion less valuable.

Not necessarily the same binaries

Posted Dec 16, 2004 17:00 UTC (Thu) by proski (subscriber, #104) [Link]

I believe the story makes it seem that Debian would use the binaries compiled by someone else. That's not what's being suggested. Bruce writes:
What changes would be necessary for Debian? The group can really be viewed as a sort of upstream maintainer for a number of packages, so it fits pretty well in the context that we're used to in working with the sources of our software.
Ian writes:
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.
In other words, Debian will compile the sources. Treating LCC as the "upstream provider" means that Debian is free to add more patches. Having the same binary is considered an "ideal scenario", but Debian doesn't have to commit to it.

The Linux Core Consortium courts Debian

Posted Dec 16, 2004 18:11 UTC (Thu) by jabby (guest, #2648) [Link]

The first thing that popped into my mind when I read the title was "They'll want it to be renamed to the *GNU/Linux* Core Consortium."

No?

Debian Are Hard-Headed

Posted Dec 17, 2004 4:18 UTC (Fri) by miallen (guest, #10195) [Link]

I've only been using Debian for a couple of months but that's long enough to know that there's no way in hell Debian will join LCC. One time someone asked on debian-user why their /etc/profile wasn't being sourced (that's right, default debian will not source /etc/profile). The answer I gave was to make /etc/Xsession.d/99xfree86-common_start:

exec -l $SHELL -c "$STARTUP"

Man I got flamed from all sides. I knew I was right so I fought back. A few people were onboard but there were louder, more obnoxious, old-school users that claimed I just didn't "get-it". And that was that.

I like debian. Mundane package management is nice with apt. But I have to say the debian crowd can be really hard-headed.

Debian Are Hard-Headed

Posted Dec 18, 2004 16:02 UTC (Sat) by IkeTo (subscriber, #2122) [Link]

Hm... but your solution (or more exactly, your problem) didn't make sense even to me, a Debian user but not a Debian developer. X startup and console startup really need to be managed differently. Making X startup script source /etc/profile means that those things people put into /etc/profile that requires an interactive shell will break X startup. I don't think Debian developers maintaining such a core package as xfree86-common should make such a mistake as you do.

Debian Are Hard-Headed

Posted Dec 18, 2004 20:47 UTC (Sat) by miallen (guest, #10195) [Link]

Well, I'm not going to rehash this issue but on debian-user I systematically debunked every claim that the login shell technique was somehow broken.

And don't blaim me, I just copied it from Red Hat (and Mandrake and Fedora and ...).

Mike

Debian Are Hard-Headed

Posted Dec 19, 2004 13:41 UTC (Sun) by IkeTo (subscriber, #2122) [Link]

> I systematically debunked every claim that the login shell
> technique was somehow brokenI systematically debunked every claim
> that the login shell technique was somehow broken

Just read the thread, and frankly I didn't see that the thread is fat enough to cover what you mentioned. After all, debian-user is for helping users out, not for dealing with (unintelligent) user suggestions.

> And don't blaim me, I just copied it from Red Hat (and Mandrake
> and Fedora and ...).

Debian has nothing to do with doing things exactly the same way as Redhat and Fedora.

I'm not saying that I like the current setup of Debian initialization. I think at many points it sucks. But yours suggestion (and those of Redhat/Fedora) also sucks, that's the problem. It basically sees a few, most common use case of initialization, and forget about the rest. So users get burnt when they use the shell in other ways that the shell support but the distributer didn't notice.

Long long time ago I've written in debian-devel about initialization:

http://lists.debian.org/debian-devel/2002/07/msg01583.html

not much is done about it as far as I know, enough that I've written my own PAM module and more or less forget everything about /etc/profile (search for pam_userenv in Google).

Debian Are Hard-Headed

Posted Dec 20, 2004 12:11 UTC (Mon) by tzafrir (subscriber, #11501) [Link]

http://bugs.debian.org/250765

for the story

Debian Are Hard-Headed

Posted Dec 20, 2004 20:24 UTC (Mon) by miallen (guest, #10195) [Link]

Note, however that other shells support the -l option. Zsh is an example.

The way I think about this is that we can either make it so that /etc/profile is sourced out of the box for 99.9999% of users (because they're using bash, zsh or whatever shell that supports the -l option) or we can leave it broken for everybody to satisfy the 4 obnoxious fools using ksh who have apparently have no problem modifying their config anyway.

Yes, technically POSIX does not even acknowledge the existance of login shells. However I believe all shells interpret a '-' prefix to argv[0] to mean that the shell should be a login shell. Therefore, if someone really wanted to be pedantic about this they could include a very small program that would just call execl with the same arguments but with argv[0] prefixed with a '-' (e.g. "-tcsh" vs "tsch"). But that would be really anal even for Debian folk.

Copyright © 2004, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds