> A persistent problem encountered in the transporting process was one related to addressing on the PDP-11. We noticed this in one of the first programs brought over to the Series/1. The program was supposed to print out "Unix" and instead printed out "nUxi" (reversing pairs of bytes). Each machine addresses words by an even address. The PDP-11 addresses a word by its low-order byte, and the Series/1 addresses a word by its high-order byte. The effect is that byte-oriented data are correct when taken from one machine to another; but word-oriented data, including instructions, must have the bytes of each word interchanged. This architectural difference had substantial implications in moving any data between the PDP-11 and the Series/1. In addition, this difference was incorporated into program logic whenever a two-byte sequence was considered at times as a 16-bit binary word, and at other times a sequence of two 8-bit bytes.
Yeah the fact that Unix/POSIX was once considered a minimal, easily ported OS is somehow lost in today's Linux-centric world with Linux-only concepts such as namespaces, systemd, etc. It's also strange that Docker has gained momentum when all it does is present a very shallow wrapper around Linux core APIs, thanks to Linux' excellent userspace compat.
>Yeah the fact that Unix/POSIX was once considered a minimal, easily ported OS is somehow lost in today's Linux-centric world with Linux-only concepts such as namespaces, systemd, etc.
The prevalent view of Linux has sort of evolved in this area.
Proponents of Linux, toward the very beginning, framed the value proposition of Linux as:
- something fun to hack on
- something striving for UNIX compatibility (not formalized in a POSIX/SUS test suite, just user testing primarily) - port your UNIX programs easily
- runs on commodity hardware actually accessible to most home users
- Free/open in a modifiable sense - not Microsoft DOS/Windows/Mac OS
- a more advanced (as in implemented, supported, tested) project than 386BSD/NetBSD/OpenBSD/FreeBSD (Linus has said that Linux probably wouldn't have taken off like it did without the AT&T lawsuit - that BSD probably would have filled its place)
Linux's level of maturity and level of adoption at this time meant that there was great value in making it interoperable with UNIX systems and providing robust support for easily porting UNIX software to it - both Free software and proprietary software. Proprietary UNIX at the time had its own problems and expensive hardware, and allowing that market to move to commodity hardware under an operating system that could grow to support different traditional UNIX workloads was a big plus.
However, it's a different time now. Linux has sufficient market share and has replaced most UNIX systems that were popular at the time of its ascendance in popularity. I have worked at a number of shops that have moved from Sun harware/Solaris OS and SGI hardware/Irix OS to either DEC Alpha hardware / Linux OS, IBM POWER hardware / Linux OS, commodity Intel x86 hardware / Linux OS, or commodity Intel x86_64 hardware / Linux OS. The Linux kernel (through Android) shipped on 85.1% of all smartphones in 2018 according to IDC compared to just 14.9% for its nearest competitor[0].
As a result, I feel the popular sentiment is now to add Linux-only extensions with the result (perhaps not the intent) of locking people in to Linux as an OS since Linux is a force of its own that cannot be ignored. Yes, it still competes with Windows and MacOS for desktop share, but the mobile and server markets are pretty much settled spaces at this point - not completely dominated but with a decent enough foothold that porting from other systems is not a primary concern at this point.
There has been friction for the past ten years or so in the Linux community about this. One side sees PulseAudio, systemd, the freedesktop.org stack, Flatpack/Snap, Wayland, and other such developments as a compromise of Linux's position as another commodity platform that allows software to be easily ported from UNIX-like to UNIX-like, providing vital competition in the UNIX space. Another side sees these additions as making Linux better, the best operating system it can be, and if other systems either do not want to add these features, do not have the resources to add these features, or do not have answers to these features then this is a defect in the other operating systems and not chiefly a concern for Linux users as the share of the market that Linux has on servers and mobile is so high that it cannot be ignored.
To the first group, this is the second round of the UNIX Wars from the 90s that lead to one dominant player in this space, and could lead to the same if another (or several) competing systems can "out-Linux Linux".
To the second group, this is a well-deserved victory lap and a chance to show that Linux can be more than just another UNIX.
>It's also strange that Docker has gained momentum when all it does is present a very shallow wrapper around Linux core APIs, thanks to Linux' excellent userspace compat.
I don't think that this is too strange. Other operating systems have had similar facilities for this - from Solaris Containers to something like IBM LPARs. Eventually, all of these APIs need to be usable by "mere mortals" - they're dead weight if something doesn't consume them. That Docker was the project that took off might have been surprising, but that something filled this space is not too surprising.
Very good points. I guess I'm looking at it primarily from a server OS PoV, and I find it indeed surprising that Linux has become so entrenched given it's license terms when it hasn't anything to offer beyond a POSIX-like API. You'd expect people to ship their proprietary apps on top of eg BSD base installs or POSIXish unikernels, but instead what is happening is that Docker is used. Apart from the density aspect and "microservice" trend, I conjecture that people use Docker as an isolation layer to get away from shipping GPL code. Because surely isolation from shared libs having different minor versions and install locations on Debian vs RHEL doesn't seem like a good tradeoff considering that those shared libs, when shipped as part of a Docker image, still need security updates. For me, Docker looks like a solution for a problem of our own making - that of needing different versions of shared libs, and in any case equivalently solvable by static linking.
> A persistent problem encountered in the transporting process was one related to addressing on the PDP-11. We noticed this in one of the first programs brought over to the Series/1. The program was supposed to print out "Unix" and instead printed out "nUxi" (reversing pairs of bytes). Each machine addresses words by an even address. The PDP-11 addresses a word by its low-order byte, and the Series/1 addresses a word by its high-order byte. The effect is that byte-oriented data are correct when taken from one machine to another; but word-oriented data, including instructions, must have the bytes of each word interchanged. This architectural difference had substantial implications in moving any data between the PDP-11 and the Series/1. In addition, this difference was incorporated into program logic whenever a two-byte sequence was considered at times as a 16-bit binary word, and at other times a sequence of two 8-bit bytes.