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

["Bryan J. Smith" <b.j.smith@ieee.org>]

On Fri, 2005-12-09 at 12:59 -0500, Jeff Licquia wrote:
> Interesting article.  I take it you like ports? :-)

That's funny, because if you didn't notice it, someone thought I was
being anti-Gentoo in the comments.

As I said in my response, people look at my views how _they_ want them
to.  I have been called anti-Gentoo/pro-Red Hat and pro-Gentoo/anti-Red
Hat.

> 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.

As an engineer, I consider regression and integration testing *HUGE*!
So if a ports distro, such as Gentoo, puts that on me, I need to be
prepared for it.

Furthermore, there is the argument whether or not well-tested community
distros, such as Debian, are "not as good" as the "Enterprise" release
that change even less.  I think Debian founder Murdock has the right
answer on that with his Progeny endeavors, testing and configuration
management is really a functionality built around your business.

The "key" here is if the vendor's testing and fixed configuration
interferes with your needs.  If you use everything Red Hat ships in
RHEL, plus only certain, certified applications -- then RHEL is a major
_value_!

If I maintain a web server with lots of added modules, and I regularly
run into dependency and configuration hell, then it doesn't.  But that
means the configuration management, testing and other details then fall
on to me.  A common _mistake_ I see people do when they deploy Gentoo is
just have each server fetch their own, and those changes are _not_
tracked.  You _still_ need to handle fixed configuration management to
ensure consistency, testing, security, etc...

> 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.

_Unless_you_ implement proper configuration management, including
integration testing, security, etc...  Again, "ports" change the
configuration management procedure, put more on you.  People who
_ignore_ it are doomed and "ports" are then _not_ a better solution.

Again, the "key" here is if the vendor's testing and fixed configuration
interferes with your needs.  In that case, it might be less work to do
your own configuration management then fight against the vendor's.  ;->

That's my _main_ point (probably better shown with a graphic).

> Often, problems are caused not by what you link with at run-time, but by
> what you build with at build-time;

Which is why the regression and integration testing falls upon _you_.
If someone stupidly ignores proper configuration management when they
deploy Gentoo, and have varying, differing configurations, they deserve
what they get.

> 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.

Yes, the BSDs at least do fixed releases, at least on core components.
Gentoo's portage takes its ports approach to an even less rigid
framework.  That means more is on you to ensure integrity, consistency,
etc...

>  - 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.

Yep, that's the big kicker on Debian too, one that Progeny hopes to
resolve with their forthcoming enterprise release that is compatible
with RPM binary-only software.  The problem with Progeny's service model
built around end-users knowing their needs and configuration management
is the reality that not all software is source.  If it was, I actually
prefer Progeny's approach to "enterprise" management over the "as a
product/subscription" model.

It's also one of the reasons why Red Hat stopped -- let alone the
vendors -- even bothering to certify applications for Red Hat Linux
which had a 6 month release cycle.  Most people still don't understand
that Red Hat Linux was a product trying to address 2 radically differing
mindsets.  People bitched about binary compatibility between revisions
while others bitched about lack of flexibility.

RHEL and FC are the natural complements to each other, and I for one saw
it coming well in advance.  But Red Hat pulled it off a lot better than
I thought they would.  People are still bitching about the trademark
('but I can't install big brand name X so my boss will let me?!"
attitude), which they don't want to stop and realize it was getting to
the point where not only was Cobalt and then Sun mis-using the Red Hat
name (and getting the blame for Cobalt/Sun created issues), but Sun's
legal paved the way for Microsoft to mis-use the Red Hat name!  Yikes!

Even when Red Hat tried to give trademark guidelines with exceptions so
replicators like Cheapbytes could still use the name, they were
demonized by Cheapbytes and others.  I let Cheapbytes know that I did
_not_ appreciate Red Hat's delicate balance and full legal permission to
allow the name use to be so demonized like that, and several people
agreed with me -- it was clearly a political move, not a legal one.

>  - 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.

Oh, very much so!  A ports distro implies you _will_ have all current
software inter-compatible!  Gentoo advocates talk about how they can use
"older approaches," but it's not that easy because of such.

>  - 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.

As someone who has worked extensively in defense and financial
environments, you don't have to tell me about the Common Criteria and
the evaluation/certification levels.  ;->

> 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.

Read that again -- only _not_ thinking I'm a Gentoo advocate (I'm not!
I deploy RHEL/FC _heavily_!  And Debian more than Gentoo! ;)
"organizations who _believe_ they can do ..." that means the
organization is taking that responsibility upon themselves.  If they
constantly find themselves "fighting" the limited flexibility of
"enterprise" distros, they might be better directed towards putting in
the regression and integration testing and configuration management to
"roll their own" just for their specific applications.

> 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?

It has to do more with their past mis-use of the Red Hat trademark.
They used Red Hat(R) Linux without a license, and one thing I understood
about the Sun-Red Hat negotiations is that Sun was furious with what Red
Hat demanded -- including compensation/retro-license for not only their
mis-use of their trademark, but Cobalt's as well.

In the case of Cobalt, I have to say, I really don't blame Red Hat.
There are still raving, former Red Hat users who blame all sorts of
things on Red Hat, and are completely oblivious to where the problem
was, with regards to Cobalts.

> 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.

But who is Sun's customer?
Who is Red Hat's customer?

Are they going after the large, enterprise systems support department
that has their own resources to do all the customizing, regression and
integration testing and configuration management on their own?

Or are they going after the customer who wants a fixed configuration,
willing to pay for those updates, and possible tap their services?

It's not about "quality" -- it's about "who pays for it with what?"  Do
I pay for it with my time and efforts instead of money?  I might
consider that if my customization is unlike most others.  Or do I pay
for the fixed configuration?  That's probably the right move if I'm
running largely what is already supported -- and has been tested -- for
thousands of others.

That's the "key"!  How much do you need to customize "off-the-path"?

> (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?)

Exactly!  You're disagreeing with a _misconception_ you made the moment
you thought I prefer "ports" distros.

I merely laid out what ports distros do better *THEN* brought up the
fact that you still can_not_ escape configuration management.  And in
that case, "ports" put the support on *YOU* -- not the vendor.

Anyone who ignores that is why projects _fail_!

> 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?

Nope.  You buy enterprise for fixed configurations, testing by many for
many -- certified against apps.

You use ports when you are highly customizing to the point where your
needs and testing differs from others.  Then all that testing falls on
you.  If you ignore it, you deserve what you get.

In between are the "rapidly changing" packages distros with sprawling
repositories that try to strike a delicate balance.

> 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.

Ports distros are ideal when you're needs a very, very different from
others.  Custom web servers tend to be this way, when a company has
their own combinations that are not easily integrated into a typical
enterprise distro, or even a "rapidly changing" packages distro for that
matter.

> 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.

And I made that point how???

Again, I think you're differing with what you _assumed_ I was, not what
I actually _said_ in that 7,000+ word blog.  ;->

Did you read the whole thing?



-- 
Bryan J. Smith   mailto:b.j.smith@ieee.org
http://thebs413.blogspot.com
------------------------------------------
Some things (or athletes) money can't buy.
For everything else there's "ManningCard."



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