Slashdot Mirror
Red Hat Pushes Out Enterprise Linux 6.1
wiredmikey writes "Red Hat today released Red Hat Enterprise Linux 6.1, the first update to the platform since Red Hat Enterprise Linux 6 back in November 2010. The latest version brings improvements in system reliability, scalability and performance, and support for upcoming system hardware. The latest version also delivers patches and security updates as well as enhancements in virtualization, file systems, scheduler, resource management and high availability." The Register, too, outlines the new release.
They're moving to 6.1 after point releases used to take them years. Case in point, 5.4 to 5.5 and then 5.5 to 5.6.
And yet, where's the long awaited Centos 6? It's been more than 6 months, and checking distrowatch, it's the longest in more than 5 years for any "de-branding" effort.
Did you forget to log off before posting?
Other than the fact that apt is probably hands down the best package manager out there. I've never run into dependency hell with Debian. Never ended up with a 1/2 broken system.
It's his first post ever, obviously created to troll this thread.
Live today, because you never know what tomorrow brings
Forget to log off? He created the account just to post to this very story.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
SL 6.1 cant wait :D,
CentOS users should buy a confortable chair, so they can sit while waiting ...
http://qaweb.dev.centos.org/qa
ISOs of 6.0 should be available in a week. I doubt that 6.1 will be too far behind.
Cool beans.
Where's CentOS 6? I don't understand what's taking them so long. Don't they just remove the RedHat branding and re-package?
According to this thread on the CentOS bulletin board they are about to begin the QA, which means that it will probably be released soon.
Many places use Redhat and I had to downgrade to Fedora as 5.x is way too old.
http://saveie6.com/
Yeah, I've never seen a RedHat shill before, but this first poster is just like that MS first post shill.
Dependency hell only happens if you don't know what you're doing. That rule applies to any package manager, and is not limited to RHEL.
Feed the need: Digitaladdiction.net
RHEL 6.1 is shipping with Perl 5.10.x which went legacy with the release of Perl 5.14 this week. Ah, moving targets! Though doesn't seem too bad since Debian Squeeze is also shipped with 5.10 in February this year.
"Never try to tell everything you know. It may take too short a time."
QA? Redhat already provided it. If it needed QA it would be called Fedora
http://saveie6.com/
that guy must be the one who sends me recruiting emails looking for 20 years java/j2ee experience
We've been hearing that since March. Forgive me if I don't hold my breath.
Be gone from my sight or prepare to feel my flaming wraith!
nope, you don't understand process that Centos and Scientific Linux must do to make the binaries. Not a trivial process and is the reason for time delay, much work. Also, you'll notice that Scientific Linux has yet to put out 5.6 while Centos has, which should get you thinking....
we have Centos running in our company doing tens of millions of dollars of e-commerce; we'll take good and tested over fast. With myself and a couple other Linux gurus, we don't need Red Hat support.
Actually, apt is (deliberately) missing a vital system verification tool - a way to verify the consistency of packages. rpm -qv will tell you what files have been changed since a package was installed. The debian way to do it is 'reinstall the package and see what breaks'.
I am not making this up.
Schlock Mercenary.
ISOs of Centos 6.0 are worthless at this point because security fixes from RedHat going forward will be based on 6.1.
Centos has big issues. I can't see how anyone would commit to it at this point.
Unfortunately, there are hundreds of people willing to help with CentOS 6, but the team has just ignored them. There was a 'list of outstanding bugs' that was linked to in the 'When will CentOS 6 be released' thread, and a couple of days after that was posted, every bug had a patch against it.
They ignored that for another couple of months, wrote their own patches, and then went off and did other things.
Whilst Scientific Linux 5.6 is easily installable. Install 5.5 and then run 'yum update'. There's an alpha ISO around, and I think there was a beta due out shortly.
Schlock Mercenary.
http://qaweb.dev.centos.org/qa
ISOs of 6.0 should be available in a week. I doubt that 6.1 will be too far behind.
You missed the next month:
http://qaweb.dev.centos.org/qa/calendar/view/2011-6
"6.0 begin sync to external mirrors" is June 6.
Maybe a release within a week of that.
This is the way I see it. I currently run a company with a very very large install base of machines.
My machines are all running Centos 5.x. For me, getting 5.6 out to production is the HIGHEST priority. I could give a crap about 6.0, especially since everyone knows that the first RHEL x.0 release will be completely buggy anyway. For deploy-able stable products, RHEL 4.3 and RHEL 5.1 were the first in their series to be decent enough to run in production from our testing and bug reports back to Redhat's bugzilla. I completely expect RHEL 6.0 to be completely unstable and bug ridden, and hopefully 6.1 has ironed most of them out.
I'd be perfectly happy if CentOS never released a RHEL x.0 release.
I personally think Scientific Linux has their priorities backward, and CentOS is in the right. I'd rather have 5.6 before 6.0.
CentOS probably wanted to create a new complete process for compiling the kernel w/ and w/o patches and verify it worked (since RH started rolling the patches into their distributed kernel source).
We saw this happen this morning at ClearFoundation and are already building against 6.1 for our 6.0 release. Look for it soon.
Well I may not administer as many servers as you, but I am in the process of putting up infrastructure that will have a lifetime past the end of Centos 5. As such not having Centos 6 available is going come back and bite me in a couple of years.
Having backports of security patches to 5.5 and 6.0 would have been a better result than the current situation.
the current status is posted on forum thread, why distract the developers like a three year old in the back seat going 'are we there yet? are we there yet? are we.."
You already are going outside the realm of supported things from RHEL. Might as well install perl yourself while you are at it.
XML is like violence. If it doesn't solve the problem, use more.
if your project timeline and lifespan is so very long, why are your knickers in a knot about whether Centos 6 comes out last month or next month? Since it will likely be out of QA in a week or so, what's the big deal?
ISOS of RHEL 6 are worthless at this point because major kinks and bugs in the new release will be worked out over the next 6 months. RHEL 6 has big issues. I can't see how anyone would commit to it at this point
Me, moderately annoyed by CentOS 6 not being out yet? Eh, not really.
The 5.6 boxes are running fine and will be for a few more years. RHEL5 doesn't exit the normal life cycle until March 31, 2014, and the extended life cycle runs until March 31, 2017. So we have until 2014 for regular patches and 2017 for critical security patches.
Which means that CentOS will still be shipping critical security patches until 2017 as well.
Wolde you bothe eate your cake, and have your cake?
I've reviewed it for a recent partner: the SL update repository has _all_ the RHEL 5.6 components and ongoing updates. CentOS held up all updates for months until they completed their CentOS 5.6 release, which left their users with significant security risks and compatibility problems with use or bundling of upstream RHEL freeware components. SL is also cooperating with links to very useful 3rdparty repositories contained in their core distribution, such as EPEL and RPMforge and altrepo. These are components which RHEL is unable to directly support for various reasons, but which make Scientific Linux even _more_ useful than RHEL for development or leading edge work, and which CentOS also refuses to proved even in their "extras" repository.
The company would not have been able to afford the RHEL 6 licenses for their entire environment: their testing environments are now SL 6, and their production hosts are RHEL 6, which saves a lot of compatibility problems. CentOS could not even be considered due to the missing version 6 release.
Please show me the gap in the security updates where they did this "held up all updates". Helpful link below
http://lists.centos.org/pipermail/centos-announce/
,br/>
I get their update emails, haven't noticed any hole in the stream in the last year....
Your putting up a set of servers that will be used past 2017? Wow!
Thats how far 5.6 will continue to get security patches.. 2014 for regular errata updates...
What are we going to do tonight Brain?
...if there were a single VM hosting provider on earth offering RHEL 6 images. I know they pissed some people off with the new pricing structure, but Red Hat has always cut special deals with hosting providers, so I'm forced to wonder what they hell they've done to piss them off so much that nobody is offering it more than 6 months after release.
There are an awful lot of people who need the kinds of data center reliability that need million-dollar investments, but don't have the economies of scale to do it themselves. It's baffling that Red Hat is leaving that revenue opportunity on the shelf, with Ubuntu 10.04 LTS offering a much newer stable distribution, and available with a lot of different hosting providers.
There's no failure quite as dissatisfying as a complete and total solution to the wrong problem.
Funnily I don't see anyone complaining about Oracle Enterprise Linux. Weird. Their main aim is undercutting RedHat and making them go bankrupt by selling the same(NOT!) product.
The same product - OEL bundles Unbreakable Linux Kernel. It might be a good thing but breaks compatibility with RHEL/CentOS and caused headaches for me.
Even with only a single machine running with Centos5, I would have felt much more uncomfortable with that one with all the security updates from the upstream-vendor waiting for testing and release in the Centos domain, while ScientificL had them all out in-time (as quick as they usually offer them to the users). This inexplainable hiatus of bug fix and security update releases hasn't occurred for the first time. I always wonder how this behavior is overlooked by many of Centos' vocal supporters, many of them claiming to use this distro on a number of business machines and feeling happy with it, so everything is fine.
January 6 through April 14. CentOS patches for version 5 were nonexistent.
Take a look at the RHEL watch list for the same period and compare.
https://www.redhat.com/archives/enterprise-watch-list/
There has been some strong criticism of the CentOS team recently and frankly, some of it is deserved.
Why should you respin for every update? The (S)RPM's are available so a simple yum update gives you 5.6 just fine.... and if you're working offline a simple USB stick/disk/DVD with all the updates works just fine as well. CentOS is too stuck in their ways to keep up with RedHat it appears. The 5.6 release took WEEKS for the CentOS team to be finished... so I wouldn't boast too much with that CentOS 5.6 release, judging by the posts on the centos-dev mailing list I wasn't the only one 'disappointed' in the 5.6 slowdown.
md5sum -c var/lib/dpkg/info/foo.md5sums
There's also a tool called debsums which does roughly the same. So that gets you at least half way there.
Pavlov. Does this name ring a bell?
That's a mailing list archive: not helpful to this question. Go directly to the CentOS 5.5 archive, now set aside to the "vailt.centos.org" site, and viewable sorted by date at
http://vault.centos.org/5.5/updates/SRPMS/http://vault.centos.org/5.5/updates/SRPMS/?C=M;O=A. Then compare it to the CentOS 5.6 release packages, and the dozens if not hundreds of published RHEL 5 updates for the time from the day _before_ the release of RHEL 5.6 and the advent of CentOS 5.6. . This kind of 4 month "pause" and the focus on completing a release rather than publishing the ongoing updates makes CentOs unsuitable for any externally exposed servers: it means any remaining 0-day exploits will remain exposed and unpatched and need to be manually built and repaired.
This sort of thing is why production environments cannot merely slap in CentOS for production environments. The much vaunted by core maintainers "binary compatibility" with RHEL is pointless when the "compatible components" for the current release of RHEL have not been published.
Would still be nice for a way to downgrade if an upgrade breaks something. When I had an issue like that come up, all I could find from Debian forums was "why would you want to downgrade?". Because it would have made a 5 hour outage only last 20 minutes, while I figured out what it was changing in the configs.
Sure, best practices weren't employed in my scenario, but when I saw that yum has a method to downgrade, I realized they build their systems around the concept that people make mistakes sometimes, and need the tools to undo them easily when they affect production systems.
RTFA is Known to the State of California to cause cancer.
Please enlighten us! I don't understand what takes so long and neither does anybody else it seems. I always assumed that it was just yanking copyrighted stuff & recompiling, with no testing necessary.
the clients of my employer are huge operations with budgets in the tens of millions to over a billion; they all run Oracle DBMS and related products but I have yet to see anyone using Oracle Enterprise Linux. It's all RedHat for the choice of Linux, and Solaris, AIX, HP/UX, and even some Windows for the rest.