Re: [TUHS] CMU Mach sources?

[Clem Cole <clemc@ccc.com>]

[-- Attachment #1: Type: text/plain, Size: 5519 bytes --]

A couple of thoughts...

1.) Mach2.5 and 3.0 was part of an *extremely successful research project*
but also did suffer from issues associated with being so.  CSRG BTW *was
not a research project*, contrary to its name, it was a support contract
for DARPA since BTL would not support UNIX the way DEC, IBM, *et al*, did
with their products.   The reality is that Mach more than Thoth**), V
Kernel, QNX, Sol, Chrous, Minux or any other uK of the day, changed the way
people started to think about building an OS.    Give Rashid and team
credit - it showed some extremely interesting and aggressive ideas could be
made to work.

2.) Comparing Mach with BSD or SunOS 4.3 is not really a valid comparison.
 They had different goals and targets.   Comparing Ultrix, Tru64, or Mac
OSx with SunOS (or Solaris for that matter) is fair.   They all were
products.  They needed to be clean, maintainable and extensible [as Larry
likes to point out, Sun traded a great deal of that away for political
reasons with Solaris].   But the bottom line, you are comparing a test
vehicle to a production one.  And I while I agree with Larry on the
internals and a lot of the actual code in Mach, I was always pretty damned
impressed with what they crammed into a 5 lbs bag in a very short time.

3.) Mach2.5/386/Vax/etc.. << OSF/1 386 the later is similar what MtUnix
shipped.  Both are 'hybrid' kernels.   But while MtUnix created a product
with it, they were too small to do what DEC would later do.   But the
investment was greater than I think they could really afford.

4.) Mach 3.0 was from CMU, Mach 4.0 (which is still sort of available) was
from the OSF/1 [this is a pure uK].

3.) DEC OSF/1 (for MIPS) << Tru64 (for Alpha) - *a.k.a.* Digital UNIX - yes
both started with a Mach 2.5 hybrid kernel and the later was mostly the
same as OSF/1386, and both supported the Mach2.5 kernel message system -
but DEC's team rewrote darned near everything in the kernel -- which in
fact was both a bless and a curse [more in a minute].

Ok, so why have I bothered with all this mess.   The fact is Mach was able
to be turned into a product, both Apple and DEC did it.   Apple had the
advantage of starting with NextOS which (along with machTen) was the first
short at making a 'product' out of it.  But they invested a lot over the
years and incrementally changed it.  Enough to create XNU.    DEC was a
different story (which I lived a bit of personally).

The DEC PMAX (mips) and the Intel 386 were the first references from OSF.
 OSF had an issue.  IBM was supposed to deliver an OS, but for a number of
reasons was not ready when OSF needed something.   CMU had something that
was 'good enough.'

This is probably where Larry and I differ a little on shipping code.  I'm a
great believer figure out one solid goal and nailing it, and the rest is
'good enough' - i.e. fix in version 2.   I think OSF/1 as a reference
system nailed it.   Their job was get something out as a starting base that
ran on at least 2 workstations (and one server - which IIRC was an HP,
maybe an Encore box) but able to be shipped on an AT&T V.3 unlimited
license [which IBM had brought to the table].   The fact that they did not
spend a lot of time cleaning up about CMU at this stage was not their job.
 The kernel had to be good enough - and it was (Larry might argue Mach2.5
vs SunOS 4.3 it was not as good technically - and he might be right - but
that was not their job).

So DEC gets a new code based.  They have Ultrix (a product) for the PMAX.
OSF has released the reference port.   From a kernel code quality
standpoint, OSF1 1.0/PMAX < Ultrix/RISC 4.5.   They also are moving to a
new 64-bit processor that is not going to run either VAX or PMAX binaries (
*i.e.* you will have to recompile).   Two technical decisions and one
marketing one were made at the management level that would later doom
Tru64.   First, it was agreed that Tru64 was going to be 'pure 64-bit' and
it turned out >>none of the ISVs had clean code.  Moreover, there were no
tools to help find 64-bit issues.  This single choice cost DEC 3 years in
the ability to ship Tru64/Alpha.   The second choice was DEC's team decided
to re-write OSF/1 subsystem by subsystem.   The argument would be:  the XXX
system sucks.  It will never scale on a 64-bit system and it will not work
for clusters.  XXX was at least Memory Management, Terminal Handler, Basic
I/O, SCSI, File System.  The >>truth<< is each of these was actually right
in the small, they did suck.   But the fact is, they all were good enough
to get the system out the door and get customers and ISV's starting the
process of using the system.   Yes, Megasafe is an excellent FS, but UFS
was good enough to start.   The marketing decision BTW, that not to ship
Tru64/PMAX.   Truth is it was running internally.  But Marketing held that
Tru64 was the sexy cool thing and did not want to make it available.  The
argument was they would have to support it.   But the truth is that asking
ISV's and customers to switch Architecture and OS in one jump, opened the
door to consider Sun or HP (and with Tru64/Alpha's ecosystem taking 3 more
years, people left DEC).





** Mike Malcolm was the primary author of Thoth as his PhD from Waterloo.
HIs officemate, Kelly Booth (of the 'Graphics Killer-Bs) had a tee-shirt
made that exhaled:  'Thoth Thucks' and gave them to the lot of the Waterloo
folks.   BTW, Mike and Cheridon would later go to Stanford and create V.
 Two of their students would create QNX with still lives.

>

[-- Attachment #2: Type: text/html, Size: 7987 bytes --]