What exactly is POSIX?
The Open Group is most famous as the certifying body for the UNIX trademark, and its publication of the Single UNIX Specification technical standard, which extends the POSIX standards and is the official definition of a UNIX system.
If the official definition of a UNIX system is an extension of POSIX, then what exactly is POSIX? . It surely seems to be a touchstone of the UNIX world, but I don’t know how it fits into the overall picture.
SUS is the official definition of UNIX since The Open Group, not the IEEE, owns the UNIX trademark. Se my answer below.
4 Answers 4
POSIX first was a standard in 1988 long before the Single UNIX Specification. It was one of the attempts at unifying all the various UNIX forks and UNIX-like systems. POSIX is an IEEE Standard, but as the IEEE does not own the UNIX® trademark, the standard is not UNIX® though it is based on the existing UNIX API at that time. The first standard POSIX.1 is formally known as IEEE std 1003.1-1988.[1] IEEE charged a substantial fee to obtain a copy of the standard.
The Open Group released the Single UNIX Specification (SUSv2) in 1997 based on IEEE’s work of the POSIX standard. SUSv3 was released in 2001 from a joint working group between IEEE and The Open Group known as the Austin Group. SUSv3 is also known as POSIX:2001[2]. There is now also POSIX:2004 and POSIX:2008 which is the core of SUSv4. As for what UNIX® is, UNIX® is whatever the current registered trademark holder says it is. Since 1994, that is The Open Group.
Novell acquired the UNIX® systems business from AT&T/USL which is where UNIX® was born. In 1994, they sold the right to the UNIX® trademark to X/Open[3] now know as The Open Group. They then sold the UNIX® source code to SCO as UNIXWARE®.[3] UNIX® itself has forked many times[4][5] partly due to AT&T’s licensing model. Purchasing UNIX® gave you the complete source of the operating system and the full tool-chain to build it. Modifications to the source can be distributed and used by anyone who owned a license to UNIX® from AT&T. The license fee was in the thousands.
BSD was a project at Berkeley which added a number of enhancements to the UNIX® operating system. BSD code was released under a much more liberal license than AT&T’s source and did not require a license fee or even a requirement to be distributed with source, unlike the GPL that the GNU Project and Linux use. This has caused a good part of the BSD code to be included with various commercial UNIX forks. By around 4.3BSD, they had nearly replaced any need for the original AT&T UNIX® source code. FreeBSD/NetBSD/OpenBSD are all forks of 4.3BSD that are a complete operating system and have none of the original AT&T source code. Nor do they have right to the UNIX® trademark, but much of their code is used by commercial UNIX operating systems. The Socket API used on UNIX was developed on BSD and the Unix Fast Filesystem code was borrowed and used on various UNIX Operating Systems like Solaris with their own enhancements.
Linux was developed in 1991, but was developed from scratch unlike BSD and uses the existing GNU Project which is a clean-room implementation of much of the UNIX user-space. It implements much of POSIX for compatibility and is UNIX-like in design, but it does not have the close connection to AT&T or UNIX® that the BSDs have.
What is POSIX? Why Does it Matter to Linux/UNIX Users?
You might have come across the term POSIX. Have you ever wondered what it is and why programmers often discuss POSIX compliance?
You’ll hear the acronym, or read about it: POSIX, on different online boards and articles. Programmers and system developers seem to worry about it the most. It can sound mysterious and, while there are many good sources on the subject, some discussion boards (brevity is part of their nature), don’t go into detail as to what it is and this can lead to confusion. What, then, is POSIX, really?
What is POSIX?
POSIX isn’t actually a thing. It describes a thing – much like a label. Imagine a box labeled: POSIX, and inside the box is a standard. A standard consists of sets of rules and instructions that POSIX is concerned with. POSIX is shorthand for Portable Operating System Interface. It is an IEEE 1003.1 standard that defines the language interface between application programs (along with command line shells and utility interfaces) and the UNIX operating system. Compliance to the standard ensures compatibility when UNIX programs are moved from one UNIX platform to another. POSIX’s focus is primarily on features from AT&T’s System V UNIX and BSD UNIX. A standard must be spelled out and followed by rules on how to achieve the goal of interoperability between operating systems. POSIX covers such things as: System Interfaces, and Commands and Utilities, Network File Access, just to name a few – there is much more to POSIX than this.
Why POSIX?
In a word: portability. Over 60 years ago, programmers had to rewrite code completely if they wanted their software to run on more than one system. This didn’t happen all that often due to the expense involved, but portability became a feature in the mid-1960s – not through POSIX – but in the mainframe arena. IBM introduced the System/360 family of mainframe computers. Different models had their unique specializations, but the hardware was such that they could use the same operating system: OS/360. Not only could the operating system run on different models, applications could run on them as well. Not only did this keep costs low, but it created computer systems – systems across a product line that could work together. It’s all common today – networks and systems, but back then, this was a huge deal! When UNIX came about, around the same time, it also showed promise in that it could operate on machines from different manufacturers. However, when UNIX started to fork into different flavors, porting code across these UNIX variants became difficult. The promise of UNIX portability was losing ground. To solve this portability issue POSIX was formed in the 1980s. The standard was defined based on AT&T’s System V UNIX and BSD UNIX, the two biggest variants at the time. It’s important to note that POSIX wasn’t formed to control how the operating systems were built – any company was free to design their UNIX variant any way they pleased. POSIX was only concerned with how an application interfaces with the operating system. In programmer-speak, an interface is the method one program’s code can communicate with another program. The interface expects Program A to provide a specific type of information to Program B. Likewise, Program A expects Program B to answer back with a specific type of data. For example, if I want to read a file using the cat command, I would type something like this on the command line:
Without going into a lot of programmer-speak, I’ll just say that the cat command makes a call to the operating system to fetch the file so cat can read it. cat reads it and then displays the file’s contents on the screen. There is a lot of interplay between the application ( cat ) and the operating system. How this interplay works is what POSIX was interested in. If the interplay could be the same across the different UNIX variants, portability – regardless of operating system, manufacturer, and hardware – is regained. The specifics as to how all of this is accomplished is defined in the standard.
Compliance is Voluntary
All of us have at least seen a message like, “for help, type: xxxxx –help.” This is common in Linux and is not POSIX compliant. POSIX never required the double-dash, they expect one dash. The double-dash comes from GNU, yet, it doesn’t harm Linux and adds a little to its character. At the same time, Linux is mostly compliant, especially when it comes to system call interfaces. This is why we are able to run X, GNOME, and KDE applications on Linux, Sys V UNIX, and BSD UNIX. Various commands, such as ls, cat, grep, find, awk, and many more operate the same across the different variants. As a rule, compliance is a willing step. When code is compliant, it’s easier to move to another system; very little code rewrite, if any, would be necessary. When code can work on different systems, the use of it expands. People using other systems can benefit from the use of the program. For the budding programmer, learning how to write programs that are POSIX compliant can only help their career. For those readers who are interested in the Linux sphere of compliance, much good information can be found at: Linux Standard Base.
But I’m Not a Programmer or System Designer…
Many people who work on computers aren’t programmers or operating system designers. They’re the medical transcription clerks, secretaries who write out letters, task lists, dictated memos, and so on. Others tabulate numbers, gather and massage data, run online stores, write books and articles (and some of us read them). In almost every job, there’s probably a computer close by. POSIX affects these users too, whether they know it or not. Users don’t have to comply with the standard, but they do expect their computers to work. When operating systems and programs conform to the POSIX standard, they gain the benefit of interoperability. They will be able to move from one system to another with the reasonable expectation that the machines will work much like another one does. Their data will still be accessible and they will still be able to make changes to it. POSIX, as well as other standards, are continually evolving. As technology grows, so does the standard. Standards are actually an agreed-upon system used by people, manufacturers, organizations, etc. to perform tasks in an efficient manner. Devices from one manufacturer is able to work with another manufacturer’s device. Think about it: Your Bluetooth earpiece can be used on an Apple iPhone just as well as it can on an Android phone. Our TV can hook up to, and stream, videos and shows from different networks, such as Amazon Prime, BritBox, Hulu – just to name a few. Now, we can even monitor out heart rate with our phones. All of this is made possible, largely in part, from compliance to standards. Benefits galore. I like that.
So what about the X?
I admit it, I never said what the “X” was for in POSIX. Opensource.com has an excellent article where Richard Stallman explains what the “X” in POSIX means. Here it is, in his words:
The IEEE had finished developing the spec but had no concise name for it. The title said something like “portable operating system interface,” though I don’t remember the exact words. The committee put on “IEEEIX” as the concise name. I did not think that was a good choice. It is ugly to pronounce—it would sound like a scream of terror, “Ayeee!”—so I expected people would instead call the spec “Unix.”
Since GNU’s Not Unix, and it was intended to replace Unix, I did not want people to call GNU a “Unix system.” I, therefore, proposed a concise name that people might actually use. Having no particular inspiration, I generated a name the unclever way: I took the initials of “portable operating system” and added “ix.” The IEEE adopted this eagerly.
Conclusion
The POSIX standard allows developers to create applications, tools, and platforms on many operating systems using much of the same code. It isn’t a requirement, by any means, to write code according to the standard, but it does help, in a big way, when you want to port your code to other systems. Basically, POSIX is geared toward operating system designers and software developers, but as users of a system, we are affected by POSIX whether we may realize it or not. It is because of the standard that we are able to work on one UNIX or Linux system and bring that work over to another system and work on it with no hiccups. As users, we gain numerous benefits in usability and data re-use across systems.