Cluster Poll Results (tangent into OS choices, Fedora and Debian)

Robert G. Brown rgb at phy.duke.edu
Sat Nov 1 10:35:03 EST 2003


On 31 Oct 2003, Tod Hagan wrote:

> While looking into the number of packages in Debian vs. Fedora I
> stumbled across this frightening bit (gotta throw a Halloween reference
> in somewhere) on the Fedora site:
> 
> http://fedora.redhat.com/participate/terminology.html
> > Packages in Fedora Extras should avoid conflicts with other packages
> > in Fedora Extras to the fullest extent possible. Packages in Fedora
> > Extras must not conflict with packages in Fedora Core.
> 
> It seems that Fedora intends to achieve applications breadth through
> "Fedora Extras" package sets in other repositories, but the prohibition
> of conflicts between Extras packages isn't as strong as the absolute
> prohibition of conflicts between Extras and Core packages. Could this
> result in a new era of DLL hell a few years down the road?
> 
> Wow, I guess I just slung some FUD at Fedora, but maintaining a 2-3
> releases per year rate probably requires a small core, putting the bulk
> of applications into the Extras category and thus increasing the chance
> of conflict. (Wasn't that the original recipe for DLL hell?) Debian has
> avoided this through a much larger core, which of course slows the
> release cycle.

Pre-yum, I would have said yes, but I honestly think that yum has
arrived in the knick of time to rescue RPM-based distributions of all
sorts from precisely this.

Fedora (and for that matter RH mainstream) appears to have embraced yum
(perhaps somewhat reluctantly, given that it obsoletes up2date
dramatically before up2date achieved anything like real traction in the
marketplace) and AFAIK are yummifying their repositories or plan to soon
(as well as provide yum as a part of the distribution).

With yum, packages that conflict will have a very, very short lifetime
in any public or private repository because the conflicts will be
immediately exposed and the conflicting packages either rejected or
rebuilt.  Note well that with rpm-based distros one can put oneself into
hell already by just using rpm --force (and who hasn't done this at
least once, seriously:-).  If one uses kickstart to install systems and
yum to install additional packages and update/upgrade the ones you've
got (religiously) one cannot enter hell as the gates are barred.  One
MAY well have packages with conflicts that one wishes to put into your
repositories, but yum will reveal them in short order and you (or the
group with whom you share an interest in the packages) will willy-nilly
fix the packages or have the PACKAGES consigned to hell.

The point is that FINALLY having a sensible toolset that can resolve all
forward dependencies, revealing conflicts, obsoletes, dependency loops,
file (as opposed to package) dependencies, and all the other Evil that
rpm as a bare specification at long last enables packages to be
developed with something approximating rigor and discipline.

This is one of several reasons that I think that Fedora (or similar
rpm-associated projects -- there will likely be more than one) will turn
out in the very short run to be MORE reliable than RHE, and that there
will be a very distinct flow of energy FROM fedora BACK to RHE.  In
fact, I think that as fedora becomes the "real" open source red hat
where development is rapid and problems are rapidly revealed and
repaired on the dynamic edge by all the people who actually wrote and
use the bulk of the software in ANY linux distribution, people who buy
RHE are increasingly going to be getting fedora, repackaged and "tested
and supported" by RH and resold to people that want to be insulated from
the supposedly chaotic process that is PRECISELY what has been driving
linux stable and unstable distributions for years now to everybody's
general satisfaction.

yum isn't even "finished", in my opinion, and will only get stronger as
tools and concepts are added to the suite.  There are some really
significant changes in the wind that could conceivably trigger a
long-overdue paradigm shift in the way packages in ALL linux
distributions, including e.g. Debian (not just rpm-based) are installed.
Then there are several ideas out there for tools that don't just install
binary/distro compatible rpm's from a distro-specific repository, but
rather install a binary/distro compatible "base" system and then
download and dynamically build source rpm's (either for a local install
or to BUILD a binary/distro non-conflicted rpm repository for yum
install and maintenance).

As I said in an earlier message, I think that the Internet's general
response to RH's attempt to coerce money on the order of $100/seat/year
(or more, conceivably MUCH more) from all its users is going to be very,
very "interesting".  Chinese curse "interesting".

(And yes, I think that this is totally absurd on a workstation or small
(<32 node) compute node that these days might cost $500-600 full retail,
where its costs is more like 20% of the base hardware where 2%/year
would STILL be too much -- noting that small <32 node clusters that
comprise the bulk of installed clusters, and that $3200 or more is
TOTALLY out of the question for most of these. I also see no reason
whatsoever for a "workstation" distribution to be crippled by omitting
http, nfs, and the various so-called "server" packages -- one of linux's
strengths for years has been that when a workstation needs to become a
server, you just chkconfig the server features on, possibly after
installing a couple of packages.  In fact, I see absolutely no reason
for any linux distribution to partition out ANY packages for special
treatment -- once they are built for a distribution, they are built,
building/rebuilding most of them once the source rpm's are made
consistent even one time is mostly a matter of rpm --rebuild
package.src.rpm.)

I could of course be wrong -- maybe we'll all be spending
trans-microsoftian amounts of money.  I'll be cheerily paying Red Hat
several thousand dollars a year for the privilege of running an internal
webserver and nfs file server in my house to serve a handful of
computers on my kids' and wife's desks. Maybe Duke will just go "sure,
we'll just raise tuition by a few hundred more dollars -- the kids and
their parents won't care -- so we can give it to Red Hat as we'd MUCH
rather pay them even more insane amounts of money than the $17/seat or
thereabouts we currently pay to Microsoft."  Maybe the NSF and DOE will
go "oh, hey, our bad" and ask the government to raise taxes a bit so
that all the government labs that use linux can now spend hundreds to
thousands of dollars extra per node/workstation/"server" (with Microsoft
sitting there perfectly happy to "compete" head to head for the same
privilege, invariably at LOWER PRICES).  Maybe consumers in Best Buy
will look at those spiffy box sets of Red Hat Linux that have finally
started to grace their shelves and say "gee, here is an operating system
that costs more than twice as much as WinXX, won't run any of these
seven hundred off the shelf WinXX applications, requires considerable
expertise to install it and maintain it and doesn't come preloaded on
any system I might buy here -- I simply MUST have it."

I personally think that Red Hat's board has lost its collective mind.
This is dicey ground; their stock price has not coincidentally been
skyrocketing as they present a public picture of "becoming another
Microsoft or Sun" complete with prices to match.  Of course, Microsoft
AND Sun have slowly but surely been LOSING market share to linux,
largely on the basis of COST-BENEFIT.  What will happen if/when this
rosy picture of huge profits turns out to be an "expectation bubble" and
that it actually SLOWS the rate at which RH is adopted in the corporate
marketplace compared to other commercial Unices and Microsofts competing
products (not to mention crushes the potential consumer linux
marketplace before it even was fully born)?  Ugly...

As Greg (in his role as a pundit:-) once remarked at a meeting I
attended, the game of being a pundit is to try to see the future and
make oracular predictions; to be provocative or evocative, right or
wrong.  So I could be wrong.  Either way things will prove
"interesting";-)

    rgb

P.S. - to Greg, sorry if I'm misquoting you -- my memory is far from
perfect but IIRC this was at the Atlanta ALS meeting and you were on a
panel discussion:-)

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu



_______________________________________________
Beowulf mailing list, Beowulf at beowulf.org
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf



More information about the Beowulf mailing list