Server Admins: Why not Fedora?

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

One of the oft-repeated statements about Fedora is that it's "not good
for running a server". Clearly, as we embark upon a mission to change
that fundamental belief, we need to start addressing the problems that
make Fedora unsuitable to so many people.

I propose that a good place to start here is to carefully enumerate
the reasons people elect not to use Fedora in their server
environments. Let's start by gathering the surface problems (in some
cases, the cargo-cult explanations) and look into what is the real
underlying problem and how we can fix it with the Fedora Server offering.

To get us started:

 * Fedora moves too quickly!
   Historically, Fedora's policy has always been to be among thefirst
   to ship new technology (whether or not it's ready, but that's another
   discussion). The problem with tracking rapidly-moving upstreams is
   that they are not all created equally. Some upstreams (e.g. glibc)
   obsessively avoid backwards-compatible changes between versions.
   These are the upstreams that Fedora's current approach works well
   for. These tend to be the low-level features of the operating system
   that understand that compatibility == relevance. No one will build
   atop these systems if they don't have a guarantee that it will
   continue to work. Other upstreams (e.g. much of the Ruby and Java
   community) tend to focus more on constant innovation without
   consideration of backporting. This allows them to make bigger changes
   much faster, but at the cost of constant churn and difficulty to
   distribution packaging. These are the systems that normally expect
   consuming applications to just bundle the exact version of the
   library known to work. This is where we get into the "Fedora moves
   too quickly" area of things. Whatever we're shipping in the standard
   location on-disk tends to be preferred by the applications, and if it
   isn't the same version that upstream wanted to bundle, all bets are
   off.

 * Fedora moves too slowly!
   This seems like the inverse of the above, but this is what happens
   when certain packages are intentionally kept on an older version in
   order to maintain compatibilitity with some high-value application in
   Fedora. A classic example of this is 'v8'. The v8 version in Fedora
   is maintained to match what Node.js upstream supports, even though it
   is rather old and lacking many of the new features. Unfortuntately,
   if Fedora pulled in the newer version, it would break hundreds of
   other packages. This causes issues with people who are trying to
   build software (such as Chromium) that depends on the latest version.

 * Fedora has too short of a lifecycle!
   This is a very common one. The idea here is that administrators who
   are deploying a server to provide functionality to their
   infrastructure or critical apps to their users don't like to change
   the underlying operating system very often. With Fedora, they need to
   upgrade every thirteen months (and more often if they want to avoid
   issues that may crop up while going from version N to N+1 and then
   N+2 all at once). In many environments, the amount of compatibility
   and functional testing that would be needed to move their
   infrastructure exceeds what they could hope to accomplish on such a
   frequent upgrade cycle.


I'm sure there are other reasons and I'd like to hear them. Also, for
those of you who *do* use Fedora in production, I'd like to hear the
reasons why you chose to do so. What did Fedora gain you?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJz26kACgkQeiVVYja6o6PjoACfehQ4A/1OnKMpSTpCgAESPirO
HOYAn2umcZLfQlY4MY+832noJIF28Hv6
=zfYV
-----END PGP SIGNATURE-----