hahn at physics.mcmaster.ca
Wed Feb 1 20:00:29 PST 2006
> I just never understood. I would love to hear some reasoning as to why
> people use Fedora in production where there are so many other distros
> that are actually designed for production use (and are free).
Fedora is designed for rapid development.
it is not NOT designed for production use.
it does not introduce deliberate and unnecessary incompatibilities.
think of it this way: software develops in frequent small steps.
some are buggy. some are major improvements. a "release" exists
mainly to distinguish specific attractive points in the development
staircase - really it's just a matter of selecting fewer, larger steps.
and yes, fewer steps _necessarily_ implies that each step is higher,
unless you're OK with falling behind.
it's not uncommon to back-port some development to previous releases: this
just means that after an upgrade, there is some minor improvement before the
next major step. again, this inter-release rate of change/improvement is
inherently slower than the mainline development, and does not remove the
absolute necessity for eventually taking a major step. this practice
(back-ports) is a form of forking, and does involve some additional work.
the work involved depends on whether the mainline has taken any major,
"infrastructural" steps - in a sense, release-conservativeness is nothing
more than delaying acceptance of these major changes.
when people invoke "production-worthy" a lot,
they really mean "I want fewer big steps".
I know they're not just being lazy, but I'm not sure
whether they realize the trade-offs.
here's a specific example: it's not uncommon for people to advocate GCC 2.9x,
since those releases often run faster than more recent ones, and sometimes
generate better code. IIRC, 3.x marked a major upgrade in C++ features,
but also introduced incompatibility (calling OO convention? something like
that). people who have finally come to accept 3.x may not rush to embrace
4.x, even though it includes some dramatic improvements (gfortran, SSA, etc).
what to do? sometimes you can simply keep all the options around, but
that is labor-intensive, both for maintenance and use. it's not as easy
to keep around glibc and kernel revisions, but you could still do it.
and if you keep gcc 2.9x around, someone will inevitably use it even
though they'd be better off with gcc 4.x (say, for optimizing data member
I use Fedora in production clusters, and will continue to do so.
the reason is simple: I value being up-to-date (bug-fix and
development-wise). I find that in a cluster, the things that matter
either do not change at breakneck speed (say, glibc), or else can be
nicely updated (I prefer to run a recent kernel.org kernel, and am
perfectly happy compiling my own ssh or gcc update, for instance.)
IMO, clusters should specifically avoid providing too many desktop-y things,
partly just to opt out of many of the updates promulgated by a distro. if
you've got a something approaching a cluster appliance, you don't care about
the latest buffer overflow in gpdf, or whether wine faithfully replicates
the recent WMP bug.
regards, mark hahn.
More information about the Beowulf