[TUHS] OT: critical Intel design flaw

[Clem Cole]

On Wed, Jan 3, 2018 at 12:28 PM, Bakul Shah <bakul at bitblocks.com> wrote:

> This slowdown (which is not much -- L4 shows it is about 5% or so)
>
​I agree.   We came to the same conclusion in the early/mid 1990's  with
Mach and Chorus.   In fact, the UI 'requirements for modern OS' document
(which is part of why AT&T got behind Chorus for the never completed
SVR5/R6 stuff - I'll see if I can find a copy) was based on that work.

The OS weenies at the time felt that the cost was low enough and hardware
cheap enough that of course kernels would be the way to go.    AT&T
Research has switched to Plan9 and the like, again going 'small and light'
as opposed to monolithic and bigger (BSD, Tru64, Solaris, etc).

Similarly, Microsoft since Windows (not OS/2) was the UI for NT in the end;
Microsoft had to put hacks into the make user code word and NT became a
hybrid (like Mach 2.x) and never pushed the pure kernel that Mica (NT's
origin had been). To do so would have broken code which at the time was
something they were loath to do.  Similarly with Apple, when they switched
to Next and the Mach family they could have become more 'pure.'


Quickly it became a game of 'speed' and the Mach 3.0/4.0 was never fast (or
small enough).  To their credit, with OSF/RI trying to make a true uK, UI
tried to counter with Chorus, but by this time, Solaris was the 'UNIX of
Choice' for the AT&T world - which was being driven on high-end/high margin
systems.  Plus Mach 3.0 was never 'micro.'

None of the production Mach folks ever switched to it, because they did not
want to pay the performance penalty and we are users never pushed them.
Plus, by that  time the 386 had become the driver to the community as a
whole (certainly the low end/entry systems) and then AT&T suite blew up
UNIX in general with the law suite; and Linux came on the scene as the
savior.  Linus's  ​distain for microkernels was understood, but frankly I
think has hurt as if a uKernel based FOSS UNIX had been the leader; I
wonder if we would still be in the mess we are in.

I have personally hoped that something like L4/seL4 with a clean
UNIX/Plan9-ish style upper layer might some day be the thing that really
wins.   Maybe be written in something else - Rust/Go/Kotlin whatever ...
But I suspect that will happen long after I'm gone.

We keep reinventing the great work Ken, Dennis and Team did years ago and
sadly not really doing a good job of learning from our mistakes.

Linux (nor Windows) is/are hardly a small, simple system these days.  The
fact that AMD, Intel *et. al.* optimize the hardware is clearly traditional
sustaining engineering right out Christensen's book.

The hope is a new disruptive market -- as you say.  Maybe Arm/Cell phones
will be that.  I would not bet against them, but then again.   IBM/Intel *et
al *have a history of recovering.    It is going to be interesting to both
watch and play the game for the next few years -- UNIX is hardly dead nor
traditional complex systems that run on them, nor the HW that delivers it
:-)

All that said - the idea is that this HW error we could limit the damage a
bit but removing some of the complexity.  Their still an open question, if
the VM was in a server process, would we completely be free of the error.
As I understand it, not completely; but I think the damage/risk/fix would
be smaller and easier - which is my primary point.

Clem

ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180103/b11720d8/attachment.html>