[wplug] My distro beat up your distro (yet again, sigh) -- WAS: OS X on Linux?

[Bryan J. Smith]

[ NOTE:  This is long and responses to multiple posts attributed/quoted
out-of-sequence in several cases. ]

On Sun, 2007-07-22 at 08:55 -0700, n schembr wrote:
> It's been a few year since I tried suse or redhad  for a desktop
> systems.  Both Redhat and Suse have supported strong communities.  I'm
> not sure what there focus is.  Are they pushing for the Desktop space?

I will not attempt to answer for SuSE, who actually released the "first
enterprise distro" with SuSE Linux Enterprise Server (SLES) 7 before Red
Hat Advanced Server 2.1 (although that's debatable with Red Hat Linux
6.2"E"**).  SLES' mainstay has been on _proprietary_ IBM "Big
Iron" (which is where 90% of their $1B dollars went, with another 100%
of $100M going to proprietary Notes/collaboration software), where Red
Hat had been limited in sales in comparison (at least in the past).

After Red Hat's first "Service Level Agreement" (SLA)** attempt with Red
Hat Linux 6.2"E"**, Red Hat has had a 2-prong focus ...

1.  A "community developed" distro supported for 1 year, with periodic
package version updates and no hardware/software certification**.  A big
"kicker" to #1 is that it is 95% focused on being the "lead-in" to
#2 ... (and has since Red Hat Linux 7 -- 5 releases before Fedora Core
1, which was merely Red Hat Linux 10 renamed end-of-Beta).

