Most support, even enterprise support, really is crap. Red Hat support is (usually) far above the rest. When I worked for Red Hat, I regularly interfaced with support staff at partner companies, and they were usually a long way below anyone who was out of training. (Before anyone chimes in with their horror story, yes, some people manage to make it through training and bungle a lot of stuff before getting fired/reassigned; some tickets get triaged by a n00b who doesn't know what they're doing; and sometimes even the experts mess up. That's when you should be requesting escalation, no matter who you're talking to.)

That said, a lot of people don't need the kind of support that Red Hat provides. Red Hat's business model focuses far more on the large enterprise than SMBs. When SMBs use RHEL, it's often through a VAR who's also helping them with whatever they're deploying on RHEL. Red Hat gets a smaller cut, for less work. CentOS is just fine for many people, at least until they grow to the point where they need a support subscription with SLAs. Red Hat gets a ton of business from people who use CentOS until they grow enough to justify fixed-price subscriptions with SLAs. The sales team doesn't lose any sleep over it. Most people who choose CentOS over Red Hat are either completely rational in that they don't need that kind of service, or they customize too much of the distribution for Red Hat support to be economical, or they're just really cheap and would inundate support with trivial questions rather than shell out to send their admin to a (very good) training course.

If you think CentOS is better for you than RHEL, odds are you're right. You don't need to guilt trip yourself about being a freeloader. Report bugs, frequent mailing lists and chat rooms, and do whatever else helps the CentOS community, because it's ultimately good for Red Hat and the community at large. Red Hat is running a profitable business, and doesn't need charity.

Lightning strikes are ephemeral, and mostly happen at high altitude where there's plenty of chance to recover from the momentary disruption.

An aircraft body is a giant metal tube that functions almost as a faraday cage. It's very good at keeping external RF out, and internal RF in. Anything that's transmitting on the inside will bounce around like mad until it gets absorbed by something inside, quite likely sensitive electronics.

Not every day. According to one rough estimate, maybe two per year. I'm afraid I can't find that study right now, but the takeaway from the study was not that number, but rather that there are so many ways that complex configurations can cause problems with things that work fine alone that truly comprehensive testing is impossible.

Actually, an airliner has much more internal reflection of RF radiation than a Cessna, so that probably offsets any benefits from stricter shielding requirements.

The law of large numbers can turn a very, very small risk into hundreds of people dying a fiery death.

Do you have any idea how many different PEDs are shipping right now? They'd more than fill a 747.

Because it's very difficult to characterize all the failure modes of consumer electronics. A circuit that goes bad may continue functioning (or may allow the device to continue functioning in a reduced capacity) while emitting huge amounts of RF radiation that never shows up in bench testing. This is why you occasionally get stories like the FAA knocking on a guy's door because his TV is emitting noise on a distress beacon frequency. With the rise of software-defined radios, it's further complicated by software states far too numerous to cover in testing.

An aircraft body is basically a faraday cage. Internal sources of radiation are many orders of magnitude more disruptive for their power level.

The FAA tries to keep plane crashes due to particular sources below statistically significant levels, so anecdotal evidence cannot be discounted.

I run the server for a small company as well, and since we do some Apache/MySQL stuff on it anyway, there's a lot of lightweight, mostly turn-key Apache/MySQL stuff I've set up opportunistically, some of which have turned out to be useful to the whole organization, and some of which have just turned out to be useful for me and the developers. It's a bit simpler to set up on a Linux server where a lot of this stuff is prepackaged for you, but Macports is rather straightforward, and installing PHP apps is only marginally more complicated than unpacking a zip file. Among other things, we're using:

Limesurvey
Pastebin
TikiWiki
WordPress

All of these require (trivial) database setup, which I manage with phpMyAdmin.

Don't overreach though. Your time is valuable, so you're much better off paying a bit to one of the many service providers who will gladly provide you with similar services for free or cheap, than mucking around in config files you don't understand. Your intranet server is still a great place to do proof-of-concept setups for things that ultimately you'd want to outsource. I use it more for things that require more customization than I can get from a service provider, but I'm a fairly experienced system administrator.

I worked in Red Hat Support when both RHEL 4 and RHEL 5 were released. Yes, each one had growing pains that made it unsuitable for many users. Most of those problems involved:

1) 3rd-party kernel modules
2) combinations of motherboards/BIOSes/peripherals/firmwares that each individually worked fine, but interacted in a way that caused undefined behavior that just happened to work correctly on the previous release
3) hardware that wasn't available for QA prior to release
4) entirely new features that had never been widely used in enterprise environments.
5) inadequate configuration tools or documentation

The first three don't apply to a VM hosting provider, because they use racks upon racks of identical hardware that's been QA'd to death, and the guest OS can run either a fully-virtualized kernel that's been thoroughly tested against the VM, or a paravirtualized kernel that you've already QA'd yourself on your hardware and run across all distributions you offer. Most of the new features that the last two apply to are for scale-up use cases, not scale-down use cases, so they mostly don't apply to the typical VM hosting customer either.

My developers want a modern LAMP stack, like the one in Ubuntu 10.04, and I want to give them that without subscribing to 3rd-party repos maintained by people who don't know how to write an RPM spec file. I'd also like it running on top of ext4, with a bunch of other management goodies in the newer distro. A RHEL 6 VM would be perfectly fine for that.

...if there were a single VM hosting provider on earth offering RHEL 6 images. I know they pissed some people off with the new pricing structure, but Red Hat has always cut special deals with hosting providers, so I'm forced to wonder what they hell they've done to piss them off so much that nobody is offering it more than 6 months after release.

There are an awful lot of people who need the kinds of data center reliability that need million-dollar investments, but don't have the economies of scale to do it themselves. It's baffling that Red Hat is leaving that revenue opportunity on the shelf, with Ubuntu 10.04 LTS offering a much newer stable distribution, and available with a lot of different hosting providers.

Okay, I just found the impoundment order attached to the TRO. I've never heard of anything like that in my life. Highly unusual.

Restraining orders are civil. You're talking about criminal evidence seizures. They're totally different and unrelated legal actions.