The State of Enterprise Linux in 2023

Introduction

Are you a professional Linux Systems Administrator, Architect, or Site Reliability Engineer? Do you use Fedora, Red Hat Enterprise Linux (RHEL) or a derivative in the course of your work? Do you find it difficult to keep up with all of the changes that have been going on with RHEL in the last few years? Are you trying to understand the difference between RHEL, RHEL CoreOS, Red Hat Universal Base Image, CentOS, Fedora, CentOS Stream, AlmaLinux, Rocky, Amazon Linux, Oracle Linux, or a host of other derivatives?
Admittedly, it’s kind of complex.
Don’t feel bad. The upstream and downstream relationships that make up the RHEL supply chain contribute to what is arguably the largest and most sophisticated open source supply chain in the world. This large, sophisticated supply chain, and all of the Independent Software Developers (ISVs) involved, give RHEL a lot of gravity, probably more than any other open source product.
For years, I think many of us in the open source world assumed that we knew everything there was to know about open source, but the truth is, we’re all still learning. In the last couple of years, there have been some big changes in the Red Hat Enterprise Linux (RHEL) supply chain, often referred to as Enterprise Linux or EL for short. This article is the third in what is becoming a series written to help people understand these changes year over year. If your interested in more background, check out the previous two related articles:

• Before You Get Mad About The CentOS Stream Change, Think About…
• The State of Enterprise Linux in 2022

Biases & Methodology

Full disclosure, I work for Red Hat, and my title is Senior Principal Product Manager for RHEL Server; if you don’t understand exactly what a product manager does (don’t feel bad), check out The Delicate Art of Product Management with Open Source. I work within a team of about 20 product managers which are subject matter experts in different areas, and drive the roadmap for RHEL. Some of our team is focused on the experiences and technologies within enterprise Linux, things like automation & management, or identity, security, & compliance. Others in our team, like myself, are focused on the offerings themselves, for example RHEL Server, RHEL Workstation, or RHEL for Edge. Being responsible for the RHEL Server offering is both exciting and challenging because it’s connected to almost everything Red Hat does (OpenShift, Ansible, our online services, Satellite Server, JBoss, etc).
Given that my role connects me deeply with other products at Red Hat, partners’ products, and upstream open source projects, last year I wrote the State of Enterprise Linux 2022 mostly from my personal knowledge. This year I wanted to provide an even richer set of perspectives so I conducted interviews with half a dozen people internally at Red Hat. I also solicited information from external organizations to garner their feedback on their experiences participating in this community.
While I have my biases, and I encourage you to read this article with a critical eye, I’ve attempted to be transparent and fair in my analysis.

The State of Enterprise Linux in 2023

This article will not cover the history of Enterprise Linux (EL) but if you are not familiar, check out The State of Enterprise Linux in 2022 which covers a good bit of history. This year’s article is organized around the following main topics:

• Suppliers: these are the projects and products that supply the EL landscape with new versions of software, packages, and therefore have a deep impact on the RHEL roadmap.
• Consumers: these are the projects and products that derive their code from the from the above suppliers
• Major Themes: These are the hot topics in the Enterprise Linux space which my team and I are paying close attention to.

Let’s quickly define what a supplier and a consumer actually means in this context. In the Delicate Art of Product Management with Open Source, I propose that open source projects can be thought of as suppliers in an open source supply chain, much like the supply chain in any manufactured products. For example, Volkswagen buys fuel injectors from Bosch and Tesla buys tires from Michelin. In this same way, open source products and projects rely on suppliers. The difference with free and open source software is, you buy it with your time, instead of money. I think this model is useful for analyzing the Enterprise Linux space.

Suppliers

Everything starts with Fedora. The Fedora project is the source of innovation for the entire EL landscape. New software and ideas are integrated in Fedora, made easy to use, nurtured, and matured as part of what we call the upstream first approach. Even when a piece of software is considered mature, it’s not automatically promoted to EPEL, CentOS Stream, or RHEL. Instead, software and ideas are released downstream if and when there is a specific use case or need. There is a healthy tension between what is and isn’t moved downstream. The goal of RHEL is to provide customers with innovation without leaving people behind. The following drawing shows the flow of software packages:

