RHEL 6 beta version available [LWN.net]

Red Hat has announced the availability of a beta version of Red Hat Enterprise Linux 6. "Red Hat engineers have played key roles in the upstream development of a wide range of kernel performance enhancements that we plan to feature in Red Hat Enterprise Linux 6. This includes a complete rewrite of the process scheduler so that it more fairly shares compute cycles among processes and provides more determinism by enabling higher-priority processes to run with minimal interference from lower-priority processes." (Thanks to Greg Bailey).

to post comments

New slogan

Posted Apr 21, 2010 13:43 UTC (Wed) by yodermk (guest, #3803) [Link] (20 responses)

Red Hat Enterprise Linux: Because Debian Stable releases far too frequently

New slogan

Posted Apr 21, 2010 14:50 UTC (Wed) by danieldk (guest, #27876) [Link] (19 responses)

Grin :). I can understand that enterprisy distributions are great administration-wise, especially on a server. But I hate to have it forced on workstations (or clusters for that matter), since it's always a pain to deal with the old version of libstdc++ (I want my TR1-style hashmaps), boost (there I lost my hope of using the boost implementation) or gcc (where has -Wextra gone?). You usually end up with a partial copy of Boost (thank bcp!), and a lot of hacks around the staleness. This all makes Debian Stable feel refreshing (unless someone happens to be running Debian 3.1).

I used to like enterprise distributions, maybe because it was nice in theory. But since I have mostly been on the development/research side of the fold, I can only hope they die sooner than later ;).

Fortunately, my employer is mostly on Debian 5/Ubuntu 9.10 these days.

New slogan

