Re: Componentized linux?
[ Sorry for the long delay in weighing in on this. ]
On Mon, 2004-03-01 at 07:10, Colin Watson wrote:
> On Mon, Mar 01, 2004 at 12:28:17PM +0100, Ondřej Surý wrote:
> > I think this goes farther then CDD, that proposal is about making base
> > distribution smaller and making releases in each areas dependant only on
> > "base" debian (lsb-1.3 in progeny). For example if I have desktop with
> > XF86 4.3 and gnome, then I don't care how much RC bugs has apache or
> > postfix. And when upstream makes new stable release of gnome 2.6 I
> > don't have to wait for release of debian as whole, but only for new
> > release of component 'gnome'.
>
> But, actually, you do sometimes. To take one of your examples, both
> Apache and GNOME have Perl interfaces, and when the version of Perl in
> the base distribution changes (e.g. from 5.6 to 5.8) then all modules
> need to be rebuilt and both Apache and GNOME need to be updated in sync
> for everything to continue working. That's far from the only example of
> this sort of thing: Debian is rife with it.
Both of you have good points. Componentized Linux does go beyond
custom distros, although from Progeny's point of view, CL enables us to
build custom distros more efficiently, and that's why it's interesting
(we are after all in the business of building them). (It enables others
to build their custom distros more efficiently too, which is why
we're starting to see the beginnings of a community forming around it.)
In order to build custom distros more efficiently, we have to break
apart the monolithic distros into independent pieces. Our customers
want to be able to mix and match components to their requirements,
and their requirements almost invariably differ from each other.
Some want core bits from woody, with edge bits from sarge, and
perhaps even a few bits from sid. Others want some very
small subset of sarge with a customized kernel and a few of their own
packages thrown in for good measure. And so on (and on).
Previously, we had done this by hand, but that's simply not scalable.
Yes, Debian is modular in the sense that it's compromised of packages
that are theoretically independent from one another, but it's monolithic
from the feature/technology perspective, i.e., you pick a distro (sarge,
sid, etc.), and that implies certain features and technologies and
certain versions of them too. Yes, you can mix and match packages from
different distros, but you often do so at your own peril, e.g.
http://lists.debian.org/debian-devel/2003/debian-devel-200301/msg01644.html.
Colin is right in that although Componentized Linux does help alleviate
one set of problems, it potentially creates an entirely new set of
problems. One problem, as Colin points out, is that dependencies are not
necessarily one-dimensional. If I install the C compiler, then I
want all the development packages for all the components I have
installed, and if I remove the C compiler, I want them all to be
removed; likewise, if I upgrade the Python component, then
I want Apache, Gnome, and the two dozen other components with Python
interfaces to be upgraded to match the new version. And there's the
potentially combinatorial explosion in QA and testing this implies..
Indeed, we are talking through those problems now (see
http://lists.progeny.com/listinfo/cl-workers if you are interested
in following the discussion or participating). If they can be solved,
would the effort pay off in spades? Undoubtedly. Could the same
work help scale the Debian release management process? Undoubtedly...
As the grand old man, I ought to resist the temptation to wax
historical, but like most grand old men, I cannot resist. ;-)
Debian was the first modular distro by necessity: it was the only way we
could think of to subdivide the work of creating an entire distro
amongst many different folks. At the time, most people said it
wouldn't work because the problems seemed intractable, but we applied
the notion of packages to those problems, came up with the idea of
using explicit dependency relationships and a set of
policies and guidelines to make sure everything worked together, and
I daresay the result has been nothing short of spectacular (can
you think of a single contemporary distro that isn't built this way)?
Componentized Linux is really just an application of the same basic
ideas to solve a new set of problems. How do you reduce the complexity
of managing a distro from thousands or tens of thousands of modules to
a few hundred modules? How do you further decouple those few hundred
modules so they can be more flexibly assembled in a greater number of
ways? How do you solve problems at the lowest layers of the module stack
so they don't have to be solved over and over again by different
parties? Given my experience with Debian, I'm confident the seemingly
intractable problems can be solved. And I'm equally confident that
when we solve them, the result will change the way distros are built.
--
Ian Murdock
317-578-8882 (office)
http://www.progeny.com/
http://ianmurdock.com/
"Don't look back--something might be gaining on you." --Satchel Paige
Reply to: