Twenty years ago, a waddle of penguins announced the launch of Oracle Linux. As we approach the 20th anniversary, I’m excited to look back at how far we’ve come.

The year was 2006, and at Oracle OpenWorld those little black-and-white birds helped introduce our enterprise Linux distribution. But our story doesn’t start on a keynote stage–it starts a few years earlier with a kernel, a customer escalation, and a fix that needed an unmistakable “do not ship” label.

It starts with a kernel build known as `2.4.9-e.19corruptsdata` – and despite the name, it did not corrupt data. At the time, customers running Oracle Database on Red Hat Advanced Server 2.1 were hitting a critical issue that no one had been able to resolve. They needed a fix … fast. We produced a special debug kernel that addressed the problem, but we had a new concern: this was a troubleshooting build, with temporary scaffolding, and we didn’t want it to accidentally end up in production before it was fully validated and cleaned up.

So we did the most effective “do not ship” labeling we could think of: we baked the unmistakable string corruptsdata into the kernel’s `uname`. It was our tongue-in-cheek, impossible-to-ignore safety label—because if there’s one thing you don’t want in production, it’s a kernel that could possibly corrupt data.

That moment turned out to be pivotal. It showed that we had highly motivated customers, a team that understood both the database and the Linux kernel, and a mission that mattered: enterprise stability and data safety. In hindsight, that little debug kernel with the dramatic name marked the point when the Oracle Linux effort truly began in earnest.

Today, Linux is the de facto standard for cloud computing, and I believe we played a role in making that possible. Here are some of the things I’m most proud of from the last 20 years of Oracle Linux.

A Modern Kernel for the Enterprise and the Cloud

Back in 2010, to support the launch of Oracle Exadata, we had to reconsider what an enterprise kernel should look like. At the time, enterprise kernels leaned heavily on long chains of backports to an “stable base”, but that approach wasn’t going to keep pace with the performance demands and fast-moving hardware in an engineered system.

Instead we introduced the Unbreakable Enterprise Kernel UEK: to deliver the features, fixes, and performance Exadata required, especially when key changes couldn’t realistically be backported to the enterprise kernels available at the time. UEK evolved through multiple generations, all the way to today’s 6.12 UEK8, and we made the work visible from day one (our kernel sources have always been public. You can browse our kernel configs too).

Moving to an upstream-connected enterprise kernel strategy also helped us make getting patches upstream a clear expectation for developers on the team. It’s not a hard rule, but a direction: fixes should go upstream whenever possible. Upstream work pays off pretty quickly (new kernel rebases get easier when your patches are already there) and it keeps engineers actively engaged in upstream development, not just consuming it.

That philosophy culminated in UEK-next: a development track where we continuously validate that new upstream Linux releases remain compatible with the Oracle-specific changes we need. It’s a significant engineering effort, but it also positioned us well for the industry’s evolving vulnerability and CNA landscape, which has driven a sharp increase in kernel CVE volume. UEK-next is now the preferred platform for new product development at Oracle, and it’s available for customers too—tracking modern upstream kernels, with 7.0 UEK-next coming soon!

It’s also gratifying to see this approach recognized by the community. At a recent Kernel Recipes conference, the lead Linux kernel stable maintainer remarked: “Yes, I’m saying more people need to be like Oracle and Android, what is the world coming to… :)” We’ve worked hard to raise the bar on how enterprise vendors collaborate with upstream—and I’m proud of the standard the team has set.

You can review our UEK source on GitHub: github.com/oracle/linux-uek.

Zero-Cost Distribution with Paid Support

One of the most practical things we’ve done for the ecosystem is keep Oracle Linux easy to adopt: the bits are available at zero cost, and customers can choose the level of support they need. All the binaries are on linux.oracle.com on our public YUM server, no paywall required.

We also built up an incredible production engineering team, the team responsible for running kernel diagnostics on live systems and fixing the most complicated edge case bugs in the kernel. Many of those folks have been here from the beginning of our Oracle Linux adventure, some of them even worked with me on those ‘corruptsdata’ kernels!

Eliminating Downtime with Ksplice

Today, fixing bugs in the operating system without rebooting is an expectation. You can’t be a real hyperscale cloud provider or OS vendor without being able to offer some kind of online patching capabilities, and Ksplice continues to stand out with our security coverage and lifecycle management. With Ksplice, Oracle helped bring that technology to the enterprise, taking an experimental feature from a fringe feature to a regular expectation. Ksplice is critical to our ability to keep up with security, meaning we can postpone maintenance outages without compromising security.

We’re not done. We’re busy innovating with Ksplice as well. As the only enterprise distribution offering live updates for userspace packages and offering known exploit detection, Ksplice continues to be a leading solution that’s integrated into the heart of Oracle Linux.

Ksplice can be used to stop actively exploited attacks, like the PWNKIT vulnerability.

