The open source world is constantly evolving, and new Linux distributions tend to appear whenever there is a need for them. Rocky Linux  just appeared last year, partly in response to a shake-up in the enterprise Linux space, but, as is often the case in the open source world, change can lead to opportunity. Rocky is already finding its way into professional server rooms, workstations, and cloud instances.
What is Rocky Linux and where did it come from? The best way to tell the story is to start from the beginning.
A Bit of History
Once upon a time, a free and open source OS called Red Hat Linux served as a cornerstone for the Linux community. Although Red Hat the company was a for-profit business, Red Hat Linux was very much a community effort. Anyone could use it, and many volunteers around the world gave their time for testing, development, and help forums.
Then one day Red Hat (the company) announced that it would no longer provide a binary version of their flagship OS for free download. The binary version would instead require a subscription, which came at a cost and included some support services. If you’re wondering whether charging for Linux is consistent with Linux’s GNU General Public License (GPL), rest assured that it is. The GPL requires that the source code be made available if the program is modified – it doesn’t require the distributor to circulate the compiled, binary version for free. As long as Red Hat posted the source code somewhere for download, they were free to charge whatever they wanted for the binary version – and they charged every bit as much as Microsoft was charging for Windows at the time. (Why not, since Linux was better than Windows?)
In an effort to maintain their ties with the Linux community, Red Hat announced that they would indeed still provide a free version of Linux, which they dubbed Fedora. Many users made the switch from Red Hat to Fedora, and Fedora continues to have fans to this day, but everyone knew that Fedora wasn’t exactly the same. First of all, it was upstream from Red Hat Enterprise Linux (RHEL) and therefore did not face the same level of testing. Secondly, it was missing many of the tools and features included with RHEL. Red Hat Linux had morphed into the familiar duality of a “community” and an “enterprise” edition, like so many other open source products in the corporate space.
But the GPL meant they couldn’t exactly put their enterprise code away forever. The source code was still out there, as was required by the terms of the GPL, and anyone who wanted to go to the trouble could take the source, remove the trademarks and other proprietary components, and then compile it and give it a different name. At the heyday, several projects offered free, recompiled versions of RHEL. Over time, a leader emerged among the RHEL clones, and it was CentOS. The CentOS community had a loyal community of users and volunteers, and it ran on file servers, web servers, and corporate workstations around the world. Whenever Red Hat put out a new version of RHEL, the CentOS team would perform the necessary adaptations and put out a new version of CentOS. CentOS became one of the most popular Linux variants – and why wouldn’t it be: It was absolutely free, and it came with all the testing and refinements of an enterprise-grade Linux.
In 2014, Red Hat announced that it would sponsor the CentOS project and hired several of its developers. Their game plan had changed by that point, and they didn’t see it as a problem to maintain free and subscription versions of the same code. It seemed they had come to the view that it could actually help them sell RHEL if users would get started on CentOS and then make the change to RHEL when they were ready to sign on for technical support.
IBM’s acquisition of Red Hat caused a reordering of priorities, and the company changed course again in 2020, announcing that CentOS would no longer be a clone of the enterprise edition. It would still exist, but it was relegated to an upstream status, much like Fedora.
Once again the community scrambled, searching for a new distro that would play the role that CentOS had played for so long. One of the leading contenders to emerge as a free Linux based on RHEL source is Rocky Linux.
On the same day that IBM and Red Hat announced they were moving CentOS upstream, CentOS co-creator Greg Kurtzer floated the idea of starting a new project that would continue to work with the latest Red Hat Enterprise source. As a CentOS veteran, Kurtzer was interested in more than an enterprise code base – he was also tuned in to the community and focused on the process.
The founding sponsor for the Rocky project is CIQ , a company with around 50 employees that provides Rocky support and offers add-on components and services. Unlike RHEL, however, Rocky is an independent project that has several other sponsors, including AWS, Google Cloud, and Microsoft Azure. The storage company 45Drives, another sponsor, uses Rocky as a base for their storage platform. The Sponsors page at the website  lists 12 sponsors so far, and Rocky is looking for more.
Rocky bills itself as a system that is “…designed to be 100% bug-for-bug compatible with Red Hat Enterprise Linux,” which means the latest version of Rocky comes with all the new stuff in the latest version of RHEL. Rocky 9 has all the features and updates you’ll find in RHEL 9. Like other enterprise distros, Rocky doesn’t purport to offer the most cutting-edge, experimental components. The enterprise audience is more interested in stability, thorough testing, and hardware compatibility. Like RHEL, Rocky offers regular updates and 10 years of support for each release.
The Rocky developers strive for seamlessness as they keep pace with new releases and updates to the source code repository. In that context, they have contributed one new tool to the community that is attracting lots of positive attention.
Peridot (and yes, you do pronounce the “t”) is a cloud-native build system created by the Rocky developers to help them turn out updates. The Rocky team has released Peridot as open source software and makes it available through GitHub. To understand what Peridot does, it is best to start with a look at what the Rocky project does. When Red Hat updates the source code for RHEL, they upload the new code to the CentOS website. (It is confusing, but yes, RHEL code source code is stored on the CentOS site even though the CentOS distro is no longer based on RHEL.) Rocky then downloads that source code and applies patches to it, such as removing trademarks and proprietary art, as well as customizing any settings and components as needed for the Rocky environment (Figure 1). The code is then built and packaged in RPM form and made available to Rocky users. Rocky, and CentOS before it, have been employing some version of this process for years.
In the past, this meant that they had to repeat the same steps for every new release. However, although the source files are unique with each new update, the patches applied to the code often don’t change. The Rocky developers therefore built Peridot to automate the patching process. When an update to the RHEL source code appears, you just click one button and Peridot grabs the code, applies the predefined patches automatically, and builds the package (Figure 2).
The Rocky team uses Peridot to build all of Rocky Linux, and you can use it to build your own customized distribution, or to build a single package. If you have source code that you maintain locally, Peridot will perform the same service for your local files.
Rocky is betting that Peridot will help them keep up with Red Hat’s schedule of new releases and security updates. Peridot could also be just the thing to help support the community of special interest users working on modified versions of Rocky.