Fedora and Extra Packages for Enterprise Linux (also called EPEL, and a Fedora Special Interest Group) are managed as upstream community projects. While RHEL customers do not get direct support for Fedora and EPEL, they’re critical to the RHEL landscape and many of the people who contribute to these projects do work for Red Hat and have a vested interest in helping RHEL users. Incentives and goals are aligned quite nicely.
Major and minor RHEL releases are often an opportunity to determine if new packages should be released downstream. This release process is based on some very specific criteria. It’s often well understood by Red Hat’s customers because they have direct conversations with Red Hat Solutions Architects, Engineers, and Product Managers, but one of the goals of this article is to highlight the process for the wider user base. Here’s a non-exhaustive list of some of the criteria:

1. New Features: new packages will often be released based on a roadmap determined by product management. Roadmaps are prioritized based on user need, as well as whether Red Hat has expertise to meaningfully “contribute to” and “maintain” the software upstream. Red Hat does not support a package in RHEL unless there is sufficient upstream contribution from a Red Hat employee.
2. Security Fixes: Sometimes these changes are back ported, but other times a package will be updated to a newer version from Fedora. This often depends on whether it’s a major or minor version of RHEL, and where a package is classified in the Application Compatibility Guide.
3. Performance Fixes: Sometimes performance optimizations can be fixed with a small configuration change. Other times, they require code changes (back ports, or package updates). Like security fixes, changes are based on whether it’s a major or minor version of RHEL, and where an affected package is classified in the Application Compatibility Guide.

The above criteria covers the why and what, but there are other criteria for where a new software package is released:

1. RHEL: If it’s determined that a package should and can be fully supported in RHEL, it will be promoted from Fedora directly into CentOS Stream and then on to RHEL. For this to happen, some criteria needs to be met. First, there must be a customer need. Second, Red Hat must feel confident that it can be supported well.
2. EPEL: If a package would be useful to RHEL users, but for any number of reasons cannot be fully supported, it will often be released in the EPEL repositories. There are a plethora of reasons why a package may be unsupported. For example, sometimes Red Hat doesn’t have enough upstream contributors to the project, other times there isn’t a strong enough use case by customers to incur the cost of support. Support, Quality Engineering, and thorough testing can be quite expensive over the long lifecycle of RHEL. That cost is incurred by all customers, but it’s not always justified if only a small set of customers have the need.
3. EPEL then RHEL: Sometimes a package will mature in the EPEL repository for a while and then be moved into CentOS Stream and on to RHEL. This will sometimes happen if customer demand increases, and/or Red Hat becomes confident in being able to support it well.

To summarize all of the information at this point, Fedora supplies CentOS Stream, CentOS Stream supplies RHEL, and RHEL supplies the rest of the EL landscape (AlmaLinux, Rocky, Oracle Linux, etc).

Now that you understand the basic flow of software, let’s move on to an update about each of the major suppliers.

Fedora/EPEL

Since EPEL is a Fedora Special Interest Group, Fedora and EPEL will be grouped together in this section. This has been an exciting year for Fedora. Recent releases of Fedora have been quite popular, and the releases of Fedora 36 and Fedora 37 in 2022, as well as Fedora 38 in 2023, have contributed to growing popularity. This article might explain the sentiment better than any I’ve seen, 5 Reasons Why Fedora Feels Like the New Ubuntu, where they describe five main reasons Fedora is so exciting this year:

1. Fedora Delivers Features First
2. Fedora’s Desktop Is Exciting
3. Fedora Is Easy to Install and Use
4. Fedora Has a Large and Growing Community
5. Fedora Has Great Software Support

You can even see the popularity of recent Fedora releases reflected in the Google Search results!

