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.
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.
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.
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.
There's only so much tiddly-winks one can play at work before you realize you'd rather play tiddly-winks with your non-work friends with your own free time.
If it exists, both the CIA and the NSA have each figured out independent ways to spy on it.
They usually try to limit the scope of anything that can be detected, to reduce the risk of people getting spooked and switching to new things that they have to do more work to figure out how to spy on. For passive attacks, they're only limited by what they can blackmail, err... convince the Justice Department not to prosecute them for.
If they're just trying to get people to sign up for their newsletter, they can still do that while complying with the GPL. That won't prevent other people from redistributing it, but if they have a trademark, they can still be the only source of "WinMTR", much like Red Hat is the only source of Red Hat Enterprise Linux, even though there are numerous community rebuilds that coexist with RHEL.
DVD and mp3 playback are supported by lots of completely free software. There are issues in some jurisdictions with patented codecs, and there used to be an issue with the legality of DeCSS, but the code itself is as free as can be.
Fedora's historical view, much like Linus's, has been that binary blobs are okay as long as they're running on special-purpose hardware, rather than the general-purpose CPU. Drivers, even though they *control* special-purpose hardware, run on the CPU, with complete access to the resources of the entire system, so the drivers themselves need to be open source to be part of Fedora proper, even if some of their functionality is implemented in a binary firmware blob.
This view is not shared universally in the Fedora community, and many (including a lot of Red Hat employees) are growing increasingly fed up with it. I would not be shocked to see Fedora do something like this in the not so distant future. Take a look at this, for example:
Disclaimer: I used to work for Red Hat and personally know some of the board.
SQLNinja is not a security analysis tool. It is no more useful for telling you if your database app is insecure than a blowtorch is for telling you if you have a gas leak. SQL injection vulnerabilities are *trivial* to detect with simple input fuzzing.
SQLNinja is certainly a legitimately useful *demonstration* tool for developers and administrators to show their bosses just how severe their problems are, such that they might be prioritized, but it's designed for software that doesn't even run on Fedora, so it provides negligible benefit to the Fedora community. Anyone who knows enough to search for "SQL injection tool" can find it and install it, so there's really not much of a barrier here, but leaving it out of the distribution reduces the risk of Fedora being used as a gateway to the fat wallet of Red Hat in any litigation, a problem which most community distributions do not suffer from.
Fedora takes a lot of moral stands, but they're ultimately about things that will somehow benefit the Fedora community in the long term, and there's really no foreseeable payoff here, or certainly none that overrides the fantastic headache it could incur. I certainly can't fault them for picking their battles.
A friend of mine tried this with her rather savvy users, but the churn in Fedora created too much work to keep up with. It worked fine, but they ended up switching to Ubuntu LTS for the longer support lifetime, since CentOS 5 was getting a little old. If you prefer the Fedora ecosystem, RHEL 6 was just released, and CentOS 6 will be out soon.
Slashdot Mirror
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.
There's also the "waste 2-3 hours more" option.
There's only so much tiddly-winks one can play at work before you realize you'd rather play tiddly-winks with your non-work friends with your own free time.
Is that what the kids are calling it these days?
If it exists, both the CIA and the NSA have each figured out independent ways to spy on it.
They usually try to limit the scope of anything that can be detected, to reduce the risk of people getting spooked and switching to new things that they have to do more work to figure out how to spy on. For passive attacks, they're only limited by what they can blackmail, err... convince the Justice Department not to prosecute them for.
If they're just trying to get people to sign up for their newsletter, they can still do that while complying with the GPL. That won't prevent other people from redistributing it, but if they have a trademark, they can still be the only source of "WinMTR", much like Red Hat is the only source of Red Hat Enterprise Linux, even though there are numerous community rebuilds that coexist with RHEL.
DVD and mp3 playback are supported by lots of completely free software. There are issues in some jurisdictions with patented codecs, and there used to be an issue with the legality of DeCSS, but the code itself is as free as can be.
Fedora's historical view, much like Linus's, has been that binary blobs are okay as long as they're running on special-purpose hardware, rather than the general-purpose CPU. Drivers, even though they *control* special-purpose hardware, run on the CPU, with complete access to the resources of the entire system, so the drivers themselves need to be open source to be part of Fedora proper, even if some of their functionality is implemented in a binary firmware blob.
This view is not shared universally in the Fedora community, and many (including a lot of Red Hat employees) are growing increasingly fed up with it. I would not be shocked to see Fedora do something like this in the not so distant future. Take a look at this, for example:
https://admin.fedoraproject.org/updates/F14/FEDORA-2010-18594
Judges are lawyers. When they see this, they'll be thinking "you've got to be kidding me", which doesn't bode well for USCG.
Except that that's an illegal business model and can get you disbarred.
This isn't Wave, this is the Wave killer!
Disclaimer: I used to work for Red Hat and personally know some of the board.
SQLNinja is not a security analysis tool. It is no more useful for telling you if your database app is insecure than a blowtorch is for telling you if you have a gas leak. SQL injection vulnerabilities are *trivial* to detect with simple input fuzzing.
SQLNinja is certainly a legitimately useful *demonstration* tool for developers and administrators to show their bosses just how severe their problems are, such that they might be prioritized, but it's designed for software that doesn't even run on Fedora, so it provides negligible benefit to the Fedora community. Anyone who knows enough to search for "SQL injection tool" can find it and install it, so there's really not much of a barrier here, but leaving it out of the distribution reduces the risk of Fedora being used as a gateway to the fat wallet of Red Hat in any litigation, a problem which most community distributions do not suffer from.
Fedora takes a lot of moral stands, but they're ultimately about things that will somehow benefit the Fedora community in the long term, and there's really no foreseeable payoff here, or certainly none that overrides the fantastic headache it could incur. I certainly can't fault them for picking their battles.
A friend of mine tried this with her rather savvy users, but the churn in Fedora created too much work to keep up with. It worked fine, but they ended up switching to Ubuntu LTS for the longer support lifetime, since CentOS 5 was getting a little old. If you prefer the Fedora ecosystem, RHEL 6 was just released, and CentOS 6 will be out soon.