Hardware references.

[John Morrison]

Hi,

Sometimes disagreements are due to differing terminology rather than differing
viewpoints, eh?

Kragen wrote:

> On Fri, 9 Oct 1998, John Morrison wrote:
> > Ray Dillinger wrote:
> > > means handling dynamic libraries and time-sharing and security
> > > and all the other awful details of a "real" operating system,
> > > eventually.
> >
> > I'm not sure I agree there.  I see DLLs/DSOs as poor substitutes for
> > dynamic Lisp (or Java) bindings.  And who cares about time-sharing in an
> > era of $340 PCs?
>
> Well, if by "time-sharing" you mean "multitasking", I care a lot about

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.

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.

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 (DSOs, IPC, pipes,
sockets, etc.-- hell, even copying filesystem contents from kernel to user
memory is another form of that cost).

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.

> 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.  It really pays to get to market first (even if you're giving software
away), unless you've got other competitive weapons you can leverage.  (Hmm... a
certain software company springs to mind...)

-jm