CentOS and Red Hat
CentOS board member Karsten Wade, who is also Red Hat's engineering manager for CentOS, came to the 2014 Linux Foundation Collaboration Summit to explain how CentOS and Red Hat are joining forces and what it means for the future of both. Back in early January, the two announced that CentOS was joining the Red Hat family. According to Wade, that was the completion of one-and-a-half years of effort to put the two together, but it was just the beginning of actually figuring out what the partnership means.
![[Karsten Wade]](https://static.lwn.net/images/2014/lfcs-wade-sm.jpg)
Wade is a longtime Red Hat employee (12–13 years) who was part of the early days of Fedora. More recently he has worked on more "meta" open source things as part of the Open Source and Standards team. That includes projects like "The Open Source Way" and other, similar initiatives.
A bit of history
When Red Hat made the decision to split Red Hat Linux into Red Hat Enterprise Linux (RHEL) and Fedora, it knew it was leaving some users behind. The company wanted a fast-moving distribution, as well as one that was commercially supportable. That split led to RHEL rebuilds, and CentOS was the most prominent of them. In fact, he said, CentOS might have a bigger user base than RHEL and Fedora combined; no one really knows for sure.
There are some overlaps, but for the most part there are fairly distinct use cases for Fedora, CentOS, and RHEL. Fedora always has the latest and greatest packages; it tends to be ahead of the curve in comparison to other distributions. The differences between CentOS and RHEL are not as sharp. CentOS has probably been used to "beat down" the Red Hat salespeople on the price for RHEL support, Wade said, but the key is that CentOS provides a base that doesn't move quickly and is not going to break (itself or applications running on top of it) on the next update. For open source development, it is sometimes important to have that stable base, he said.
CentOS was interested in working with Red Hat so that it would have more resources both to create that stable base and to add new things on top of the base. Wade said he understands Red Hat's motivations better because he has worked there so long; he is a longtime CentOS user, but a new member of its community. Red Hat knows that the open source development model works, and not just for R&D.
Ultimately, Red Hat is trying to grow its user base. For many years, Linux itself was an interesting platform, but we are moving away from that, at least in some places. For example, OpenStack is the platform of interest to many today—what's underneath is much less interesting. The RDO project is a Red Hat effort to make it easy to get the latest OpenStack code up and running on Fedora, CentOS, and RHEL. Users of RDO just care about OpenStack for the most part.
CentOS had some of the same problems, but were viewing them "from the other side", Wade said. He met CentOS project leader Karanbir Singh at a Puppet conference in 2012. At that point, Wade knew that Red Hat saw the need to have a community distribution with a slow moving base in addition to the fast-moving Fedora. He knew that the company would either create its own rebuild or join forces with the leader, but he couldn't say anything to Singh at that point.
Wade talked with Singh and Fedora project leader Robyn Bergeron for several hours at that conference. One thing he learned was that CentOS had run into a problem when RHEL 6 was released: RHEL no longer shipped the Xen virtualization system. But CentOS had lots of users who wanted to continue using Xen, so CentOS teamed up with Xen to put the virtualization solution on CentOS 6. In that case, the vast majority of core CentOS is still used, but there are some minor tweaks (including a different kernel) atop the stable base.
So the goal for CentOS is to create a next-generation platform that is supported for a longer period of time than Fedora is. Ten years would be good, but most people just want something longer than 13 months, he said, and 2–3 years seemed to be a sweet spot. There will be CentOS variants that mostly ship code from the CentOS repositories, with some differences, and, importantly, with a special interest group (SIG) to feed and care for it. Variants can differentiate at different levels and could include things like variants for storage, cloud, or the Mate desktop.
Bringing CentOS into Red Hat is also meant to help defragment the Linux ecosystem, Wade said. RHEL Rebuilds were proliferating, so he is hoping that some of that energy can be pulled into CentOS by creating some "gravity" around the project. In the end, CentOS is something like the third leg of the stool for Red Hat, and it was needed for Red Hat to grow its communities.
Post-announcement
Many of the organizational and governance decisions about CentOS moving forward were deferred until after the announcement so that they could be made in public. Every other board meeting is now held in Google Hangouts so that people can see what's going on (and put faces to the participants). One of the more prominent community rebuilds, Scientific Linux, has been participating as well. It has been invited to join the community, and a board seat is being saved for it, but they are currently "talking among themselves" about how to work with CentOS. It is possible that it could become a SIG or that its community may want to keep its autonomy; time will tell, Wade said.
SIGs started cropping up right away. Around a dozen have been discussed, but the board wants to see broad SIGs, so it would rather there be a storage SIG instead of a Ceph SIG, for example. Four SIGs have been accepted so far, including core (the base distribution), virtualization (both in CentOS and of CentOS), and cloud instances (creating CentOS images for various cloud providers). More will be coming soon, he said.
Historically, there have been perceptual and actual barriers to participation in the CentOS project. Wade has something of a personal crusade to lower those kinds of barriers, and CentOS won't be any different in that regard. Singh has said that CentOS never really was an open-source project because it didn't really produce any software, but that is changing with SIGs and variants. There is a lot of "pent-up energy" for CentOS to be an open-source project, Wade said, and that energy will start to move into the project now.
Instead of roughly one-and-a-half full-time people on the project, there will now be five. But there will also be support from the Open Source and Standards group at Red Hat, so that the team can focus on technical problems rather than having to order T-shirts or organize conferences. The team is firewalled from the RHEL team, however.
One of the outcomes of that firewalling is that CentOS will get its own build system, which will provide visibility and access to users. It will likely be based on Fedora's koji build system. There will be two parallel build systems, actually, one for the core SIG and one for all of the other SIGs. To start out, the release process for SIGs will be somewhat akin to the Apache model: SIGs will demonstrate that the release is sound and it will be signed and released. After some time, the SIG will be able to sign its own releases. One other thing to note: it will be possible for people outside of Red Hat to join the core SIG, though it will likely be a rather arduous process.
All in all, Wade painted a highly optimistic picture for the future of CentOS and Red Hat. It could be argued that CentOS already had a bright future, but it should be able to do a lot more with Red Hat's help. He also did not leave Fedora out of the picture, as it is an integral part of the family, complementary in many ways to both RHEL and CentOS. Fedora effectively becomes the upstream for many of the add-ons that will be shipped in the CentOS variants, for example. While it may have seemed a bit puzzling at first, CentOS joining Red Hat seems to make more and more sense over time.
[ Thanks to the Linux Foundation for supporting my travel to the Collaboration Summit. ]
Index entries for this article | |
---|---|
Conference | Collaboration Summit/2014 |
Posted Apr 3, 2014 12:38 UTC (Thu)
by dag- (guest, #30207)
[Link] (18 responses)
One of the strengths and attractiveness of CentOS always was that CentOS strived to be 100% compatible to what Red Hat shipped. Obviously 100% compatibility was not possible before, but now it can be. Yet that goal seems to have disappeared.
The wiki (http://wiki.centos.org/FAQ/General?action=diff&rev2=9...) used to state:
> CentOS conforms fully with the upstream vendors redistribution policies and aims to be 100% binary compatible
but since 2014-01-07 only says:
> CentOS conforms fully with the upstream vendors redistribution policies and aims to be functionally compatible with the upstream product.
And from Red Hat's FAQ (http://community.redhat.com/centos-faq/#_centos_and_red_h...):
> Only Red Hat produces, validates, and distributes authenticated Red Hat Enterprise Linux binary packages with certified and tested ISV and IHV compatibility.
So while I assume this is the reason to have a firewall between the CentOS project and the RHEL product, why this change of heart ?
Posted Apr 3, 2014 12:42 UTC (Thu)
by dag- (guest, #30207)
[Link]
That's not at dispute.
Posted Apr 3, 2014 16:11 UTC (Thu)
by dowdle (subscriber, #659)
[Link] (14 responses)
Posted Apr 3, 2014 18:45 UTC (Thu)
by NightMonkey (subscriber, #23051)
[Link]
"Wording" matters.
Posted Apr 3, 2014 18:49 UTC (Thu)
by dag- (guest, #30207)
[Link] (12 responses)
Yet, only "functional" compatibility is promised.
Posted Apr 4, 2014 23:37 UTC (Fri)
by giraffedata (guest, #1954)
[Link] (11 responses)
To me, they're synonomous, but "functional compatibility" is plainer English.
Posted Apr 6, 2014 1:54 UTC (Sun)
by egoforth (subscriber, #2351)
[Link] (1 responses)
Posted Apr 6, 2014 3:31 UTC (Sun)
by raven667 (subscriber, #5198)
[Link]
Posted Apr 8, 2014 15:48 UTC (Tue)
by drag (guest, #31333)
[Link] (8 responses)
100% binary compatibility as a ideal state will never really be achievable, but it means that they are going to go all out bug for bug compatibility with as little regard as possible to improvements or bugs or user's concerns. So they, essentially, just slavishly try to match Redhat as close as possible.
Functional compatibility means that they are free to change things and improve things independent from Redhat as long as they try to make sure not to break compatibility with the mothership.
Posted Apr 8, 2014 16:32 UTC (Tue)
by dag- (guest, #30207)
[Link]
But:
1. 100% binary compatibility would be possible today, if CentOS and Red Hat agreed that this is useful.
2. CentOS being free to change things and improve things without ensuring to break compatibility is an impossible task. If 100% compatibility is impossible because of differences in environment and tools (at the time of rebuilding) it surely is impossible to attempt the same while changing and improving things.
Besides, nobody would be in favor for CentOS to change/improve things and deviate from RHEL, it would defeat its purpose IMO.
In the light of things, I still find that change in wording very peculiar, and generally unwanted/unnecessary.
Posted Apr 10, 2014 15:22 UTC (Thu)
by giraffedata (guest, #1954)
[Link] (6 responses)
This is a circular definition. What compatibility is it they cannot break in order to have functional compatibility?
What compatibility is there to speak of besides 100% binary compatibility?
Posted Apr 20, 2014 14:51 UTC (Sun)
by hughesjr (guest, #29949)
[Link] (5 responses)
By functional compatibility we mean bug for bug, link the same libraries, the same file lists in the package, etc. Basically, what we have been doing since the beginning and intend to continue to do in CentOS.
The real issue here is that we now understand that we will never have full binary compatibility since we build only on released CentOS packages and Red Hat is using a completely different staged build system. Red Hat sometimes builds a package into their staged build system multiple times between public releases, so they may do builds of packages against some library versions that are not released publicly. CentOS only builds against our released repositories. This means there always will be slight differences between CentOS and RHEL. As such, we are just trying to be more accurate in our description.
Posted Apr 20, 2014 15:59 UTC (Sun)
by giraffedata (guest, #1954)
[Link] (4 responses)
...
The real issue here is that we now understand that we will never have full binary compatibility
Are you saying there are RPMs that work on RHEL but not CentOS? I.e. there are RPMs with which Red Hat is compatible but CentOS is not? If so, the functional compatibility is limited (because installing and running packages from RPMs is one of the significant functions of an OS), and you really should clarify that whenever you say "functional compatibility."
Posted Apr 21, 2014 2:34 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link] (3 responses)
Posted Apr 22, 2014 14:14 UTC (Tue)
by hughesjr (guest, #29949)
[Link] (2 responses)
However, if something runs on RHEL and not CentOS (and if that is for any other reason than the writer of the program specifically looks at something like /etc/redhat-release and runs only on RHEL and not CentOS on purpose) ... then this is a bug and we will figure out why it is not working and fix it.
So the answer is no, we are not saying anything about any changes in CentOS ... it is the same as it has been with respect to building RHEL sources. We are just telling you what kind of compatibility we have always provided.
Our goal is exactly what you want ... compile the exact sources, with the only changes in the core distribution being changes for branding and artwork.
Posted Apr 22, 2014 15:57 UTC (Tue)
by giraffedata (guest, #1954)
[Link] (1 responses)
It sounds like there are people who think "full binary compatibility" means bit for bit identical, thus totally misunderstanding the word "compatibility." If so, it was a good idea for CentOS to stop using the term.
For anyone who is unclear on compatibility: it comes from latin meaning "ability to lie together" and refers to things that can coexist and work together.
We're already taking license with the term when we say two things with the same role are compatible with each other (for example, a classic Dell PC-clone computer being compatible with an IBM PC). In that case what it means is the two things are compatible with the same things.
Posted Apr 22, 2014 16:20 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
Posted Apr 4, 2014 2:29 UTC (Fri)
by salimma (subscriber, #34460)
[Link] (1 responses)
Posted Apr 4, 2014 12:07 UTC (Fri)
by dag- (guest, #30207)
[Link]
If that would be the case, replacing it with "functionally compatible" doesn't improve anything as it also applies only to the "core". So it does not explain the change.
Also the effort to rebuild CentOS core with the goal to make it as compatible as possible to RHEL, is a wasted effort if only the builds would be made identical to RHEL, rather than a reverse engineered effort with different tools, a different process and a different environment.
Posted Apr 3, 2014 13:01 UTC (Thu)
by jnareb (subscriber, #46500)
[Link] (3 responses)
Posted Apr 3, 2014 13:19 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Apr 3, 2014 15:38 UTC (Thu)
by seyman (subscriber, #1172)
[Link] (1 responses)
It's "Special Interest Group", Fedora's equivalent of teams.
Posted Apr 3, 2014 18:03 UTC (Thu)
by mattdm (subscriber, #18)
[Link]
And for better or for worse, that means it is very different from the way Fedora uses the term -- in Fedora, SIGs are informal groups of people who share an interest (and maybe a mailing list) but there is no necessary structure beyond that. The subprojects/teams/working groups are more formal, and it appears that the CentOS SIGs will be more like that.
CentOS and Red Hat
CentOS and Red Hat
CentOS and Red Hat
CentOS and Red Hat
CentOS and Red Hat
What is your perception of the difference between 100% binary compatibility and functional compatibility?
CentOS and Red Hat
CentOS and Red Hat
I'm not sure what "functional compatibility" means.
CentOS and Red Hat
CentOS and Red Hat
CentOS and Red Hat
CentOS and Red Hat
Functional compatibility means that they are free to change things and improve things independent from Redhat as long as they try to make sure not to break compatibility with the mothership.
CentOS and Red Hat
CentOS and Red Hat
By functional compatibility we mean bug for bug, link the same libraries, the same file lists in the package, etc.
CentOS and Red Hat
CentOS and Red Hat
CentOS and Red Hat
CentOS and Red Hat
CentOS and Red Hat
One of the strengths and attractiveness of CentOS always was that CentOS strived to be 100% compatible to what Red Hat shipped. Obviously 100% compatibility was not possible before, but now it can be. Yet that goal seems to have disappeared.
A likely explanation is that core (with its own build system) is the part that is 100% binary compatible with RHEL, while the different SIGs, by definition, are not, as they build on top of CentOS and in some cases even replace core components such as the kernel (e.g. for Xen support)
CentOS and Red Hat
What is SIG
What is SIG
What is SIG
What is SIG
> It's "Special Interest Group", Fedora's equivalent of teams.