Red Hat intros 12 month only support on 'consumer' OSes (Register)

On the other hand, for RedHat, 12 months is really kinda short. I tried RedHat 8.0 for about 24 hours, long enough to figure out that I really didn't want to be running RedHat 8.0. (I think the "wait for x.2" heuristic for RedHat must still apply.) But if 7.3 becomes deprecated before 8.1 or 8.2 is out, you're stuck.

(I've switched to Debian myself, which is conservative enough that by the time a new "stable" release comes out, you can be pretty confident upgrading to it.)

-Rob

RedHat doesn't have anywhere near enough value added at this point to be trying to get away with this. Throw in the fact that their upgrades cost an arm and a leg plus you have to pay extra for automated software updates and its not hard to see where this company will be heading in a year or two without some major changes. Suse is a much better value for those who want commercial support, and Debian is far superior to RedHat for the knowledgable user. Its hard for me to see how RedHat can grow their business with their current philosophy given the existence of these two alternatives.

How do you expect a company to keep maintaining things forever with maybe 30 engineers who are dedicated to the OS? There are over 600 packages for say 3-4 releases each at different revs, and well there arent as many people paying for supporting the old ones as one would think.

Most people just want to ride the FreeBeer train as long as they can.

Many packages on the list are 'deprecated' upstream faster than Red Hat is willing to do so themselves. There were too many times when I worked there that the upstream developers have said we arent going to look at this XYZ bug, but paying customers said "we have to go through 6 month testing for any major changes in software code" and Red Hat has to drop 2-3 developers on fixing 6 month old 'legacy' code in the meantime.

I don't agree with everything Red Hat does in its business practices, and I also feel 12 months is a bit short... but I also know that maintaining 4.2 for 2+ years was a major drain of resources during every errata because even the original developers had no idea what various code bits did anymore.

There is no such thing as a free lunch. Your bill has come due.

And the comparison to Microsoft's end-of-life policy is a false one. When Microsoft stops issuing fixes for my OS I am SOL, as nobody but them can provide those fixes. Red Hat, on the other hand, just packages other peoples software. I can turn to those software authors to get updates and fixes.

In short, I am not *dependent* on Red Hat. If they stop issuing RPMs for my version of RHL, it is an inconvenience to me, not a brick wall. That is the difference between Red Hat's products (and policies) and Microsoft's.

That's why there have to be separate RPMs for 4.2, 5.2, 6.2 (let's confine ourselves to truly stable releases here) and 7.3. We all know I should be able to run any 4.2 RPM on a Red Hat 7.3 or 8.x system, and I should be able to install a set of RPMs to run a Red Hat 8.x RPM on an old 4.2 system. (Of course we also expect that, in some cases the number of RPMs to upgrade might be excessive --- that upgrading the whole system and downgrading specific packages for "legacy" reasons will sometimes be the better strategy).

For the most part we're seeing that the package management system in Red Hat simply isn't sophisticated enough, yet. I manually know how to install a set of shared libraries and export an LD_PRELOAD_PATH to force a particular application to use an older, or newer set of libraries, as necessary. I know how to manually create a chroot jail and how to write a wrapper script in that environment --- providing a complete "subsystem" for me to test new versions of applications, even a whole distribution, or to support a legacy environment. In fact, I routinely do this for my Debian installations (manually).

When it boils down to it, the only part of the system that could not, technically, be managed using Linux' shared library versioning and/or chroot "jail" features are at the kernel level. However, new kernels provide a high degree of backward compatibility, and the number of utilities that are affected by non-backward compatible changes is quite small and limited (procps,modutils, raidtools etc.).