There’s a new fedoraproject.org website and a lot of exciting discussions going on under the website and marketing tags on the official discussion site. To get an idea of everything leading up to Fedora 36/37/38 in 2022 and 2023, check out 35 Fedora Releases in 30 Minutes by Matt Miller, from November 2021. You can really feel the energy when you check out the Fedora Community Blog, as well as the Fedora Twitter account (180K followers). There’s also a discussion going on about joining and supporting Mastodon.
Fedora comes in five editions including Server, Workstation, IoT, Cloud, and CoreOS, as well as one Emerging edition called Silverblue. Of particular interest to the EL community, Fedora CoreOS is seeing a lot of usage, and has really become the spiritual successor to the original CoreOS. There’s a lot of excitement around bootc and what this will mean for future versions of RHEL. The idea of bootc, is to deploy operating system updates as container images, instead of RPMs. One transaction across the network, and one transaction on the host which takes it from point A to point B. Very interesting and elegant. Built on the foundational work of bootc, Universal Blue is also exciting. Think of it as bringing the simplicity of containers to the OS as a whole.
Getting more into the development side of Fedora, the cadence of Rawhide looks really good and is already shaping up to what RHEL 10 will look like. If you’re a contributor, start putting work into Fedora Rawhide now so that it lands in time for RHEL 10 (yeah, I said it)! Moving on to Extra Packages for Enterprise Linux (EPEL). Red Hat now has full-time employees dedicated to EPEL, and there’s a program call on a scheduled cadence. EPEL 9 is now ready for prime time! Pulling the latest stats at the time of this writing, there are more packages in EPEL 9 than there are in EPEL 8.

• EPEL 7: 13,744 RPMs 7,287 SRPMs
• EPEL 8: 9,545 RPMs 4,841 SRPMs
• EPEL 9: 13,892 RPMs 5,075 SRPMs

Seeing all of this development work in Fedora and EPEL really excites me about the future of the EL landscape.

CentOS Stream

CentOS Stream 9 was first announced in December 2020, and the code was released in February 2021, approximately 15 months before RHEL 9 was launched in May, 2022. CentOS Stream has served as the upstream development platform for two major versions of RHEL (8 & 9). But, CentOS Stream 9 has been special, because it was used since the beginning of RHEL9 development, making it a truly open development process. You can see the merges for CentOS Stream publicly, in our GitLab instance. We’re seeing really quick uptake of EL9 across the board, and we believe it is directly related to the transparent development process. And, if you’re a Red Hat partner or community contributor to CentOS Stream, stay tuned in 2024 for the bootstrap period of CentOS 10, which will help drive an expected launch of RHEL 10 in 2025.

Now, let’s celebrate a few other milestones with CentOS Stream. First, CentOS Stream has gotten so good that it’s become the underlying foundation for upstream development of OpenShift: OKD Streams: Building the Next Generation of OKD Together. This quote summarizes it well, “The OKD Community is now able to build and release stable builds of OKD 4.12 on both Fedora CoreOS and the newly introduced CentOS Stream CoreOS. We are calling it OKD Streams.”
It’s not just Red Hat products either, we’re seeing a lot of activity in the community too. For example, we’re seeing a lot of work around BTRFS in the Hyperscale SIG even though Red Hat does not support BTRFS in RHEL (and does not plan to). Another example is that the EPEL community is building faster and faster, which is driving developer mindshare because the packages available are newer and fresher.

Given the adoption and excitement we’re seeing around CentOS Stream 9, I want to make a couple of points about stability. Since the deprecation of downstream CentOS, there’s been a lot of commentary around whether CentOS Stream is good enough. Consider the following:

• CentOS Stream is still bound by the RHEL compatibility rules. It can only be as different as RHEL can be between minor versions.
• Carl George does some good analysis of “how different” CentOS Stream is from RHEL here. About 0.5% of the packages were newer in CentOS Stream than RHEL 8.7.
• CentOS Stream still has major version numbers, and the The life cycles of RHEL and CentOS Stream run in parallel. For example, CentOS Stream 8 will remain the upstream for RHEL 8 for its entire life cycle until 8.10 when major changes cease to happen in RHEL 8 (original Q&A here).
• CentOS Stream is used at Facebook (great video here).
• Twitter was taking a serious look too, though admittedly, we’re unsure of the status given the recent shake-ups there.
• Cern is successfully using CentOS Stream

