RHEL 5.4 released

Posted Sep 2, 2009 18:14 UTC (Wed) by jengelh (subscriber, #33263)
In reply to: RHEL 5.4 released by jgg
Parent article: RHEL 5.4 released

Time for ripping 2.6.18 support out of all programs that do happen to still have it. That should give them the hint!

to post comments

RHEL 5.4 released

Posted Sep 2, 2009 18:35 UTC (Wed) by jhubbard (guest, #5513) [Link] (2 responses)

You don't understand. RHEL is made up of versions of applications that were around when RHEL 5.0 was released. New versions of software are rarely introduced and when they are it's older versions. For example, boost 1.33.1 was released with RHEL 5.3. At that time, I believe that boost 1.37 was the newest.

Backporting drivers and other new features of the kernel takes up an enormous amount of time. It's been covered many times before in articles here. There's a reason that they do it. It because customers want it. I work on systems where they expect leave them deployed for 5 years on more with a minimal amount of change. They only want critical bug fixes and security patches. They have neither the budget or time to update the system every year.

A good example of the churn that customers want to miss is all of the effort going into fixing X. There are many good articles on getting X fixed here. If you'll notice, it's been painful. The ABI for the server has changed multiple times and the various modules that need to be used have changed.

Since the opensource drivers don't support the full functionality that customers need, they have to use something that does. Yes I know that we need to support the effort to the open drivers. However, you have to be pragmatic and do what's needed to get the job done.

Examples: I still can't suspend my laptop with the nouveau driver. What about CUDA, StreamSDK, or OpenCL drivers for apps that need the parallelism? Don't forget the general high 3D applications.

RHEL 5.4 released

Posted Sep 3, 2009 1:12 UTC (Thu) by qg6te2 (guest, #52587) [Link] (1 responses)

There's a reason that they do it. It because customers want it. I work on systems where they expect leave them deployed for 5 years on more with a minimal amount of change.

While I'm stating the obvious by pointing out that the above is an instance of "we want stuff that's not going to break", it also implies that the real problem lies with kernel development (or more precisely, the testing part of development).

Regressions are bad, but this problem would be far less prevalent if the kernel developers (which includes many RH folks) were more thorough in their testing before forcing a release every 3 months. I'd wager that most users would be far happier with a 6 month release cycle if they were assured an upgrade wouldn't break their existing setup.

On the other hand, it could be argued that sticking to an ancient upstream release and patching the crap out of it is a way of keeping regressions in check. At the same time, I really do wonder about the stability of such mongrel kernels, given that far less eyes have looked at the final source and there was far less exposure to various environments. Maintaining a huge patchset also destroys the huge leverage RH gets from collaborative development in the upstream kernel.

(and yes, I do submit bug reports).

RHEL 5.4 released

Posted Sep 3, 2009 1:23 UTC (Thu) by dlang (guest, #313) [Link]

with a 3-month release cycle, the amount of new things that are found tapers off towards the end of the three months. delaying the release longer doesn't gain as much as you would like to think.

there is usually a 2-3 week time period where there are not many known regressions (there are very seldom none, and it's not unusual for a reported regression to actually be related to a change that was introduced several releases ago), the reason these regressions don't get fixed is that they are hard or impossible for the kernel developers to duplicate. what they can't duplicate they can't fix. if what caused the problem can be identified, but not fixed easily, it's usually reverted (specificly to avoid regressions), the one exception to this is if the fix is deemed 'important' enough (usually a security issue)

note that arguments along the lines of 'but it fixes far more boxes than it breaks' are _not_ allowed.