Hardware references.

[Kragen]

On Fri, 16 Oct 1998, John Morrison wrote:
> Sometimes disagreements are due to differing terminology rather than differing
> viewpoints, eh?

Yep.  :)

> When I mean multiple execution contexts (i.e., program counter and stack
> pointer values, irregardless of address space -- e.g., different threads or
> processes on a single given machine), I would say "multitasking."  However,
> when I mean different users logged on to the same machine, then I would say
> "time-sharing."  I think we both agree that we want
> multi-threaded/multi-tasking boxes.

OK.

> In addition (and all that follows are just my opinions), I see two
> qualitatively different kinds of boxes -- (1) highly-available, very "robust"
> servers, useful for time-sharing (e.g., shell accounts, web, NFS, OLTP), which
> of necessity must put threads/users in their own address spaces for robustness
> purposes, and (2) single-user desktop boxes, which needn't.

Well, highly-available robust boxes must ensure that users don't
interfere with each other.  Separate address spaces and hardware memory
protection are one way to handle one aspect of this.  Pointer safety,
enforced linguistically, is another way to handle the same aspect.

Myself, for my single-user desktop boxes (which run a lot of buggy
software, especially the one I develop on) I prefer OSes that ensure
that my buggy programs don't crash the kernel, or each other.

Evidently you want that too, from what you said below.  :)

> For servers, in which you've got a lot of separate-address-space processes
> which contain huge hunks of common code, DSOs can be a nifty memory-usage
> optimization through the use of shared-text pages (if done correctly -- NOT
> like Microsoft DLLs or early IRIX DSOs for lots of different reasons).
> Basically, you're spending lots of effort and runtime building  memory
> firewalls (heavyweight processes), and then spending lots more effort and
> runtime to help people clamber over them conditionally 

Ahh, now I understand what you meant when you said DSOs were a poor
emulation of Lisp dynamic bindings.  You didn't mean the
dynamically-linking-at-runtime part; you meant the sharing across
address spaces.

> For multithreaded/multitasking desktop boxes, why bother?  Just share bindings
> in a single address space (subject to suitable language robustness support 
> such as that found in LISP and/or Java for the memory firewalls you've 
> passed up). Even things like streaming video/audio get more efficient, etc.

Sounds good to me.  :)

> > The design was probably more of the Right Thing.  Linux is lots faster,
> > though, partly due to Mach.
> 
> I'm not really competent on to make specific comments on the relative merits of
> those approaches, but I'll bet time-to-market had something to do with it,
> too.

Probably so.  (I'm not really competent either.)

I think it also had a lot to do with the cathedral/bazaar thing.

Kragen (who has never booted his own OS, and who needs to learn how 
	to agree less violently)

-- 
<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
A well designed system must take people into account.  . . .  It's hard to
build a system that provides strong authentication on top of systems that
can be penetrated by knowing someone's mother's maiden name.  -- Schneier