Now, as the RHEL Server product manager, I would never claim that CentOS Stream is a drop-in replacement for RHEL. That’s not its goal, but it is still a very good distribution. From a bits perspective, CentOS is nearly the same, but the development model is more sustainable and actually allows for contributions to the operating system.
With all of those positives, I also think it’s important to have a transparent discussion about some of the challenges people might bump into with CentOS Stream.

• Partners could historically see all of these development kernels in RHEL, but the general public couldn’t participate. We don’t ship these kernels in RHEL (composes), but the idea is that each of these kernels are candidates for shipping (aka they are tested through the normal test suites). Though, there is a bit more QE for the final one released in RHEL.
• CentOS Stream alone is not enough for our partners to develop for the RHEL Extended Update Stream (EUS), nor Extended Life Phase (ELS) channels, because these are not available in CentOS Stream. This is something we’re thinking through, to make partners’ lives easier.
• CentOS Stream is definitely the development space for RHEL, but not all of these kernels get shipped to RHEL. After approximately six months, we pick one and ship it in RHEL. AKA, they are all high-quality kernels, though not identical to RHEL.
• There are more kernel releases in CentOS Stream 9. At the time of this writing, there were about five new kernels available in the last months, and older kernels got pruned. Some of the iteration was preparation for the next version of RHEL 9. If you want the latest, up-to-date information, you can look in the CentOS Stream Build Service.
• Because CentOS Stream is always ahead of RHEL, Convert2RHEL has proven nearly impossible. Package downgrades often cause regressions. For example, we’ve seen metadata/schema corruption in Identity Manager. Furthermore, since CentOS Stream doesn’t have minor versions, there’s no upgrade/rollback points to tie into.

To summarize, I think CentOS Stream is a great distro, and it’s working wonderfully to make RHEL development more transparent, as well as providing a foundation for users who want to roll their own EL distribution. It is not a drop-in replacement for RHEL, and it’s not intended to be, but it’s still a solid distribution. As long as you understand that, you will not be disappointed.

RHEL

First off, Red Hat Enterprise Linux 9 was released in May 2022! A colleague I work closely with, Gil Cattelain, did a great article covering the major changes: Hot Off the Presses: Red Hat Enterprise Linux 9. Our friends in the Developer team also did a nice article explaining the latest versions of developer tools: What’s new in Red Hat Enterprise Linux 9. Then, RHEL 9.1 was released in November 2022! Again, Gil did a wonderful job with the release blog: Red Hat Enterprise Linux 9.1 is now available. Now, RHEL 8.8 and 9.2 are out: Speed innovation with new features in Red Hat Enterprise Linux 9.2 and 8.8. Engineering, Product Management, Product Marketing and a huge team of others are executing these releases better than ever.
Historically, RHEL has been critiqued for moving too slowly, but I think that rumor is now firmly dead. We’ve been nailing our release cycles like clockwork: 6 month release cycles for minor versions and 3 year release cycles for major versions. With new versions of Python, Ruby, Node.js, Podman, etc, developers are no longer waiting for old releases of tools, and when they put applications into production, they’re supported for a legitimate life cycle which makes the software manageable for administrators and SREs.
As mentioned before, CentOS Stream 9 has been the upstream development platform for RHEL 9 since its inception, which itself was based on Fedora 34. This made the development process way smoother than RHEL 8, and completely transparent. For those watching closely, the next major version of CentOS Stream, and hence RHEL, will tentatively be based on Fedora 40, about 2 years from now. The planning and development of Fedora, CentOS Stream and RHEL are running like a Swiss watch, and it’s great for customers who can more easily predict our technology roadmap and release dates.
To summarize, I’m thrilled with the way RHEL releases are going, and RHEL 9 is probably our best launch ever!

Consumers

As defined early, consumers are all of the Linux distributions that derive their code from RHEL, Fedora, or CentOS Stream. The following drawing attempts to demonstrate the flow of code within the lanscape:

To simplify this, I will break this down into three classes of consumers:

