Submitted by Barry (not verified) on Mon, 2008/05/19 - 04:45.
Red Hat's first foray into the "Enterprise Linux" market was 6.2EE which was essentialy Red Hat Linux 6.2 with a support contract for those that wanted it. It wasn't built differently, or tested any more (or less) than any oter previous version of Red Hat Linux. At the time, running a Red Hat distrubution seemed to me as though it was a constant treadmill. Build a farm of servers this month, and next month or a few months later, there is a new version released. A choice had to be made whether to move ahead with the new release or to stick with the old release based upon the relation of this farm to the previous one. Software vendors were in a worse position. They would test their software for a given Red Hat release, and would keep testing the same version of their software on subsequent versions of RHL. At the time Red Hat released patches for a given RHL version for quite a long time .. although I don't believe there were too many hard and fast timelines until the end of RHL, all I know is that I never had to reinstall a newer version of RHL because that version was being EOL'd. Once Red Hat became focused on the enterprise market, they changed their thinking, and more importantly changed their engineering process. Consider this. RHEL 2.1 uses a 2.4.9 kernel foundation. Although RHEL 2.1 will be out of support in 2009, Red Hat is still maintaining a kernel that has *7 years* of backported patches. Did I mention that they guarantee API/ABI compatibility for *7 years*? Who does that? Red Hat does. Any other takers? Didn't think so. I know that certain Ubuntu relases such as the most recent releases are dubbed LTS. Is there anything different about these besides the name and how long patches are released? Were considerations made as to what would be supportable and maintainable for the next several years, or did Canonical just say "This is the kernel we are using because it is current." If I recall, Red Hat used the 2.4.9 kernel as its foundation for RHEL 2.1 (aka Red Hat Advanced Server) because there was a significant change in memory management in the 2.4.10 kernel that Red Hat was not interested in using. These are the types of decisions that *MUST* be considered when choosing software to include in an "Enterprise Linux" distribution, most notably the kernel. For everyone that complains that Red Hat and subsequently CentOS are outdated, I have 2 words, centosplus, and rpmforge. Both centoplus and rpmforge as well as others I'm sure fill the gap that isn't viable for Red Hat to fill with updated versions of software. Enterprise Linux is all about stability, support contracts and having no surprises. If you want newer versions of software on any Linux distribution, knock yourself out, install whatever you like, but don't expect Red Hat or anyone else besides yourself to support it. If you buy a Ford Mustang, and replace the engine and transmission that's great, assuming you know how to do these things, but if your engine causes the car to explode, you cannot blame Ford, especially if you had to replace Ford parts with aftermarket parts to accomodate your new engine/transmission. The same applies to third party software and Red Hat support contracts. I think Ubuntu has done great things for the desktop, but until they start thinking like an enterprise company with an enterprise Linux distribution and those changes are reflected in their distribution, they will not be a major player in the enterprise space.
Engineering is paramount
Red Hat's first foray into the "Enterprise Linux" market was 6.2EE which was essentialy Red Hat Linux 6.2 with a support contract for those that wanted it. It wasn't built differently, or tested any more (or less) than any oter previous version of Red Hat Linux. At the time, running a Red Hat distrubution seemed to me as though it was a constant treadmill. Build a farm of servers this month, and next month or a few months later, there is a new version released. A choice had to be made whether to move ahead with the new release or to stick with the old release based upon the relation of this farm to the previous one. Software vendors were in a worse position. They would test their software for a given Red Hat release, and would keep testing the same version of their software on subsequent versions of RHL. At the time Red Hat released patches for a given RHL version for quite a long time .. although I don't believe there were too many hard and fast timelines until the end of RHL, all I know is that I never had to reinstall a newer version of RHL because that version was being EOL'd. Once Red Hat became focused on the enterprise market, they changed their thinking, and more importantly changed their engineering process. Consider this. RHEL 2.1 uses a 2.4.9 kernel foundation. Although RHEL 2.1 will be out of support in 2009, Red Hat is still maintaining a kernel that has *7 years* of backported patches. Did I mention that they guarantee API/ABI compatibility for *7 years*? Who does that? Red Hat does. Any other takers? Didn't think so. I know that certain Ubuntu relases such as the most recent releases are dubbed LTS. Is there anything different about these besides the name and how long patches are released? Were considerations made as to what would be supportable and maintainable for the next several years, or did Canonical just say "This is the kernel we are using because it is current." If I recall, Red Hat used the 2.4.9 kernel as its foundation for RHEL 2.1 (aka Red Hat Advanced Server) because there was a significant change in memory management in the 2.4.10 kernel that Red Hat was not interested in using. These are the types of decisions that *MUST* be considered when choosing software to include in an "Enterprise Linux" distribution, most notably the kernel. For everyone that complains that Red Hat and subsequently CentOS are outdated, I have 2 words, centosplus, and rpmforge. Both centoplus and rpmforge as well as others I'm sure fill the gap that isn't viable for Red Hat to fill with updated versions of software. Enterprise Linux is all about stability, support contracts and having no surprises. If you want newer versions of software on any Linux distribution, knock yourself out, install whatever you like, but don't expect Red Hat or anyone else besides yourself to support it. If you buy a Ford Mustang, and replace the engine and transmission that's great, assuming you know how to do these things, but if your engine causes the car to explode, you cannot blame Ford, especially if you had to replace Ford parts with aftermarket parts to accomodate your new engine/transmission. The same applies to third party software and Red Hat support contracts. I think Ubuntu has done great things for the desktop, but until they start thinking like an enterprise company with an enterprise Linux distribution and those changes are reflected in their distribution, they will not be a major player in the enterprise space.