We get blasted from (distro) partisans when we say this ...

… so it is better to point out that the distro people are saying it themselves:

This is from lwn.net. Not me. Don’t shoot the messenger.

The link to the thread in question contains far more explosive (for distro partisans) content. Without cherry picking this author, he does a very good and succinct job of describing what Fedora is and what it is not. To wit:

Introduction of 4k stacks. Blew up lots of drivers, file systems, and other assorted things. I fail to see the benefit of 4k stacks. It is, IMO, a very bad idea. Introduction of tickless kernels. Ok, this was done in Ubuntu as well. And I have roundly criticized it as it appears to destabilize a number of drivers that we use in JackRabbit. We have customers who are excited about using Fedora on our systems or on systems to connect to our systems. We point out that as a non-production bleeding edge distribution, they should expect breakage. We offer our customers our kernel for their Fedora systems, in the hope that it will stabilize it. And sure enough, in most of the cases where we have run into Fedora in production use, the addition of Infiniband via OFED or other bits has resulted in (usually violent) breakage, random crashes, and all sorts of other (bad) things. We find that unacceptable. If the smallest change we can make is to swap out their kernel with ours, and it brings stability, we are fine with that. Call the distro what you want, just use a decent kernel. Note that this means that you really, really, want to avoid kernels with backports. Really. It should be obvious why, but in case it isn’t … a backport moves forward functionality into a previous generation kernel. It often does so to provide features to the older kernel that it doesn’t have. The problem is that there is a dependency tree and set of assumptions, explicit and implicit, that you have to deal with when you do this. So if you simply port the explicit dependency tree (mostly this is done) back to the older kernel, and leave the implicit assumptions about system behavior and functionality behind … you don’t simply add features to the old kernel, you add bugs. Usually hard to find and diagnose bugs. Even harder to fix bugs. You really have to move the whole enchilada backwards. A new libata module that provides a better support and bugfixes for various SATA chips? Great, pull it in. Oops, it depends implicitly upon cleanups and bugfixes in other parts of the kernel. So pull it in, but where the assumptions don’t align … here be heisenbugs. I have used all of the major distros over the last decade plus. Some of them are ok, a fair number are annoying in their assumptions or missing features and bugs. Anaconda having a failure mode that doesn’t allow you to recover an installation when an exception occurs is unforgivable in 2008. The other installion systems all allow you to gracefully recover from failure. The lack of a real file system for large storage and I/O users is unforgivable in RHEL. All the other distros have needed bits. SuSE’s penchant for ignoring user input during installation has only been rectified in the 10.3 and 11.0 OpenSuSE distros as far as I can see. Ubuntu’s annoying and useless nVidia support is best quietly forgotten about … the OLF08 video was a Ubuntu 8.04 desktop with nVidia advanced graphics. Installed by hand, as lrm-video and other related bits are horribly broken beyond repair and it is simply not worth my time/effort to fix it for them at this moment. If we get a large order for our Pegasus many core workstations, sure, we will do this. I am not partisan. We will install what our customers want. The issue is when we encounter broken things, or bad ideas, we will let our customers know and we will offer solutions and workarounds for the broken bits. [Update] I guess I find it … well … amusing that Fedora, a largely unfunded group, has the ability to support xfs and jfs in their kernels (though you have to explicitly ask for it at install time to get the right bits) but the well funded cousin, RHEL, does not. Sort of renders their “xfs is hard to support” statements to be … um … hard to believe. They also claim “ext3 is on par with xfs for performance” which has been debunked by quite a few groups for a long time now. As our customers often have greater than 2TB files, and file systems much larger than 8TB, ext3 isn’t even a consideration, even if we neglect its performance issues.