Red Hat Enterprise Linux Extended Life Cycle Support [LWN.net]

Red Hat has announced Red Hat Enterprise Linux Extended Life Cycle Support (ELS), which allows customers to continue use of Red Hat Enterprise Linux (RHEL) major releases such as RHEL 3 beyond the regular 7-year life cycle. "Available as an add-on option, Extended Life Cycle Support complements the customers in-place Red Hat Enterprise Linux subscription and is available in single-year subscriptions that allow customers to extend the total use of given major releases by extending the overall supported life cycle from 7 years up to a total of 10 years. This new offering requires the customer to have an existing RHEL subscription with equivalent subscription terms and support level."

to post comments

Red Hat Enterprise Linux Extended Life Cycle Support

Posted Aug 20, 2010 19:38 UTC (Fri) by jspaleta (subscriber, #50639) [Link] (13 responses)

Otherwise known as the "From My Cold Dead Hands" server support option.

We are on track to seeing _supported_ RHEL 3 installations with lifespans of 20+ years. That's both a scary and amazing prospect to think that people want to keep servers in operation that long...and that the service model being used by Red Hat makes it possible for customers to choose to pay for such extended service out to 10 years or more instead of migrating to a newer platform.

I wonder are the customers who need to keep RHEL 3 systems in production for 10+ years looking to migrate them to virtualized instances of RHEL 3 running on top of a newer Host OS to extend the in-service lifespan of their production RHEL 3 instances indefinitely across hardware refreshes?

-jef

Red Hat Enterprise Linux Extended Life Cycle Support

Posted Aug 20, 2010 19:53 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

Yes, indeed. This is one of the major reasons for customers to be interested in virtualization. Hardware that is currently running RHEL 3 won't usually perform well with Xen or run at all with KVM and moving from bare metal to VM is not as smooth as it could be and there is less interest in disrupting what works. However newer systems being deployed on RHEL 6 or RHEV could run older versions under a VM letting customers abstract themselves away from hardware (and software) changes to a good extend.

Red Hat Enterprise Linux Extended Life Cycle Support

Posted Aug 20, 2010 19:57 UTC (Fri) by zlynx (guest, #2285) [Link] (6 responses)

Over those time scales, I wonder how closely RHEL 3 can approach "perfection."

No known bugs, no known exploits, no new features to disturb things...

Red Hat Enterprise Linux Extended Life Cycle Support

Posted Aug 20, 2010 20:07 UTC (Fri) by tzafrir (subscriber, #11501) [Link] (1 responses)

Except for bugs in the backported code to support newer hardware and such?

Red Hat Enterprise Linux Extended Life Cycle Support

Posted Aug 20, 2010 20:30 UTC (Fri) by blitzkrieg3 (guest, #57873) [Link]

There is no hardware enablement.

Red Hat Enterprise Linux Extended Life Cycle Support

Posted Aug 20, 2010 20:33 UTC (Fri) by cesarb (subscriber, #6266) [Link] (2 responses)

> Over those time scales, I wonder how closely RHEL 3 can approach "perfection."

The problem is that the environment around it changes.

Today's hardware is more powerful and today's software is more advanced. People expect these capabilities, and do things that depend on them without noticing. Older hardware and software (living in the past) will have more difficulty dealing with them as time goes on.

For example, some time ago the standard screen resolution was 640x480. Today's standard resolution seems to be 1366×768. Because of this increase, people tend to create larger images, which need more memory, which modern systems have. For older systems, this means increased memory pressure.

As another example, modern browsers (except perhaps IE6) have many more capabilities than older browsers. People start depending on these capabilities when creating web sites, making it more likely that it will not work on older browsers.

You can find these sorts of examples at all levels of the stack. How well will RHEL 3 deal with IPv6-only networks after IPv4 is exhausted? Will the increasing use of DNSSEC uncover some long-fixed (in newer versions only of course) bug on bind? And, showing that environment changes can happen even outside the network, how would an older server deal with an increasing amount of users on a growing company?

It is a Red Queen's race - if you want to remain in the same spot, you have to keep runing.

IE6 != modern browser

Posted Aug 20, 2010 21:12 UTC (Fri) by dwheeler (guest, #1216) [Link] (1 responses)

I don't know anyone who thinks that IE6 is a modern web browser. Widely deployed, sure, but that's not the same thing.

IE6 != modern browser

Posted Aug 20, 2010 22:30 UTC (Fri) by cesarb (subscriber, #6266) [Link]

It is if you compare to Netscape 4. The modern way of doing things (document.getElementById and friends) has a chance of working with IE6, but IIRC will not work at all with NS4.

We ARE talking about really old software, after all ;-)

Red Hat Enterprise Linux Extended Life Cycle Support

Posted Aug 20, 2010 20:46 UTC (Fri) by jengelh (subscriber, #33263) [Link]

Scary are the exploits not yet publicly known.

Red Hat Enterprise Linux Extended Life Cycle Support

Posted Aug 20, 2010 22:12 UTC (Fri) by arjan (subscriber, #36785) [Link] (4 responses)

The 2.4 kernel that would not die.

Nice to see that someone at least is stepping up to do security maintenance for 2.4 kernels still.....

Red Hat Enterprise Linux Extended Life Cycle Support

Posted Aug 20, 2010 22:40 UTC (Fri) by dlang (guest, #313) [Link] (3 responses)

I really doubt that they are doing any research, they will probably look to fix things that are pointed out to them (unless it's too hard)

for example, the recent fix for a bug that's been in every 2.6 kernel, did anyone report if it's in a 2.4 kernel?

Red Hat Enterprise Linux Extended Life Cycle Support

Posted Aug 20, 2010 23:15 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (2 responses)

It's OK, the most realistic way to trigger that bug is X.org, and that's a desktop feature. Extended Life Cycle Support excludes the desktop. Well, how many people do you know who seriously have an RHEL 3 desktop in 2010? Right.

Red Hat Enterprise Linux Extended Life Cycle Support

Posted Aug 20, 2010 23:43 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

Desktop packages are excluded but that does not include Xorg

http://www.redhat.com/rhel/server/extended_lifecycle_supp...

Red Hat Enterprise Linux Extended Life Cycle Support

Posted Aug 21, 2010 14:48 UTC (Sat) by tialaramex (subscriber, #21167) [Link]

Ah. Thanks for the correction.

Red Hat Enterprise Linux Extended Life Cycle Support

Posted Aug 20, 2010 23:13 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (10 responses)

This was not unexpected, RHEL 3 had only a couple of months left. Check out the historical behaviour of Microsoft regarding sunset dates for their operating systems. There are always stragglers who find that, whoops, they aren't going to upgrade before the sunset date and it can be very profitable to take their money if you have the manpower to support them, just as companies with a cash surplus can make money from credit terms on customers who always pay but aren't very good at paying on time (whereas a small company will go bust if it has such customers)

The timing is interesting. Evidently either Red Hat wanted 2.1 dead, or customers don't care too much about it. Either way, it was allowed to expire while RHEL 3 gets this new "extended life". It isn't much of a life, for what it's worth. Further restrictions apply compared to the existing "phase III" support, with less software getting patched and less platforms supported. The focus is definitely on commodity servers running stuff like Apache or sendmail.

Red Hat Enterprise Linux Extended Life Cycle Support

Posted Aug 20, 2010 23:21 UTC (Fri) by drag (guest, #31333) [Link] (6 responses)

People who are using commodity stuff probably moved on. People wanting to extend RHEL 3 support into the future probably have custom/proprietary software that is too costly to upgrade for one reason or another.

In these cases they probably have sufficient in-house expertise to manage the software that runs on top of RHEL so they are not interested in that level of support, but they want to maintain a efficient division of labor were their in-house folks are able to concentrate on supporting the applications while they can depend on Redhat to help with the OS (software that is bundled with the OS counts as part of the OS in this scenario). That is it's more cost-effective for them to pay Redhat to support the OS stuff then have their admin's valuable time spent doing anything other then babysitting the software running on top of it.

That's just a guess. I know it's certainly true for many of the bigger corporations, but I wonder how true that is in general.

Red Hat Enterprise Linux Extended Life Cycle Support

Posted Aug 21, 2010 12:49 UTC (Sat) by tialaramex (subscriber, #21167) [Link] (5 responses)

Yeah, good point, commodity OS running custom stuff that has in-house support is also a plausible thing to support this way. I think I'm a bit scared of any in-house project that can't track OS upgrades well enough to be known to work on RHEL 4 by now. It makes me think of anecdotes where people have lost the source code and now get along by patching the disassembler output...

Such cases are more common they you may think...

Posted Aug 21, 2010 14:14 UTC (Sat) by khim (subscriber, #9252) [Link] (2 responses)

I know a guy in Intel who worked with some [unnamed] customers on PDP-11 emulation for Itanium. They had some legacy software which was almost impossible to change (even if you have source it's not easy to port the software for such an old platform) so they just used an emulator and needed help to make it faster.

As you can guess such support directly from Intel does not come cheap - but they were willing to pay for it rather then pay for the port to modern architecture.

It'll be interesting to see of RHEL3 will ever reach such a state...

Such cases are more common they you may think...

Posted Aug 22, 2010 9:52 UTC (Sun) by epa (subscriber, #39769) [Link] (1 responses)

What's amazing is not that such old software is still running, but that given the huge increases in performance between a PDP-11 and today's hardware (even allowing for a 1000x slowdown caused by emulation), it still isn't running fast enough!

Actually there are no 1000x slowdown...

Posted Aug 22, 2010 13:01 UTC (Sun) by khim (subscriber, #9252) [Link]

You only get 1000x slowdown when your emulator is exceptionally stupid. If it's simple interpreter it's more like 100x and if it's optimized JIT it can ge between 10x and 2x.

And yes, it means the software runs much faster then it ever did on original PDP-11, but then datasets are bigger today too...

Red Hat Enterprise Linux Extended Life Cycle Support

Posted Aug 21, 2010 15:07 UTC (Sat) by NAR (subscriber, #1313) [Link]

Software projects can move around in multinational companies between R&D centres. In a transfer like this 50-75% of knowledge is lost (of course, some of the knowledge is rebuilt later). Imagine the expertise of the maintenance developers of product that has been transferred to the third continent in 5 years time... Cases like these call for extended OS support.

Red Hat Enterprise Linux Extended Life Cycle Support

Posted Aug 21, 2010 15:47 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

I know a project which runs on Linux 2.2 kernel (helped to migrate it to VM) which controls custom hardware (yay for IOMMU!). This software doesn't use networking or anything complicated and it generates several million dollars of profit each year.

And there's no sense in updating it, because it'll be useless in 3-4 more years when the hardware finally fails.

Red Hat Enterprise Linux Extended Life Cycle Support

Posted Aug 20, 2010 23:29 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

You claimed earlier (http://lwn.net/Articles/351306/) that only crippling problems would make Red Hat change it's release support cycle and that is now shown to be not that case.

Even before this announcement, Red Hat has always done this on a ad-hoc basis (Announcement preceding EOL telling customers to contact sales for more details) and although I don't have any internal information, I would assume RHEL 2.1 is supported for some customers still. Red Hat already had a mission critical program with 10 year support

http://www.redhat.com/promo/mc_program/

This seems a extension of it rather than a completely new effort.

Red Hat Enterprise Linux Extended Life Cycle Support

Posted Aug 21, 2010 1:06 UTC (Sat) by tialaramex (subscriber, #21167) [Link] (1 responses)

What I wrote, as you can see from your own link is,

The existing lifespan numbers are a commitment, nothing short of crippling financial problems would induce Red Hat to break it, but they don't prevent commercial interests from dictating an extension, even a very long one.

I'm not really sure how (short of just not being a fluent English speaker) you could understand this statement to now be disproven. Red Hat is still providing the 7 years it committed to, and now also offers an extension. Should I have also predicted what it would be called?

If I say "Yes, I will feed your goldfish for one week" and then your flight is delayed and you ask if I can now feed them for 10 days and I agree, I have not broken a commitment. Quite the contrary.

Red Hat Enterprise Linux Extended Life Cycle Support

Posted Aug 21, 2010 1:08 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

Yep. Sorry, misread your comment.

Red Hat Enterprise Linux Extended Life Cycle Support

Posted Aug 21, 2010 16:59 UTC (Sat) by dag- (guest, #30207) [Link]

I reported on this yesterday as well:

Is 10 years of RHEL support still sufficient ?
http://dag.wieers.com/blog/is-10-years-of-rhel-support-still-sufficient