• Fedora Derivatives: Products and offerings based directly on code from Fedora
• RHEL Derivatives: External products and offerings which are based on code from RHEL
• Red Hat Derivatives: Products and offerings from Red Hat which are based on code from RHEL

Fedora Derivatives

As I mentioned last year, AWS had announced that they were going to base Amazon Linux 2 on Fedora directly (not RHEL). Last year, I had been watching to see if the Amazon Linux team contributes upstream, files bugs, submits patches and drives improvements in Fedora. I’m happy to report that we are indeed seeing the foundations of some work in this area. For example, this OpenSSH key logging patch was added to Fedora 38 by the AWS team. If users have different ssh keys to access the same account, Fedora will now be able to track the user by the key. The great part is, this will get inherited in RHEL. This is how open source works. We each contribute a little, and it improves the whole landscape!
This year, I also scoured the Fedora Gitlab and Bugzilla instances looking for leads on bugs filed, merge requests, etc. There appears to be some work around adding some AWS packages and libraries which is good, but it’s tough to discern much of the activity. In the future, I hope we’ll have better tooling, and I hope we’ll see more activity!

RHEL Derivatives

When a new major version of RHEL is launched, the world pays attention, to see how fast the rebuilds are able to compose their own distributions. The speed of this process is typically a point of intrigue. The world wonders if Red Hat will make it more difficult to rebuild RHEL. They wonder if the rebuilds will figure out the process quickly. People even whisper conspiracy theories that IBM might force Red Hat to stop making it easy!
Well, I’m happy to report that we launched RHEL 9 back in May, 2022 and many of the rebuilds were available within weeks. This can be pretty clearly linked to the fact that the development of RHEL 9 was done in a transparent, open, and collaborative way, leveraging the CentOS Stream community. RHEL 9 was the first major version built completely in the open, and it shows. It’s also important to highlight that Red Hat employees who build and maintain RHEL go through the exact same merge process as outside contributors. Red Hat is strongly committed to our very successful upstream first policy and the release of RHEL 9 is a testament to it.
Watching how quickly AlmaLinux, Rocky, Oracle and others released their EL9 versions, I’d say this process is working quite well. We’re even seeing upstream contributions from some of the downstream rebuilds. While many of these are minor and involve debranding or tooling (changing Anaconda, Composer, installation of CentOS SIG packages, etc), they’re happening, and that’s a good thing. It does appear that there was a little bit of political intrigue between some of the open source communities (for example OpenSuse and Rocky, or AlmaLinux and Rocky)this year, but in general things are working quite well between upstream (CentOS Stream) and downstream derivatives (AlmaLinux, Rocky, Oracle Linux, etc).
That’s especially good for RHEL because many of our ISV partners view RHEL and all of the derivatives as a single ecosystem for which they can target their applications. ISVs want to target as few platforms as possible, while meeting the needs of as many customers as possible, and many customers have different Linux distributions. That’s one reason the RHEL ecosystem is so attractive to ISVs, you target one platform and you can meet the needs of 90% of Fortune 500 customers who use RHEL.
Now, here’s a slightly deeper update on each of the major derivatives:

• AlmaLinux: Many members of this community have made public commitments to work upstream with the CentOS Stream community, and even lists some of the Special Interest Groups (SIGs) on their website. I think it’s no coincidence that a lot of the AlmaLinux community participates in CentOS Stream, and AlmaLinux released their new major version (based on RHEL 9) in 8-9 days, and release minor versions and errata within 24 hours. In other news, it seems like the AlmaLinux ELevate project has been fairly quiet this year. I’m not sure if that’s because there is less community demand for migrations, or people involved in the project put their time into other things (these things often happen in open source).
• Rocky: It’s important to point out that Greg and the Rocky community have come around and are starting to work in the CentOS Stream community. In fact, I reached out to Greg to provide some information for this article, and he was receptive. Regrettably, I ran out of time to publish this article and didn’t get feedback from him (and several other people). I’m looking forward to future versions of this update where I can provide feedback directly from Greg and the community.
• Oracle: We recently made an announcement that Red Hat Enterprise Linux is now available on Oracle Cloud. This is a major breakthrough for joint customers. But, like all large technology companies, Oracle and Red Hat are more cooperative in some places, and more competitive in others. Coopetition as they say. A simple Google search for the words “Oracle CentOS Stream” will quickly inform you that Oracle Linux still mostly positions itself as a competitor to CentOS, but hopefully, in the future, we’ll see them participate more in the Fedora and CentOS Stream communities!? As for now, Oracle seems to mostly do their own thing, with their own EPEL, etc, which is fine.

