Check the status of CVEs. Learn More.
Keeping your systems up 100% of the time requires live patching. Our solutions will align strongly with your risk, compliance, and operational uptime requirements.
TuxCare is trusted by the most innovative companies across the globe.
Our partner program is designed with flexibility in mind for partners who are at various stages of their business lifecycle. With financial investment and dedicated resources, you will continue to grow with TuxCare.
Would you like to work with a leader in open source and Linux security that values innovation and partnerships?
Partners receive benefits that are designed to reward the commitment that they have made to the sale of our products and services.
Learn about TuxCare's modern approach to reducing cybersecurity risk with Blogs, White Papers, and more.
Continually increasing Cybersecurity, stability, and availability of Linux servers and open source software since 2009.
August 27, 2021
Binary compatibility is one of those important tech concepts that hides in the background – but that is a critical element in making things work. For Linux developers, in particular, binary compatibility is a major question given the number of different Linux distributions out there.
In this article, we take a closer look at what binary compatibility is, including the different contexts of binary compatibility. We also take a close look at what binary compatibility means for Linux distributions in particular.
First, what do we mean with a “binary”? In development terms, a binary is compiled executable code. In other words, a developer writes code in high-level, human-readable language such as C or C++, and then runs the source code through a compiler to generate machine-readable executable code. That resulting file is called a binary.
Binaries are compiled for a specific computing environment. You can’t execute a binary compiled for a Linux OS on a Windows OS, for example. While some small environmental changes may not affect binary compatibility, substantial differences will cause execution to fail.
Binary compatibility can mean slightly different things depending on the context, but the principle of binary compatibility is simple.
Two distinct computing environments are binary compatible if source code compiled into a binary for one environment will also execute flawlessly in the second environment. In other words, the developer does not need to re-compile the source code to successfully execute it in the second environment.
Why does binary compatibility matter?
You could look at the importance of binary compatibility from two perspectives. First, if you’re developing software for a single, specific purpose you will want to avoid the need to re-compile a large codebase just to respond to a change in environment.
From another viewpoint, you may be the user of off-the-shelf software where a commercial vendor stated that their software has been tested on a specific operating system and that it may or may not work on a similar operating system (for example, another Linux distribution). You don’t have the option to recompile the code – and your environment might not match the environment the vendor tested their software in.
The problem with recompiling
While recompiling is an option in some cases, you may find that you have many different environments you need to cater to – and very complex applications where recompiling just simply takes too long.
Either way, recompiling an application to ensure that the new binary works in the new environment requires time and effort – and often also requires specialized skills. By definition, if a different environment is not binary compatible there will be many issues that crop up – whether it is files in different locations or libraries that are slightly different.
Binary compatibility removes the need to recompile
However, for both of the above cases, if you know that the alternative environment is binary compatible you are assured that the compiled executables – whether your own or those supplied by a vendor – will run in your target environment without hassle.
A range of circumstances can bring binary compatibility into question. What happens, for example, when a new version of an operating system is released? Will existing applications continue to run – i.e., is the OS binary compatible?
Consider another scenario, where your OS of choice is end of life. Does your organization have an alternative, binary compatible OS that it can switch to instead, or do you need to engage with a recompile – or even switch applications? For these reasons, binary compatibility needs consideration when you review your OS strategy.
The story of binary compatibility under Linux
Linux is a relatively unique operating system because of the number of different versions or distributions of Linux out in the wild. The different Linux distributions often have specific purposes – for example, Talis is security and privacy orientated, while the Kali distribution is specifically designed for penetration testing.
However, just because a distribution is part of the Linux family does not mean that it is binary compatible with another distribution.
The various Linux distributions can differ significantly, creating environments that are so distinct that there’s no guarantee a package that runs on one distribution will work on another. This could be due to different shared libraries for example, or because one distribution is stripped down to meet a specific purpose – and therefore lacking in some common features.
Indeed, binary compatibility is the sole reason for the existence of some Linux distributions. In other words, some Linux distributions exist with the promise to deliver binary compatibility – possibly alongside other benefits such as reduced or indeed no fees.
Two aspects of Linux OS binary compatibility
It’s worth understanding that binary compatibility of Linux distributions matters in two key directions. First, there’s the binary compatibility between two different distributions. For example, while Ubuntu is essentially derived from Debian, sufficient changes are made to Ubuntu to imply that packages built for Debian may not necessarily run on Ubuntu.
In contrast, both CentOS and Oracle Linux are application binary compatible with RHEL. In other words, if your application is developed and certified for RHEL, it is by consequence also ready to run on CentOS and Oracle Linux.
That said, even if two Linux distributions are not binary compatible, some packages may run on both distributions given that Linux distributions have the Linux kernel and many other components in common.
Another factor to keep an eye on is the binary compatibility from one version of a distribution to the next. In general, there is a broad expectation that, say version 9 of a specific Linux distribution would maintain binary compatibility with version 8. However, at some point, binary compatibility may be compromised to incorporate improvements into a distribution.
Referring to the vendor or community release guidance will give you the necessary reassurance as to whether you need to review your application compatibility – or whether the version you intend to upgrade to is binary compatible, which means that upgrading your OS will not interfere with the correct operation of applications.
Case in point: The story of CentOS and RHEL
Earlier in this article we pointed to the fact that applications are generally tested on a single distribution, and guaranteed to function on that distribution only. Commercial software vendors tend to focus on enterprise-focused Linux distributions – think about Red Hat Enterprise Linux (RHEL), or Oracle Linux.
Enterprise Linux distributions typically come with a high price tag. It may well be that developers feel that those willing to pay substantial sums for a Linux distribution would be more likely to pay for their software – and by consequence, test and certify their software on commercial distributions.
For various reasons – including factors such as cost and lock-in – an organization may not want to adopt an enterprise Linux distribution. That’s why some of the binary compatible Linux distributions exist including one of the most famous examples – CentOS.
CentOS is a 1:1 fork of RHEL and was released by Red Hat. Unlike the commercially-licensed RHEL, CentOS is a free distribution that promised full binary compatibility with its enterprise-focused parent, RHEL. In other words, if you were running an enterprise application developed for RHEL you could be assured that it would also run on the free-to-use CentOS.
However, in December 2020, Red Hat stopped issuing CentOS as a stable release which meant that it no longer suited many workloads.
Because so many users depended on CentOS the Linux community quickly came up with alternatives. These alternatives have an important quality: binary compatibility with CentOS, which in turn implies binary compatibility with RHEL.
Binary compatibility helps – just don’t assume it’s there
In many ways, for those governing a Linux distribution, binary compatibility is a worthy goal on its own even where that means that there are limits to the degree to which included packages can be changed.
However, as a rule, you’ll find that Linux distributions are not binary compatible. Whether you’re writing your code or purchasing code from a vendor, binary compatibility is something you need to look out for given the complex field of Linux distributions.
Nonetheless, some distributions are binary compatible – which means you have options if you’re trying to save costs over an enterprise-orientated distribution, or indeed if you are forced to switch away from another distribution.
Stay updated with the latest news and announcements from TuxCare.com