Re^6: Nobody Expects the Agile Imposition (Part VI): Architecture

Your reply above was why I had belated moved my comment about NT/Unix to a separate reply from my IBM history reply (I hadn't realized you were already composing a response - sorry about that). I wanted to see a fuller discussion from you.

I've been doing some more browsing because that memory of some ribbing in the press for "unix borrowings" (whatever that means) is fairly firm. Based on your comments above and also a book review I found covering a book on the development of NT, I suspect the ribbing quality came from some rather public anomisity towards Unix by the NT team, but I only suspect. I have no memory of that either way and haven't read the book - just the "so there" quality in the press.

The comment about claiming A is like B because of superficial similarities rings a bell. While browsing around the web looking for where and what was behind whatever it was I remember being reported, I came across an article in InfoWorld way back when in 1987 arguing that *DOS* "borrowed" from Unix because it had pipes. InfoWorld, Aug 3, 1987:

from the start, DOS has been influenced by Unix. DOS 2.0 explicitly incorporated directory structures, pipes, redirection and other features that had long been hallmarks of other systems.

It may also be that those reporting on NT and OS/2 development falsely understood the built-in POSIX support as "Unix borrowings". According to Wikipedia,

Windows NT-based operating systems up to Windows 2000 had a POSIX layer built into the operating system, and UNIX Services for Windows provided a UNIX-like operating environment.

My only quibble with your post is this line: "There are obviously many things that every OS has to have in common."

They may have to, but by what definition? There are many things we now assume as must haves in OS's that were not part of some early operating systems - including multi-tasking. I agree that superficial borrowings of features are not the same as borrowing core internal architecture. On the other hand, the features that eventually became attractive enough to be "must-have" s in other systems, were built-in right from the start in *nix.

I do think we have to be careful about assuming that what now seems to us a no-brainer was always commonly accepted as so. The best innovations are tricky that way: once they are stated they seem so obvious we wonder why they are even innovative.

Comment on Re^6: Nobody Expects the Agile Imposition (Part VI): Architecture

Replies are listed 'Best First'.
Re^7: Nobody Expects the Agile Imposition (Part VI): Architecture by BrowserUk (Patriarch) on Jan 25, 2011 at 20:30 UTC
the features that eventually became attractive enough to be "must-have" s in other systems, were built-in right from the start in nix.* Hm. I've been trying to avoid getting into a full chronological review of OS development as it is all pretty well documented on-line, but the reality is that if modern users of (say) Linux sat down at the console of a machine running the early version of unix, they would find very little that they recognised. And if they attempted to program those early versions, they'd feel that same way that modern kids would if you made them swap their iPhones for CB radios. Very little of what constitutes a modern nix, even by the original POSIX-1 definition, was a part of unix "from the very start". Even such stalwarts of what is now seen as fundamental nix--tcp/ip, sockets, locking and much more--simply didn't exist until many years later after the unix-wars, when the IEEE POSIX initiative pulled them back together from System V, BSD, Xenix/SCO etc. And a whole bunch more of what went into the original unix came from different pre-existing systems. Multics: hierarchal filesystem, swap space. RSX/VMS:the User/Group/Other file permissions mechanism. (Actually, this mechanism appeared almost unchanged in much earlier DEC OSs.) Even the much quoted unix pipes mechanism closely resembles the 'communications files' mechanism from DTSS. Almost nothing that made up the original unix was either completely original, or revolutionary. Indeed, the historical success and usability of nix comes more from what they left out from Multics and the other contemporary OSs, as from what they put in. Much like Perl, their great achievement was in cherry-picking the very best ideas from many systems and putting them together as a coherent single entity that worked for programmers. Perhaps the single biggest innovation that can be attributed to nix, is the "everything is a file" architecture. That is what makes the unix shells work, but even that is a double-edged sword. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]
Re^8: Nobody Expects the Agile Imposition (Part VI): Architecture by Anonymous Monk on Jan 25, 2011 at 21:11 UTC
That is what makes the unix shells work, but even that is a double-edged sword. Twice as awesome :)	[reply]
Re^9: Nobody Expects the Agile Imposition (Part VI): Architecture by BrowserUk (Patriarch) on Jan 25, 2011 at 21:22 UTC
Twice as awesome :) For sure, if sporadic digital() amputations is one of your goals :) ()As in fingers and toes.	[reply]
Re^10: Nobody Expects the Agile Imposition (Part VI): Architecture by Anonymous Monk on Jan 25, 2011 at 21:30 UTC
Re^7: Nobody Expects the Agile Imposition (Part VI): Architecture by eyepopslikeamosquito (Archbishop) on Jan 26, 2011 at 00:01 UTC
It may also be that those reporting on NT and OS/2 development falsely understood the built-in POSIX support as "Unix borrowings". According to Wikipedia, Windows NT-based operating systems up to Windows 2000 had a POSIX layer built into the operating system, and UNIX Services for Windows provided a UNIX-like operating environment. The media may have been taken in by the Windows NT "POSIX subsystem" but most developers saw through it as a cynical ploy to allow Microsoft to tick the "POSIX compliant" box required by some government contracts, without actually being usable. The POSIX subsystem was (deliberately?) crippled by being unable (by design) to properly interoperate with the Win32 subsystem and most developers accordingly avoided it like the plague (again writing this from memory of 10+ years ago when we briefly considered using it but opted instead for Win32 subsystem Unix emulation layers). To paraphrase Dave Cutler, "Microsoft Windows Unix products are a crock". :) Generally, 3rd party Unix toolkits (eg. Cygwin) are preferred.	[reply]


Welcome to the Monastery
	PerlMonks