We also offer live patching without the compromise that many other vendors require: with Ksplice, we don’t place artificial restrictions on what kernels you can run in production, and we maintain critical bug fix support for kernels long after our competitors have given up. It’s not always a best practice to keep systems running this long, but here’s an example.

$ uname -r
5.15.0-300.163.18.1.el9uek.x86_64
$ uptime
15:54:53 up 520 days, ...
$ ksplice show | wc -l
438

That’s more than 400 zero-downtime updates applied to a single kernel, and we do that for every kernel we’ve released. With the number of Ksplices and kernels we support, that adds up to thousands of Ksplices built each month!

Top Contributor to Linux and Upstream Stewardship

Oracle has consistently been a top-five contributor to Linux (excluding contributions to device drivers). Oracle started out as the first commercial database to run on Linux, and since then we’ve contributed a half-million lines of code to key areas of filesystems and memory management, helping ensure that Linux could become the real enterprise solution it has become. Even before 6.1, Oracle was the #1 contributor to the core of Linux in 5.18.

It wasn’t until kernel 6.1 that Oracle was the No. 1 overall contributor to the Linux kernel, but we’ve been there as contributors and maintainers every step of the way, helping drive the adoption of Linux in the enterprise–and helping Linux grow into the most important operating system in the world, driving the world’s most critical workloads and supercomputers. Today, Oracle Linux provides the foundation for Exadata and Oracle Cloud customers where we operate everything from the customer OS to the hypervisor, backend services, and even the SmartNICs and the Oracle Acceleron chip.

And it should also be noted that all those contribution statistics are based on volume, not quality. And they don’t measure one of the things I care about most: upstream stewardship. A healthy upstream project needs people willing to do the work that doesn’t “top the charts” – the unglamorous work of reviewing other peoples’ patches and maintaining key subsystems.

We’ve pushed Oracle developers to take on those community roles. This often means their personal “lines of code” output decreases, because maintainership is time-consuming! But it’s also one of the most direct ways to help guide the direction of the project, enforce a quality bar for future Linux kernels, and ensure that Linux remains a solid platform on which to build your business.

Some of that work has been to contribute key data structure optimizations deep within the kernel. These little changes help the whole system scale better, like Matthew Wilcox’s work to improve radix trees, create page folios, and Liam Howlett’s work on the Maple Tree. We even found practical ways to apply it in places like expanding NR_IRQ on ARM.

Page Folios are a simple concept (look at groups of pages instead of single pages!), but surprisingly difficult to implement correctly, yet increasingly necessary as the size of memory and applications continues to grow. When this work started, a lot of Linux development was focused on smartphone sized workloads, and comparatively less attention was being paid to very large server-style compute. Today, that pendulum has swung back as servers, clusters and data centers grow to accommodate enormous AI workloads, and I’m glad to see that work finding real utility.

Observability via DTrace, drgn, and OLED-tools

Part of our commitment to making Linux enterprise-ready was a focus on real-world diagnosability and observability, largely borne from our own experiences diagnosing and fixing production systems. For many years, the most popular Linux session at the annual Oracle conference was my talk on how to “Fix it the First Time.” Too often, service owners are asked to reproduce a problem, especially when insufficient diagnostics are available on affected system. We want everyone to have access to the same kind of “power tools” for diagnostics that we possess.

We started by porting DTrace to Linux–not part of DTrace, and not as a harness, but the full fledged, enterprise DTrace from Oracle Solaris, re-implemented from the ground-up as native Linux eBPF calls. This, along with innovations in userspace DTrace probes (USDTs), allows us to seamlessly profile applications down to the kernel level and back up to the application, providing a full view of where the system is spending its time. More recently, we’ve even shown how to make that power more accessible with natural language system tracing for DTrace.

We’ve also built a whole set of tools that have made kernel diagnostics simpler and more accessible. Those tools include ‘corelens‘, our standalone vmcore viewer (you don’t have to upload a whole vmcore any more!), ‘drgn‘, a python-based kernel debugger, and the whole suite of OLED-tools. These innovations help bring enterprise reliability and fault-analysis to the Linux ecosystem and are available as open source.

Showing the community momentum we’re building here, I’m happy to report that Debian has picked up DTrace in their latest OS.

Advanced Filesystems and Storage

Since we started Oracle Linux, we’ve seen both storage and RAM increase to almost unimaginable levels, but we’ve been there making sure the OS can keep up. If you’re doing any IO on Linux, there’s a good chance your code goes through paths invented or maintained by the Oracle Linux team. For starters, we have maintainers working on the NFS client and server, the SCSI subsystem, the iSCSI target and initiator, XFS and more. Btrfs was originally written by Chris Mason when he was at Oracle and it continues to power many production servers across the world. Scaling up to petabytes and exabytes has been an exciting challenge. We started with OCFS2, a cluster filesystem that’s still fulfills a very specific niche in upstream Linux, all the way to xfs, btrfs, fuse and io_map.

