POSIX (Portable Operating System Interface) is a great differentiator between UNIX-like operating systems (see https://en.wikipedia.org/wiki/POSIX). Who knew it would also correlate with clunkiness?
Of course, POSIX is a family of standards specified by the IEEE Computer Society (see https://en.wikipedia.org/wiki/IEEE_Computer_Society) that endeavored to standardize a UNIX (https://en.wikipedia.org/wiki/Unix) approach to computing.
Before all that clunkification, UNIX itself was a deliberately unclunky – funky, even – operating system designed in 1969 just to facilitate computer games. However, it did have its own Siddhartha-like legacy inherited from innovations designed for the more formal Multics (“Multiplexed Information and Computing Service” – see https://en.wikipedia.org/wiki/Multics) operating system.
The temporary often outlasts the permanent, and this was definitely the case with Multics vs UNIX. The former was written by committee, with a great deal of effort and research and design. And while Multics never cracked the “big time,” some of its key innovations were incorporated into the design of the casually-intended UNIX. And since UNIX was written in the C programming language, it could be recompiled (and then debugged) on any platform that had a C compiler, so it spread like wildfire throughout academic and other underfunded institutions before people and organizations had a chance to contain it or capitalize on it. But contain it they did – kind of – and capitalization has clearly been the case, notwithstanding UNIX’s affinity for mixed case.
Different sets of UNIX source code, each emergent from the original legacy, branched out and soon battles were being fought over who owned the copyright, while the appropriate behavior for a UNIX was codified in standards such as POSIX, which none of the contemporary versions fully manifested.
By the early 1990’s, the question of UNIX source code copyright had become a toxic matter, even as the functionality had become a default set of paradigms, given the many universities and other institutions that had standardized on it and used it in their education.
The solution? Rewrite it from scratch as “UNIX-like” without being beholden to the copyright holders. Enter the fraternal twins of the UNIX world, both written using entirely new (therefore copyright-safe) source code in the early 1990s: Linux and USS.
Linux was the nearly-eponymously named brainchild of Linus Torvalds, who put the Finnish touch on the copyright issue. Writing from scratch, he developed a PC version of a UNIX-like operating system entirely in new source code to avoid copyright issues and optimize it for resource-constrained personal computing environments. And in a GNU (see https://en.wikipedia.org/wiki/GNU) turn of events, he protected it with the “copyleft” license (see https://en.wikipedia.org/wiki/Copyleft) to avoid the copyright wars that UNIX was mired in. After prototyping his OS starting in 1991, version 1.0 was officially released on March 14, 1994 (https://en.wikipedia.org/wiki/Linus_Torvalds).
Being created for commodity consumer electronics computing platforms, the Linux culture manifested all the easy-going attitude that we have come to expect from open source computing environments. And as it grew and expanded and forked into numerous distributions, it began to look more and more like the future of consumer computing, or at least a serious open-source alternative to Microsoft and Apple, with a very broad range of widely-used applications. Adding to this aura of informality, Linux was not designed to be POSIX-compliant, so any similarities between the theory of POSIX and the practice of Linux were happy coincidences, but not formally-purposed.
Meanwhile, also in 1991, InfoWorld analyst Stewart Alsop famously said, “I predict that the last mainframe will be unplugged on March 15, 1996.” (See https://blog.share.org/Article/a-brief-history-of-the-mainframe.) By 1993, the year before Linux went GA, IBM had pre-empted such a future by making their premier mainframe environment the first truly POSIX-compliant computing platform. With an early appellation of MVS/ESA OpenEdition (https://en.wikipedia.org/wiki/MVS#MVS/ESA), and written entirely in new source code to avoid copyright infringement while meeting the formal standards, what is now known as USS, or more formally as z/OS UNIX System Services (https://en.wikipedia.org/wiki/UNIX_System_Services), was the business-focused manifestation of UNIX that was fully integrated with the established side of the IBM mainframe.
But there was something funny about this environment. Several things, in fact. First, it was written by IBM mainframe technologists with a serious business-and-results attitude. And it was written strictly according to the standards in POSIX, which no other UNIX-like environment had ever achieved yet. And it spoke EBCDIC and mainframe architecture natively. This allowed the mainframe to play with the rest of the world using a UNIX-like approach, RFC’s, daemons, TCP/IP and all. Well… maybe not play… but definitely interoperate, according to the strictest of requirements, while using entirely new code that was not subject to anyone else’s copyright.
And there, that 1993, both equally lay, in pages no smirch had trodden black. And we kept both ways for many a day, until they reunited on the mainframe’s back!
One good turn, they say, deserves another. So, the turn of the millennium led Linux to take a turn on the platform that runs the biggest businesses. Actually, just before then, in late 1998, another northern European, Linas Vepstas (https://en.wikipedia.org/wiki/Linux_on_IBM_Z) recompiled the Linux C source code for the IBM mainframe environment, and had it arriving at customer environments by the time the nines turned to zeroes in the year. In short order, IBM tooled up the mainframe to become a powerhouse for running Linux on Z, from providing the original hypervisor, z/VM, to run tens (or more) of thousands of concurrent Linuxes, to creating the speciality IFL (Integrated Facility for Linux (https://en.wikipedia.org/wiki/Integrated_Facility_for_Linux) processor for running Linux concurrently with established workloads on a normal IBM Z environment, to having their own dedicated Linux One mainframes (https://www.ibm.com/products/linuxone).
But wait: there’s more! HiperSockets allowed Linux on Z to use memory as a virtual network for talking at memory speeds to other operating system images (e.g. z/OS) on the same box. And then containers allowed Linux instances to run as address spaces directly under z/OS!
So, with all this flexibility, who needs USS? Why, z/OS, of course, because it’s the bridge to talking to everyone using a broad range of TCP/IP-and-UNIX-relevant applications. And, with encouragement from its cool sibling, USS keeps getting more and more with it as well, with a growing range of utilities and interfaces allowing it to join the dance.
With Linux on the left, z/OS on the right, and USS in the middle, the once-clunky takes flight!
0 Comments