| |||||||||||||
Competition at the kernel levelCompetition at the kernel levelPosted Sep 21, 2010 9:47 UTC (Tue) by cventers (subscriber, #31465)In reply to: Competition at the kernel level by tmassey Parent article: Oracle's "Unbreakable Enterprise Kernel"
> There's a difference between updating existing servers and installing new
> ones. That's why RHEL supports--and need to support--multiple major > versions.
Indeed, but if you decide you're going to support X versions of a distribution, your support window for any one of them necessarily decreases with the period of its release cycle. Choosing X depends on how much manpower you're willing to spend on the problem.
Each major release in a stable distribution is effectively a huge set of forks. The older the software gets, the harder it can become to maintain, which is multiplied by how many major releases you're maintaining. Inevitably this has an effect on which packages, and how many, Red Hat is willing to support. (I really disliked RHEL until I found out about EPEL.)
Don't get me wrong... I wish RHEL 6 would have come around sooner. Just so long as that doesn't force users off "old" software too quickly.
(Log in to post comments)
Competition at the kernel level Posted Sep 21, 2010 13:41 UTC (Tue) by tmassey (guest, #52228) [Link]
Yes, but you would have to support multiple forks for *less* time if you had more of them.
Right now, Red Hat is looking to have to maintain RHEL5 for as long as 10 years or more. Realistically, they'll have to support it for at least 5 years after they release RHEL6, simply because brand new servers that were loaded with RHEL5 right before (and quite likely, for some time *after*) the release of the next version will have that type of life expectancy. So, the longer they go between releases, the longer they have to support the older versions. And as you said, the longer they have to do this, the more painful it becomes.
So, it's not as simple as "more versions = more work, less versions = less work"; by releasing major versions more frequently, they maintain more forks, but for less time.
But whether it's more work or less work, the fact remains: Red Hat has fallen *way* behind the standard they themselves set when they created the RHEL line. RHEL5 is crazy behind the times--especially the userspace. Any competition that inspires them to rectify this is, to me, a very good thing.
Competition at the kernel level Posted Sep 21, 2010 18:10 UTC (Tue) by mrjk (subscriber, #48482) [Link]
That isn't what a stable enterprise release is. You still have to support ALL of the releases as long as you say, could be 10 years or more. The more releases the more things you have to support and the more chance for issues. Keep the releases as they are and you can look elsewhere for your quick changes.
Competition at the kernel level Posted Sep 21, 2010 19:39 UTC (Tue) by dowdle (subscriber, #659) [Link] Keep the releases as they are and you can look elsewhere for your quick changes.Ok, how ARE the releases? Red Hat said they plan to come out with new releases every 18 - 24 months. RHEL 5 is 3.5 years old now. Their update schedule they've been doing pretty well with in my opinion... with an update about every 6 months. I don't recall them saying every 3 months but maybe I'm wrong on that. Should the schedule be kept as Red Hat said it would be... or should we use this new, as yet unknown, release cycle length? If you want to stick with RHEL 5 after RHEL 6 comes out, more power to you. Having a new release come out does not make RHEL 5 go away... so why there would be a downside to a new release for you makes no sense. I will give them some credit for re-basing some user apps... from both a usability stand point and an upstream-no-longer-supports-it stand point... and they do backport a ton of drivers and some features to their kernel so that it isn't so ancient.
|
|||||||||||||