software development

Is Linux POSIX-Compliant?

4 years ago
by Frank Hofmann

Software is written by numerous developers with various backgrounds. General algorithms are available under a free license or have been scientifically published, and they might also be available for free for studying purposes. This results in different implementations and software versions that fit a variety of needs. A standardization of interfaces and data formats is necessary to make these different implementations both interchangeable and modular.

In short, POSIX [1] does exactly that for UNIX and UNIX-like systems (see Zak H’s article [4] for a more detailed history on this topic). It defines the exchange interfaces, calling mechanisms, and transferred data for the software but leaves the internal implementation to the developer or maintainer of the software. The aim is to unify all the various UNIX forks and UNIX-like systems in such a way that different software implementations can interact with one another. The main advantage of POSIX is to have a binding documentation for these components – interfaces, mechanisms, and data – available in written form.

An operating system that follows the POSIX standard in its entirety is classified as being POSIX-compliant. In this article, we explain what POSIX stands for, determine whether Linux belongs to this category, and list which Linux components must be excluded from this classification.

What Does the Term POSIX Stand for?

POSIX is an abbreviation for Portable Operating System Interface. As briefly explained above, POSIX is the name for a collection of standards that are required to maintain compatibility between operating systems. As stated in [1], “[it] defines the application programming interface (API), along with command-line shells and utility interfaces, for software compatibility with variants of Unix and other operating systems.” The first version of POSIX was published in 1988. Since then, POSIX has been continuously expanded and updated by the Austin Common Standards Revision Group (also known simply as The Austin Group) [7].

As of 2021, the POSIX standard contains the following parts:

  1. Core Services (Incorporates Standard ANSI C) (IEEE std 1003.1-1988) – Process Creation and Control, Signals, File and Directory Operations, Pipes, C library, I/O Port Interface and Control, Process Triggers
  1. Extensions (Symbolic Links)
  2. Real-time and I/O extensions (IEEE Std 1003.1b-1993) – Priority Scheduling, Real-Time Signals, Clocks and Timers, Semaphores, Message Passing, Shared Memory, Asynchronous and Synchronous I/O, Memory Locking Interface
  3. Threads extensions (IEEE Std 1003.1c-1995) – Thread Creation, Control, and Clean-up, Thread Scheduling, Thread Synchronization, Signal Handling
  4. More real-time extensions
  5. Security extensions (Access control lists)
  1. Shell and Utilities (IEEE Std 1003.2-1992) –  Command Interpreter, Utility Programs

The standard is regularly reviewed to reflect technical changes and improvements. It can sometimes take several years before a new version is published and the changes are incorporated. This can be disadvantageous, but it is understandable given the scope of the standard.

In recent years, extensions to real-time processing have been added. The current version was released in early 2018 [3]. The authors of SibylFS [5] have also published many annotations to the POSIX standard to determine higher-order logic and interactions.

What Does Being POSIX-Compliant Mean?

The term “POSIX-compliant” means that an operating system meets all the POSIX criteria. An operating system can run UNIX programs natively, or an application can be ported from the UNIX system to another system. Porting an application from UNIX to the target operating system is easy, or at least easier, than if it does not support POSIX. To be on the safe side, an operating system should have successfully achieved the POSIX certification [2]. This step is achieved (at a cost) by passing an automated certification test. The corresponding test suite can be found here [11].

As of 2021, the list of POSIX-certified operating systems contains AIX from IBM, HP-UX from HP, IRIX from SGI, EulerOS [6] from Huawei, Mac OS X from Apple (since 10.5 Leopard), Solaris and QNX Neutrino from Oracle, Inspur’s K-UX [11], and the real-time OS INTEGRITY from Green Hills Software [15]. It is currently unclear whether newer versions of the three Solaris successors, OpenSolaris, Illumos, and OpenIndiana, are classified as fully POSIX-compliant, as well. These operating systems were POSIX-compliant until POSIX 2001.

Other operating systems that are seen as mostly (but not fully) POSIX-compliant include Android, BeOS, FreeBSD, Haiku, Linux (see below), and VMWare ESXi. For Microsoft Windows, Cygwin provides a largely POSIX-compliant development and run-time environment.

Is Linux POSIX-Compliant?

The term “Linux” refers to the entire Linux operating system, regardless of flavor, such as Debian GNU/Linux, RedHat Linux, Linux Mint, Ubuntu Linux, Fedora, and CentOS, for example. To be precise, Linux is just the name of the kernel that is the core component of this free operating system.

As Linus Torvalds described in the book “Just For Fun” [8], to develop the Linux kernel, he requested a copy of the POSIX standard. This helped him to implement the same mechanisms that are used in commercial UNIX systems. Furthermore, this allowed him to link the Linux kernel with the GNU tools that mainly followed the same approach. To be fair, the software on a Linux system is contributed from a variety of sources that respect the POSIX standard, but that also sometimes implement their own concepts. At the same time, however, this also shows the diversity that makes up Linux as an operating system.

One example of this is the way in which command-line arguments are written. Arguments with two dashes (e.g., “–help”) are GNU conventions, whereas POSIX commands never use two-dash arguments but instead only a single (e.g., “-help”). Right from the start, Linux was designed with GNU in mind, and that is why the commands contain GNU-style

arguments. To achieve POSIX compliance, POSIX-style arguments have been added step-by-step. Still, the final decision is made by the developer. As of today, most commands accept both short and long arguments, or even arguments without any dashes, such as the “find” command, for example. To be fair, there is no consistency between the commands on one system, and this can be a problem when you intend to use the same command on a different UNIX-based system, particularly when switching between Linux, OS X, and Solaris.

For now, Linux is not POSIX-certified due to high costs, except for the two commercial Linux distributions Inspur K-UX [12] and Huawei EulerOS [6]. Instead, Linux is seen as being mostly POSIX-compliant.

This assessment is due to the fact that major Linux distributions follow the Linux Standard Base (LSB) instead of POSIX [9]. LSB aims “to minimize the differences between individual Linux distributions” [14]. This refers to the software system structure, including the Filesystem Hierarchy Standard (FHS) used in the Linux kernel. LSB is based on the POSIX specification, the Single UNIX Specification (SUS) [10], and several other open standards, but also extends them in certain areas.

LSB-based Linux distributions include RedHat Linux, Debian GNU/Linux (2002-2015), and Ubuntu (until 2015), to name a few.

Developing with POSIX in mind

To understand POSIX in greater detail, we recommend obtaining a copy of the POSIX standard and reading it in full. You can get the book from the Open Group website. This requires a registration fee but gives you full access to this valuable resource. Standards help since they allow you to develop software in such a way that it behaves in the same way on all UNIX platforms.

Links and References

Thank You

The author would like to thank Axel Beckert and Veit Schiele for their help and advice while preparing this article.

About the author

Frank Hofmann

Frank Hofmann is an IT developer, trainer, and author and prefers to work from Berlin, Geneva and Cape Town. Co-author of the Debian Package Management Book available from dpmb.org.

View all posts