Slashdot Mirror
Red Hat To Help Develop CentOS
An anonymous reader writes with news that Red Hat and the CentOS project are "joining forces" to develop the next version of CentOS. For years, CentOS has been a popular choice for users who want to use Red Hat Enterprise Linux without having to pay for it. Some of the CentOS developers are moving to Red Hat, but they won't be working on RHEL — they say the "firewall" between the two distros will remain in place. CentOS Project Chair Karanbir Singh said, 'The changes we make are going to be community inclusive, and promoted, proposed, formalised, and actioned in an open community centric manner on the centos-devel mailing list. And I highly encourage everyone to come along and participate.'
Buzzword bingo anyone all in one sentence.
I understand GPL allowing CentOS and Scientific Linux to use Redhat in their respective products, but I find it really puzzling that they would actively *help* CentOS... Doesn't make a lot of sense to me...
THANK YOU, Edward Snowden!! Americans owe you a debt of gratitude (whether they know it or not..)
Those of us who've been using Centos understand that if you use it to deploy, and ultimately in your data center, often in place of Windows, then it is just a matter of time before you begin to use RHEL to get support for at least their mission critical production boxes. Centos and RHEL are a nice mix. So, this definitely makes sense for RH. Plus, they have nothing to lose since Centos thrives with or without their endoresment.
Yet, the back and forth relationship RH has taken over the years with the community-driven open source from which it was born and has built its business suggests that, despite this move, they only seem to consider relationships that produce pofits from no more than one degree of separation. This makes the end to this very long estrangement, where Centos only referred to Redhat as the "upstream provider" to keep RedHat's trademark legal team at bay, just plain-old WEIRD.
The question is, how will RH help Centos? That isn't very clear from this announcement.
CentOS 6 was delayed quite a bit from the corresponding RHEL release, for a variety of reasons. If being an unofficial-official Red Hat project means that CentOS 7 tracks the upcoming RHEL 7 release better, then everybody wins. (Conversely, if they turn into Sunacle, then we're likely moving to Debian.)
I use Macs for work, Linux for education, and Windows for cardplaying.
...and dumping all of our Redhat licenses. There's no need to pay Redhat thousands of dollars when Centos is the same thing. We already have a mix of Centos and Redhat and the Redhat licenses don't give us anything.
I'm very glad and happy for you that you figured that out. Welcome to 2005. Trust me, it will be a good year for you. I'd hold off on buying that house, though, if I were you...
I've been using CentOS and other Red Hat derivatives for 15 years. When I want to get a certification, who do you think I'll get it from? Microsoft? I'll get Red Hat certified, of course. When my employer, a government agency, adds new servers and wants enterprise support, which OS am I going to recommend. Hint - not Ubuntu.
Red Hat isn't competing with CentOS. They are competing with other large companies selling enterprise support, certifications, and training. More people using Linux is good for Red Hat and especially more people being comfortable with Red Hat derived systems is good for Red Hat.
Originally, Red Hat Linux was free. The company was built on cooperating freely with the communityand
contributing, while earning a reputation that allowed them to sell support, training, etc. Working with the CentOS community is classic Red Hat, that's the kind of thinking that once made Red Hat THE Linux distribution and the #3 operating system behind Windows and Mac.
It looks like yes, from the FAQ
Red Hat has worked with the CentOS Project to establish a merit-based open governance model for the CentOS Project, allowing for greater contribution and participation through increased transparency and access.
Did that where I used to work also.
Used Redhat at first, because Redhat support helped get everything set up and working. Once everything was working, they started phasing in CentOS.
To understand this, you have to understand the relationship Red Hat Enterprise Linux has with recompile derivatives. While the compiled RPMs for RHEL cost money and are not redistributable without a license, the source RPMs are nearly all open source. Anyone with a RHEL license can download the RHEL SRPMs and do a recompile. This was great for people who want a RHEL-alike without paying for licenses and CentOS (and then Scientific Linux) came into existence. Red Hat was pleased with this because it gave a cheap way for enterprise customers to try RHEL and eventually become customers who pay for licenses/support.
Then came Oracle Linux who did the exact same thing as CentOS and Scientific Linux, but started charging for licenses and support outside of Red Hat's control. Red Hat wasn't pleased so they started packaging their SRPMs so instead of them containing upstream tarball with RH patch files, they would ship tarballs only or mega huge patch files without comments pointing to the relevent Red Hat bugzilla bug. This made it harder for Oracle to provide support to their customers, but it also had the effect of causing CentOS to get delayed by a good amount every new RHEL release.
Without a quick turnaround on CentOS releases that match RHEL releases, it threatened to kill their "the first one is free" business model. And it probably caused some customers to switch to cheaper Oracle value-added distributors. So Red Hat's only remaining move is to make a relationship with CentOS official. Presumably most of the relationship with be done in private to keep Oracle from gaining an advantage.
Red Hat support can be worth it when you don't want to scour the internet for a solution to changes made between RHEL5 and 6 for example - and just asking a Red Hat tech support guy will be a lot quicker. Some organisations see value in that, aside from the obligatory "point of blame" when things go wrong. Solving problems quickly saves time AND money in various business scenarios, where downtime equals lost profits. YMMV however.
Some info on the finer points of using RedHat simply aren't available on-line, much less will you have anyone to chat with you about them if you are scouring blogs.
Furthermore, RedHat support is actually good, compared to say, Oracle... who despite their thinly veiled attempts to try and eat RedHat's lunch and cut their grass, have pretty horrid support all around. I know orgs that run Oracle applications on RedHat just for RedHat support (despite Oracle's attempts to hijack their own customers on RedHat in an attempt to move them to Oracle Linux)
In addition RedHat does the lion's share of development for the Linux kernel, and other companies with distros that leech from RedHat would likely know less about the dev and design decisions in their own distros that they claim to support.
READY.
PRINT ""+-0
I suspect few desktop users run an OS targeted for "servers" where stability is the number one goal?
RHEL 7 Beta is based off Fedora 19, with a 3.10 kernel. Usually their beta cycles run about 6 months. Oh, and they heavily backport to their stable kernel (it is "stable", not meaning crashes less, but referring too the fact that the API/ABI doesn't change when they release updates).
2.6.0 came out in 2004, 3.0 (the next after 2.0.39) in 2011. You are not being very precise saying 2.6 related to redhat kernel. But, about to your point, Redhat/centos 5.x came with kernel 2.6.18 (released in 2007, still had the same kernel version in RedHat 5.10 that came out last october), and Redhat 6.x, that came out in 2010, had kernel 2.6.32 (released in 2009). As enterprise distribution, what matters is stability, and certification for 3rd party software, not having the latest versions, all is tested with an specific kernel version, and that kernel (and in general, packages) are kept in the same version, backporting/patching fixes when necessary, and you won't have to worry about a newer version of a sofware changing a configuration file format or keywords and stopping working after updating. Anyway, you can still install extra repositories (like EPEL) that will give you newer versions of some packages.
If you want to use something bleeding edge, you can try Fedora, Ubuntu, or another of the desktop distributions
I have had occasion to run into a kernel bug (back when AMD64 was still a new adventure) and, due to being at a large organization that regularly paid Red Hat various sums of cash, was put in direct contact with high level support. I provided them with my analysis of what was apparently going wrong and a C program to reproduce the failure in a short time (otherwise it would only occur naturally after a system had been running jobs for several weeks to months). Within a day or two they sent back a custom patched kernel that fixed the issue, and later rolled that fix out generally in the next update release (though, admittedly, that second part took quite some time). I might be a competent programmer but diagnosing and fixing a fundamental problem in the kernel and then being on the hook if it has undesirable side-effects isn't something I'd want to do myself, nor could I expect such a rapid answer from the community for what was basically a small corner-case problem, but one that was affecting our business. Having the support is what made the difference.
Of course, for many cases, self support and community support can be good enough, but all it takes is one major issue where you can't solve the problem and you're losing revenue and reputation, and all the sudden that "expensive" support starts to look really cheap in comparison.
And I also agree, stay far far away from Oracle Linux if at all possible (heck stay away from Oracle altogether if you can, but that's frequently impractical).
The advantage of RHEL is being able to call somebody when you have a problem that you can't resolve by reading or need to resolve faster than you can on your own. RHEL generally has patches and improvements quicker than CentOS does which is important if you're running a heavily used server exposed to the internet.
I've been quite happy with CentOS and use it in the majority of systems that I set up. However, if I need somebody to call when it crashes and the boss is standing in my doorway demanding to know what I'm doing about a problem, I want to be able to make that all important call to the experts. I have made that call once or twice and I was quite happy in feeling like my company's money was being well spent when I did.
B) Eliminate all the stupid users. This is frowned upon by society.
The clause prevents you from installing a bunch of CentOS servers, paying for one RHEL license and then updating the CentOS with the RHEL repository RPMs (or private repository mirror). You're more than welcome to pay for a RHEL license for one server and update it with the RHEL repository RPMs and then have a farm of CentOS that you update with the CentOS repository RPMs. Other things that are OK: paying for one RHEL to have access to the Red Hat knowledge base and using that information to support your CentOS installs (with CentOS RPMs).
Not only does that just work but so does my approaching 5 year old Windows 7 too!
As a desktop user I do not have to worry about an update killing something because it uses a standard abi like other OSes and unlike Ubuntu throughout 6.x. My scripts will work without breaking, all the apps have matured and are well tested. Driver makers target it, and I keep gnome 2.x and don't have to worry about guis designed for teenagers.
I get a minor update each year! ... Oh and every 5 years I get that huge update 7.x where you Ubuntu guys worked on all the bugs for me :-)
What's to hate about it? I have work to do and do not want to play with operating systems too much.
http://saveie6.com/
Its actually about time. We old timers remember when RedHat was free and support was the money maker for RedHat. Then they split to RHEL and Fedora, that was bad and caused a lot of initial distrust of RedHat. Fortunately, RedHat didn't screw everyone and is doing largely the right thing.
The problem with the RHEL/Fedora split was it made two different strategies. If it were not for CentOS, RHEL may have lost a lot of business. Now that Oracle wants to steal RedHat business, keeping CentOS viable keeps the mind-share of people who neither need nor want support using the equivalent of RHEL while RedHat keeps its customers.
I can see why paying for one RHEL license and then surreptitiously using it to support 1000 CentOS installations is stealing plain and simple.
Don't redefine words. It's a blindingly obvious abuse of the service agreement for RHEL. It's wrong. It's not stealing. Your abuse of language weakens the point you wanted to make.
I suspect few desktop users run an OS targeted for "servers" where stability is the number one goal?
Actually, I used to be working on a CentOS workstation for quite some time and it was a very pleasant experience. The only issue I remember is that I had to manually compile some applications to be able to watch soccer streams during EURO 2012, but I'm pretty sure people at the IT department saw this as a feature rather than a bug ...
OS Reviews: Free and Open Source Software
The only reason RH is behind is they haven't had a major release since 3.x came out.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
I feel your pain. I wish Fedora would go to a 9 month update schedule, it would make me happier.
We probably won't go to 9 months permanently, but it's very likely that Fedora 20 -> F21 will be along those lines as we retool for Fedora.next ideas, and work on improving qa and releng automation.