It’s tough to do any quantitative work to determine how much work these downstream communities are putting into CentOS Stream, and the community is aware of it. The CentOS Stream community wants to put some work into being able to better identify specific contributors (people) with specific communities (AlmaLinux, Rocky, Amazon, Oracle, etc). I’ll be watching this year, trying to find new ways to analyze, and looking forward to major news with the RHEL derivatives.

Red Hat Derivatives

In this section, I’ll provide an update on the products from Red Hat which are based on RHEL. Things like Red Hat Universal Base Image, RHEL for Edge, RHEL CoreOS, etc.
This year, there’s been particular excitement in the CoreOS community. A CentOS Stream CoreOS was launched (Cloudy with a Chance of OpenShift: CentosStream, CoreOS and OKD Road Map). The new bootc project was also launched, which should enable the concept of a Composable Operating system, similar to building on a container image. The idea is that Red Hat could easily provide hotfixes, or users could conveniently add agents, etc. Turning the OS into a set of container images, allows users to leverage their existing container infrastructure, scanning, CI/CD, etc. Stay tuned for more developments in this space, and here’s a drawing to help understand the idea:

There have also been some developments in the RHEL for Edge world. First, Edge Management 2022 was launched (Managing Red Hat Enterprise Linux at the edge). The idea is that you can create images, deploy them, manage them, update them, group and filter them, and use Red Hat Insights all in one convenient service from Red Hat. You can check out the documentation here, and use it here at: https://console.redhat.com/edge/
Also, Red Hat Device Edge (RHDE) was announced this year. Think of RHDE as an offering that sits between OpenShift and RHEL, and includes MicroShift. Also note, these are RHEL bits, which leverage FDO and Ignition, but currently this supported offering is only available for Atom and Core I class hardware (Intel Nooks, OnLogic, etc). Keep your eyes peeled for Nvidia support coming soon.
A couple of exciting announcements with UBI. First, Red Hat Universal Base Image (UBI) versions 8 and 9 are now listed as Verified Publisher images on DockerHub. It’s the exact same image you find at registry.access.redhat.com, but where a lot of developers go to find images. Second, you can now use it as the base layer for Docker Certified images. This means that in addition to official base images like Fedora, you can now build Docker Official images on top of UBI. Also, we have beta SBOMs in SPDX format which users can test (bottom of the page).
Finally, this year, Red Hat announced the Red Hat In-Vehicle Operating System (RHIVOS). Think of it as a derivative of RHEL that goes through the tough in-vehicle safety standards certification process. It’s based on RHEL bits, and heavily leverages the container technologies in RHEL. You can read more here: The new standard: Red Hat In-Vehicle Operating System in modern and future vehicles

Technology Landscape

This year, in addition to Consumers and Suppliers, I want to touch on some technology trends which I think will affect this space.

Digital Connection for Disconnected Environments

In recent years, you may have noticed that Red Hat is more and more focused on bringing useful services to customers. This is part of a long trend that was ahead of its time with Red Hat Network (RHN). Since those days, Red Hat has expanded to tools like Image Builder, Edge Management, and Red Hat Insights (which is now expanding beyond RHEL). If you lean back, and squint, you can probably see a trend here.
Use cases for Linux are ever expanding, and customers need collaboration with their vendors to make customizations to meet the requirements for these new deployments. Even our friendly competitors at SUSE are thinking about this user problem. How do vendors collaborate with customers more efficiently and improve software supply chain security?
I’ve been thinking deeply about this problem, especially in the context of disconnected environments (think high security data centers for governments, etc). These are some of the toughest customers to bring innovation to. This probably deserves a separate blog, but I want to outline the concept here.

