Red Hat To Help Develop CentOS 186
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.'
Bingo (Score:5, Funny)
Odd... (Score:3)
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...
Re:Odd... (Score:5, Insightful)
At a guess, it could be the same logic that makes Bill Gates not care that people pirate Windows. Sure, they might not be paying you for all the effort you put into the product, but one day, when they can pay, yours will be the system that they know, so they'll come to you.
Re:Odd... (Score:5, Interesting)
So some guy fiddling around with CentOS to knock together a website has skills which are easily transferrable to Red Hat because it's almost identical aside from some logos and text.
Re:Odd... (Score:5, Insightful)
If given a choice, I'd imagine that Red Hat would have users choosing CentOS than Ubuntu if they are looking for a free Linux distribution with longer term support. At least Red Hat can then give them the option to easily upgrade to RHEL without forcing them to reinstall their systems.
Switching between the two distributions (or even Scientific Linux) is already as easy as switching repos and updating a few branding specific packages. I'd imagine that Red Hat would make the process even easier to do so in the next release.
Re:Odd... (Score:5, Interesting)
Re: (Score:3)
At the most basic level, there are no barriers at all. RedHat's self-support subscription (~$300 annually per server) gives you access to their non-public knowledge base. It fully applies to CentOS, there's nothing either RedHat or CentOS or you would need to do to use it.
Re:Odd... (Score:4, Interesting)
"At least Red Hat can then give them the option to easily upgrade to RHEL without forcing them to reinstall their systems."
It's good for Red Hat in that knowledge of CentOS means knowledge or Red Hat and time investment on CentOS means *not* investing time in anything else but... please go read what Red Hat has to say about upgrading major releases: "please, don't do it; you should reinstall".
Re: (Score:3)
please go read what Red Hat has to say about upgrading major releases: "please, don't do it; you should reinstall".
They weren't saying upgrading versions, they're referring to a licensing/support "upgrade" from CentOS to the equivalent RHEL, which due to their near-identical nature is supposedly a matter of switching repositories and changing out some branded packages. For example CentOS 6.5 becomes RHEL 6.5.
I don't care much for the RPM toolset so I don't know how practical such moves are in the RH world, but it seems like a feasible idea.
Re:Odd... (Score:4, Informative)
It's very easy to do. I've done the reverse (RHEL to CentOS) on a few occasions. It is generally as simple as installing a single -release rpm.
Re: (Score:2)
It's really that easy? Didn't know that. (I'm a desktop user who runs Fedora and have zero experience with "enterprise" RedHat/CentOS)
Re: (Score:2)
I too have done it and it really is that simple. We tend to do that when we're moving servers out of 'critical' production, and can no longer justify paying for support.
Re: (Score:2)
Been there, done that, in both directions. It shouldn't take more than 5 minutes. Seriously.
Re: (Score:2)
Redhat/CentOS is no substitute for Ubuntu desktop (Score:2)
The Redhat/CentOS kernel is about five years old. Still using version 2.6.
I suspect most desktop users want something newer than that.
Re:Redhat/CentOS is no substitute for Ubuntu deskt (Score:5, Informative)
Re: (Score:2)
And there is a distro for just that purpose:
http://distrowatch.com/table.php?distribution=stella [distrowatch.com]
Personally I probably wouldn't run something like CentOS/RHEL on my primary desktop or laptop since I like to run all the latest stuff without too much of a wait. But if I had a secondary "work" machine and wanted absolute rock-solid stability and unsurpassed support (ten years), then such an OS would be excellent. Running a machine with for the most part only minor updates being required and no major, potential
Re: (Score:3)
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 ...
Re: (Score:2)
I suspect few desktop users run an OS targeted for "servers" where stability is the number one goal?
It's not targeted at servers.
RHEL Server is targeted at servers.
RHEL Desktop and RHEL Workstation is targeted at desktops/laptops.
Re: (Score:2)
There's no reason not to. Desktop users want "stability" too! CentOS/RHEL users can simply add some more repos to get more recent software packages.
The only reason you might avoid a "stable" release, is if you have newer hardware that isn't supported by the old, "stable" kernel and supporting software. Personally, I was able to manage that just fine by compiling my own Fedora 3.x kernel SRPM on CentOS6...
Re: (Score:2)
It might sound like work, but it's a lot less effort than living with all the horrible nasty bugs that come with a Fedora distro.
What nasty bugs are those? I'm a Fedora user and I haven't ex ^H^H
I feel your pain. I wish Fedora would go to a 9 month update schedule, it would make me happier. When I jumped to Linux on x86 from PPC (long story), I narrowed down my distro choices to either CentOS or Fedora. I chose Fedora...maybe I should have gone CentOS but I haven't had too many major problems with Fedora.
Recompiling a kernel can be "guru" work...yes I've done it by following a "recipe" in a book but I haven't done it in years,
Re: (Score:3)
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.
Re: (Score:2)
This is exactly the reason that I have a workstation in our lab running Fedora instead of CentOS. I'd prefer to use a distro closer to RHEL, since that's what run some of our expensive instruments, but the drivers just weren't there and it's really not worth my time to sort out all the dependencies or compile a newer kernel without breaking other stuff in order to get support for newer hardware.
I'd also like to know what nasty bugs you're talking about in Fedora releases. I've had a few non-critical package
Re: (Score:2)
Myself, I'd absolutely love to run RHEL or CentOS on a desktop if I were using Linux on a desktop. You don't have to worry about things becoming fucked up with upgrades. For the few things I test on Linux, I always run CentOS in a VM, but my daily desktop runs on OS X.
Re:Redhat/CentOS is no substitute for Ubuntu deskt (Score:4, Informative)
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).
Re:Redhat/CentOS is no substitute for Ubuntu deskt (Score:5, Informative)
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 [fedoraproject.org]) 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
Re: (Score:2)
Re: (Score:3)
The only reason RH is behind is they haven't had a major release since 3.x came out.
Re: (Score:2)
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.
That's true for most software in RHEL, but not the kernel. It is heavily updated in each point release. Take a look at the release notes some time just to see what gets in there. RHEL 5 uses the 2.6.18 kernel for example, yet supports both KVM and ext4; features that Linux didn't have at that point.
Re:Redhat/CentOS just works on the desktop (Score:4, Insightful)
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.
Re: (Score:2)
The Redhat/CentOS kernel is about five years old. Still using version 2.6.
I suspect most desktop users want something newer than that.
I suggest that you take a closer look at the acutal kernel source code. The version number is 2.6.32, but that's just because that was when Red Hat _forked_ it from kernel.org. They continiously backport features and hardware support during the production support life cycle.
Re: (Score:2)
The RHEL/CentOS kernel does get security and bug fix backports from later kernels, but the reason it runs such an "old" kernel is for stability reasons. Most Windows desktop users never upgrade their OS to a newer major release during the lifetime of their PC (because it costs money and can be a hassle - remember most of the world's desktops are running the OS that was pre-installed when the machine was bought), but apparently most Linux desktop users are constantly chasing the bleeding edge if you're to be
Re: (Score:2)
The RHEL/CentOS kernel does get security and bug fix backports from later kernels, but the reason it runs such an "old" kernel is for stability reasons.
It isn't stable. The kernel is heavily updated in every point release including actual features, not just bug fixes.
Re: (Score:3)
Switching between the two distributions (or even Scientific Linux) is already as easy as switching repos and updating a few branding specific packages. I'd imagine that Red Hat would make the process even easier to do so in the next release.
Actually their FAQ says that isn't an option, you have to re-install from scratch to get an officially supported system (as the binaries are not exactly the same).
Re: (Score:3)
No, it's perfectly fine for switching between RHEL and CentOS as CentOS is fully binary compatible with RHEL (that is one of the project goals) so if it doesn't work for compatibility reasons then it is a CentOS bug.
SL is not quite as strict on compatibility, but it should still work fine even though it's unsupported.
Oracle Linux even provides a utility to switch from other EL distros to Oracle and all it does is switch the -release package and a couple other key packages over (although I don't recommend Or
Re: (Score:3)
Oracle is a less expensive RHEL,
No, Oracle rips off RHEL just like CentOS SL and others do, but Oracle doesn't add value to RHEL, instead they compete with RedHat and with less expensive you get a fourth party to the sources (after they have gone through the original project, then Fedora, then RHEL) trying to provide support for something they only cloned off of someone else, whereas RedHat are pretty much 2nd party to the sources and have a lot more knowledge on them, so you get what you pay for in terms of support or with Oracle even le
Re: (Score:2)
One of the most interesting bits of the announcement for me is the deprecation (and future removal) of the SRPMS at ftp.redhat.com ...
Instead the sources will be provided directly at git.centos.org ...
That could have very interesting implications on SciLi/OEL...
Re: (Score:2)
Oracle less expensive? They offer it for less than ~$300 per year per server? Seriously?
Re: (Score:2)
RedHat realized that it can't make money off CentOS users anyways. If you make it really hard to use a free copy of RedHat EL, they will just move onto some other distribution. It's not like there aren't alternatives.
Re: (Score:2)
Kind of, I think it's more like RedHat is targeting a certain kind of customer with their business. They want to get the big spending Enterprise customers who are willing to fork out a lot of money for a product with major backing behind it, RHEL is one such product but there are other companies that also sell enterprise Linux distros, not to mention all the other OSes out there that RedHat has to compete with.
They don't loose money on CentOS users because CentOS users generally do not fall into their targ
Makes sense, but weird (Score:5, Insightful)
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.
Re: (Score:2)
The question is, how will RH help Centos? That isn't very clear from this announcement.
Help them reduce the lag between the time something is released for RHEL and CentOS.
Re:Makes sense, but weird (Score:5, Insightful)
There's a little more to it than that. The announcement doesn't cover the history CentOS has had with RHEL, but when CentOS people found bugs or made improvements, they would pass the info back to RHEL. It makes sense for CentOS because when they make improvements, they can hope that in the next release, they can just reuse RHEL work rather than having to apply the patches each time. It made sense for RHEL because they were getting a better product to offer their customers than they would have without the CentOS contributions, and by integrating the work of their biggest potential competitor, they decrease the incentive to move to somebody who has patches and improvements they don't.
It's rare to read about "synergy" between companies that actually makes sense, but RHEL and CentOS have benefitted from each others' work. The more RHEL helped CentOS, the better RHEL software was. The more CentOS helped RHEL, the better CentOS software was. This move to actually formalize their relationship makes sense for both of them.
Re:Makes sense, but weird (Score:4, Informative)
"The question is, how will RH help Centos? That isn't very clear from this announcement. "
It does mention that we (RH) have hired the core CentOS devs - that is, we're giving them a paycheck to work on CentOS full time, we're not hiring them to do other stuff instead. And it mentions that RH has offered CentOS some resources to improve their build infrastructure, though CentOS is still deciding whether to take that offer up or not.
Re: (Score:2)
GPL doesn't limit the negative actions you can take if someone exercises their GPL rights. For example, IIRC if you're a RHEL customer with a subscription and you leak their RPMs or SRPMs, even if they are subject to GPL, your subscription is terminated and you're often banned for life from ever becoming their customer again. Seriously.
mindshare vs. Oracle, Canonical, Microsoft (Score:5, Insightful)
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.
Re: (Score:2)
> dick move ... dick move ... classic RH ...
Larry Ellison, is that you?
Re: (Score:2)
Re: (Score:2)
Re:mindshare vs. Oracle, Canonical, Microsoft (Score:4, Informative)
Originally, Red Hat Linux was free.
Red Hat Linux is *still* free - just download [redhat.com] and install it.
Red Hat charges for *support*.
RHEL is only free as long as all you want is the source. The binary costs money, even if you go with the cheaper "self support" option.
Re: (Score:2)
If RH does pull an Oracle (unlikely) there is always scientific linux [scientificlinux.org] as an option.
Re:Odd... (Score:4, Insightful)
Closer ties prevents Oracle from "helping" CentOS instead.
Re: (Score:2)
I honestly don't think that was ever a concern. The CentOS community tends to have a dislike for Oracle almost as much as RedHat does.
Re: (Score:3)
Well when Oracle published and were pushing this it didn't exactly foster good feelings:
http://linux.oracle.com/switch/centos/ [oracle.com]
Re: (Score:2)
Re: (Score:3)
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...
Didn't this use to be the norm?
A paid distro, with full support and a community distro side by side?
Suse Linux and Opensuse?
Red Hat and Fedora?
Re: (Score:2)
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...
Well, as the saying goes, a rising tide lifts all boats.
RedHat gains in a number of ways:
If it means faster CentOS development, good (Score:3)
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.)
Re: (Score:3)
Hopefully, from the FAQ [redhat.com]
Will this new relationship change the way CentOS obtains Red Hat Enterprise Linux source code?
Yes. Going forward, the source code repository at git.centos.org will replace and obsolete the Red Hat Enterprise Linux source rpms on ftp.redhat.com. Git provides an attractive alternative to ftp because it saves time, reduces human error, and makes it easier for CentOS users to collaborate on and build their own distributions, including those of SIGs.
Re:If it means faster CentOS development, good (Score:5, Interesting)
you know, in some sense you just convinced me that the CentOS 6 debacle could well have been the motivating factor here. Basically RH was cheapskately depending on CentOS for it's overall business strategy (same way microsoft turned a blind eye to piracy in China), and CentOS basically retaliated by being unable or unwilling to invest energy to get the early v6 releases done anywhere near in time to the corresponding RH releases. And thusly, RH now has to respond by actually ponying up the effort to keep the CentOS community more viable. I.e. the quicker they can get people on CentOS-7, the quicker they can cash in on the substantial percentage of those that eventually want the RHEL7 support level. For this and other good reasons mentioned in the comments, I wonder why I'm still so shocked by this move... I guess it's like the end of cannabis prohibition. Something so blazingly obviously ignored for so long, that when people finally get around to doing the obvious right thing, it's - breathtaking. Sad, but true.
Re:If it means faster CentOS development, good (Score:4, Informative)
Redhat does not want CentOS to quickly produce compatible releases, doing so would encourage people to use CentOS rather than buying Redhat.
The CentOS 6 debacle was at least partly caused by:
1) Redhat not making publicly available some information regarding rebuilding the sources.
2) CentOS being a closed development group that refuses to accept any help from outsiders. Scientific Linux is another clone of Redhat that was able release their version of Redhat 6 much faster.
Re: (Score:2)
Scientific Linux isn't as close to RedHat as CentOS. CentOS is fully, 100% binary compatible, while Scientific Linux doesn't try to be. This is rarely a problem, but occasionally you'll come across some huge commercial softwa
This is more about Oracle Linux (Score:5, Interesting)
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.
Re:This is more about Oracle Linux (Score:4, Interesting)
Don't forget Amazon EC2, etc.. Where you can get Ubuntu for cheap or RHEL for more $$ with a subscription, but installing CentOS you have to go through the "Store", I'm sure RedHat would prefer if people installed CentOS instead of Ubuntu..
Re: (Score:2)
Re:This is more about Oracle Linux (Score:5, Interesting)
Close, but there are a few important points to add:
First, compiling CentOS 6 wasn't just a matter of re-compiling the SRPM's. The big patches don't make recompiling harder, it makes support harder (which is meant to hurt Oracle, as you said).
What killed the release of CentOS 6 in a timely manner was all the build dependencies. To get an exact binary-compatible RPM for foo.el6 you needed to build it on, say, Fedora 13, with libbar-verisonX.Y.Z.fc13 installed. It wasn't self-hosting or documented how to build el6. Scientific Linux came out much more quickly because they didn't care about binary compatibility.
Why is this important? To validate the security of both RHEL and CentOS. If you can reproduce the binary from source you're an order of magnitude better off than trusting a blob. If you have all the same dependencies as your upstream, you can get third parties to also certify you.
After some initial handwringing about protecting Redhat's interests, CentOS agreed to disclose the build process so others could validate their work. The arguments about how it was going to happen lasted a few months, but came out on the side of openness.
I can't imagine that CentOS will abandon this transparence for el7, because they would lose the community's trust in the code. So the leverage against Oracle has to be something else. There are other ways to marginalize Oracle's offering, and Oracle itself participates in that to a certain degree.
Re: (Score:2)
Re: (Score:2)
What killed the release of CentOS 6 in a timely manner was all the build dependencies. To get an exact binary-compatible RPM for foo.el6 you needed to build it on, say, Fedora 13, with libbar-verisonX.Y.Z.fc13 installed. It wasn't self-hosting or documented how to build el6. Scientific Linux came out much more quickly because they didn't care about binary compatibility.
I don't think anyone really cares about binary compatibility. I cannot think of a single operational advantage that this gives - apart from "narf, the checksums match what I could have paid for". The massive migration away from CentOS in version 6 proved this.
Re: (Score:2)
Apart from anyone wanting to run software certified for RHEL, you mean?
Re: (Score:2)
Binary compatibility does not mean that the checksums match.
It means that every binary RPM has the exact same library version linkages and dependencies.
Re: (Score:3)
One of the big slowdowns for getting 6.0 out the door was getting 5.6 and 4.9 out the door.
I have rebuilt CentOS 5 from source on Itanium (IA64) and the step from 5.5 to 5.6 was rather interesting, and took a lot of thought as to which versions of certain libraries would build properly and needed to build properly in a very specific order (I don't recall right off hand the details, since it's been over a year since I did it, but there was a fairly substantial library uprev about halfway through the rebuild
Re: (Score:2)
You're imagining connections that aren't there. CentOS had an internal political problem, including GPG key owners and source control repository owners, who went offline and were not responsive to requests. With their small, closed group of maintainers, and with Karanbir Singh being the only one who shows up on the mailing list, well, it was late because they didn't ask for, and actively refused, the help of dozens of competent people who offered to help but couldn't even get one word about the CentOS build
Re: (Score:3)
Sigh. Much of this is incorrect. Only the kenel package was changed to put all the patches into a single conglomeration. And this had nothing to do with the CentOS 6.0 delay. Why should CentOS care about the format of the patches? Patches are patches. CentOS (and Scientific Linux for that matter, and the others) doesn't care about the individual patches; just the entire batch, and there they are. Understand that CentOS does not do its own bugfixes. It just propagates those originating from RHEL.
The hold-up
Re: (Score:2)
Re: (Score:2)
And that is precisely what happens!
Re:This is more about Oracle Linux (Score:4, Interesting)
Re: (Score:2)
Why would they? Do you have any understanding of the relationshipo of CentOS SRPMs to RHEL SRPMs?
Re: (Score:2)
So what's to stop Oracle from using CentOS srpms instead?
Because then they would be going from being a derivative to being a derivative of a derivative.
Re: (Score:2)
The same thing that stops them from using Red Hat's src.rpms.... that is, 'nothing whatsoever.'
Crap crap crap crap damn (Score:2)
Red Hat has piles of cash, CentOS (at best) has piles of pennies. This is not a relationship of equals. I not only use CentOS because it is free but because I don't like the flavor of Red Hat; to me it is the most MS of Linux with Ubuntu a far distant second.
When Oracle snagged MySQL
Makes perfect sense (Score:5, Informative)
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.
Re: (Score:3)
Remember that RedHat used to be a workstation / desktop distribution. Then it moved into server. With server there was a desire for much longer support windows, more stability.... In general all the big Linux vendors (Ubuntu being an exception) moved towards server (or embedded) and away from desktop. Making Fedora open gave them a way to experiment without polluting the (now) server brand with unreliable software. Honestly it makes a lot of sense. I never found it suspicious.
My thoughts on this. (Score:2)
I posted this on G+, but figured I would post it here too.
---------------
As a user of RHEL and CentOS, I use each for specific purposes. Several of the purposes I use CentOS for, Redhat wants me to use RHEL for. Now they could easily make CentOS less of an acceptable option almost forcing me to use RHEL since I use RH as my standard infrastructure distribution.
CentOS has always taken revenue away from RH where a full blown license of RH wasn't necessary and RH knows this. I have no doubts this move is to
Re: (Score:2)
I think Redhat has been a very good influence on and partner in the OSS movement for a long time. If I trust any company to get involved with CentOS and not dick around, but try to actually make it better, it's RedHat. Generally nice folks trying to make money and the world a better place. And not necessarily in that order.
Voltron! (Score:2)
http://arstechnica.com/information-technology/2014/01/red-hat-and-centos-become-voltron-build-free-operating-system-together/ [arstechnica.com] sayus it will be a Voltron together! :P
Scientific Linux (Score:2)
As long as we are on the topic of Cent. Anyone know the popularity / status... of Scientific Linux. Scientific Linux has some differences in RPMs so it is a bit further away but I'd think that they would want to support it if they offering a support / conversion service. Anyone have any insight?
Re: (Score:2, Funny)
...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...
Comment removed (Score:5, Insightful)
Yes, it's worth it (Score:5, Informative)
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).
Re: (Score:3)
"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)"
There are, as you can probably imagine, a hell of a lot of hoops a patch has to jump through before it lands in a stable RHEL kernel update =)
Re: (Score:3)
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.
Re:We're moving everything to Centos.... (Score:4, Insightful)
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.
Re:Are they moving actual open community developme (Score:4, Informative)
It looks like yes, from the FAQ [redhat.com]
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.
Re: (Score:2)
The FAQ also admits that Red Hat will now owns a majority of the board members, and the board can only take new members via a majority of the board agreeing.
It's a takeover.
Re: (Score:2)
"As part of this though, are they going to be moving to an actual open and inclusion development process for CentOS?"
No. They get supermajority in the governing board. Red Hat controls the show from now on:
* Ralph Angenent - ???
* Tru Hyunh - ???
* Johnny Hughes Jr - redhat
* Jim Perrin - redhat
* Karanbir Singh - redhat
* Fabian Arrotin - redhat
* Carl Trieloff - redhat
* Karsten Wade - redhat
* Mike McLean - redhat
Quite a clever move. With Fedora they got community approval and support for their betatesting pro
Re:Will RedHat soften its contract stance? (Score:5, Interesting)
Re: (Score:2, Informative)
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.
Re: (Score:2)
Color me baffled. It is ridiculously simple to add EPEL and the other add-on repos to CentOS. I do it exactly the same way on CentOS as on Scientific Linux (and PUIAS, etc): "yum localinstall "http://blah/blah". You are on your own with any of these third party repos on any of these distros. As for atrpms: [shudder].
Re: (Score:2)
It's pretty simple, but you can get in a bit of a bind dependency wise if you aren't careful which ones you mix and match. Nothing that makes the sky fall in, though.
I guess that's what you get when you try to use a servery distro and try and use it for desktopy things.
Re: (Score:2)