I do not currently have the time or inclination to address the various
points raised in the exchange/commentary, to which I am adding some
comments, in sufficient detail.
UC CSRG BSD original deployment largely evolved for DEC hardware
platforms, such as the PDP-11 (with segmented overlay memory) and the
VAX 11/780 (the first "large deployment" production "non-mainframe" with
demand-paged virtual memory), with -- by current standards -- very slow,
limited RAM, low bandwidth bus (such as UNIBUS), and "ethernet" NICs
such as the DEUNA. All of this hardware platform was much less capable
than a current X86-64 home "PC" platform, or even some ARM based
"tablets" or "smart phones". BSD did promulgate "sockets", and other
innovations. It was somewhat constrained by early ATT Unix, with a
version of the Unix source license from ATT. Had the legal games over
"unix" not ensued, and had there been some entity similar to CSRG and
the community that supported and used BSD (largely "professional"), some
of what you wrote might not have happened. However, it was a policy to
build each installation of BSD from source, much more tedious than
installable "executable" packages from commercial vendors, the same
methodology adopted by the Linux community (communities?). Was the BSD
C compiler system as good as ultimately the FSF GNU C compiler? Again,
a matter for discussion -- but ultimately for a number of reasons,
including open source, the GNU compilers have become a widely used
implementation. It was a too long time interval before a BSD variant
was ported to the first widely deployed IA-32 machine with demand paged
virtual memory, the 80386 with 80387 FPU; if memory serves, this was
after ATT released a Unix for that platform.
We could discuss the file system debates to some length. Would either
the BSD file systems or EXT3, etc., scale to distributed WAN "file
systems"? Would either be "reliable" at such scales? I daresay no.
As for ultimate performance (say in minimizing actual CPU clock cycles,
memory accesses, etc., per "program execution"), a monolith typically
will outperform a microkernel design, just as a traditional unstructured
FORTRAN program (or in some cases, an assembly program) will outperform
an OO-design C++ program with encapsulation, etc. Which program is
longer-term maintainable? Which can be built by a large and dispersed
team? These are issues of practical software engineering, and again, a
subject of another discussion.
On 12/17/20 5:59 PM, Konstantin Olchanski wrote:
Rumination time, I jump in.
Why did monolithic kernel Linux, based primarily upon the
non-production-environment OS Minix from Tanenbaum used as an
implemented example for teaching OS at the undergraduate level,
achieve sector dominance over micro-kernel BSD-derivatives? ...
Linux killed everybody with superiour performance, for every
competitor, both microbenchmarks and real-use performance
of the Linux kernel were/are measurably better.
[what happened to BSD & derivatives?]
... it boils down to a great deal of uncertainty around BSDI,
UCB's CSRG, Bill Jolitz, and 386BSD, all of which descended from
the Unix codebase ...
The USL-BSD lawsuit came just at the right moment to cut the BSD
movement down at the knees. By the time the dust settled and
BSDs were running on PC hardware, Linux was already established.
correlate the timelines of lawsuit against Linux and BSD timeline:
https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_UNIX-5FSystem-5FLaboratories-2C-5FInc.-5Fv.-5FBerkeley-5FSoftware-5FDesign-2C-5FInc&d=DwIDAw&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=47s95Ne0aOss4Lm0rou8QPxpzTQCi3wXRAuoDuFUQCk&s=RFr_K56_2XQYOg5Dxhg6Opq3kewSaB-o7k4ldfvsSwk&e=
.
Linux is greenfield
I tend to think that was the key. Linux always had the advantage over BSD
in three areas (if you studied, programmed and used both, you already know
this):
- better TCP/IP stack in Linux
- better virtual memory system in Linux
- better filesystems in Linux
In all three, Linux had the "green field" advantage, plus the incentive
to beat competitors (at the time, BSD UNIX, SGI/IBM/DEC/SUN Unix derivatives).
In the TCP/IP stack, Linux people implemented zero-copy transfers and support
for hardware-acceleration pretty much right away.
In the VM system they figured out just the right balance between
application memory, kernel memory and filesystem caches, compared to BSD
"active/inactive" (and nothing else).
In filesystems, Linux was the first to solve the problem of "no corruption,
no need for fsck" after unexpected system reboot (i.e. on crash or power loss).
(with ext3/ext4). (ok, maybe SGI was there first for the rich people, with XFS,
but look what happened, XFS is now a mainstrean Linux filesystem).
Although, re-think your statement; Darwin with the macOS skin on it
has a great deal more marketshare than Linux. In many ways the
BSD-system-layered-on-a-microkernelish core did win; just not the
hearts of developers.
I would say, MacOS "won" not because but despite it's BSD foundations.
If you look behind the curtain (heck, if you look *at* the curtain), you will
see a BSD-ish kernel firmly stuck in the 1990-ies. No semtimedop() syscall,
incomplete
pthreads (no recursive locks), no /dev/shm (no command line tool to see and
control POSIX shared memory). The only visible kernel level innovation
are the "never corrupts" filesystem (mostly due to "never crashes" hardware, I
suspect)
and improved VM (encrypted *and* in-memory compressed, impressive!).
Anyhow, today, MacOS wins at ping-pong while the game is hockey, if Apple still
built hardware for serious computing, for sure the MacOS BSD "win" would count.