Since many offline customers use core builds to deploy disconnected fleets, the question becomes, can we make it easier to collaborate with Red Hat at design time? I think so. Some customers might be comfortable enough to take automated recommendations and resolutions from Red Hat on their core build, and then deploy those themselves in production. Others may just want to “compare notes” – perhaps building their core build from scratch, but comparing it to what we build with Image Builder, and cherry picking the changes they want.
Stay tuned, I think this is an interesting space for Enterprise Linux…

Software Bill of Materials (SBOM)

The concept of SBOM is a hot topic upstream (example: FOSDEM), as well as internally at Red Hat. This is another place where I think Red Hat was ahead with the concept of Errata, for as long as time remembered. Before trying to understand SBOM, I suggest a quick refresher by reading: Demystifying risk using CVEs and CVSS by Vincnet Danen, and Explaining Red Hat Errata (RHSA, RHBA, and RHEA) which I helped contribute to.
To understand the power of SBOM better, how it will increase our understanding of the security posture of entire products, as well as improve it, check out: How is Red Hat addressing the demand to develop offerings more securely? By Jeremy West. This doesn’t just apply to the bare metal server/OS either, it also applies to Containers, and can be easily used with Podman. Check out: Establishing a Secure Pipeline by Sally O’Malley.
There’s a lot of collaboration going on at Red Hat between Product Security, the CTO’s Office, and the product teams (like RHEL) to ensure that we’re at the forefront of the next generation in security, including open component registries and SBOM. We’re also keeping an eye on which formats (SPDX versus CycloneDX) will become ubiquitous in this space.
Great work by my friends Vincent Danen, Sally, O’Malley and Jeremy West at Red Hat. Keep an eye on this space as well…

WASM

In full transparency, five years ago, I wasn’t very excited by WASM on the server side. I viewed it as an unnecessary technology. I’ve written extensively about my views on compatibility, portability, supportability, and the subtle differences between all three. Historically, I still believe that standardizing on RHEL provided the level of portability, compatibility and supportability that most customers needed to run the vast majority of workloads, across the most commonly needed infrastructure (on-premise x86 servers, on-premise x86 virtual machines, and cloud-based x86 virtual machines). But, I think the future looks different…
Today, in 2023, and looking forward, I see a much more multi-architectural world. When we look at workloads on Edge devices, in automobiles, or even when we at how countries are becoming more protectionist with chip manufacturing, or Apple, AWS, Ampere, and Nvidia’s investments in ARM, it’s difficult not to see a future world with multiple, popular general purpose processors, which includes x86 and ARM, and likely even RISC-V. This is a huge change, and an exciting time. This is the first time in my life that I can truly see a multi-arch world.
And that changes everything with regard to portability…
WASM on the server server, or something similar, is likely needed to create a layer of compatibility between hardware architectures. Since WASM combined with WASI is essentially like an Instruction Set Architecture (ISA, like ARM, or x86) and Posix, it potentially solves this compatibility problem, and creates a foundation for excellent portability and supportability.
Now, I’d now call myself a cautious optimist about WASM, and I’ve written about it on InfoWorld (The ever-widening world of Wasm) as well as RedHat.com (Red Hat and WebAssembly) if you’re interested in learning more. If you’re interested in getting your hands on the technology, check out: Running WebAssembly Workloads on Container Runtimes by Ivan Font.

Conclusion

This was a long article, so if you made it this far, congratulations! You deserve an adult beverage. I think I deserve several adult beverages for writing it, and without the help of ChatGPT! 🙂In full transparency, it took months to write, involved reading countless articles and even interviewing half a dozen people.
I feel a bit ashamed, and I hope I haven’t come off as name dropping too many people in this article, but this work really is the culmination of countless conversations, collaborations (blogs, meetings, calls, etc), and I really couldn’t have put all of this together without the network of people at Red Hat. Thank you to everyone!
Stay tuned for another update in 2024!