Re: This was posted on Digg.com -- Linux Distribution blog/article

[Jeff Licquia <jeff@licquia.org>]

On Thu, 2005-12-08 at 20:11 -0800, Bryan J. Smith wrote:
> FYI, here's a very long blog entry of mine on software
> development and distribution, including some historical
> perspectives on UNIX, Windows and Red Hat.  I invite people
> who only see differences in Linux distributions to read and
> may see the real similarities ...
> 
> http://thebs413.blogspot.com/2005/07/linux-distributions-packages-v-ports.html
> 
> I was cleaning it up for a publication, but I've been working
> 80 hours/week the last few months that I haven't had the
> chance.

Interesting article.  I take it you like ports? :-)

The impression I got from your article is that package-based distros
only have an advantage because of integration testing, and even there
only when it actually happens.  Allow me to provide a few extra points:

 - Predictability/uniformity.  Because everything is built from source,
no two systems of a ports-based distro are quite alike.  Often, problems
are caused not by what you link with at run-time, but by what you build
with at build-time; these problems will be different for every
individual system, since everyone will have built their components at
different snapshots of the source tree.  The *BSDs (at least) mitigate
this somewhat by doing regular stable releases, which should provide
uniformity with newly-installed systems, but even there things start
diverging with the first stable upgrade.

 - Binary ABIs.  The blessing of only enabling the features you want can
also be a curse if you ever install software not provided by the core OS
that need features you didn't include.  Sure, you can rebuild those core
components with the new features, but that adds to the difficulty of
getting something installed.

 - Backward compatibility.  Similarly, whenever you build binaries for
distribution, you run the risk of locking out potential users who might
be using slightly older components than you.  This is still a problem
with package-based distros (see the debate between DCC/Progeny and
Ubuntu for many examples), but at least you have tight control over what
you want to support, as well as an easy way to preserve compatibility
when you need it.

 - Standardization.  Gentoo can never certify to LSB, POSIX, etc.
because every Gentoo system is different.  Certifications are an
important source of confidence in engineering that things will work
together and work the same way every time, and people responsible for
critical systems are going to want those kinds of assurances.

Further, I think you overstate the advantages of ports.  A lot of them
are contentious; for example, the relative merits of sparing features in
a world of 200GB disks and 1GB DIMMs, and the relative merits of
processor optimization on systems that are nearly always I/O-bound.  But
this comes to mind as the most interesting:

> Organizations who believe they can do a better, more relevant and
> custom drop of assembling, building and supporting Linux will see
> little value in an "enterprise" Linux.

This quote is demonstrably untrue.  Consider Sun JDS.  Sun certainly
knows how to put together an enterprise-grade Unix; why then did they
base JDS on SuSE?  I expect that's because their enterprise-grade-Unix
engineers have better things to do.  And if Sun thinks using an existing
enterprise Linux is a better use of their time than assembling one of
their own, you can bet that 99.9% of the rest of the world will think
the same thing.

(In fact, that's the key of Progeny's business model.  Most people using
custom Linux have better things to do than maintain an enterprise-grade
OS for their things to run on, so why not let us do it instead?)

But even more important, having everyone build their own means that no
one can work together.  Enterprises don't buy RHEL to run Oracle on
because it minimizes their own integration testing; they buy RHEL to run
Oracle on because Oracle won't help them with problems they have if they
don't.  (Or SLES, but you get the point.)  And this is entirely
reasonable.  Why should Oracle support need to be experts in the
combinatorial explosion of Linux components?

It's always going to be true that, when two entities cooperate, they
need a shared base to work from.  Package distros can provide that.
Ports distros generally can't, not unless the shared base is defined too
loosely for most people's comfort.

That's not to say that ports-based distros are a waste of time, of
course.  But let's not pretend that the world of ports is rosy and
uncomplicated by the stresses of packages.


-
To unsubscribe, send email to majordomo@luci.org with
"unsubscribe luci-discuss" in the body.