One of the areas of filesystems I’m most excited about has been the innovations by Darrick Wong to make XFS self-healing. No longer will your systems start with “check forced” and drop into fsck for 5, 10, or 15 minutes… XFS now offers online fsck and online repair, allowing filesystem errors to be identified and resolved without having to unmount the filesystem. I don’t miss the rite of passage of rebooting a production server only to find that it was time to run fsck… and now with the latest innovations in XFS, that has become a thing of the past.

Making Virtualization Better

Virtualization has been at the core of Oracle Linux from the very beginning. From technical constraints on limiting the number of cores visible to the Oracle Database, to our work to enable the Private Cloud Appliance (PCA) and Oracle Virtualization, the Oracle Linux team has been deeply involved in making virtualization work well for customer and Cloud workloads.

In the beginning, we were a Xen shop. We still use Xen for a few specific applications, but for the most part we followed the industry and pivoted to the Linux kernel upstream solution of ‘kvm‘ where we continue to innovate today.

Oracle Linux has played an important role with virtualization security, helping devise mitigations for speculative side-channel attacks and ensuring a secure virtualization boundary. We were part of the original Spectre and Meltdown team, working alongside developers across the industry from CPU vendors and key Linux maintainers to mitigate that situation.

We’ve also had to redouble our focus on virtualization performance, as performance often suffered as we shut off side-channel attacks.

Virtualization doesn’t end with the kernel; qemu is an important part of the virtualization ecosystem on Linux. QEMU serves as the “control plane” for virtualization even when QEMU’s emulation functions are not used – and we did a lot of work to significantly reduce the attack surface of QEMU by breaking it up into its component parts, because breaking up QEMU is hard to do.

We introduced technology to allow the minimized QEMU to be restarted at a new version without restarting guests. This involved a lot of complicated pointer work to pass a running guest’s memory to ensure that guests could continue operating seamlessly. QEMU live update is now part of upstream QEMU as well. This feature alone saves thousands of hours of downtime for our cloud customers.

Oracle Linux has also focused on compilers and toolchain work to ensure that the Linux kernel compiles well and that we can fix security bugs at the compiler level, like this work to catch problems with flexible arrays that caught hundreds of security bugs in the kernel.

Enterprise Security and Compliance: SCAP, CC, FIPS, and more

In addition to the big events, we’ve also worked hard to ensure that Oracle Linux helps strengthen the everyday security posture that enterprises rely on. Oracle Linux includes support for FIPS140 certifications, integrations with OpenSCAP workflows, and an emphasis on ensuring that SELinux is enabled, helps customers ensure their Linux footprint is secure. We’re also pioneering work to make FIPS 140-3 certifications modular for the Linux kernel.

Setting the Enterprise Linux standard with OpenELA to keep Linux Open and Free

Oracle helped found OpenELA to support an open, collaborative approach to Enterprise Linux compatibility and long-term stability, and as a direct response to Red Hat further preventing access to their open source code. OpenELA is a consortium of organizations working together to provide timely, publicly available sources and tooling that help the ecosystem build and validate Enterprise Linux–compatible distributions.

Through OpenELA, we’ve focused on practical outcomes: extending support timeframes for key stable kernel lines (including 4.14) and developing an EL-Validated program to help formally demonstrate binary compatibility. We’ve also written about that work in Binary Compatibility and OpenELA’s ELValidated Project. The goal is simple—give customers and partners more choice, more transparency, and more confidence that their Enterprise Linux environments will behave consistently across compatible distributions.

Delivery, Images, Packaging and Upgrades: Managing the OS Lifecycle

Oracle Linux has had numerous initiatives to help users manage the OS lifecycle–from delivery and packaging to images and upgrades. We’ve made contributions to LEAPP, the in-place upgrade tooling that helps migrate between major versions, and that work has been essential in smoothing upgrades not only for customer systems, but also for platforms like SmartNICs and Exadata where predictability and repeatability matter.

It’s also a good reminder that the OS does not start and end with the kernel. Two of the grub2 maintainers are part of the Oracle Linux team, maintaing the code that helps almost every computer start up. We help maintain libcgroups and many other assistance functions. Our folks have been instrumental in evolving glibc and gcc and so many other projects over the years, building the capabilities to make Linux and also Oracle Linux a world-class operating system.

We’ve also continued to invest in OS management across both on-premises and cloud environments, including our work toward Autonomous Linux. And more recently, we’re putting increased focus on bootc and the emerging model of bootable containers—bringing container-style build and delivery workflows to the operating system itself, so teams can standardize how they build, ship, and update the OS with the same rigor and automation they expect for applications.

Looking Ahead

Twenty years ago, Linux in the enterprise was still something you had to prove. Today, it’s the default, and Oracle Linux is part of the reason why.

From that early 2.4.9 kernel to UEK, Ksplice, upstream stewardship, observability tools, filesystems, and security work, the thread has been the same: solve the hard problems that stand between our customers and reliable, secure, high-performance systems.

I’m incredibly proud of what this team has built, and I can’t wait to see what comes next!