2015-10-31
One advantage of System V is that it was available
I mentioned recently that even though I have a negative view of System V, it made its own contributions to Unix. There are a number of technical contributions, but one of the under-appreciated things it did was simply that System V was available.
The reason that Unix vendor after Unix vendor used System V is in large part because AT&T made it available for licensing. My understanding is that it was even licensed on relatively generous terms; it didn't cost particularly much money to get a source license with binary redistribution rights, and AT&T mostly let you do whatever you wanted with the result without many restrictions. The results of this is that from the mid to late 1980s onwards, Unix versions flourished everywhere, from the small to the large. We probably would not have the broad Unix ecology we do today if AT&T had tried to be more restrictive.
This is all the more noteworthy because AT&T itself was in the business of selling Unix machines for much of this time, and they weren't particularly successful machines either. AT&T undercut its own Unix server business by selling AT&T Unix licenses to direct competitors who then generally offered better products with it.
(Although I don't know for sure, I don't believe that AT&T required things like per-system royalties in its commercial Unix licenses.)
Now, I don't know how much money AT&T earned from its Unix licensing business. But either way, AT&T made an unusual decision to let its server hardware business suffer when it might well have been able to give it a hand, a decision that many companies have decided differently. The result of AT&T's decision here drastically helped Unix spread, especially in the basic server market that became the bread and butter of many Unix vendors.
So, regardless of what I feel about System V at a technical level, I have to respect it simply for being available, for being out there in the world and introducing a great many people to Unix.
2015-10-28
System V was kind of backwards for a long time
I mentioned recently that I have a blind spot about System III and some cultural biases about System V. Well, calling them 'cultural biases' understates things, because it makes the differences between BSD and System V back then sound like the differences between Linux and the *BSDs today. Unfortunately, the split was nowhere near that nice. In fact, I'm going to be blunt: for most of its life, System V was a fairly backwards system.
Do you like job control in your shell? System V didn't have that. Do you like being in multiple groups at once? Nope. Things like symlinks and renaming directories? Of course not. Paged virtual memory? Believe it or not, System V spent a surprising amount of time without it (although less than I thought until I looked it up). The result was that merely using a System V system at the shell level was fairly different from using a BSD system, in a way that is not the case for Linux versus the *BSDs.
(We won't even talk about TCP/IP, which only showed up in SVR4 in AT&T's releases. And I believe that System V was stuck with 14 character filenames for most of its life.)
While System V had a certain amount of good things, it was a very foreign environment for BSD people to use. Many of us didn't like it very much. Some of the strangest and most foreign feeling Unixes I've ever used have been strongly based on System V (pre R4).
With that said, in practice many vendors started from System V but then folded in any number of BSD features; this was especially popular with people who wanted to sell machines to universities. I understand that the result could be a reasonably decent approximation of BSD.
(I'm sure that people who grew up on System V could write up a similar list of important things that BSD was missing. But I do really believe that System V was behind BSD at a technical level for much of its life, even if it had some good bits. Well. Behind what vendors like Sun and DEC were doing with BSD, at least, as actual BSD Unix basically stopped around the time of 4.3 BSD.)
2015-10-25
More on chroot()'s history, and my blind spot about System III
In a comment on my entry on chroot()'s history,
Greg A. Woods noted that System III is the first Unix where chroot()
actually prevents your process from just doing chdir("/..") to
escape the new root directory. System III predates 4.x BSD, so I
was more or less wrong in my entry on this.
Only in the BSD line was 4.1c the starting point for this bit of
chroot() security. System III source code is even available
online here, so I
could have checked and seen this myself if I'd thought of it.
I didn't, though, and that's because I have a blind spot about System III. For a long time Unix was split into two sides, which I'll call the university side and the commercial side. BSD and all of its descendents come from the university side; System III and then System V came from the commercial side. The university side dominated both in universities themselves and in Sun and DEC workstations that more or less derived from that environment, while the commercial side mostly wound up in high end big iron servers.
(SGI was an odd case; it was System V derived but had a bunch of BSD stuff added. This caused a certain amount of heartburn in people who dealt with it.)
Although I've used System V machines, in cultural terms I come from
the university side of Unix; it's what I have the most exposure to,
what I'm most familiar with, and as a result it's what I reflexively
think of as 'real Unix'. In other words, it's a tribal affiliation.
With a few exceptions I tend to just assume that BSD did something
first and best, and that System V had a lot of hacks.
So when I was looking at the history of chroot(), I didn't pay a
lot of attention to System III; I didn't really look to see the
state of chroot() in it, and I didn't actually look at its release
date (which is surprisingly early).
(It looks like System III and information about it probably wasn't
publicly available early enough to influence BSD's chroot() stuff,
but it's at least possible I'm wrong here and that hearing about
chroot() security in System III helped push BSD to implement it.)
This is, of course, kind of a mistake. System III and later System
V had their own innovations, chroot() security among them, and I
shouldn't dismiss their contributions to Unix so reflexively and
tribally (even if AT&T too often had terrible ideas there).