Having spent many formative years at IBM Research throwing (metaphorical)
bombs at mainframe systems and infiltrating the place with BSD, I have
thought about this question on and off.
I would like to augment your comments with a couple of extra observations:
UNIX was built for a particular set of users - document writers and
programmers
Before UNIX the systems were industrial in design and scope. Sort of like
MVS was a locomotive - designed to be used for hauling heavy freight
(acres of data entry clerks answering 800 numbers and entering
transactions). UNIX was more like cars and trucks - designed for use by
knowledge workers.
When I was a grad student I hung out with some remarkable programmers. We
all observed that learning to program was impossible without a body of code
to read, study, and learn from. The best places to learn programming in
the 70s and 80s were places like MIT, Berkeley, Bell Labs, and IBM Research
... places with an established culture of sharing code internally and large
repositories of code to read.
By the mid-1980s the Microsoft folks established the notion that software
was economically valuable. People stopped giving away source code (IBM's
change in strategy was called OCO - "Object Code Only") and it totally
shocked the software developer community by destroying the jobs for
programmers at user sites. Combine that with the mid-1980s recession and
the first layoffs that programmers had ever seen and we saw the first
horrified realization that the social contract between programmers and
employers did not actually exist.
We, the programmer community, woke up and committed ourselves as much as
ever we could to non-proprietary languages and tools, putting our shoulders
to the OSS movement and hence to UNIX and the layer of tools built on top
of it.
Of course it helped to have some brilliant engineers like Ken, Dennis,
Doug, Rob, Michael, Stu (and and and) and brilliant writers like Brian so
that the thing (UNIX) had intellectual integrity and scope.
It took UNIX twenty to thirty years, but the economic logic of our approach
put an end to efforts to totally dominate the tech world.
=====
<https://www.mindthegapdialogs.com/home>
On Mon, Sep 5, 2022 at 7:49 PM steve jenkin <sjenkin(a)canb.auug.org.au>
wrote:
I’ve been looking at this question for a time and
thought it could’ve
appeared on the TUHS list - but don’t have an idea of the search terms to
use on the list.
Perhaps someone suggest some to me.
As a starting point, below is what John Lions wrote on a similar topic in
1978. Conspicuously, “Security” is missing, though “Reliability &
Maintenance” would encompass the idea.
With hindsight, I’d suggest (Research) Unix took a very strong stance on
“Technical Debt” - it was small, clean & efficient, even elegant. And
‘shipped' with zero known bugs.
It didn’t just bring the Unix kernel to many architectures, the same tools
were applied to create what we now call “Open Source” in User land:
- Multi-platform / portable
- the very act of porting software to diverse architectures
uncovered new classes of bugs and implicit assumptions. Big- &
Little-endian were irrelevant or unknown Before Unix.
- full source
- compatibility layers via
- written in common, well-known, well-supported languages [ solving the
maintenance & update problem ]
- standard, portable “toolchains”
- shell, make, compiler, library tools for system linker,
documentation & doc reading tools
- distribution systems including test builds, issue / fault
reporting & tracking
An emergent property is "Good Security”, both by Design and by (mostly)
error-free implementations.
In the Epoch Before Unix (which started when exactly?), there was a lot of
Shared Software, but very little that could be mechanically ported to
another architecture.
Tools like QED and ROFF were reimplemented on multiple platforms, not
‘ported’ in current lingo.
There are still large, complex FORTRAN libraries shared as source.
There’s an important distinction between “Open” and “Free” : cost &
availability.
We’ve gone on to have broadband near universally available with easy to
use Internet collaboration tools - e.g. “git”, “mercurial” and “Subversion”
just as CVS’s.
The Unix-created Open Source concept broke Vendor Lock-in & erased most
“Silos”.
The BSD TCP/IP stack, and Berkeley sockets library, were sponsored by
DARPA, and made freely available to vendors as source code.
Similarly, important tools for SMTP and DNS were freely available as
Source Code, both speeding the implementation of Internet services and
providing “out of the box” protocol / function compatibility.
The best tools, or even just adequate, became only a download & install
away for all coding shops, showing up a lot of poor code developed by
in-house “experts” and radically trimming many project schedules.
While the Unix “Software Tools” approach - mediated by the STDOUT / STDIN
interface, not API’s - was new & radical, and for many classes of problems,
provided a definitive solution,
I’d not include it in a list of “Open Source” features.
It assumes a “command line” and process pipelines, which aren’t relevant
to very large post-Unix program classes: Graphical Apps and Web / Internet
services.
regards
steve jenkin
==============
Lions, J., "An operating system case study" ACM SIGOPS Operating Systems
Review, July 1978, ACM SIGOPS Oper. Syst. Rev. 12(3): 46-53 (1978)
2. Some Comments on UNIX
------------------------
There is no space here to describe the technical features of UNIX in
detail (see Ritchie and Thompson, 1974 ; also Kernighan and Plauger, 1976),
nor to document its performance characteristics, which we have found to be
very satisfactory.
The following general comments do bear upon the present discussion:
(a) Cost.
UNIX is distributed for "academic and educational purposes" to
educational institutions by the Western Electric Company for only a nominal
fee,
and may be implemented effectively on hardware configurations costing
less than $50,000.
(b) Reliability and Maintenance.
Since no support of any kind is provided by Western Electric,
each installation is potentially on its own for software
maintenance.
UNIX would not have prospered if it were not almost completely
error-free and easy to use.
There are few disappointments and no unpleasant surprises.
(c) Conciseness.
The PDP-11 architecture places a strong limitation on the size of the
resident operating system nucleus.
As Ritchie and Thompson (1974) observe,
"the size constraint has encouraged not only economy but a certain
elegance of design".
The nucleus provides support services and basic management of
processes, files and other resources.
Many important system functions are carried out by utility programs.
Perhaps the most important of these is the command language
interpreter, known as the "shell".
(Modification of this program could alter, even drastically, the
interface between the system and the user.)
(d) Source Code.
UNIX is written almost entirely in a high level language called "C"
which is derived from BCPL and which is well matched to the PDP-11.
It provides record and pointer types,
has well developed control structures,
and is consistent with modern ideas on structured Programming.
(For the curious, the paper by Kernighan (1975) indirectly indicates
the flavour of "C"
and exemplifies one type of utility program contained in UNIX.)
Something less than i0,000 lines of code are needed to describe the
resident nucleus.
pg 47
(e) Amenability.
Changes can be made to UNIX with little difficulty.
A new system can be instituted by recompiling one or more files (at an
average of 20 to 30 seconds per file),
relinking the file containing the nucleus (another 30 seconds or so),
and rebooting using the new file.
In simple cases the whole process need take no more than a few minutes.
(f) Intrinsic Interest.
UNIX contains a number of features which make it interesting in its own
right:
the run-time support for the general tree structured file system
is particularly efficient;
the use of a reserved set of file names smooths the concepts of
device independence;
multiple processes (three or four per user is average) are used in
a way which in most systems is regarded as totally extravagant
(this leads to considerable simplification of the system/user
interface);
and the interactive intent of the system has resulted in an
unusually rich set of text editing and formatting programs.
(g) Limitations.
There are few limitations which are of concern to us.
The PDP-11 architecture limits program size, and this for example
frustrated an initial attempt to transfer Pascal P onto the 11/40.
Perhaps the greatest weakness of UNIX as it is presently distributed
(and this is not fundamental!)
is in the area where other systems usually claim to be strong:
support for "bread and butter" items such as Fortran and Basic.
(h) Documentation.
The entire official UNIX documentation, including tutorial material,
runs to less than 500 pages.
By some standards this is incredibly meagre,
but it does mean that student can carry his own copy in his brief
case.
Features of the documentation include:
- an unconventional arrangement of material (unsettling at first,
but really very convenient);
- a terse, enigmatic style, with much information conveyed by
innuendo;
- a permuted KWIC index.
Most importantly perhaps UNIX encourages the programmer to document his
work.
There is a very full set of programs for editing and formatting text.
The extent to which this has been developed can be gauged from the
paper by Kernighan and Cherry (1975).
==============
--
Steve Jenkin, IT Systems and Design
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA
mailto:sjenkin@canb.auug.org.au
http://members.tip.net.au/~sjenkin