POSIX is the standard most engineers have heard the name of and most have never opened the document of. The acronym stands for Portable Operating System Interface, with the trailing X added at the IEEE's request to evoke the Unix family the standard was codifying. The name was suggested by Richard Stallman, at a working-group meeting in the mid-1980s, after the IEEE asked for a name that would be both pronounceable and recognisably Unix-adjacent. The full document — currently published as IEEE Std 1003.1-2024 — runs to several thousand pages and describes the system calls, shell commands, command-line utilities, regex flavours, and file-system semantics every Unix-like operating system is expected to implement. Most engineers interact with POSIX every day, indirectly, by typing shell commands and calling syscalls whose behaviour the standard is silently arbitrating. Almost nobody reads it.

The 1988 founding moment

The IEEE 1003 working group convened in 1985 to standardise the Unix interface. By the mid-1980s, Unix had fragmented: AT&T's System V, the Berkeley Software Distribution, SunOS, Xenix, HP-UX, AIX, and several other vendor variants each implemented a slightly different version of the Unix system call interface, with slightly different shell behaviour and slightly different command-line tools. Code that ran on one Unix did not necessarily run on another, and the cost of cross-Unix portability was material for any vendor selling software.

The standardisation goal was the same as every other standardisation effort: define a common subset of the existing implementations that vendors could agree to support and that customers could rely on as the floor of compatibility. The working group published its first document, IEEE Std 1003.1-1988, in 1988 as a 200-page specification of the syscall interface.

The name POSIX was suggested by Stallman after the IEEE working group struggled with longer candidates. Stallman's original proposal was IEEEIX — IEEE Unix — which the IEEE rejected as too cumbersome. Stallman then proposed an acronym that included X at the end for Unix, with the rest spelling something readable: Portable Operating System Interface. The IEEE added the X. POSIX was born as the name of a standard whose acronym does not quite parse cleanly into its expansion.

What POSIX actually covers

POSIX is not a single document. It is a family of standards, all maintained under the IEEE 1003 umbrella, that collectively define:

• System calls (POSIX.1) — open(), read(), write(), close(), fork(), exec(), wait(), kill(), signal(), the whole 200-or-so syscall interface that every Unix-like kernel must implement.
• Shell behaviour (POSIX.2) — the syntax and semantics of the sh shell. Variable expansion, quoting, redirections, control flow, pipelines.
• Utilities (POSIX.2) — the behaviour of standard command-line tools: awk, sed, grep, find, tar, ls, cp, mv, cat, and another hundred or so utilities. Each entry specifies the command-line options, the input/output behaviour, and the exit codes.
• Regex (POSIX.2) — Basic Regular Expressions (BRE) and Extended Regular Expressions (ERE), the two flavours of regex that command-line utilities are expected to support. See the regex post.
• Threads (POSIX.1c, 1995) — pthread_create(), mutexes, condition variables, the threading model every Unix-like OS ships some flavour of.
• Real-time extensions (POSIX.1b, 1993) — timers, scheduling priorities, asynchronous I/O.
• File system semantics — what stat() returns, what rename() does across directories, what happens to file descriptors across fork(), the model of the file system tree.

What POSIX does not cover, at least not until later revisions, is networking. Sockets — the API that defines TCP/IP programming on Unix — were a BSD invention from 1983, picked up by every Unix vendor independently and codified only retroactively into POSIX.1-2001. Graphical interfaces, package management, init systems, and the half-dozen other things that distinguish one Linux distribution from another are entirely outside POSIX's scope.

Compliance is a spectrum

The colloquial question is X POSIX compliant? almost always has the same answer: partially, depending on which subsections of which revision you mean. The formal compliance picture in 2026:

• macOS is POSIX certified — specifically, UNIX 03 certified by The Open Group since macOS 10.5 (Leopard, 2007). It is the only consumer operating system in the certified column.
• Linux is not certified. Most distributions implement the POSIX interface functionally — GNU coreutils plus glibc plus a POSIX-compliant shell will produce a system that passes the POSIX test suite — but no major distribution submits for certification. Certification is expensive and offers little practical value when most software is already targeting Linux as the de facto standard.
• The BSDs (FreeBSD, OpenBSD, NetBSD) are mostly POSIX compliant in practice, none of them certified.
• Windows had a POSIX subsystem — Services for UNIX (SFU), later Subsystem for UNIX-based Applications (SUA) — from 1996 to 2012. It was deprecated in Windows 8.1 and removed entirely in Windows 10. The modern Windows Subsystem for Linux (WSL, 2016+) is the actual replacement and is built on running a real Linux kernel inside Windows rather than implementing POSIX natively.
• AIX, HP-UX, Solaris — the older commercial Unixes — are all formally POSIX certified, which is one of the small marketing arguments left in their favour.

The compliance question is therefore mostly a marketing question. POSIX compliant in 2026 means roughly this operating system speaks Unix, with the rare exception of corner-case syscall behaviour where the standard's precise wording matters and most implementations differ.

Why POSIX-compliant became a marketing claim

The 1980s and early 1990s were the period of the Unix wars: AT&T's System V, the Berkeley distributions, Sun's SunOS-then-Solaris, IBM's AIX, HP's HP-UX, DEC's Ultrix-then-Tru64, Microsoft's Xenix-then-not-Xenix, NeXTSTEP, and a dozen smaller variants all positioned themselves as the real Unix. POSIX compliance was the neutral ground: a vendor could claim we are POSIX compliant and reach customers who refused to commit to a specific Unix vendor.

The compliance claim became a procurement requirement. The US government, in particular, baked POSIX compliance into procurement specifications through the 1990s, which forced every commercial Unix vendor to maintain certification regardless of how closely the certification matched what customers actually relied on. The certifications are still there. The customers, in most cases, are not.

In 2026 the practical floor of cross-Unix compatibility is will GNU coreutils run on it, which is a stricter requirement than POSIX-compliance because GNU coreutils ship a set of options and behaviours beyond POSIX. The looser requirement — does it implement POSIX — has been mostly subsumed.

The Open Group, ISO, and the joint maintenance

POSIX has been jointly maintained by three organisations since the late 1990s: the IEEE, The Open Group (which inherited the UNIX trademark in 1996), and ISO/IEC as ISO/IEC 9945. The joint specification is published as the Single UNIX Specification — currently version 5 — and the latest revision is POSIX 2024, aligned with the C17 language standard. The revisions roughly track the C standard: each new C standard prompts a POSIX revision to align library calls, integer types, and threading semantics with the host language.

The 2024 revision picked up pthread_setname_np, several network-related additions, clarifications around asynchronous I/O, and a tightening of the regex specification. Most of the document is unchanged from 2017, which is unchanged from 2008, which is unchanged from 2001. The standard moves slowly because the underlying interface moves slowly. Most of POSIX 2024 is recognisably the same document Stallman helped name in 1988.

A short close

The standard nobody reads has shaped every shell prompt and every read() syscall for almost forty years. Its success is measured by its invisibility: an engineer who types ls -l | grep foo | awk '{print $9}' and gets the same output on Linux, macOS, FreeBSD, and AIX is using POSIX, and the standard is doing its job because that engineer does not have to think about what the standard says. The fact that almost nobody opens the document is not a failure of the standard — it is the point of the standard. POSIX is the contract that lets Unix-like systems look like one operating system most of the time, and that nobody has to negotiate.