Weekly Edition
Return to the Distributions pageRecent Features
| |||||||||||||
Red Hat extends RHEL5 and 6 support
Red Hat has sent out a
press release stating, in pure marketing style, that the support period
for versions 5 and 6 of Red Hat Enterprise Linux has been extended to ten
years. "Many of our customers have come to realize that
standardizing on Red Hat Enterprise Linux improves efficiency and helps
lower costs. With a ten-year life cycle, customers now have additional
choices when planning their Red Hat Enterprise Linux deployment and overall
IT strategy. We are pleased that customers are looking far into the future
with Red Hat."
(Log in to post comments)
Red Hat extends RHEL5 and 6 support Posted Jan 31, 2012 16:08 UTC (Tue) by kragilkragil2 (guest, #76172) [Link]
Will this ever stop? 13 years is quite insane. Just imagine trying to run a 2.2 kernel today.
Red Hat extends RHEL5 and 6 support Posted Jan 31, 2012 16:13 UTC (Tue) by arjan (subscriber, #36785) [Link]
As long as the customers make it worthwhile for RH to put in the $$ to support them... good for them!
It's not like Red Hat will be asking the community (or other companies) to do work for this; it's Red Hat engineers providing their customers what RH gets paid for: Good, long term support.
The irony tends to be that the people that want support this long, also really tend to be change averse, so the support (in terms of updates at least) they expect decreases in amount of work. Likewise for bugfixes, if a server has been running well for 7 years, the chance that you find a critical bug that you don't have a simple workaround for in those last 3 years is ... very small. (but of course, you want the option to call someone just in case)
Red Hat extends RHEL5 and 6 support Posted Jan 31, 2012 16:39 UTC (Tue) by jengelh (subscriber, #33263) [Link]
>if a server has been running well for 7 years, the chance that you find a critical bug that you don't have a simple workaround for in those last 3 years is ... very small.
Math tells otherwise. The longer it runs, the higher the chance that one will strike. (Because the likelihood that you go without bugs for an growing time window decreases, given a bug occurs every other period on average.)
Red Hat extends RHEL5 and 6 support Posted Jan 31, 2012 16:44 UTC (Tue) by drag (subscriber, #31333) [Link]
The longer it runs the more they charge, typically.
If it is possible to know if it is practical and economical for Redhat to support these systems for longer terms then it would be Redhat who would know.
Red Hat extends RHEL5 and 6 support Posted Jan 31, 2012 20:11 UTC (Tue) by Wol (guest, #4433) [Link]
This is a classic fallacy. Assuming bugs follow a normal pattern, they have a half-life, and will *reduce* over the years, assuming they are *correctly* fixed as they are found.
And also, I would say that the chances of any individual bug striking will FALL with time. If you don't trip over it quickly, chances are you'll never trip over it.
That said, I would expect support costs to go up over time. Engineers need to remain familiar with the code, the number of customers go down, and even if the total cost to RH goes down, the number of customers that cost is shared over will be going down as well. It's just a case of which goes down fastest.
Cheers,
Red Hat extends RHEL5 and 6 support Posted Jan 31, 2012 21:42 UTC (Tue) by arjan (subscriber, #36785) [Link]
but for long running systems, a bug striking once in 7 years is not relevant, box gets rebooted (at best).
only things that block production (and thus, by definition keep happening) are expected to be fixed. (and security of course)
Red Hat extends RHEL5 and 6 support Posted Jan 31, 2012 17:23 UTC (Tue) by ballombe (subscriber, #9523) [Link]
You know what makes a nice business model?
1) Pay developers so that RH n+1 is very different from RH n 2) Customers are scared to upgrade and pay for long term support 3) Use the longterm support money to pay developers of 1)
Red Hat extends RHEL5 and 6 support Posted Jan 31, 2012 17:50 UTC (Tue) by drag (subscriber, #31333) [Link]
They would just stop using Redhat, period.
Nobody wants to put up with that BS and nothing Redhat is doing is forcing them to stay. Any company can offer support for Redhat systems...
Red Hat extends RHEL5 and 6 support Posted Feb 1, 2012 10:23 UTC (Wed) by dag- (subscriber, #30207) [Link]
If this was the case, why did Red Hat extend the normal support from 7 years to 10 years ? It doesn't bring in any money if a customer runs RHEL5 or RHEL6, so why would Red Hat make support more costly without any direct benefits.
You know by extending normal support from 7 to 10 years, and keeping the additional 3 years of extended suport, Red Hat makes it less attractive for companies to use extended support. And for any companies considering it, extra revenue is delayed by 3 additional years.
So if Red Hat has this evil plan of yours, they are acting to the contrary :-)
Red Hat extends RHEL5 and 6 support Posted Feb 3, 2012 20:28 UTC (Fri) by jwarnica (subscriber, #27492) [Link]
Because RH sells subscriptions. You don't buy RH vX and get support for as long as they think to extend it, you buy a 12 month subscription to RH and get support for 12 months.
Red Hat extends RHEL5 and 6 support Posted Feb 5, 2012 21:34 UTC (Sun) by dag- (subscriber, #30207) [Link]
It makes absolutely no difference to Red Hat whether you would move to RHEL6 or stay 3 years longer on RHEL5 now. So if Red Hat is evil, extending support from 7 years to 10 years is counter-productive as people are _less_ likely to pay for the more expensive RHEL5 ELS.
Your clarification has no effect on anything I said.
Red Hat extends RHEL5 and 6 support Posted Jan 31, 2012 16:31 UTC (Tue) by rijrunner (guest, #49442) [Link]
Well, since RedHat will not allow you to upgrade from 5.0 to 6.0, instead forcing you to do an new OS install and reconfiguration from scratch, a lot of people would rather just stay on the OS version until they phase out the app running on it.
The lack of a smooth upgrade path is likely the main culprit in the extension.
Red Hat extends RHEL5 and 6 support Posted Jan 31, 2012 16:36 UTC (Tue) by rijrunner (guest, #49442) [Link]
Slight correction.. they make you jump through hoops and upgrades are done at your own risk..
Red Hat extends RHEL5 and 6 support Posted Jan 31, 2012 18:42 UTC (Tue) by tialaramex (subscriber, #21167) [Link]
Realistically if you're paying RH good money for this service you are likely going to have an evaluation process for RHEL N+1 which more or less prohibits dodgy schemes like "let's try running Anaconda on the production hardware and see if it works". That would be true for any plausible upgrade process, it's just the nature of a major version OS upgrade IMO.
You can (unlike with similar schemes 15-20 years ago) upgrade in the sense of buying a bunch of new hardware, putting the new OS on it, and throwing out the old hardware, without buying all new licenses for everything.
I do the "run Anaconda, cross fingers" thing at home on some Fedora machines. I can just about imagine doing it to a development server, particularly if that server ran as a VM so I could just roll it back. I can't imagine trying it on a production system where people are going to be genuinely unhappy if we break it and can't get it working again in 10 minutes. If I found out our sysadmins were planning such a thing I would either faint or start yelling.
Red Hat extends RHEL5 and 6 support Posted Jan 31, 2012 20:33 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
I do exactly that with Debian on not-very-essential servers that can stay down for a couple of hours. Of course, with full backups before the upgrade (just in case).
Red Hat extends RHEL5 and 6 support Posted Feb 2, 2012 17:18 UTC (Thu) by zlynx (subscriber, #2285) [Link]
I'm not a Debian expert. I only ran it a bit because it had the best Itanium support.
I've seen a Debian version upgrade nearly destroy a system (well, it was a mess to figure out just what happened to it), just because I got the answers to some mysterious questions wrong. You know how the Debian packages, unlike Redhat packages, are allowed to interact with the console during installation. Argh. What a horrible idea. It's just like fsck asking if you want to reset inode 118182. Well? Do I?
Because Itanium is a niche architecture I was probably the first one to ever try upgrading that particular combination. But still.
If I had a production Itanium server running Debian I'd *never* try an upgrade on my only server. If I did I'd make sure to plan the downtime to include a full OS restore from backup.
So, Debian upgrade isn't much better than Redhat's process. It usually works but you cannot rely on it being perfect.
Red Hat extends RHEL5 and 6 support Posted Feb 2, 2012 20:55 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Well, you can force Debian to answer 'Y' to all queries essentially giving you braindead RPM behavior (-y switch). You can also script answers.
You can ran into bad situations with a major upgrade (it's major, after all). But it's quite rare these days and I don't actually feel any problems upgrading my computers.
Red Hat extends RHEL5 and 6 support Posted Feb 9, 2012 22:38 UTC (Thu) by filteredperception (guest, #5692) [Link]
"You know how the Debian packages, unlike Redhat packages, are allowed to interact with the console during installation. Argh. What a horrible idea. It's just like fsck asking if you want to reset inode 118182. Well? Do I?"
Mod quote up. As to the response that you can force Debian to answer Y, I request feedback that such is really true. 5 years ago, on whatever stable was back then (sid-1?), I spent literally many hours attempting such, figuring out which aspects of my install kernel cmdline I had to sacrifice due to character limits, in order to place the things there that alleged to achieve this 'force Y' mode. What I discovered, is that with 2 major avenues taken to try this, there were _still_ half a dozen packages that managed to thwart my attempt at a fully automated install. Eventually I managed to preseed, _explicitly_ the problem questions that affected my single case installset. But I never did find a solution to achieve this mythical 'force Y(thus allowing fully automated install)' mode. Now, I presume the half dozen I ran across were just packaging bugs, doing off-policy things. I hope to hear that in the last 5 years things are better. But it did strike me that I never had that problem with fedora/rh and kickstart, because of what I presumed to be a key differentiation between the rpm/dpkg world. Though note, I had run across some corporate annoying rpm which would use post-scripts to go unavoidably interactive. But I never ran into that with any typical routine stock fedora/rh installset (or in fact any installset I ever tried, which is a fair number).
Red Hat extends RHEL5 and 6 support Posted Feb 10, 2012 18:40 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
I wonder…how does dpkg react when /dev/tty is nothing and stdin is /dev/null?
Red Hat extends RHEL5 and 6 support Posted Feb 11, 2012 2:20 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
Things are certainly better.
Here's a nice overview on how to do preseed 'Debian way': http://blog.hjksolutions.com/articles/2007/07/27/unattend... We use Puppet and dpkg to manage Amazon EC2 clusters just fine.
Red Hat extends RHEL5 and 6 support Posted Feb 1, 2012 8:50 UTC (Wed) by niner (subscriber, #26151) [Link]
We do exactly this. Of course the whole upgrade process has been tried before in our virtual testing environment. We try it there, train it there and once it works flawlessly we announce a maintenance window and perform the upgrade on our production servers. And since we're running openSUSE on them we repeat this process about every year.
Red Hat extends RHEL5 and 6 support Posted Jan 31, 2012 16:41 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]
To be more specific, Red Hat "allows" upgrading but doesn't support it
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linu...
Anaconda however has the technical capability and customers do continue using it. However there are tons of customers who wouldn't want to upgrade often regardless of how smooth it is because they don't want to change what works for them. There is not enough data to support the claim that upgrade capabilities are anywhere close to a strong reason for the extensions. Validation of software and hardware for instance is a major reason.
Red Hat extends RHEL5 and 6 support Posted Feb 1, 2012 14:59 UTC (Wed) by charlieb (subscriber, #23340) [Link]
You can *try* to upgrade from RHEL5 to RHEL6 using anaconda (with 'upgradeany' switch), but you won't end up with anything like a RHEL6 system - if you are running 32bit at least. yum does not replace i386 rpms with a later i686 rpms, but that is what is required when upgrading RHEL5 to RHEL6 in-place. That's just one fundamental issue - there are probably other show-stoppers.
Upgrade vs. Clean Install? Posted Jan 31, 2012 18:05 UTC (Tue) by dowdle (subscriber, #659) [Link]
Minor upgrades (e.g. RHEL 6.1 -> 6.2) have always been painless for me. Major upgrades (e.g. RHEL 5.7 -> 6.2) have "major" in the name and as you pointed out, they are not supported.
Clean installs are MUCH BETTER. They might take more work (they might not) but the end result is better. Why, because the system is closer to a known state than an upgraded system would be. If one supports upgrades, how far do you take it? How much more cruft is there from having done two major upgrades... or three? It generally just gets worse over time.
All distros retire packages from one release to the next. The more packages there are, the more that get retired or replaced. Upgrades, even on systems that are famous for good upgrades, can be difficult when retired packages and/or third-party packages come into play. I have heard a lot of horror stories from users who have have done upgrades on distros that support them. I've also heard good stories. The difference seems to be how complicated the original was... with how many packages it had installed... and if there are any kernel hardware support regressions. On systems with a very low package count, the upgrade is more likely to go well. On systems with thousands (and some distros have or have had "install all packages" options), not so much.
I used to upgrade from one release of Fedora to the next. Now I just build my own remix (LiveDVD) with all of the software I want and updates applied... and do a clean install (retaining my data with a separate /home, a backup of /etc, /root, and any bits in /var I care about)... and it takes a small fraction of the time that a package-by-package upgrade does.
You also have to remember that RHEL comes out less frequently and the version changes can be quite large for some things... making it even harder to upgrade... and better to do a clean install. On the more rapidly released distributions, it'd be like starting at version X and then upgrading to version X+3.
While I'd like to wave a magic wand and just make all upgrades work perfectly, that ain't going to happen so I'll continue the clean install method. I have less problems that way.
If you don't like the way Red Hat does it, just consider it an opportunity for someone to come up with a process and the software to make it happen... to do major upgrades. I mean, it is possible... but no one has done it yet.
Upgrade vs. Clean Install? Posted Jan 31, 2012 18:27 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
I've been upgrading my trusty Debian installation on my server from Debian Woody to the latest Wheeze testing. The only major problem during upgrade was caused by grub->grub2 switch (which is understandable).
Of course, some packages got removed during the upgrades, but most often they could be replaced by other packages in a matter of minutes/hours.
So smooth upgrades are definitely possible. It's just that RedHat isn't really interested in them.
Upgrade vs. Clean Install? Posted Jan 31, 2012 18:55 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]
How many commercial ISV application did that installation depend on? The problem isn't necessarily what is in the repository which can be tightly controlled.
Upgrade vs. Clean Install? Posted Jan 31, 2012 20:31 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Several. And sometimes I had to reinstall/update them during the upgrade, that's fine and expected.
However, we have problems with RedHat upgrades on fully RedHat-supported systems without any 3-rd party apps.
Upgrade vs. Clean Install? Posted Jan 31, 2012 21:22 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]
Good for you but other have other experiences. Last time I did this, it broke several third party apps on a Debian box.
Upgrade vs. Clean Install? Posted Jan 31, 2012 23:09 UTC (Tue) by rijrunner (guest, #49442) [Link]
Here, you have to factor in target audience.
I did 10+ years at IBM where the customers were very much in the "If it ain't broke" set of mind. And just saying "Upgrade is not supported" essentially put upgrades off the table. They simply did not want to to do a fresh install and reconfigure apps. For *no* effort, they have a working system. For a lot of effort, they will eventually get the system back to the current level after an install. (And they invariably would never allow that to be on the same hardware.) When you are running a full HA environment, you simply can not afford the downtime.
There are different layers of support and requirements. The ability to just re-install and pull in configs is a lot simpler when you have what amounts to appliance software. You run a webserver and need to upgrade. OK. That is mostly just files in a directory structure. But, try an HA environment where you are not allowed downtime, then interlink supported databases, OS versions, etc, etc. A supported minor revision upgrade path can be justified. But, a major one? There had better be a world ending reason for that. In most cases where this occurred, the ones who went through with an OS version step generally bought hardware. If they could not justify that expense, they did not do anything.
But, the more complex the system, the harder it is to do. So, your statement of "while I would like to wave a magic wand" is why this is getting extended.
Red Hat extends RHEL5 and 6 support Posted Jan 31, 2012 18:13 UTC (Tue) by epa (subscriber, #39769) [Link]
Put your system configuration under version control, build your software as RPM packages, and force yourself to do a clean install at least every six months to check it still works. Otherwise you are balancing precariously on top of a decaying pile of cruft which has accumulated on the disk of your server.
Well, this finally brings RHEL to the Windows level... Posted Jan 31, 2012 18:43 UTC (Tue) by khim (subscriber, #9252) [Link] The question "will this ever stop?" is interesting one but so far thus extension only gave users what Microsoft provided all along (as I've pointed out years ago). I know it's hard for the "let's redo everything twice per year" crowd to believe, but 10 years support is industry standard, so... yes, kudos for RHEL team, but don't forget that they have just finally done what they were expected to do from the beginning.
10 years is indeed industry standard Posted Feb 1, 2012 9:49 UTC (Wed) by rvfh (subscriber, #31018) [Link]
Isn't it what's required by automotive too? As Linux is trying to invite itself in the 'infotainment' system of cars, 10 years support might become the norm for some distributions... and I mean non-server, multimedia-oriented distributions.
10 years is indeed industry standard Posted Feb 2, 2012 16:40 UTC (Thu) by jmalcolm (guest, #8876) [Link]
Embedded in general is an interesting point. As you say, the support window might have to be as long as the expected, supported, or even regulated lifetime of the hardware. RHEL is obviously not an embedded solution though. So, the implications of a ten years support commitment here is in the context of enterprise use.
Red Hat extends RHEL5 and 6 support Posted Jan 31, 2012 21:34 UTC (Tue) by lkundrak (subscriber, #43452) [Link]
What's wrong with 2.2?
Red Hat extends RHEL5 and 6 support Posted Feb 1, 2012 3:15 UTC (Wed) by jmalcolm (guest, #8876) [Link]
Although I agree that ten years is a long time but there is nothing wrong with wanting to just let a server run as long as it continues to do the job. Besides, running Red Hat 5 is not like dusting off your old Ubuntu Feisty Fawn (7.04) CD to install on your server.
Red Hat does a pretty good job of modernizing the hardware compatibility with their point releases. For example, Red Hat 4 was first released way back at the beginning of 2005 but continues to get updates. An up-to-date Red Hat 4 machine loads Intel microcode from late 2010 and has specific support for Xeon Nehalem hardware. Nehalem itself first appeared in 2008.
The same holds true for things like file systems and the virtulization infrastructure. KVM was first included in the 2.6.20 kernel but it is fully supported in up-to-date versions of Red Hat 5. The Red Hat 5 kernel reports as 2.6.18.
The trend of running instances on a VM will make it even more desirable to get support for old versions. For example, why would I want to mess with an instance of Red Hat 5 in a VM that is reliably serving up some internally developed web application? Why not move it as is even when I upgrade to newer hardware? Why risk breaking something? But just because I do not want to mess with it does not mean that I do not appreciate/need things like security updates or updated admin tools.
Red Hat extends RHEL5 and 6 support Posted Jan 31, 2012 16:19 UTC (Tue) by ssam (subscriber, #46587) [Link]
10 more years of Gnome 2.
Red Hat extends RHEL5 and 6 support Posted Feb 1, 2012 7:10 UTC (Wed) by ssmith32 (subscriber, #72404) [Link]
Actually, that would suit me just fine :D
Red Hat extends RHEL5 and 6 support Posted Feb 1, 2012 11:22 UTC (Wed) by miguelzinho (subscriber, #40535) [Link]
I have being a Debian guy for the last 7 years. Having a decent Gnome 2 environment makes me seriously consider CentOS 6 now. I simply can't stand looking at Gnome 3 and even more Unity.
Gnome Posted Feb 1, 2012 13:29 UTC (Wed) by marcH (subscriber, #57642) [Link]
I do not understand why so many people feel like they have to use Gnome - at all. Even if Gnome 2 was the best user interface ever (and I seriously doubt that), surely at least one among the many alternatives is not as good but good enough to do the job.
Gnome Posted Feb 1, 2012 16:00 UTC (Wed) by mpr22 (subscriber, #60784) [Link] One does not have to think it's the best ever. One merely has to think it's better than the others that exist - or at least, not sufficiently worse to justify changing. (I'm not keen on Gnome 2 - I tend to use LXDE - but Unity sounds like it's optimized for displays rather less pixel-rich than my home PC's 1920x1080 flat panel, and I haven't heard anything particularly convincing said about Gnome 3.)
Gnome Posted Feb 1, 2012 17:16 UTC (Wed) by marcH (subscriber, #57642) [Link]
What you seem to have missed is: some people want to upgrade their distribution. This is the reason why they lose Gnome 2 - not like they want to change.
Gnome Posted Feb 2, 2012 17:23 UTC (Thu) by jmalcolm (guest, #8876) [Link]
> I do not understand why so many people feel like they have to use Gnome - at all.
As a huge fan of GNOME 2, I mostly agree. Consider that you can configure XFCE to look and act almost identical to GNOME 2 and it ships pretty close to this way in many distros. It is also built on almost the same technology, much of it from GNOME itself. Examples include GIO, GVFS, libnotify, pango, gstreamer, GDM, nm-applet (NetworkManager), ATK, and of course GTK itself. LXDE is much the same.
I realize that other desktops, like XFCE, theoretically come with a whole other suite a programs but gnome-terminal, nautilus, evince, brasero, totem, and the like are right at home under these GTK environments. Even things like panel applets and notifications work just fine. I have not heard any GNOME fans complaining that they hated the GNOME 3 apps and switching "desktops" does not have to mean giving them up.
The laptop I am writing from right now is running LXDE on Debian (old laptop). The open applications on my desktop right now are Evince (GNOME 3 version), gcalctool, Aurora (Firefox), Transmission, MonoDevelop (boo hiss I know), and Terminal (XFCE). These are all GTK apps. If I was sitting at a GNOME 2 box, I would likely be running the same stuff.
Conflicted feelings Posted Feb 1, 2012 2:55 UTC (Wed) by dskoll (subscriber, #1630) [Link] I don't use RHEL. But if I were a RHEL user, I'd be very happy with this announcement. A long lifetime helps with planning. I am an ISV and have conflicted feelings. It's nice to have a long-supported platform. On the other hand, our customers are going to expect to be able to run our latest and greatest product on an ancient operating system, and that can be a real pain. It means we need to write our product to the lowest common denominator of libraries, PostgreSQL versions, etc. We already have product features that are not available in older versions of RHEL and keeping the building and testing sane is really annoying.
Conflicted feelings Posted Feb 1, 2012 3:38 UTC (Wed) by jmalcolm (guest, #8876) [Link]
While I can appreciate the pressure that ISVs feel, there is no reason that a given ISV has to support the "latest" version of their software on an older version of RHEL. What is more important, I think, is that they continue to support the version that is already successfully running on that old RHEL version.
After all, even Red Hat is not supporting all "their" latest software on old RHEL versions. There are features available in RHEL6 that I cannot get/use in RHEL5. To get them, I have to upgrade the OS.
Conflicted feelings Posted Feb 2, 2012 0:33 UTC (Thu) by jospoortvliet (subscriber, #33164) [Link]
use SUSE Studio and sell your product as a self-contained VM or image easily installable on bare hardware... Seriously, you're exactly the target group for that. www.suse.com/products/susestudio/ and susestudio.com for a free testdrive :D
Conflicted feelings Posted Feb 2, 2012 19:56 UTC (Thu) by dskoll (subscriber, #1630) [Link] We already sell our product as a self-contained image (based on Debian), but some shops insist on RHEL because they're accustomed to the RHEL administration tools.
RHEL 7 will be long-time coming ? Posted Feb 1, 2012 6:30 UTC (Wed) by gk22 (guest, #82679) [Link]
Given that Red Hat generally releases RHEL version N when version N-2 is close to becoming unsupported, the new 10 year support would imply that RHEL 7 will be (very) far off.
To whit, RHEL 5 was released early 2007. So, no RHEL 7 before 2016 ?
While this is a simple extrapolation, there are also other good reasons for it: Red Hat has a finite amount of engineering resources, meaning that it can only support a finite number of releases at any one time.
I can imagine that backporting features and drivers to ancient kernels like 2.6.18 (in RHEL 5) takes a great amount of effort, time and testing. While the kernel in RHEL 6 is still relatively recent (2.6.32), the upstream kernel is naturally diverging more and more, meaning it will take more effort to keep RHEL 6's kernel "modern" (while maintaining the API and ABI compatibility that RHEL customers love).
By having RHEL 7 so far off in the future, Red Hat risks looking rather out-of-date, with more nimble competitors (commercial or otherwise) being able to more easily overtake it with newer features that cannot be backported (eg. stuff that's too invasive, risking stability). There's also the question of a stale user-space. I certainly don't want to be using gcc 4.4 in 2016 (things like support for the new C++11 standard come to mind), or gimp 2.6, etc.
RHEL 7 will be long-time coming ? Posted Feb 1, 2012 12:42 UTC (Wed) by nim-nim (subscriber, #34454) [Link]
I'd assume that Red Hat now earns enough money to pay a separate team to maintain each long-term release, while keeping its primary team on the next one.
Anything else would mean slow Solaris-like fading-into-irrelevance of RHEL, as resources are pulled from the next version to maintain old versions (always for good reasons, except that attrition accumulates over time).
RHEL 7 will be long-time coming ? Posted Feb 1, 2012 13:33 UTC (Wed) by marcH (subscriber, #57642) [Link]
I guess it's much more efficient to assign employees to specific software areas across all their different releases.
RHEL 7 will be long-time coming ? Posted Feb 1, 2012 13:35 UTC (Wed) by marcH (subscriber, #57642) [Link]
"invasive" and "risking stability" are not frequently used keywords in the server space.
RHEL 7 will be long-time coming ? Posted Feb 1, 2012 17:09 UTC (Wed) by raven667 (subscriber, #5198) [Link]
Honestly though I can't even think of a feature that RHEL6 2.6.32 doesn't have that I could want and the performance is great so there just isn't much pressure to upgrade. The kernel is a very mature project now so if there were no changes except for driver updates and bug/security fixes that would be just fine by me. Even RHEL5 2.6.18 runs just fine, the only feature I've needed that it doesn't have is IPv6 statefull packet filter support.
It's actually kind of silly that there was talk about dropping 2.6.32 stable support from kernel.org as this kernel is going to be shipping for another 10 years. Each vendor is going to be doing their own maintenance, it'd be a shame if that work wasn't coordinated and pooled through kernel.org.
Linux distributors, as a matter of tradition, make no real separation between the base system OS and all the applications and support libraries which I am starting to believe was a mistake. The kernel is good enough and the base userspace is good enough that there really isn't much upgrade pressure but you always need new libraries to run new software which can be a pain to support. Developers love to track the most current versions of the libraries they use and get all surprised when their software doesn't run on an Enterprise distro because it isn't tracking HEAD of libfoo. Then you have a problem. This has been fixed for some software, like web browsers but this fix could probably be applied to other parts of the system as well.
RHEL 7 will be long-time coming ? Posted Feb 2, 2012 17:33 UTC (Thu) by jmalcolm (guest, #8876) [Link]
At this point, Red Hat is a large and profitable company. I doubt that the resources required to support this move are onerous for them.
After all, they seem to have enough spare engineering bandwidth kicking about to create their own programming language:
Remember, RHEL is their core product and they will have deep expertise in it by the time a version has been out that long. Another thing to consider is that they already offer extended support today. For example, you can pay for three more years of RHEL 4 support right now. So, this announcement might have more to do with messaging and positioning than it does with additional investment in the long-term support infrastructure.
Red Hat the new Sun? Posted Feb 1, 2012 11:55 UTC (Wed) by paulj (subscriber, #341) [Link]
Sun made lots of money from large customers who didn't want to change things and were willing to pay mega-bucks. This is quite a good thing in the mid-term for a company - it's really nice to have a reliable cash-cow. There is also a danger though, in that your organisation can become dominated by the needs of those ultra-conservative, special customers and become very conservative itself, and blind or even dismissive of the next big thing.
|
|||||||||||||