So, it seems that we (as a community) could go further to modularize Linux software and insulate it further from these sorts of "all or nothing" upgrades. With that and further development of rollback and system configuration checkpointing (ensuring that upgrades aren't "one-way" risk propositions) the fact that "old versions" are only supported for a supported for a limited time will be moot.

JimD

However, having dealt with ISVs, OEMs, and resellers/integrators (until very recently I worked for another of the "major Linux players") I can say that this has the potential to become an ordeal for professionals. These professional types install software and don't reinstall or upgrade for years unless absolutely necessary. One of these folks could probably make a mint providing updates and support for defunct Red Hat distros, but I think in the end lots of these people will end up migrating to something that moves more slowly and is guaranteed to be supported for X number of years. UnitedLinux comes to mind immediately, but I'm sure others out there offer similar guarantees.

In the end, I believe that Red Hat "the business" is going to hurt over this decision unless they at least offer ISVs, resellers, etc. some kind of extended support option. If they cut off everyone and say "sorry, you're just going to have to run updates on the hundreds of computers you currently service", I would be very surprised if the reseller in question installed any more Red Hat systems. End users seem fine with installing and supporting their own systems, but folks who paid for their relationship with Red Hat, inconvenienced themselves by getting RHCE certified (expensive, and for most folks requires travel), set up a solid base of customers expecting a bit of longevity in the 3rd tier support, etc. may end up feeling sufficiently screwed to say "manyana, amigo" and go elsewhere.

Just my two shares of VA Software stock... (No, I didn't work there.)

Naturally RH have the right to apply their support resources in a way which benefits their, and their stockholders', interests. However...

1) The fact that RH seems to be ending support for hardware platforms other than IA32 appears to be being ignored.

2) Just think of the outroar if M$ tried to force upgrades in this way. Well, they DID (though not quite as agressively as RH), there WAS an uproar, and there was a considerable amount of fudging around when the new policy was to come into force.

Personally I think there should be a two-stage cutoff:

(a) support for enhancements & cosmetic fixes to be short - say until the next minor release but one;

(b) support for critical security issues (those which could result in the system being rooted, or abused in a major way by an intruder) should be guaranteed for a reasonable time - I'd suggest 3 to 5 years.

I've been using apt-rpm from Fresh RPMS for a while now, which doesn't have these problems.

Apt-rpm provides a free solution, with an open back end (so that you can publish your own packages - for example gstreamer use apt-rpm in this way) and works really well. The alternatives, up2date and red-carpet, have closed back ends, you have to get redhat or ximian to publish your package for you.

Perhap we would go to Red Hat Bugzilla and raise enhancment requests to ask for this?

Contrary to what most people believe a lot of corporates view free as risky and they they'd prefer to pay and if you offered them two contract staff, one at 105% of "typical rate" and another at 45% of "typical rate" they would take the expensive one - why? less risk.

When a company is faced with a testing and migration project or pay $$$ to maintain status quo - they will pay the $$$ because it is less risk.

Redhat - don't cut the support, just start charging for it after 12 months. Fair enough, you want free stay with the crowd, you want more stability and longer term use from our products? we're happy to oblige.

This level of upgrading would introduce massive admin costs into the organisation, one of the areas in which Linux is supposed to excel. I have seen so many posts where people have claimed (correctly in my opinion) that significantly more Linux boxes can be administered by a single admin than NT boxes. If you have to upgrade every system every year you can kiss goodbye to low admin costs.

The first thing potential hackers will do is save up all their security exploits until just after support expires, then god help the admin who has only managed to upgrade 1/2 their boxes so far, bang goes the Linux claim that it has superior security. I suppose you could alway start upgrading imediately a new release comes out, nothing like going in at the bleeding edge to get a good reputation for bug free stable software.

The comment made earlier about finding the fixes yourself and then compiling everything simply won't wash in a large business scenario this is exactly why companys tend to buy distributions. Not to mention if it takes Redhat 30 people to support an old OS surely it will take any other company at least this amount of support staff to perform the same roll (Again spiralling support costs).

And as far as server operating systems go, any admin worth his salt running a mission critical system would not usually consider upgrading to a new release for the best part of a year after release as stability is paramount.

The problem is Redhat want to play with the big boys, but at the end of the day their toys just won't last long enough to make this a reality. They either need to make up their minds to release and support systems that businesses will want to buy or go back to playing in the small leagues.

Oh well, time to find a new distribution.