Posted Apr 21, 2010 14:58 UTC (Wed) by djf_jeff (subscriber, #62173) [Link] (10 responses)

I guess that's the beauty of Linux, you are not stuck with one OS for all your needs.

At our current job, we do a lot of Red Hat (RHEL and their other products) but our web servers run on Debian. The reason for this is that we run TYPO3 and it need a recent version of PHP, something RHEL lacks.

The only problem with this hybrid approach is that it's harder to find a solution to centrally manage everything from one place.

Linux with caveats

Posted Apr 21, 2010 15:09 UTC (Wed) by pboddie (guest, #50784) [Link] (7 responses)

I guess that's the beauty of Linux, you are not stuck with one OS for all your needs.

You are if your place of work only "supports" one particular flavour. Usually, such regimes are quite happy to throw money around on supporting the latest Windows versions, too. Make of that what you will.

Linux with caveats

Posted Apr 22, 2010 1:03 UTC (Thu) by gmagklaras (guest, #65547) [Link] (5 responses)

As part of the "regime", I do not really understand why you are stuck, when your RHEL 5.5 workstation could easily KVM/xen your favourite distro on which you can base your development environment.

As a side note for the latest windows versions, well, I was never in favour of NT/2000/XP or Vista, but 7 is a lot better to administer and run than all previous versions.

Linux with caveats

Posted Apr 22, 2010 14:55 UTC (Thu) by pboddie (guest, #50784) [Link] (4 responses)

As part of the "regime", I do not really understand why you are stuck, when your RHEL 5.5 workstation could easily KVM/xen your favourite distro on which you can base your development environment.

Some things for my friendly sysadmins to do when they get back, then. :-)

What motivated my remark was that claims to support "Linux" which amount to only being able to run one particular "blessed" distribution often undermine the benefits of Linux, one of which was articulated in the comment I responded to: you can always find a distribution which suits you best. Of course no-one wants to have to support every distribution out there, but when the "regime" is happy to indulge Windows users with the latest and greatest, but they won't even entertain a second choice of well-regarded Linux distribution, one can't help feeling that one has drawn a very short straw indeed.

Linux with caveats

Posted Apr 22, 2010 19:35 UTC (Thu) by nevyn (guest, #33129) [Link] (3 responses)

> Of course no-one wants to have to support every distribution out there,
> but when the "regime" is happy to indulge Windows users with the latest
> and greatest, but they won't even entertain a second choice of
> well-regarded Linux distribution

But these are not the same. In many ways the difference between RHEL-5 and RHEL-6 will be significantly less than the difference between RHEL-6 and Ubuntu-10.4, even though they'll be released within months of each other (as against years).
Also any support problem that hits both will require at least double the work of using a single vendor.

Linux with caveats

Posted Apr 23, 2010 12:51 UTC (Fri) by pboddie (guest, #50784) [Link] (2 responses)

The most blatant differences are surely in things like packaging and update delivery, but in a sense, these things are what you rely on the vendor for (if they can be bothered to fix stuff, that is). Meanwhile, having all the infrastructure hooks in place is going to be more work for the "regime" in question: how the software uses the existing authentication systems, and so on.

Even if it's not the case now, over time the goal of the distribution vendors should be to make their products fit in with the minimum of local effort. Once upon a time, having huge numbers of local customisations and packages would have been the norm, but effectively saying that "Red Hat's package for XYZ isn't as good as our local package" can be regarded as making a bold claim indeed, at least for software where Red Hat can bring a lot of top-level expertise to bear.

I've worked in places where the "regime" even felt the need to have their own special Windows distribution, much to the annoyance of colleagues who found stuff mysteriously disappearing and having "fresh" stuff copied in on a regular basis, so if the support burden starts to stack up to "double the work", my experience tells me to review what the nature of some of that "support" is. I can well imagine that an mindset of maintaining lots of "special" software (from the days when people had to deliver stuff in a heterogeneous environment where the target platforms - stuff like Ultrix, IRIX, HP-UX, Tru64, SunOS, Solaris, AIX - had no decent repositories of their own) persists in many institutions and is not always adequately reviewed.

But anyway, the deployment of different distributions shouldn't be radically different. Although vendors may see some benefit in having things that way, or selling management tools to smooth over the cracks, it's certainly not in the spirit of giving end-users the choice, which is what many people see (perhaps implicitly) in Linux.

Linux with caveats

Posted Apr 23, 2010 15:43 UTC (Fri) by nevyn (guest, #33129) [Link] (1 responses)

> The most blatant differences are surely in things like packaging and
> update delivery, but in a sense, these things are what you rely on the
> vendor for

Yes, but that's a huge difference on it's own! The next big difference is that the bits coming from those updates are very different.

> But anyway, the deployment of different distributions shouldn't be
> radically different

I guess this depends on your definition of "radically different". Some of the components are the same or similar (say, the version of vim, coreutils or maybe perl). But a _lot_ is different.

Configuring network is radically different between debian/ubuntu and Fedora/RHEL, a bunch of other configuration is almost as bad. As you said, all the package tool are named differently, act differently and have different feature sets. Packages are named differently, split differently
and often go into different places. Things like multi-minor-versioned python are std. in debian but not in Fedora.

If you hit a kernel bug in one distro. there's no guarantee it'll be in the other one (even with 10.4 vs. 6, the backport work is _huge_ on the 6 side ... and there are a bunch of changes from debian in 10.4). If it is in both you'll need to open two support tickets, and they'll almost certainly have different resolution timelines etc.

All of which is why I said it'd be nearly double the work, to support both.

> it's certainly not in the spirit of giving end-users the choice, which
> is what many people see (perhaps implicitly) in Linux.

There is choice ... you just have to choose given a number of differences.

Even if you forked from RHEL-6 beta tomorrow, by the time RHEL-6 came out you are guaranteed to have "more than one difference". If the user liked some differences on one side and some on the other, they'd have to choose the least worst.

Linux with caveats

Posted Apr 24, 2010 16:13 UTC (Sat) by pboddie (guest, #50784) [Link]

Yes, but that's a huge difference on it's own! The next big difference is that the bits coming from those updates are very different.

So, Debian and Red Hat split things up differently. It'd be interesting to see, once you've installed all the necessary packages, which differences there actually are. And why should it matter? Back in the day, you'd have your institution's private repository giving out packages, albeit all built from source and more or less the same on every platform, but underneath all that the differences would be profound.

Configuring network is radically different between debian/ubuntu and Fedora/RHEL, a bunch of other configuration is almost as bad. As you said, all the package tool are named differently, act differently and have different feature sets. Packages are named differently, split differently and often go into different places. Things like multi-minor-versioned python are std. in debian but not in Fedora.

I don't deny that it could be confusing, but as an individual it's possible to remember how the networking is configured on different distributions and where the Python packages go, so I struggle to see how it should be an insurmountable burden for an organisation dedicated to managing this kind of stuff. And weren't there tools for handling at least stuff like network configuration? Once upon a time, people swore by stuff like Webmin, and before Caldera was subverted for lawsuit purposes they even had a project going to try and standardise this stuff.

If you hit a kernel bug in one distro. there's no guarantee it'll be in the other one (even with 10.4 vs. 6, the backport work is _huge_ on the 6 side ... and there are a bunch of changes from debian in 10.4). If it is in both you'll need to open two support tickets, and they'll almost certainly have different resolution timelines etc.

Isn't Launchpad supposed to solve this problem? No, you don't have to answer that. ;-)

All of which is why I said it'd be nearly double the work, to support both.

For one specific kernel-related bug, yes. For the entire Linux support activity, I'm not completely convinced. Either way, vendors should be working towards standardising much of the administrative interface, and those deploying Linux should be attempting to take advantage of the choice the Linux ecosystem offers, not taking one particular vendor's flavour and pretending it's something like HP-UX.

Linux with caveats

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

Quite so. I just had to spend a day adding workarounds because of a crash bug in zsh, introduced in 2002, fixed in 2003... still there in the ancient RHELs some of our customers insist on.

New slogan

Posted Apr 21, 2010 15:53 UTC (Wed) by danieldk (guest, #27876) [Link] (1 responses)

Well, that assumes that there is the opportunity to choose. Our university has a standard Windows and UNIX workplace, and that's what you get. I am not complaining, because it is actually useful to have the same environment everywhere, and a recent Ubuntu version is used for the workplace (and Debian on servers). Fortunately they have banned old (but supported) Red Hat and SUSE versions.

However some computing resources with a lot of cycles use old RHEL/CentOS/Scientific Linux versions, e.g. one particular cluster has just migrated from RHEL4 to RHEL5 (which is not really stellar). Compiling our codebase there is always a drag, where you have to bring things four or five years back in time.

New slogan

Posted Apr 21, 2010 16:52 UTC (Wed) by horen (guest, #2514) [Link]

Funny... OUR university group has standardized on RHEL, almost solely because of its aggressive approach to security updates.

As an old(er) Unix maven said to me, some twenty years ago, "Once you've secured your network against the Bad Guys on the outside, you can begin to defend it against those on the *inside*."

Some things haven't changed. The bulk of those probing and banging on our systems are this university's own students.

Yup, we run RHEL/5.5, and we're quite happy when RedHat pushes out yet-another security update.

Of course, YMMV.

boost updated post RHEL-6 beta

Posted Apr 21, 2010 15:28 UTC (Wed) by bkoz (guest, #4027) [Link] (3 responses)

I feel your pain on this issue.

Please note that the RHEL-6 beta released today has an older version of boost than the 1.41.0 version that will be in RHEL-6 final. (Ie, RHEL-6 will sync with F13 for libstdc++/boost.) The F13/RHEL-6 packaging has some notable improvements over RHEL-5 versions.

It would have been very nice to have GCC 4.5.0's libstdc++ in RHEL-6 (especially if we are going to have to live with it as "top of RHEL tree" for another 4 years on the server!) but the release dates didn't sync, sadly. And the backport to 4.4 based gcc's isn't feasible.

If you care about this kind of stuff please let your RH reps know.

boost updated post RHEL-6 beta

Posted Apr 21, 2010 16:01 UTC (Wed) by danieldk (guest, #27876) [Link] (2 responses)

Having the latest and greatest new helps a bit. However, within two years g++ will probably support many more C++0x features than it does now, but since RHEL7 probably won't be rolled out until 2015, you can't use them for a window of three years when the rest of the world has moved on. I am emphasizing on C++ here, because that's what I use mostly, but I am sure that the same applies to Python or Ruby. I like turnaround times of two year max ;).

Before someone points out that Windows has even longer release cycles: that's true, but the Windows 'userland' isn't tied as much to the base system as a Linux distribution. Try to replace Gtk+ in CentOS 5 to a newer version, it is a pointless exercise. On Windows you can install the latest installment of Visual Studio and enjoy new features.

boost updated post RHEL-6 beta

Posted Apr 21, 2010 16:47 UTC (Wed) by danpb (subscriber, #4831) [Link]

There's no need to replace existing versions of apps. It is entirely possible to install multiple extra versions providing you compile them with non-clashing install prefixes. I know people using RHEL whom have as many as 5-10 different GCC/G++ toolchain versions, each in /opt/. Likewise you can do this for other libraries like GTK. Perl / python is doable too, though you might need to change #!/usr/bin/perl in scripts to reference a binary with a specific alternate version number

RHEL 7 when?

Posted Apr 21, 2010 20:43 UTC (Wed) by dowdle (subscriber, #659) [Link]

Why do you think RHEL 7 won't hit until 2015? I would imagine that RHEL development will be back on track (18-24 months) after RHEL 6 is released. Even if not, 2015 is 4.5 years away and even RHEL6 won't take that long.

New slogan

Posted Apr 21, 2010 16:23 UTC (Wed) by jspaleta (subscriber, #50639) [Link] (3 responses)

So your employer.... are they a paying Canonical any thing for support customer for those Ubuntu 9.10 installs? Are they paying the $10k+ to have Landscape satellite server on premises?

-jef

New slogan

Posted Apr 21, 2010 19:22 UTC (Wed) by danieldk (guest, #27876) [Link] (2 responses)

I do not know whether they paid for customer support, I guest most support requests are too specific (lots of third party software). But they do use Landscape... (I'd guess local)

New slogan

Posted Apr 21, 2010 19:33 UTC (Wed) by jspaleta (subscriber, #50639) [Link] (1 responses)

Can you get a confirmation about the existence of a local landscape server?
And ballpark how many nodes on Landscape? We talking hundreds or tens?

The published rate for Landscape is $150 per node annually before undisclosed volume discounting. And if you are running a local Landscape server that's a reported $8k on top of that.

-jef

New slogan

Posted Apr 21, 2010 20:21 UTC (Wed) by danieldk (guest, #27876) [Link]

Yes, they run a local Landscape server. A 2008 report estimates ~900 Linux desktops in the university (yes, universities are Windows shops as well). As far as I know, the intention is to migrate all Linux desktops to the centrally provided Linux environment, as they did with Windows desktops long ago. I have totally no clue about the (volume) pricing, as I am just a user.

Wot no Exim?

Posted Apr 21, 2010 15:06 UTC (Wed) by dwmw2 (subscriber, #2063) [Link] (3 responses)

Exim is missing, allegedly because there are other packages which provide duplicate functionality. Although I can't see any other MTA which is even close to Exim in functionality. But I can still see Postfix, which also duplicates Sendmail functionality.

Wot no Exim?

Posted Apr 21, 2010 18:33 UTC (Wed) by cesarb (subscriber, #6266) [Link]

http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux... seems to imply that exim is there.

Wot no Exim?

Posted Apr 21, 2010 18:57 UTC (Wed) by smoogen (subscriber, #97) [Link]

No one could support it to the level you did :).

Wot no Exim?

Posted Apr 21, 2010 20:44 UTC (Wed) by wtogami (subscriber, #32325) [Link]

OTOH, exim can now live in EPEL. This means much more flexibility in package maintenance as you don't need to run the Red Hat product management gauntlet to make any necessary changes. I personally would trust the dedicated EPEL maintainer of exim over grumpy engineers at a company that does not consider that component to be important.

RHEL 6 beta version available

Posted Apr 21, 2010 20:25 UTC (Wed) by sjlyall (guest, #4151) [Link] (7 responses)

Work has standardise on RHEL/Centos with a policy of updating quickly.

One thing I found that compared to Debian there are a lot of packages missing. Fairly common things like collectd, nginx and memcached are the ones I particularly miss.

There are 3rd party package sites but these seem to be a bit random in quality (but at least enough people run it that 3rd party packages are common) and obviously you can still have problems. For example the recent 5.5 update pushed libevent from 1.1 to 1.4 (well overdue I suspect) but the 3rd party rpms I use for memcached depend on libevent 1.1. I'll probably end up rolling by own rpms but having packages directly supported in the distributing is good.

I have to find out a package/version list for what is in 6 to see if some of the missing ones above are included.

RHEL 6 beta version available

Posted Apr 21, 2010 20:34 UTC (Wed) by wtogami (subscriber, #32325) [Link] (6 responses)

The quality of EPEL is not good? EPEL is pretty much the de facto semi-official add-on repository for RHEL. It is maintained by the same people as Fedora.

RHEL 6 beta version available

Posted Apr 21, 2010 20:49 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

It could be better integrated into the RHEL experience. EPEL runs up against some of the same problem that any 3rd party repository split does when it comes to policy synchronization. Debian certainly has some advantage in the fact that they don't have a split between "supported" and "unsupported" repositories.

Are paying RHEL customers sufficiently interested in EPEL as a resource to start talking to Red Hat about working to better integrate EPEL into the RHEL experience? I'm not a paying customer, but as an EPEL maintainer I'd love to know what the RHEL customers are looking for as a starting point for for a roadmap for better integration.

-jef

RHEL 6 beta version available

Posted Apr 21, 2010 21:49 UTC (Wed) by Banis (guest, #59011) [Link]

As a RHEL customer with 1500 deployed boxes I've had a fair bit of trouble with EPEL. The packages are managed to haphazardly. Some stuff gets pulled out of Fedora at the latest version, some gets old versions and some get left out. EPEL also doesn't play nice with other third party RHEL repos that have more history behind them. The packages also do not tag themselves as being EPEL in the package name. The package release gets tag'd with el5 and the Vendor is left at Fedora Project. I know where I got the various packages because there in carefully separated local repo's, but EPEL not claiming any of the packages needs to be fixed. They are not supported by redhat and should thus not carry the .el5 tag at the end of the release.

I finally just pulled all the EPEL stuff off my network and rolled my own straight out of Fedora for anything I need not already provided by RHEL5.

And for the record a 2 year release cycle for our OS would be a problem for us. It takes 4 months to just deploy all our boxes (they are scattered in groups of 10 all over the US with a few in Korea). We'd probably end up skipping every other release if they come to fast, but that has it's own issues.

RHEL 6 beta version available

Posted Apr 21, 2010 22:13 UTC (Wed) by sjlyall (guest, #4151) [Link] (3 responses)

I didn't actually realise EPEL was "official". It does seem a little nicer than some but not great.

For instance the memcached package is from July last year and won't work with libevent-1.4 in RHEL 5.5

I grabbed a Package list for RHEL 6 and out of the packages I'm interested in the following are newly added:

memcached
tokyo cabinet

But the following are missing which I would have liked to see (especially nginx and puppet).

nginx
puppet
collectd
Mondo rescue
tokyo tyrant
cassandra

I'm trying to work out how to submit a wishlist ticket to RHEL support.

RHEL 6 beta version available

Posted Apr 22, 2010 0:27 UTC (Thu) by jspaleta (subscriber, #50639) [Link] (2 responses)

An updated memcached is in updates-testing.

updates in EPEL have to spend a certain amount of time in updates-testing before they are released to stable...or enough people give it positive karma.
That's done to help in QA. As an EPEL user you could help by giving it some positive karma in the update system

But I understand the gist of what you are saying. I'll try to state it more exactly.

Because RHEL and EPEL are distinct repositories they have distinct management policies. EPEL tries to provide as coherent an update policy as can be expected given that RHEL's build system is distinct from EPEL's.

Currently there's no way to do a coordinated push, EPEL doesn't get access to RHEL update packages any earlier than RHEL users do. So as a result there will be a lag in EPEL update availability.

Can the volunteer, community run, EPEL do better at serving RHEL customers? I'd like to hear some suggestions on that. For package coordination, its difficult for me to see how. Unless Red Hat is willing to work with us to do coordinated builds prior to RHEL updates going out to the public, the lag will remain.

As an EPEL maintainer, I'd certainly appreciate if customers would let Red Hat know they'd like to see better coordination in updates between RHEL and EPEL. I'd love to see a public discussion between Red Hat, RHEL customers, and EPEL contributors on where the low hanging fruit is.

-jef

RHEL 6 beta version available

Posted Apr 22, 2010 17:21 UTC (Thu) by Banis (guest, #59011) [Link] (1 responses)

I have to apologize for my complaints about EPEL. I did not realize EPEL was not fully managed by redhat. Last time I had a redhat sales guy out he all but claimed the project himself. I assumed redhat was building the packages internally as a way to provide RHEL folks with a broader package set.

RHEL 6 beta version available

Posted Apr 22, 2010 17:46 UTC (Thu) by jspaleta (subscriber, #50639) [Link]

Well it's certainly nice to know that Red Hat sales team is aware of the work and sees it as a valuable thing to talk about.

It's not surprising that EPEL's role was miscommunicated.

Getting a good idea of internal Red Hat corporate culture perception of Fedora and EPEL can be harder than gauging public perception.

What I would LOVE to see is a high profile public meeting of the minds between Red Hat reps, EPEL maintainers, and a panel of RHEL customers about how a roadmap for making it easier for customers to utilize AND contribute to EPEL and a set of accurate talking points about where EPEL fits in as a value proposition.

There's a lot of room to grow EPEL to better meeting customer needs...but that growth has to either come from sweat-equity from customers themselves contributing to EPEL and shaping it directly or be driven by customer cash channelled through Red Hat to pay for the manhours to build the infrastructure to make RHEL/EPEL synchronization more coherent than it is now. I'm an EPEL maintainer, but I'm not a RHEL customer and so I can't really speak to how EPEL fits into the RHEL customer experience. But what I need is for the conversation to happen in the open. If its always a conversation between a salesperson and a RHEL (potential) customer there's no way I can constructively shape that conversation.

-jef

RHEL 6: already obsolete ?

Posted Apr 21, 2010 23:34 UTC (Wed) by lwkejrlej (guest, #64237) [Link] (23 responses)

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?

RHEL 6: already obsolete ?

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

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] (14 responses)

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] (4 responses)

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] (3 responses)

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] (2 responses)

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 (guest, #60553) [Link] (1 responses)

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- (guest, #30207) [Link] (8 responses)

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] (7 responses)

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] (6 responses)

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] (5 responses)

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] (4 responses)

"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] (3 responses)

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] (2 responses)

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] (1 responses)

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- (guest, #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] (2 responses)

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- (guest, #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 (guest, #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 (subscriber, #41334) [Link] (1 responses)

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.)

Smack and TOMOYO

Posted Apr 22, 2010 5:26 UTC (Thu) by haradats (guest, #44782) [Link] (6 responses)

# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set

Ouch.

I believe that enabling CONFIG_SECURITY_SMACK and CONFIG_SECURITY_TOMOYO does not hurt anything. Am I wrong?

Smack and TOMOYO

Posted Apr 22, 2010 6:45 UTC (Thu) by adobriyan (subscriber, #30858) [Link] (5 responses)

Turning on kernel config option roughly means "I support this".
But Red Hat invested heavily in SELinux.

Smack and TOMOYO

Posted Apr 22, 2010 7:33 UTC (Thu) by haradats (guest, #44782) [Link] (4 responses)

Well, everybody on this planet knows "Red Hat has invested heavily in SELinux" and "Red Hat does not support Smack and TOMOYO". ;-)

So, IMHO they don't have to use the sacred config options. I even think if Red Hat gives chances their customers to try Smack and TOMOYO, it might help promoting RHEL. (ahem)

Smack and TOMOYO

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

Red Hat's service agreement boils down "if we ship it, we support it". Enabling some configuration options implies support. Red Hat had to drop "kernel-unsupported" package in newer releases of EL precisely because customers demand support for everything that is included. Simply enabling all the options available is not a strategy that would work especially when these have security implications.

Smack and TOMOYO

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

Exactly.

There are third party repositories with software for RHEL that's not supported by Red Hat. Most notably, EPEL, which ships loads of software from Fedora.

Smack and tomoyo are kernel modules, which are not permitted in Fedora. There's another community-maintained repository, RPM Fusion, which would allow it though. If anyone needs tomoyo or smack for RHEL, he's free to add it to RPM Fusion.

The community around Fedora and RPM Fusion is quite supportive, if a packaging experience were a problem.

Smack and TOMOYO

Posted Apr 23, 2010 2:22 UTC (Fri) by haradats (guest, #44782) [Link]

Considering the people who develop/support SELinux and its history, I think it may be safe to say SELinux is the finest and most trustable MAC implementation in the world. However, I personally believe keeping alternatives is good for Linux users and that is the reason LSM exists. RPM Fusion sounds like a good starting point. Thanks a lot for your suggestions.

Smack and TOMOYO

Posted Apr 23, 2010 2:05 UTC (Fri) by haradats (guest, #44782) [Link]

Thank you very much for your informative comment. Now the reason EL disabled Smack and TOMOYO is clear to me and I understood why RH did so. I came to realize that if one wants his work (software) to be used globally, making it in-tree is not the goal but an important first step. Making software in-tree is technical, but affecting distributors decision should involve non-technical issues, I guess.

Grub2 and >2TB boot partitions

Posted Apr 22, 2010 7:46 UTC (Thu) by al4711 (subscriber, #57932) [Link] (2 responses)

I haven't read in the announcement if RHEL 6 is able to boot from systems with more then 2 TB Partitons.

Have I overlooked something?

Grub2 and >2TB boot partitions

Posted Apr 22, 2010 19:41 UTC (Thu) by gurulabs (guest, #10753) [Link] (1 responses)

I had a 6TB Hardware RAID volume that I couldn't boot from (in RHEL5).

What I did was the following:

In my hardware RAID controller I carved off a 1GB volume. That 1GB volume appears to the BIOS and Linux as /dev/sda. The other 5999GB volume shows up as /dev/sdb. Both volumes come from the same RAID6 volume set.

My /dev/sda has one fdisk MBR style partition that uses the whole device, -- it holds /boot. I boot off of it.

My 5999GB volume has a GPT partition table, uses LVM (maybe I could have skipped the GPT partition table altogether), and has Linux installed to it.

Grub2 and >2TB boot partitions

Posted Apr 25, 2010 20:22 UTC (Sun) by al4711 (subscriber, #57932) [Link]

Thanks, but we create the partition table automatically.
We need to handle different disc sizes for this it is easier to use the same process for all discs.