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

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,

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.

How can you steal something when Redhat make it available for free? You pay for Redhat if you want support and their management tools. They probably consider CentOS a loss leader, a lot of their business is likely "won" by converting sysadmins from the free distro.

How can you steal something when Redhat make it available for free? You pay for Redhat if you want support and their management tools. They probably consider CentOS a loss leader, a lot of their business is likely "won" by converting sysadmins from the free distro.

That's why we use it.

We use CentOS on the boxes where support doesn't matter and RHEL on the boxes where it does matter. It didn't cost us anything to dip our toes in the water and get comfortable with how CentOS does things. And that knowledge transferred right over when we started using RHEL for the important stuff.

t. CentOS is just stealing from Red Hat and you can't expect it to be up to date.

I'm puzzled. How can you "steal" GPL software if you make your source available upon distribution as the license requires?

By your standard, RedHat should shut down because they "stole" work from Linus Torvalds, Novell, Caldera/SCO, SGI, IBM, HP, and many, many others who have contributed to various parts of the overall "linux" software stack,. including of course Linux itself (the kernel). Thanks to the magic of the GPL, Red

In fact you would be well within your rights to re-brand RedHat, brand it as "myEnterpriseOS" and charge ONE BILLION DOLLARS if you so desire (good luck finding someone willing to pay for it though)

Maybe not a billion, but yeah there's been quite a few cases of open source software getting a different logo slapped on, obscuring that it's GPL and bundled with ad/mal/crapware or sold as if it was payware. Generally frowned upon, but grayishly legal enough they mostly get away with it.

I'm all for the "standing on shoulders of giants" thing, but the whole "let someone else do all the work, slap on a new logo and ship as our own" is more taking the bad with the good. Otherwise you'd run into a ton of legal

Your reasoning is defective, Red Hat didn't write most of the GPL software in their distribution, by your thinking they "stole" it from the FSF, the apache foundation, etc. And aside from their artwork and a few proprietary binaries, the rest is GPL so can't be "stolen".

Centos is a wonderful project that takes GPL software (most of it *not* from Red Hat), plenty of huge corporations use it as well as small ones. If that bothers you, migrate to Windows or HP/UX or something. They turn around critical

But their 5.6 is not out yet. CentOS has 5.6 out and lagging on 6. Since they were released very closely, there was a vote on the CentOS lists on priorities. For example, RHEL 6 is still not certified by Oracle for RDBMS so a lot of people prefer still installing 5.6. Hence majority preferred to get the updates instead of trying out something new.

CentOS, while a great community effort, is lagging too much. If you want the lated RedHat unbranded, go to http://www.scientificlinux.org/ [scientificlinux.org]
Quoting from their page:
"SL is a Linux release put together by Fermilab, CERN, and various other labs and universities around the world. Its primary purpose is to reduce duplicated effort of the labs, and to have a common install base for the various experimenters."
I just use it, and am slowly replacing my CentOS boxes with SL.

where's your Scientfic Linux 5.6 then??!! Oh, your SL team was too busy going for the ooo-shiny 6 so that wee little thing got left behind for now.....meanwhile Centos has 5.6 and has put 6 to their QA team. Many people need a most rational road map.....

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.

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 component

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 athttp://vault.centos.org/5.5/updates/SRPMS/http://vault.centos.org/5.5/updates/SRPMS/?C=M;O=A [centos.org]. 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 foc

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

How fast did SL 5.6 come out? Oh, wait.. it hasn't.. So if you have stuff running on SL 5.5, that you don't want/can't move to 6 yet your sitting and waiting...

4.9, 5.6, and 6.0 were all released in a very short time.. CentOS decided to do the ones that were currently being used first. SL decided to go with the new shiny one (which is nice about being small, and not having many people using your software on externally facing things)

What do you imagine "debranding" is? they have to compile everything from source and test, not a trivial process.

The distro is getting bigger, building and testing "debranded" version will take longer unless more volunteers, money and hardware are donated. they give the world their work free of charge, but turds like you sit on your ass helping no one but bitch.

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.

The 5.6 boxes are running fine and will be for a few more years [redhat.com]. 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.

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.

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.

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?

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 the

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

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

No, SL has all the *components* of RHEL 5.6 in their rolling updates, which were updated continuously since the release of RHEL 5.6. CentOS buggered themselves by holding up all updates until after they completely bundled RHEL 5.6, which was pretty useless. Rolling updates are the way Red Hat publishes them for already installed machines: you can install with any of the RHEL 5.x media and update to the current release on line, and this is what SL does. The only use fo the the RHEL 5.6 media, or bundle, is t

false, you can't get any kind of 5.6 by doing any kind of yum update in SL. CentOS 5.x works fine on the major vendor's servers because the vendors supply the drivers. Centos 5 is used by huge enterprises for DBMS, financial systems and ERP, including at some of my clients. If you're whining because RHEL / Centos 5.x doesn't support your usb camera, who gives a shit?

After they shafted the desktop users who help make them successful, and get them into the enterprise in the first place; by relegating them to guinea pigs for the half baked trial balloons in Fedora, RedHat earned the right to reset the version numbering system.

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.

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

I've worked with Red Hat distros for over ten years. It's very simple really, hosting companies don't want to deal with half-baked crap. Anything from Red Hat ending in a.0 is half baked crap. Been true in 1998, true now, no exceptions. Give Red Hat another six months or more and they'll have the bugs and kinks worked out of 6, but that steamin' pile is not fit for production now, somewhere around 6.2 or 6.3 will be golden.

You should really take a step back from the keyboard and look at the history..0 releases are, without fail, a major step forward in the technologies that Red Hat want to put in their distro. New kernel base, new packages, new security, new authentication etc. The list goes on. To call it "half-baked crap" is really little short of a half-baked comment. You can demand a flawless OS all you like, but without early adopter customers (of whom I've worked for several), these things don't stand a chance of g

I worked in Red Hat Support when both RHEL 4 and RHEL 5 were released. Yes, each one had growing pains that made it unsuitable for many users. Most of those problems involved:

1) 3rd-party kernel modules2) combinations of motherboards/BIOSes/peripherals/firmwares that each individually worked fine, but interacted in a way that caused undefined behavior that just happened to work correctly on the previous release3) hardware that wasn't available for QA prior to release4) entirely new features that had never