RedHat, Fedora future?

[esm at logic.net]

(In retrospect, I'm not sure why I'm bothering to respond to this, but
since I can't get back that five minutes of my life spent reading the
article, I can at least say something about it.)

Am Do, den 05.02.2004 schrieb Robin Laing um 16:50:
> Red Hat or SUSE for the enterprise? Hint: Bet the chameleon
> <http://www.newsforge.com/article.pl?sid=04/01/28/219249>

What a disappointing article, but then again, Newsforge really hasn't
been much other than an editorial avenue for most of it's life. (Any
news site that considers a MozillaQuest editorial a credible news
source isn't really the first place I go to find out what's really
going on.)

> The range of available applications is adequate, but not nearly as
> complete as, say, Mepis, which draws on the huge Debian application
> repository.

Gotcha. "Red Hat bad, Debian good." Maybe the author missed the large
collection of public yum and apt repositories available for Fedora?
Fedora.us and Livna, Freshrpms, Dag's repo, along with a ton of
repositories focused on particular sets of packages...

> It wasn't Red Hat's unique administration tools. There are none.

I'm sorry, redhat-config-* must have been a figment of my imagination.

> Maybe it was Red Hat Package Manager (now RPM Package Manager), the
> company's tool for installing binary applications. RPM is an excellent
> tool, but it's no match for Debian's apt-get application and .DEB
> files.

Of course, the author fails to mention that up2date has been available
for quite some time, and apt-get/yum are both available today, with a
wide (and growing) variety of public repositories to draw on. Once again,
they're confusing the underlying implementation (rpm vs. deb) with the
user interface (apt-get, dpkg, yum, up2date, etc), like every other
impassioned "why don't they love Debian!?" plea I've seen.

> SUSE's acquisition by Novell has paired a top distro with a top
> networking company.

...overstating more than just a little bit the importance of Novell to
the IT ecosystem today. Five years ago, I would have conceded this, but
not today.

> dropping the Red Hat Linux desktop is a questionable tactic.

It sure would be. Luckily, they didn't do that, did they? Did the author
miss the fact that Red Hat has a professional *workstation* product in
their line-up, not to mention the fact that a lot of people who follow
or participate in Fedora are desktop weenies too? ;-)

> (Though why they picked the name of an existing open source project
> is another mystery.)

...demonstrating the author's lack of research into the history of the
Fedora project, including fedora.us. Looking at the Cornell project,
they didn't even get a grant to start on it until late 2001, which
means I doubt they had something worth showing anyone until late 2002,
which is, imagine that: about when the fedora.us folks got going. (I
see posts to the fedora.us devel mailing list dating back to November
of 2002, and I'm quite sure they were active prior to that.) I'm not
sure why the author thought little jabs like this helped his case.

[...skip a bunch of unsubstantiated assertions and more jabs...]

> Fedora is a cast-off project from a company without significant
> technology differentiators.

Loosely translated as: author has not been paying attention. Maybe he
missed the work going into offering a 2.6 kernel, a distribution built
for SELinux, laying the groundwork for the new version of Gnome,
among a ton of other major updates, while retaining an upgrade path
for existing users.

He's obviously right, nothing differentiating to see here, folks.

> Today Red Hat is the default choice for U.S. businesses.

I'm sure Red Hat's salesforce wished this was true. ;-)

The whole article sounds like the sour grapes of a developer who wishes
people liked his distribution of choice better, but since people aren't
flocking to it, at least he can take a jab or two at the company he
thinks caused the downfall of his "top-notch distro".

-- 
Edward S. Marshall <esm at logic.net>
http://esm.logic.net/

Felix qui potuit rerum cognoscere causas.