LWN.net Logo

RHEL 6: already obsolete ?

RHEL 6: already obsolete ?

Posted Apr 21, 2010 23:34 UTC (Wed) by lwkejrlej (guest, #64237)
Parent article: RHEL 6 beta version available

Congrats to Red Hat for the hard work. However, I do hope (along with probably many others) that the user space will not become ridiculously crusty like it did RHEL 5.

Amongst the many examples, one is Python 3.x -- it would be nice to have this parallel installable with the Python 2.6 release. Another would be GCC 4.6/4.7/etc when it comes out -- the improved/full support for C++0x will be a very important feature.

Looking at the stuff available in RHEL 6 beta already raises questions of obsolescence. For example, why KDE 4.3 when 4.4 has been around for a while? Why OpenOffice 3.1 when 3.2 is out? The now ancient Firefox 3.5?


(Log in to post comments)

RHEL 6: already obsolete ?

Posted Apr 22, 2010 1:24 UTC (Thu) by airlied (subscriber, #9104) [Link]

its called QA, you can't just shove the latest version of everything into packages and shove it out and call it a RHEL beta, thats called a Fedora or Ubuntu LTS beta.

RHEL customers expect a bit more process and stabilisation for their money.

The thing is customers pay for the userspace to remain crusty, as in the whole point of running an enterprise distro is that it isn't Ubuntu or Fedora, it doesn't change all the rules every 6 months.

Though you'll notice with RHEL5 there is already updates for desktop apps a lot more often, it gets latest firefox quite quickly for example.

RHEL 6: already obsolete ?

Posted Apr 22, 2010 1:58 UTC (Thu) by lwkejrlej (guest, #64237) [Link]

    its called QA, you can't just shove the latest version of everything into packages and shove it out and call it a RHEL beta

Good in theory, but in practice this isn't always the case. OpenOffice 3.2 contains fixes for bugs present in 3.1. So in effect RHEL 6 beta, after the "QA", is actually shipping a more buggy version of OpenOffice than what is currently available (and will be present in F13).

Similar reasoning applies to KDE 4.3 and Gnome 2.28, all of which have been superseded by less buggy versions.

RHEL 6: already obsolete ?

Posted Apr 22, 2010 2:35 UTC (Thu) by airlied (subscriber, #9104) [Link]

how do you know they are less buggy? how do you know the bug fixes didn't break other things, engineers always have the best intentions but you need QA to make sure.

RHEL 6: already obsolete ?

Posted Apr 22, 2010 3:04 UTC (Thu) by lwkejrlej (guest, #64237) [Link]

    how do you know they are less buggy?

By the rather long lists of bugs fixed ? Did the RHEL 6 "QA" address all of the bugs present in OO.org 3.1 that are listed as fixed for 3.2 ? Is Red Hat's QA team the same size as OO.org's development team ?

It can be argued that anything with new features carries the risk of bugs. However, recent OO.org, Gnome & KDE are evolutionary releases rather than groundbreaking or totally fresh codebases, and as such it's much more likely that the amount of bugs introduced is less than the number of bugs fixed.

RHEL 6: already obsolete ?

Posted Apr 22, 2010 3:37 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

Such assumptions often turn out to be incorrect. Evolutionary releases tend to introduce enough new bugs as well. This is especially the case for desktop environments and large and complex codebases like Openoffice.org. Also importantly, even minor changes in the UI cause alarm from enterprise customers who really don't like change (except for the features they really want but that is another story).

RHEL 6: already obsolete ?

Posted Apr 22, 2010 7:41 UTC (Thu) by evad (subscriber, #60553) [Link]

Of course, this would seem to suggest that you assume that evolutionary releases are introducing more bugs than they fix with each successive release. I'm not sure that this is not the case, otherwise software would simply get worse and worse over time, when I've found that software such as GNOME and (Linux) gets more reliable and stable over time.

The argument is that staying with the old branch and only backporting just the fixes is a good thing. It works whilst the upstream supports it (usually about 6-12 months) but then you are forced to backport fixes to older versions that were never intended to have those fixes. Things break.

Red Hat have admitted this in person to me during subscription negotiations: Red Hat tend to break things badly by back porting critical bug and security patches (as well as new features). They fix security bugs and then they have to fix the fix because it exposed code paths that were never seen upstream.

So, customers should compare the latest stable versions of the software from upstream with an older version being maintained by Red Hat with new features/fixes (cherry picked ones, note!) backported over the top in a way that was never designed.

As you say, newer releases introduce *new* bugs (whilst fixing old ones) and *new* features. I don't really like the Enterprise Linux releases (they are obsolete at release and the package set is small) or the non-enterprise ones (Huge package set but insufficient testing, lots of new untested features, short lifespan). There has to be some middle ground we can get to.

RHEL 6: already obsolete ?

Posted Apr 22, 2010 8:21 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

"Of course, this would seem to suggest that you assume that evolutionary releases are introducing more bugs than they fix with each successive release"

That is indeed possible but not what I am suggesting. What I know instead is that even evolutionary updates introduce *new and different* bugs from the previous version while introducing new features and fixing some old bugs. Red Hat cannot simply just use the latest upstream user space for major codebases like a desktop environment or a office suite as has been suggested here. QA, hardware and software certifications take a lot of time and effort.

This is not to claim that backporting is a panacea but it is a solution that has worked better than anything else for the most part for the target market and Red Hat does update leaf packages like Firefox more often and introduce parallel installable versions of new software like Postgres. In the case of Postgres, some customers want the new features in it but simply upgrading to the latest version is not a option when the new version also introduces incompatibilities.

If more upstream projects would stop introducing so many (often avoidable) incompatibilties and take API/ ABI stability more seriously, it would certainly help but I am not sure there is a definitive movement towards that.

RHEL 6: already obsolete ?

Posted Apr 22, 2010 2:37 UTC (Thu) by dag- (subscriber, #30207) [Link]

Also that is good in theory, but in practice new software comes with new features and new unknown bugs, while old software has old known bugs patched.

New releases also ship with new features that change behavior or even interfaces. An Enterprise distribution is supposed to keep behavior and interfaces stable and trusted. So shipping latest software goes against that need that business have. The last thing you want is that a kernel update suddenly impacts performance/behavior and outdo any performance tweaks you prepared and implemented on your 400 servers before.

Of course if you don't have that need, you may as well find yourself using a bleeding edge distribution, or one that is more often updated. But that is not what enterprises desire in general. It's a balance of what you think is important, and that might as well be different for different users.

If a typical hardware lifecycle is about 4 years, and commercial software is adapted to run on a new OS release only after 18 months of general availability, you cannot expect a company to standardize on new OS releases every 6 or 12 months. The preparation and migration of your production environment simply is too time-consuming (and too costly)...

RHEL 6: already obsolete ?

Posted Apr 22, 2010 3:12 UTC (Thu) by lwkejrlej (guest, #64237) [Link]

    you cannot expect a company to standardize on new OS releases every 6 or 12 months.

I didn't imply that there should be a major update to a critical component, such as the kernel, every 6 to 12 months. That would be insane.

My point of contention is that there is user-space software available now that fixes bugs present in its earlier versions. Those earlier versions are present in RHEL 6 beta, and I do not see Red Hat's development team being able to backport all of the fixes from the newer version. It's simply easier to take the latest version, before Red Hat pours in the concrete and solidifies everything until 2015 / RHEL 7.

RHEL 6: already obsolete ?

Posted Apr 22, 2010 4:59 UTC (Thu) by airlied (subscriber, #9104) [Link]

But now is when the RHEL6 beta is released. Not composed, *released*. There is a chance my RHEL6 final there will be changes to the package list and version, its also possible there isn't.

Again this isn't a Fedora or Ubuntu, a major amount of stabilisation work has gone into this already. You can't just shove major revisions of apps in the week before beta release. I think you seriously underestimate the amount of work that goes into this prior to the actual beta release. Its not a just a bunch of maintainers chucking shit at a packaging system and hoping it produces a coherent OS. Like I'll guarantee you can say the exact same things about RHEL6 when it finalises, in that there will of course be newer versions of all those components than it ships with, but that isn't what the RHEL OS is aimed at. Its aimed at people who don't care about constant version revisions, they want a stablised version with lots of bug fixes only, not new themes or applets or whatever KDE4.x+1 might drag in along with the bug fixes.

RHEL 6: already obsolete ?

Posted Apr 22, 2010 5:54 UTC (Thu) by lwkejrlej (guest, #64237) [Link]

    they want a stablised version with lots of bug fixes only

Fair enough, but can Red Hat guarantee that all the bug fixes present in package version N+1 are backported to version N, which happens to be shipped in RHEL 6 ?

I'm also not totally convinced about the QA process. Going by the embedded versions within the names of package rpms (and the patches in source rpms), it would appear that things such as gnome-panel haven't been really updated from the version in F12. gnome-panel crashes all the time whenever you do a minor interaction with one of its components. This is a highly visible bug that has existed for quite some time, and yet it hasn't been fixed.

RHEL 6: already obsolete ?

Posted Apr 22, 2010 8:26 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

"Fair enough, but can Red Hat guarantee that all the bug fixes present in package version N+1 are backported to version N, which happens to be shipped in RHEL 6 ?"

That is never the goal. Just like new features, bug fixes are also cherry picked. Not everything gets the same priority. Upstream projects often exchange one set of known bugs with another set of unknown issues in newer releases. So just moving to a new upstream version doesn't solve the problem.

RHEL 6: already obsolete ?

Posted Apr 23, 2010 14:12 UTC (Fri) by nix (subscriber, #2304) [Link]

On top of that, I've seen code rely on the *presence of bugs* and break if those bugs are fixed. Sure, the code shouldn't rely on those bugs, but often it's nasty closed-source stuff and when you contact the vendor they say 'yes, this is fixed in the next version, please pay $$$$', and because it's closed-source you can't fix it yourself even if you want to.

Sure, for everything other than kernel and daemon bugs you can work around this with suitable library paths, and for kernel and daemon bugs you can work around it with a VM, but if you need a complete virtualized copy of the pre-updated RHEL to get things done, the updates really have done harm, even if all they did was fix bugs.

RHEL is for stability hounds, and often what matters there isn't that there are no bugs but that *the set of bugs does not change*, so the users can consistently work around them.

As a developer, I hate this crusty stuff, but I understand why the users like it.

RHEL 6: already obsolete ?

Posted Apr 24, 2010 19:42 UTC (Sat) by madscientist (subscriber, #16861) [Link]

ITYM "as a user, I hate this crusty stuff, but I understand why the IT folks like it."

:-)

RHEL 6: already obsolete ?

Posted Apr 24, 2010 20:24 UTC (Sat) by nix (subscriber, #2304) [Link]

The users in this case are giant banks. They really do like things to not change much. :)

RHEL 6: already obsolete ?

Posted Apr 25, 2010 1:03 UTC (Sun) by dag- (subscriber, #30207) [Link]

Not just banks, to be honest I prefer my non-technical family members to run something that doesn't require too much attention either as well.

In fact, as long as it is timely and digestible, and there is a clear roadmap for minor updates you've got something you can plan your organization around.

RHEL 6: already obsolete ?

Posted Apr 22, 2010 8:06 UTC (Thu) by danieldk (guest, #27876) [Link]

You mean the splendid QA process that let through changes to RHEL5(.0) that kills network completely on any machine with a Xen kernel and two network interfaces? And then after reporting it through Bugzilla (iirc the fix was a one-liner), you have to wait one quarter until the next release, because that one line change needs to go through QA again?

In the months I have helped CentOS as a volunteer (and used it on servers) I have seen enough slip through Red Hat's QA that I don't believe in their approach anymore. Many bugfixes are fairly trivial, and can be verified and patched quickly.

RHEL 6: already obsolete ?

Posted Apr 22, 2010 12:35 UTC (Thu) by mmahut (guest, #45550) [Link]

Many bugfixes are fairly trivial, and can be verified and patched quickly.

Yes, but also many one-liner (and verified) bug fixes can break customers' high-production environment very badly. At the end of the day, it's about how much is the customer willing to risk for a specific bug fix.

RHEL 6: already obsolete ?

Posted Apr 23, 2010 10:00 UTC (Fri) by dag- (subscriber, #30207) [Link]

Daniel, you cannot expect such a big compilation of software to be without bugs. Certainly not in the first release, but even in subsequent minor releases they are never free of bugs. And if you follow Red Hat's bugzilla you can zoom into all known bugs, and that gives you a very twisted view of reality. (You only see what is wrong, not what is right :-))

But the opposite (like eg. OpenSUSE, Fedora or Ubuntu) will never be more stable, more reliable or less bug-ridden. If you don't even try to freeze your code-base and instead have a rolling distribution, you can only assume software gets better (both more feature-rich and less bugs) but reality is very much different. Mostly because it will never be as well-tested in enterprise environments as a 2-year old RHEL release.

And yes, Red Hat does from time to time release new features or update software as well, and does introduce new drivers, but for a big part they refrain from making too big changes of which the impact cannot be overseen. Mostly in those areas their customers have no interest in, or Red Hat cannot guarantee to support it.

So the question is, does X past bugs or Y existing bugs in RHEL prove that Red Hat's Enterprise strategy is wrong ? Or does it validate to ship the latest and greatest software instead of trying to keep a stable environment for third parties to depend on ? I doubt it and most large companies seem to agree.

Developers and home users disagree, but they have very different needs.

RHEL 6: already obsolete ?

Posted Apr 22, 2010 3:04 UTC (Thu) by nevyn (subscriber, #33129) [Link]

> Amongst the many examples, one is Python 3.x -- it would be nice to have
> this parallel installable with the Python 2.6 release.

The Fedora/RHEL python maintainer has put a lot of work into F-13 to have a parallel installable Python 3.x. One significant reason for this was the desire to have that be available in EPEL too.

> Looking at the stuff available in RHEL 6 beta already raises questions of
> obsolescence.

There are a lot of people who think that way in Fedora, which is why it's now having more than one major regression per. release.

Hopefully the sane people will be able to fix things for Fed-13, with the new updates policy ... but even with that it won't be comparable with RHEL bug wise, and I don't mean it'll be better.

RHEL 6: already obsolete ?

Posted Apr 22, 2010 11:50 UTC (Thu) by lkundrak (subscriber, #43452) [Link]

Dude, you need (or want) Fedora.

RHEL 6: already obsolete ?

Posted Nov 27, 2010 13:24 UTC (Sat) by ceplm (guest, #41334) [Link]

Dude, you really don't get it.

Just to illustrate that mentality of our customers and yours is really radically different. I hope I won't leak terribly important information when I say that AFAIK the biggest outcry among our customers was ending of support for RHEL 2.1 (that's kernel 2.4.9, just to get an perspective, http://distrowatch.com/table.php?distribution=redhat). There are some widely unsubstantiated rumours of navy admirals (or CEO of bank?) begging on their knees in front of Jim Whitehurst.

I wouldn't expect our customers too loose a second of their sleep over availability of Python3.

RHEL 6: already obsolete ?

Posted Nov 29, 2010 17:24 UTC (Mon) by nix (subscriber, #2304) [Link]

Meanwhile, your customers's suppliers wept quiet tears of relief that they wouldn't have to keep working around bugs that had been fixed for most of a decade, but finally had an excuse to force their ridiculously tardy customers to upgrade. (My workplace actually had a thank-god-they're-upgrading party.)

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds