Forking (was Ubuntu Under Attack)

[Eric Dunbar]

This is a great thread in the questions is raises, BUT IT REALLY
BELONGS ON SOUNDER. This has nothing to do with trouble-shooting or
discussing operational problems. It's philosophy!

Anywho, the angry keyboarder has some interesting points. I thought
I'd do some blatant plagiarism from the SABDFL (insert GNU Copyleft
licence here probably ;-).

Some interesting tit-for-tat from an old rocker and an angry
keyboarder that summarise the twists-and-turns of this thread
<groan>...

On 12/21/05, Scott <angrykeyboarder at angrykeyboarder.com> wrote:
> Old Rocker wrote:
> > Since I started this thread, a number of people have contacted me off
> > list and basically asked:
> >
> > "Does it matter if Ubuntu/Kubuntu is a fork of Debian?" or "What do you
> > mean by a fork anyway?"

> > As most people have probably realised, it matters to me and I hope it
> > matters to the whole of our community.  The best explanation I have
> > been able to find is in the book "Rebel Code: Linux and the Open Source
> > Revolution" by Glyn Moody.  Although published first in 2001, the book
> > still stands up today.  Here is the quote:
> >
> > "Large-scale forking is generally regarded as a kind of fratricidal
> > civil war, the worst thing that can happen to a hacker community and to
> > be avoided at all costs....

>  > However, Ubuntu/Kubuntu has its own
> > repositories and code base, which are close to Debian, but not
> > interchangeable with it.    Simply, you can't guarantee that Debian code
> > will run with Ubuntu, its has to be code recompiled for Ubuntu.
>
> Ubuntu is hardly the only Debian-based distro that has this "problem".
> The same applies to RPM based distros as well.

From <https://wiki.ubuntu.com/MarkShuttleworth>, written by the SABDFL himself:

What about binary compatibility between distributions?

A lot has been said about the fact that Debian is not
binary-compatible with Ubuntu. Sometimes this manifests itself as "I
can't install Ubuntu packages on Debian", sometimes its more "Why does
Ubuntu use GCC 4 when Debian is using GCC 3.3?". Or "Why is the kernel
and glibc on Ubuntu 5.04 different from that in Debian Sarge?". I'll
try to address all of those here.

I'll start with our general policy and approach, and then examine some
of those examples in detail.

First, "binary compatibility" means different things to different
people. If you've followed the trials and tribulations of the LSB
standards process, you'll understand how difficult it is even to
*define* binary compatibility in a meaningful way across multiple
distributions. That, in essence, is why we don't set "binary
compatibility" as a goal for Ubuntu. Sometimes it happens, but if so,
it's because there was an opportunity to make something work nicely -
not because it's a hard goal. We take opportunities for binary
compatibility across distributions where we can find them, but we
don't constrain ourselves by making that an absolute requirement.

Just to be clear, I'll say it again, for the record. We don't aim for
"binary compatibility" with any other distribution. Why?

In short, because we believe in Free Software as a collaborative
process focused on SOURCE CODE, and consider it superior to the
proprietary process which is focused on specific applications and
binary bits. We choose to devote the large majority of our energy to
the improvement of the source code that is widely and freely
available, rather than trying to work on binary bits that cannot be
shared as widely. When we spend hours of time on a feature, we want
that work to be usable by as many other distributions as possible, so
we publish the source code in "real time" as we publish new versions
of the packages. We go to great lengths to make those patches widely
available, in an easy to find format, so that they will be useful to
upstreams, and other distributions. That benefits Debian, but it also
benefits Suse and Redhat, if any of them are willing to take the time
to study and apply the patches.

