Slashdot Mirror
Red Hat Announces Product EOL Calendar
BrunoC writes "Looks like Red Hat is getting a little Microsoftish and is quietly introducing its brand new 12-month-only Errata. Quoting The Reg: 'Red Hat's current death list EOLs RH 7.1-8.0 at the end of this year, while 6.2 and 7.0 get theirs as of the end of March.' You can read the whole article here." I don't see how this is "Microsoftish" -- the code Red Hat creates or includes is still GPL, and you can pay anyone willing to fix it. They're not required to support it forever :)
Agreed, just like Microsoft shouldn't be forced to support old products like Windows98 or Office97.
Microsoft also still makes available all the online information (MSKB) for the discontinued OS's.
And its a bit different with redhat, most of the components of old redhat releases are current projects still making releases, theres nothing stopping you from doing the upgrade yourself, chances are if you cant you can prob get your slightly geekier friend to compile and rpm it for you. With windows, think someone is still working on the windows 3.1 version of the networking components?
Jesus saves, everyone else takes full damage from the fireball.
"I don't see how this is "Microsoftish" -- the code Red Hat creates or includes is still GPL, and you can pay anyone willing to fix it. They're not required to support it forever :)"
I think the more important question is. Why is everyone so gung ho about seeing every RH action as "Microsoftish"? As many have already argued RH couldn't be another Microsoft. Has Microsoft scared us all so bad that we jump at the slightest movement by a commercial company? What about all the other commercial companies out there? Aren't they doing something "Microsoftish", or is it just RedHat?
This ISN'T microsoft-ish. Microsoft atleast supports their products for a little while. What this is, is a company screwing the living hell out of the community that's supported it. I've sat here and sold personal version after personal version alot with errata accounts to clients because a) cheaper b) would be supported for quite some time with good security updates and wouldn't always require upgrades to continue to use their other products.
/. apparently didn't like). I've started installing Gentoo on my workstations here already and within the next 4 weeks my redhat boxes will be gone as well.
Now I have to turn around and tell them that Redhat changed it's game plan and convert each one of these clients over, or let them continue to pay me to constantly upgrade their network just to keep them within their errata entitlements. I for one....basically said to hell with redhat about 5 hours ago (incidently right after I submitted my story that
Face it people, the people like "us" have made redhat and they just turned their back on us for the corperate world.
Don't get me wrong, I have NO problem with end of life, but 1 year for what's there now. The woman I spoke with at Redhat (yes I did research it directly with the company not just reading what nimrods say) she said that after this first round, there's going to be another change. Anyone using personal or the "free" version (and probably the professional) will ONLY be eligable for errata during the time that the release they are using is current. As soon as they release another version, errata for the older is gone. In other words, since redhat releases usually twice a year....that would me 2 upgrades a year just to keep yourself up2date. Screw that.
Why not tie the EOL for redhat desktop products to the vailidity of of the RHCE for it? For corporates, its going to be very hard to get approval for certification training if you know the EOL of the product is less than the period of the certification (I recall the figure of 2 major releases being mentioned by the instructor). This could damage RedHat's rep in the training market (one of their key publicity points in the last few years).
I'm surprised that people are still running RH6.0. It's far less secure than 7.x or 8.0. The desktop (and server environment) are much better as well. Sure there are some libc5 legacy apps but there's really no excuse for a server to be running it. Upgrade or do a fresh install and use the newer features (like journalling, LVM, iptables, 2.4 series kernels etc) because they make an immense difference. RH7.2 really should be a minimum if you are serious.
You mean we can't download a free product and suck down bandwith from the company for the rest of our lives?! REVOLUTION! Maybe some people haven't noticed but Mandrake who we thought was doing great is all but dead, how Redhat pays thier bills I have no idea. Look people, It's time we allow some of these open source companies to ern some money, they have done alot for us and are still doing more than just about any other company. The only companys I can think of off the top of my head that do more for the people are charitys and ones funded by tax dollars. The only thing I would ask is that, when I buy redhat 7.3 the errata will last untill redhat 8.3. I look at everything inbetween as a sort of beta software, I have no problem spending $50 every year and a half, but not every 6 months.
-- "of course thats just my opinion, I could be wrong." --Dennis Miller
http://www.redhat.com/licenses/rhlaws_ita_us.html? location=United+States&
especially the report and auditing section.
I support a lot of redhat machines.I appreciate that they ahve to make money and all, but really. I don't call them and ask for support. i don't use the RHN. i run a mirror.
I did call once and ask for support...I got tossed back to HP!
-- Who is the bigger fool? The fool or the fool who follows him? --
..and is quietly introducing its brand new 12-month-only Errata.
"Quietly??" Hardly. I've received notice of this at least three times in the past couple of months from various RH newsletters. I even considered writing to let them know I had gotten the message. It's been on their errata web page for over a month (at least since 8.0 has been out).
I guess this shows you CAN'T count on people to get the message unless you beat it into them, or perhaps this whole article is a RH troll to actually get the message out??
I now expect to receive several other explanatory e-mails from RH after this slashdot article.
It's not like they're killing you because you need to pay $$$$ to upgrade to RedHat 2005. All you need to do is download the new version and upgrade. I do think a year is kind of short ... Like someone said maybe they should support at least the last mayor release.
... 4.7? 4-stable? I don't see them recommending 4.4 to anybody right now, even though it was pretty stable. 4-stable is the recommended Server software until what ... 5.2?
I mean, how does FreeBSD do it? Do "they" fully support 4.0?
In this case, the question is, how long do you give support for a product so that your costumers feel that the upgrade will be stable, after all, it's not like they _have_to_ request PHB for a few grand to upgrade.
All I can say is good for RH, but I would have thought a "previous major version support" would have been better.
Then again, you can always just get the latest stable version of whatever software you need so much (apache? sendmail? vi?). And in the case you're building a new system, why not install the latest stable distro version anyway.
I do understand that people have different requirements, so there are exceptions to everything. I mean, you can always do your own RedHat 5.0 support department if you wish.
cl
Reply . . . let's get it over with.
But the RHCE program is geared towards this same "consumer" release. Current RHCE is for Redhat 8.x version and you have to get recertified every other (consumer) major release number. So, what good is RHCE? You get certified to run your home Linux box then?
Actually this may explain why RedHat is doing things this way. If major apps require old versions of RedHat then that would, all by itself, force a lot of people to refrain from upgrading - even if they would like to. Even worse if different apps require different versions then that is going to seriously undermine the value of the RedHat Distro.
By limiting support to a small number of versions they encourage vendors to keep up with more recent releases of Redhat, and make it more likely that all the major apps will actually work on one of those supported versions.
Amen, and this is the argument I threw at my RH account rep. We currently pay a few grand annually for RHN enterprise and I am very happy with it. But if RHN stops offering errata after just one year, it's utility goes away from me and hence I'll stop paying for it. I'd bet others in my shoes will do the same thing. I'll either have to switch to another distro or start hand patching systems or just switch to Windows Server (well, hmm, I'm not *THAT* pissed off... :)
It was the availability of a cheap base price and an affordable RHN subscription that got me the green light to replace our NT servers with Red Hat servers. I expended a lot of political capital making arguments about savings in maintenance and deploring the Microsoft upgrade treadmill. Management was suspicious but in the end trusted my judgement as the "expert" opinion.
I'm going to look like a fucking asshole if red hat puts us on the same high cost / upgrade treadmill program that I convinced everyone we were getting out of.
Note to red hat: continue to provide an affordable RHN subscription and don't force us to upgrade our servers every 12 months. If you do, during one of those upgrade cycles, you will find yourselves alongside MS in the dustbin, and we'll move to another distro. Or, worst case scenario, management will no longer see the monetary benefit and decide to return to the comforting familiarity of Microsoft's eager clutches, and I'll be "that dick with no sense of judgement" for the rest of my career.
pr0n - keeping monitor glass spotless since 1981.
This new policy dramatically increases the cost of maintaing Red Hat Linux in any business computing environment. I have RH machines with uptimes longer than 12 months.
Given that Red Hat has 6 month release cycles, a lot of people are going to find themselves with software that is to be EOL'd six months after it was installed, when at the time of installation it was the latest and greatest version.
I'm very partial to Red Hat Linux, but this new policy makes me rethink my opinion.
What has *science* done?!? -- Dr. Weird (ATHF)
I thought this was supposed to be a pro-linux site?
Timothy completely missed one of the key points - that the "advanced server" version has a 3 year support plan. Its still not great, but to have "Redhat announces 12 month only errata" (or words to that effect on the front page of Slashdot is just going to give Redhat a bad name with the casual observer. We all know how few people actually RTFA...
smash.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
It's suprising that some folks are just now finding this out. I noticed this a while back while trying to get a decent fix for the fubar xinetd package Redhat is pushing on its pre-8.0 distros.
I was really suprised by this since a long lifespan is the one thing that RedHat had over Mandrake (Mandrake's product lifespan is 2 years from date of initial release..) I don't know about the rest of you, but I have servers running right now with 2 years of uptime..some are in the same city as me, some are colocated in other cities. I can't upgrade these systems without either flying to the colocation site or having them mailed to me.
I came to precisely the same conclusion as the folks in this article. If you're using Linux on a server, it's stupid to use anything other than Debian. The commercial distros NEED you to upgrade, whether or not there are any compelling new features in their new versions. The Debian developers could care less about you buying a new set of CDs every six months.
It's pretty funny that RedHat seems to be following right in Mandrake's footsteps here. It will be a great boon for virus writers if they really do drop support for all those 7.2 installs out there...but I can't imagine that serious sysadmins will put up with this for very long.
Red hat is doing this because they don't have the resources to support 6 different versions of their O/S full time. These are just errata updates. If having the errata (security, bug fixes, performance issues) is important enough to you that you're going to care, then you can:
(1) Download the latest RH and buy RH support for it (because this is really just about support),
(2) Hire your own admin to stay abreast of these issues, or do it yourself. (But this is why people pay for RH service, so this isn't a likely option, or
(3) Contract out to another company to step in and do errata updates on EOL'd RH distributions. It's legal, but probably expensive, unless a bunch of people band together to do it.
Anyways, as the argument goes for contributing back to the linux codebase . . . It doesn't make any sense for a company to update programs without trying to get their updates put back into the codebase. Same thing is going on here. It doesn't make sense for RH to back-patch all of these older programs just for errata updates. Too much time and effort that could be spent on the real task: creating more advanced and better working programs. You don't see many people doing updates to Linux Kernel 2.0.39 these days, do you? Wonder why that might be. . .
Karma: Not Particularly Funny.
But it seems like a really stupid move to me.
Isn't RedHat trying to woo big corporate/enterprise accounts? From what I know of the corp/enterprise attitude (admittedly not a lot), they don't wnat to have to upgrade the whole OS on a yearly basis in order to stay up to date.
I do realize that the packages themselves will very likely be upgraded and that any admin can go get them and apply the updates himself, but isn't up2date and its associated collection of updates in one easy to find place one of the biggest selling points?
How is RedHat not shooting itself in the foot on this one? Someone please explain it to me, I'd really like to know.
Information doesn't want to be anthropomorphized anymore.
You missed one category:
3) Educational users: upgrading our servers is also a pain. We do it as little as possible. Our main server is still running 6.2. I am in the process of replacing it with an 8.0 server, but it takes a lot of time. We cannot afford Advanced Server. We are going to be left out in the cold.
I do support Red Hat however I can. I buy RH Pro for each release. That is about the limit of our budget.
Linux distributions are a collection of three primary factors, and a number of secondary. The primary factors are;
Emphasis on #2. Like most other distributions, RedHat maintains their own custom packages for their software applications. That's why each distribution will in-turn address security updates on the likes of BUGTRAQ; each of them is distributing their own RPMs/DEBs/TGZz/etc. to fix the problem. That's what RedHat is ceasing; support for their custom software RPMs.
You'll always be able to download/install the latest kernel, be it via RPM, SRPM, or sources from kernel.org; I don't believe that's an issue in the slightest.
Once you've upgraded all the packages to their current level, all that's left are the few packages (Base layout, package management interface, etc.) that comprise the "OS". If you require support but RedHat declines it on this basis, simply apply the updates and call them back.
The high school I worked for had testbed systems. They're just common-sense. When you're deploying mission-critical, or even just important updates to a system, it's always adviseable to test it first. Be it a server upgrade or a workstation image, it's just good business practise to test it before you put it live.
The advantages to spending the money preemptively and having a solid software update policy in effect will save the company countless dollars, man-hours and heartache when and if that policy would have helped the most - in the case of an intrustion or major software meltdown.
BTW - Even when RedHat christens a newly released RPM that upgrades an existing package, it should be standard policy to test this upgrade on a testbed before putting it live, so the extended product life cycle won't do you any good anyways; damage done is money lost.
A testbed server doesn't have to be some kind of elaborate, highly-involved process. Essentially, you keep a 'good' image of the install base, else simply a mirror of the production server. Install this on a similar hardware platform (ideally a machine with the same hardware configuration), apply the upgrade(s), and test the robustness of the new system. Re-boot it and ensure sofware comes up. Watch for panics. Put some load on it and make sure the services don't fall over. (This, of course, will be done on a case-by-case basis, as all servers face different load scenarios). That done, migrate the changes to the production server, monitor it closely for a few days (even if you just watch Big Brother or a couple of log tails on your desktop), and call it a day.
I maintained upwards of ten separate workstation images and five servers using this methodology and virtually never had problems with any production setups as a result. We continued to stun the IBM tech reps (with whom we had a support contract, but that's a story for another day) when they'd come to the school and find themselves with absolutely nothing to do. They'd start to ask us about a problem they'd seen at other schools and we'd stop them with "Fixed that three weeks ago before it became a problem."
BD Phone Home!
Shameless plug. Like you weren't expecting it.
I asked a Red Hat sales rep at LinuxWorld.
He said that more than 80% of users use one of the last 3 releases of Red Hat Linux. Yet they support 6 releases, which makes very little business sense.
He also said that the Advanced Server has a minimum of 5 years of ongoing maintenance (apparently they are still considering making that 7 years).
He said further that they had already announced an Advanced Workstation product and that they would add more corporate Linux products with different price points, so that there will be good alternatives for current users of 7.x when their errata streams expire.
Does not sound too crappy to me.
I had an email from redhat _LAST_YEAR_ with these details. Why is this news now? Was it even news then?
I couldn't believe my eyes when I read the announcement on Dec. 19th when it come though on the redhat-announce mailing list. I had often wondered why RedHat was still supporting 6.2 but I would have never imagined they would ever go to only a 1-year life-span. That is just way too short. I have been using RedHat for my client's servers but now I am looking for another distro to switch to that has some kind of reasonably easy update procedure for patches and such. I'm currently planning on not installing any new servers using RedHat Linux after June 30th of this year due to this policy change. I do not fell it is right to change my clients full price for a new server install when I change them over to whatever distro I finally decide to switch too so I will likely loose some potential income over this. Speaking of which, does anyone have any good suggestions of distros to use for servers? I'm currently looking mostly at just going to Debian and I am also looking into Slackware. I have used Mandrake in the past for servers and did not find it satisfactory for a server (its perfectly fine for a desktop though). Does anyone have any suggestions that I've overlooked? As far as a desktop distro goes, I'm still trying to decide if a 1-year EOL is reasonable or not. It would be nice if RedHat changed the EOL of 7.3, 8.0 and future releases to be closer to 5 years, or even the 3 years that they are planning on doing with their Advanced Server line. The one thing that gives some hope that the 1-year EOL is not in stone is this line from the announcement: "Therefore, starting with Red Hat Linux 8.0, we have updated the errata support policy and will now provide errata support for all releases of the base OS for at least 12 months from the date of the initial release." (emphasis mine)
I've also been wondering why this has taken this long to make it onto Slashdot. I was expecting to see it on the front page the day it was sent to the redhat-announce mailing list or at least within a week, not over a month later.
If it's true that companies want support for their installations so they don't have to upgrade, then I'm betting that it's worthwhile enough that someone could start a little company providing support to old RH installs.
Think about it; you don't have to do NEW development as you might if you were doing a full distro - RedHat is paying for that. The bugs are going to be identified and repaired by others - you just have to patch up the software and send it out. Wouldn't need to be that big of a company, either, I'll bet - half a dozen techies and a few biz types would probably do it.
Several years just isn't good enough. Desktop OS's should be supported for at least 5 years if you are paying for support, and server OS's for 10. Otherwise you'll only land accounts at small firms.
Anarchists never rule
You missed a key point: I'm a consultant. I have to support what clients are using, which is largely WinNT/2K/XP and RedHat's distribution of Linux. I cannot afford to pay their corporate level pricing because I am a self-emplyed individual, not a consulting group that can leverage and distribute the costs among the profits from several consultants in the field.
I follow a lot of products I don't believe in and don't use, because it's my job to stay informed about the marketplace and the products my clients are going to be asking about.
Most clients are not well informed. They've heard about Linux, they've heard about RedHat. They don't know enough to realize that because I work with a couple other distros on a daily basis I'll have no trouble working with RedHat -- they'll just see I don't run the specific older release of RedHat they have support for, and assume I can't do the job.
Why won't I be running their release?
Because I won't be able to afford to run the releases they're using, because I can't drop several thousand dollars to maintain multiple AS releases, even multibooting the same hardware. And without the corporate updates provided to AS, it won't be an option to just run outdated software -- I wouldn't be running the same patch levels, which means I wouldn't be able to replicate and isolate the software problems the client is having.
I do not fail; I succeed at finding out what does not work.