2.  An "enterprise developed" distro supported for 5-7 years, with _no_
package version updates, _only_ backports for maximum ABI/API
compatibility, with hardware/software certification.
  RHL 6.2 "E" (retro-actively called "RHE 1") -- based on RHL 6.2
  RHEL AS 2.1 (latter released RHEL 2) -- based on RHL 7.2 (w/some 7.3)
  RHEL 3 -- based on RHL 9 (w/some RHL10/FC1)
  RHEL 4 -- based on FC3
  RHEL 5 -- based on FC6 (originally alpha/beta'd from FC5)

Yes, this leaves a lot of "open space," especially with #1 being 95%
focused on feeding #2 (and the reason why Red Hat finally admitted,
publicly, it won't "give up" Fedora control), but that's Red Hat's
model.

[ **NOTE:  Rob said it best at the last meeting, Red Hat wanted to be
the "new Sun" from a government standpoint -- and that explains SELinux
(and even the GCC 3/ANSI C++ compliance push before that) _big_time_.
When they realized they could charge a lot of money for smaller unit
distributions, that's when "Enterprise" was born.  Red Hat released RHL
6.2"E" with SLAs, but then SuSE did SLES 7, which Red Hat then countered
with a completely separate product in RHAS 2.1.  By mid RHEL 3, Red Hat
went from having far less market share to SLES 7/8 to 5x as much.  Red
Hat spent some time through RHL7.x, 8 and 9 (2000-2002) trying to figure
out what it was going to do with the "project/product."  At that time,
Red Hat was often supporting no less than 6-7 simultaneous releases,
which became a support nightmare.  But after some "trademark issues"
were forced by Sun (largely after their acquisition by Cobalt) -- of
which the "Trademark Guidelines" where poorly accepted -- Red Hat
decided to just address many aspects with a differently named project
(building upon some existing projects, like those of the University of
Hawaii and Duke University), hence Fedora(TM) -- which went through a
lot of commentary, but ended up as most people expected it to be after
the first 3 years (by 2005).  Today Red Hat still has no interest in
"selling" a product to consumers, and only "volume" sales of its (now
named as of RHEL 5) Client (including volume enterprise "Desktop"
licenses -- which existed as RHEL WS/Desktop prior) and [Advanced]
Server (which existed as AS/ES prior) products.  The one nice thing is
that Red Hat does 100% GPL (sans the trademark issues -- understand Red
Hat was the _only_ major commercial Linux vendor to _ever_ allow its
trademarks to be freely redistributed -- SuSE _never_ allowed such
before Novell's purchase) -- and they pay for a lot of GPL developer
salaries.  So that money gets funded back into a good number of core,
community developments.  But that also means Red Hat does get to
"inflict its will" on a lot of core projects too -- kernel, GCC, GLibC,
etc...  Catch-22. ]

With that all said, over the last 7 years (and 5 years before that and
before RHEL with just RHL), I've professionally found myself deploying a
combination of Gentoo, Fedora and RHEL/CentOS.
- Gentoo** for cutting-edge, "from source" development
- Fedora for "mid-stream, next RHEL release" preparation
- RHEL (or CentOS) for release/post-release support

[ **SIDE NOTE:  I was estatic when I first learned Daniel Robbins, who I
humbly (or I should humbly -- I'm no where near in his ballpark) share
publication credits with, decided to create a "BSD ports-like, from
source" distro which became the "portage" tools and, correspondingly,
Gentoo.  The open source world very much needed such. ]

Now that's in my _professional_ career ... (continued below) ...

On Sun, 2007-07-22 at 07:30 -0700, n schembr wrote: 
> Ubuntu has taken the lead with a Desktop System that just works.  I
> hope that canonical gets into the hardware business.  It would be fun
> to see them team with Wal-Mart, Toshiba, Sony or Hp on a laptop or
> embedded device. Yes, Wal-Mart,
> http://money.cnn.com/2007/07/12/news/companies/walmart_electronics/index.htm

I've also been a Debian maintainer (of little note) and _do_ like Debian
in general for many things on many fronts (I won't dump it all here).

Which is why I find most consumers prefer Ubuntu (and variants like
Kubuntu/Xubuntu -- I even use XFCE on RHEL/CentOS to keep the run-time
memory usage below 100MB after login), and I'm sure if I hadn't based
90% of income for the last 12 years on Red Hat-based solutions, I'd be
running Ubuntu as well (most like Xubuntu).

I do _not_ run Fedora/RHEL(CentOS) because I think it's "better."

Although I will state Gentoo is the only "source build" that I find
feasible to support (although there are arguments for/against whether a
"source build" is "feasible" in some situations).  And I list some of
those situations in this run-on blog entry from 2 years ago here:  
  "Linux Distributions:  Packages v. Ports"
  http://thebs413.blogspot.com/2005/07/linux-distributions-packages-v-ports.html  

As long as you understand that "ports" distros puts the
integration/regression testing 100% on you, you're fine.  But when
you're running a "packages" distros and changing out a crapload of
packages, then you're basically _undoing_ and _negating_ all of that
integration/regression testing anyway.

This is my #1 complaint with Montavista [HardHat] Linux in the embedded
space as well.  ;)


On Sun, 2007-07-22 at 10:47 -0400, Michael H. Semcheski wrote: 
> I don't want to start a flaming religious war either... Too nice a day.
> In my (limited) experience, Redhat and their community has been
> putting out some pretty nice products.  As long as you stick to the
> [limited] supported repositories, things 'just work' acceptably.

Unfortunately, even I -- a well known "Red Hat apologist" -- will be the
first to say that leaves a lot of "open space.  But where Ubuntu is at,
Red Hat does _not_ want -- other than maybe wishing they had the same
mindshare among "consumer" users -- but not enough to give up their
profit model.

> I've found that with many of the later releases, whether its CentOS,
> Ubuntu, Fedora, or whatever, when you start dabbling in RPM's that
> aren't part of the officially supported distribution, its only a
> matter of time before you start having problems.

Putting Ubuntu aside (since it's not Red Hat-based, but Debian), the
"repository hell" issue affects _all_ "packages" distros.  The
RHL/Fedora - RHEL/CentOS story is long, but rather straight-forward fro
those who have been around RHL for a long time (and stuck around post
RHL 10 Beta).  There were, and still are, a lot of "unofficial"
repositories around Fedora, just like RHL prior which led to the
"de-productizing" of RHL.

The two highlights are ...
A.  The formal "Extras" then recent, complete end of "Core"
B.  The recent, on-going EPEL project (not-yet-official)

First off, Red Hat _finally_ established and, more importantly, put
their own people "in-place" to establish a formal "Extras" procedure and
repository to ensure basic integration testing for Fedora circa Fedora
Core 2/3.  And by Fedora 7, this was formalized enough (along with
Fedora's "final" organization) that the Core-Extra separation is no
longer from a build/release standpoint.  Anyone who wants to "maintain"
packages for Fedora can go through Red Hat's process.  More and more
members of "RPMForge" are doing that, and no longer merely having their
own, "official" repositories (which Fedora has called "Fedora 3rd Party"
from virtually day 1)

Although one must remember that Fedora is "officially" _only_ a 1-year
supported distro.  That has been Red Hat's long-standing stance on its
releases since the Red Hat Linux 4 release, although they had to
reclarify it at the release of Red Hat Linux 6.1, 7.2 and after the Red
Hat Linux 10 Beta turned into Fedora Core 1 Test 1 (in reality, most
releases have been supported 18-24 months, and a few -- namely Red Hat
Linux 5.2 and 6.2 -- as long as almost 4 years).  That's one issue a lot
of "Fedora 3rd party" and RPMForge suppporting repositories take issue
with, along with Red Hat's limited "alternatives" support and other
details.

A lot of this has to do with -- as I mentioned above -- #1 feeding #2.
Red Hat standardizes on a fixed kernel/GCC/GLibC ABI/API for 2-4
Community releases which then feed into Enterprise.  Those of us in the
Debian world, especially maintainers, are commonly used to building
against different kernel, GCC, GLibC, etc... in a Debian release (let
alone other packaging guidelines that Fedora has not had).  The limited
lifespan of a Fedora release, like RHL before it, also causes issues --
especially leaving that "open hole" between "fast moving/deprecated" and
"enterprise duration/absolutely no changes."

The second is the new (name currently not formalized) Extra Packages for
Enterprise Linux (EPEL) from the Fedora Project, or packages for RHEL
and, correspondingly, CentOS (so explicitly named in the Project, not
ignored).  The idea is that Fedora package maintainers for packages that
are still complementary to packages on RHEL/CentOS can maintain their
packages under a Fedora-style test/release process, instead of relying
on 3rd party mechanisms/RPMForge rebuilds that are not (as anyone who
has tapped CentOS Extras, DAG, etc... can attest).  Again, the idea here
is to offer an "official" repository for added packages to RHEL/CentOS,
to avoid "repository hell" like Fedora Extras and, now (as of 7), just
Fedora itself in its entirety.


On Sun, 2007-07-22 at 08:55 -0700, n schembr wrote:
> The system is greater then the sum of all parts.  We stand on the
> shoulders of giants.   

That is the truth that I wish was more proliferated.

One of the articles I wrote for SysAdmin was on a project that was
forked from another project 4 years earlier, which was a full kernel
version back, and the entire "front-end" (98% of the project) was
replaced.  Yet the original project wanted kudos -- despite the fact
that 99% of what is in the distro come from others, and 98% of that
remaining 1% was _nothing_ of the original.

In the end, we made a blanket "thanx to all developers" and didn't name
anyone.


On Sun, 2007-07-22 at 08:55 -0700, n schembr wrote
> As for Apples defects, It's a marketing. I think they stand by there
> products as well as anyone else.  I like to have a warm fussy feeling 
> about a big ticket item.

On Sun, 2007-07-22 at 07:30 -0700, n schembr wrote: 
> This is all about a unix environment that works.  After 10 years
> working on linux systems I've gotten to the point that I just want it
> to work.   I can see why so many people want to run OSx.  

I wrote a blog entry some 2 years ago entitled "6 Things To Know About
Linux" which touches on why some people -- yes, UNIX users -- prefer
MacOS X":  
  http://thebs413.blogspot.com/2005/10/6-things-to-know-about-linux.html  

There are some things that people expect that the Linux community cannot
offer, at least not until 3rd parties stop trying to protect their IP.

nVidia learned that first hand back in 1999 (remember nVidia's 100%
source code release for the "nvidia" driver back for XFree86 3.3? ;).
Many other companies have also had the same happen to them, because many
times companies don't own the software IP they use.  And that software
IP is basically the "guts" of that 3rd party provider's profit model.


-- 
Bryan J. Smith         Professional, Technical Annoyance
mailto:b.j.smith at ieee.org   http://thebs413.blogspot.com
--------------------------------------------------------
        Fission Power:  An Inconvenient Solution