We synchronise our development with upstream, and with Debian, and
with other distributions such as Suse and Gentoo and Mandrake and Red
Hat, on a regular basis. We draw code from the latest upstream
projects (which might not even be in Debian, or in Red Hat, or
addressed in the LSB). We try to merge with Debian Unstable (a.k.a.
Sid) every six months. We have no control over the release processes
of other distributions, nor of upstream, so it would be impossible for
us to define in advance an API or ABI for each release. We are in the
hands of hundreds of other developers every time we freeze Ubuntu in
preparation for a new version. Even though the Ubuntu community is
substantial and growing rapidly, it is still tiny compared to the
total number of developers working on all the free software
applications that make up the distribution itself. Our job is to
package what is there, efficiently and cohesively, not to try to
massage it to some pre-defined state of compatibility. We focus on
delivering the newest-but-stabilised-and-polished versions of the best
open source applications for your server or desktop. If we were to set
binary compatibility (at any level) as a top priority, it would
massively diminish our ability to deliver either newer software, or
better integration and polish. And we think our users care most about
the fact that they are getting the best, and most integrated, apps on
the CD.

It is worth noting that the Linux kernel itself takes the same
approach, shunning "binary compatibility" in favour of a "custom
monolithic kernel". Each release of the kernel requires that it be
compiled separately from previous releases. Modules (drivers) need to
be recompiled with the new release, they cannot just be used in their
binary form. Linus has specifically stated that the monolithic kernel
- based on source code, not trying to maintain a binary interface for
drivers across releases - is better for the kernel. We believe the
same is true for the distribution.

So the imperative to work with very current code overrides the idea of
maintaining compatibility with a specific ABI, especially if we have
little or no say in the ABI we should be trying to remain compatible
with.

But, I heard that Ubuntu is LESS compatible than other similar projects?

If you've heard this specific allegation, it's absolutely not true.

If you touch or change the kernel, or x server or clients, or libc, or
compiler, you have effectively made yourself incompatible. And as far
as I am aware every significant distribution has, with good reason,
invested work in those components to ensure that they meet the needs
of their users. In the process, they make themselves "binary
incompatible". What makes open source work despite this, of course, is
the fact that source code and patches usually travel across distros,
which is why we focus our attention there, not on the binary bits.

Some people might say "but I installed a Linspire package on Ubuntu,
and it worked, so they must be compatible". And yes, in many cases a
binary package from Linspire or Debian will Just Work (TM) on Ubuntu.
But this is "accidental compatibility", not "certified binary
compatibility". Your Mileage May Vary (YMMV) is not the sort of
certainty most people would accept, and can hardly be called
"certified compatibility". Many packages have very simple
dependencies, and don't really require specific versions of system
libraries, and they may well Just Work. But if you look below the
hood, at some level or other, you will find binary incompatibility in
every significant derivative distribution, from Knoppix through
Linspire and the DCC, with Ubuntu being no different.

> > A fork duplicates effort (why should two set of people be developing
> > essentially the same software?) and holds back development (we should
> > be working together, not apart).
>
> If Ubuntu "worked with" Debian as you desire, I might have to wait three
> years for the next stable release. No thanks. That's exactly why I chose
> Ubuntu. I has all the advantages of Debian, without most of the
> Disadvantages.   Why should Ubuntu modify it's operation at this point?
> They would be messing up a perfectly good thing.  That makes no sense.
>
> BTW, isn't Fedora, SUSE, Mandriva, Slackware, Gentoo, YOPER, Arch,
> Vector, YellowDog, RedHat and countless others also duplicating efforts?
> They all produce Linux distributions with much of the same software as
> Debian too.

> Why people wish to make this into a big deal, that really isn't is
> beyond me.

> > Far better if Ubuntu could use the software developed in the various
> > Debian repositories than going off on its own.
>
> Take a look at the changelogs on any Ubuntu package. You'll find most of
> the notes in there are from people with email addresses ending in
> "@debian.org".   It seems to me Ubuntu uses most of Debian's software.
> They just improve upon it.

> If Debian can't cope with Ubuntu, it's nobody's fault but their own.

> BTW, this discussion really belongs on sounder and not ubuntu-users
> Scott

<chorus of angels> Amen!

> www.angrykeyboarder.com
> (c) 2005 angrykeyboarder™ & Elmer Fudd. All Wights Wesewved

Eric.