[TUHS] OT: critical Intel design flaw

[TUHS] OT: critical Intel design flaw

[Noel Chiappa]

    > From: Andy Kosela

    > it appears this is a fundamental Intel bug that exists in all x86_64
    > CPUs.

I'm highly amused by the irony. Intel throws bazillions of transistors at
these hyper-complex CPUs in an attempt to make them as fast as possible - and
(probably because of the complexity) missed a bug, the fix for which
involves... slowing things way down!

I wonder how many other bugs are lurking in these hyper-complex designs?
Didn't anyone at Intel stop to think that complexity is bad, in and of itself?
But I guess the market demands for faster and faster machines outweighed that
- until it bit them in the posterior. The real question is 'how many more times
will it have to happen before they get a clue'?


There's an interesting parallel between this, and uSloth's struggle with
security and bugs. For a long time, it seemed it was more important to the
market to add features (i.e.  complexity), and security be damned - until poor
security really started to become an issue.

So now they're trying to catch up - but seemingly still haven't got there, in
terms of the fundamental architecture of the OS, as the never-ending stream of
bug patches attests.

The sad thing is that how to provide good security (not perfect, but much,
much better than what we have) was worked out a long time ago, and Intel hired
Roger Schell to add the necessary hardware underpinnings when they did the
386:

  http://conservancy.umn.edu/bitstream/11299/133439/1/oh405rrs.pdf

Mutatis mutandis.

	Noel

[TUHS] OT: critical Intel design flaw

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1556 bytes --]

below..

On Wed, Jan 3, 2018 at 8:43 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>
> I'm highly amused by the irony. Intel throws bazillions of transistors at
> these hyper-complex CPUs in an attempt to make them as fast as possible -
> and
> (probably because of the complexity) missed a bug, the fix for which
> involves... slowing things way down!
>

​+1 however... I think there is a corollary ​

>
> I wonder how many other bugs are lurking in these hyper-complex designs?
> Didn't anyone at Intel stop to think that complexity is bad, in and of
> itself?
>
​Exactly....​
​ and a loud "Amen Brother Chiappa​
."
​

IIRC this is part of the argument Dykstra made with the THE paper years
ago, Parnas in his information hiding paper -- i.e. why microkernels and
proper layering are a good idea.   Keep is simple and do one thing
well/protect yourself against other subsystems not being 100%.  Linux and
Winders are are bad a the processor.

​Yup microkernels are a tad slower and have more overhead, and might
(probably will) cost a little more.   But I really do think simplicity
beats complexity and I'll pay a bit in over head to keep it simple.

The problem of course for my employers over the years, is that many  people
(most
​people ​
probably)
​ ​
do not think me
​ and follow their wallet on the fastest for the cheapest​
;-)

Clem​

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

[TUHS] OT: critical Intel design flaw

[Bakul Shah]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 738 bytes --]

On Jan 3, 2018, at 6:26 AM, Clem Cole <clemc at ccc.com> wrote:
> 
> ​Yup microkernels are a tad slower and have more overhead, and might (probably will) cost a little more.   But I really do think simplicity beats complexity and I'll pay a bit in over head to keep it simple.

This slowdown (which is not much -- L4 shows it is about 5% or so)
is more due to h/w security architecture that has not evolved for
decades. None of the microkernel research has had any influence on
x86/ARM etc. Look at how Mill solves the problem. A protection
domain switch (a portal call) takes two extra fetches. Second, I
think the protection ring idea was counterproductive. It allowed
people to be lazy and stuff all sorts of things in the kernel.

[TUHS] OT: critical Intel design flaw

[ron minnich]

The type of kernel is orthogonal to this particular design flaw from what I
know. It's about how page tables are set up for user mode processes. I may
be wrong but pretty much every Unix or Unix-like kernel (including Plan 9)
follows the page table model Windows and Linux use: the ring 0 PTEs are
present in the page table, even in user mode, and we count on the
architecture to prevent ring 3 access to ring 0 memory. This is certainly
the case on all the ones I've worked on.

I don't think a microkernel would save you.

This is not a much ado about nothing case: it's early days and people can
make it work: https://twitter.com/brainsmoke/status/948561799875502080
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180103/8dc6e01a/attachment.html>

[TUHS] OT: critical Intel design flaw

[Bakul Shah]

On Jan 3, 2018, at 9:46 AM, ron minnich <rminnich at gmail.com> wrote:
> 
> The type of kernel is orthogonal to this particular design flaw from what I know. It's about how page tables are set up for user mode processes. I may be wrong but pretty much every Unix or Unix-like kernel (including Plan 9) follows the page table model Windows and Linux use: the ring 0 PTEs are present in the page table, even in user mode, and we count on the architecture to prevent ring 3 access to ring 0 memory. This is certainly the case on all the ones I've worked on. 
> 
> I don't think a microkernel would save you.

My point was simply that in a ukernel this arrangement doesn't buy
you much as the real "OS" is just another user level process. The
ukernel is basically just a message router. In Mill the message
routing itself is done in h/w (well, a portal call is more like
a call to a different protection domain in the same thread so no
need for marshalling/unmarshalling arguments).

[TUHS] OT: critical Intel design flaw

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3575 bytes --]

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-0001.html>

[TUHS] OT: critical Intel design flaw

[Forrest, Jon]

It will be interesting to see if RISC-V suffers from this. If not,
that might be just the ticket they were looking for to gain (more)
mainstream acceptance.

Jon

[TUHS] OT: critical Intel design flaw

[ron minnich]

it's implementation dependent, not architecture dependent.

RISC-V implementations I've seen don't do the kind of speculation that
brought intel to grief.



On Wed, Jan 3, 2018 at 10:39 AM Forrest, Jon <nobozo at gmail.com> wrote:

>
> It will be interesting to see if RISC-V suffers from this. If not,
> that might be just the ticket they were looking for to gain (more)
> mainstream acceptance.
>
> Jon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180103/980ba447/attachment.html>

[TUHS] OT: critical Intel design flaw

[Paul Winalski]

On 1/3/18, Clem Cole <clemc at ccc.com> wrote:
> On Wed, Jan 3, 2018 at 12:28 PM, Bakul Shah <bakul at bitblocks.com> wrote:
>
> 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 work 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.

Microsoft's developers had a "hook and hack" mentality with regard to
the OS.  This goes back to the days of DOS, when once your application
started, you could do anything you pleased, as long as you put the OS
kernel back to its clean state before you exited.  Dave Cutler fought
tooth and nail against any attempts to insert hooks in the NT
microkernel, or to muddle the layered design.  But after Dave left
day-to-day NT development, things got muddied up.

-Paul W.

[TUHS] OT: critical Intel design flaw

[Bakul Shah]

On Jan 3, 2018, at 10:27 AM, Clem Cole <clemc at ccc.com> wrote:
> 
> 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.

It may be sooner than you think. Now it is much harder to
produce faster processors than to produce processors with
larger and larger number of cores.  For most tasks not *all*
of these cores have to work in tandem -- more likely you will
run a set of loosely coupled diverse tasks on such a machine.
In this scenario it is not clear to me that centralized OSes
like like unix/windows can use these cores efficiently. Not
even plan9 will do well. In the "cloud" we have already given 
up on such centralization (though present solutions seem
clunky and inefficient).

IMHO what we need a much more composable architecture. In
Barrelfish, a research OS based on L4, each core has its own
ukernel that can be independently brought up. This may be a
direction worth exploring[1]. If done right + an orchestration
protocol can provide the basis for clean, secure, scalable
and resilient distributed systems.

> 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.

a) Actually we don't reinvent their work -- we just keep
   fiddling at the edges!
b) IMHO their work is better thought of as a compositional
   architecture or service protocol. That is, in a ukernel
   arch., different user processes can implement different
   Unix "system call" protocols. There is no reason to stuff
   all that in a single "kernel". This model actually fits
   in with what you said (L4/seL4 with a clean UNIX/Plan9-ish
   style upper layer).

[1] My real bias is that even ukernels shouldn't exist! That
is, the very core OS function of thread and protection switch
should be done in h/w via a few instructions. The *policy* of 
this is implemented in s/w. Then an OS is just a (set of)
shared libraries and a set of initial services. Thinking this
way, it is clear that a ukernel is merely implementing this
model in s/w and it makes perfect sense for each core to have
its own emulation layer!

None of above has anything to do with the "intel design flow".

[TUHS] OT: critical Intel design flaw

[Theodore Ts'o]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3941 bytes --]

On Wed, Jan 03, 2018 at 01:27:19PM -0500, Clem Cole 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.

It's possible to keep the slowdown at 5%, but how much extra
engineering work does it take to get the performance gap down to that
level?  And during that time while the micro kernel team is playing
catchup, if the OS with the monolithic kernel adds new features to the
OS, how much additional time does it take to add those features to the
OS?  (Regardless of whether the features are implemented in userspace,
or in the kernel, or some combination of the two.)

> 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.

Actually, at least part of the problem was that graphics performance
was *terrible*.  So in NT 4.0 they moved it into the kernel for
performance reasons.  One could argue that with enough effort, the
graphics performance perhaps could have been improved while keeping
within the microkernel design principles.  But in the commercial
marketplace, timing is everything; and even being six months late to
the game can be enough to lose the battle for mindshare.

(There are those who have argued that the *BSD's were delayed by
around six months due to the AT&T / Berkeley lawsuit, and if it were
but for that, Linux would not have gained the prominence that it
had/has.  I'm not completely sure I buy that; there were *BSD
developers in the Boston area, and it was primarily because of a
certain toxic personality that they failed to lure me to the *BSD side
of the force --- and I got my start working kernels with BSD 4.3+ at
MIT Project Athena.  Despite how people like to complain about Linus's
shortcomings in that department, let's just say that IMHO there are
*far* worse personalities in the open source OS world, and leave it at
that.)

> 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
> :-)

Well, Fuchsia is based on a microkernel, and one interesting thing
about it is that full POSIX compatibility is *not* a goal.  The team
is apparently not worried about legacy support (where they consider
Linux and Unix "legacy") and performance on HDD's is also a legacy
issue.  (It's the 21st century, except for big data centers at Google,
Facebook, Microsoft, et. al, who uses disk drives in this day and
age?)

There will be rough POSIX compatibility, but it is refreshing that
they don't consider horrendous design decisions (e.g., such as telldir
and seekdir) things that they are bound to support.

Of course this means no X11, no GNOME, no KDE, etc.  (And because
there is no telldir/seekdir, no Samba support, either.  Oh, well.  Who
needs to serve CIFS, anyway?)  All graphical applications that want to
run on Fuchsia have to be rewritten to use graphics SDK called
"Flutter".  It'll be interesting to see what happens with this
approach, and whether it can supplant the Linux/Unix ecosystem.

       		   	    		   - Ted

[TUHS] OT: critical Intel design flaw

[Larry McVoy]

On Wed, Jan 03, 2018 at 06:40:25PM -0500, Theodore Ts'o wrote:
> On Wed, Jan 03, 2018 at 01:27:19PM -0500, Clem Cole 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.
> 
> It's possible to keep the slowdown at 5%, but how much extra
> engineering work does it take to get the performance gap down to that
> level?  And during that time while the micro kernel team is playing
> catchup, if the OS with the monolithic kernel adds new features to the
> OS, how much additional time does it take to add those features to the
> OS?  (Regardless of whether the features are implemented in userspace,
> or in the kernel, or some combination of the two.)

To add to Ted's points.  I was good friends with one of the core guys
on the QNX team a long time ago (he died early in 1998 of brain cancer.
Yuck).  The QNX micro kernel really was micro, the kernel fit entirely in
a 4K instruction cache on x86 (thanks CISC).  It did very, very little.
It took a lot of thinking and discipline to figure out what the kernel
should do and what should be delegated.  There was constant pressure to
put more stuff in the kernel.

My buddy told me that there were only 4 people who were allowed to touch
the actual kernel code.  And they all both backed each other up and
second guessed each other in code reviews.  They counted instructions
and cache misses each time they changed stuff.

As a result, the QNX kernel of the late 1980's and 1990's was super
super fast.  I ran as much as 10 users logged in to a 80286 running
QNX doing text editing and compiles and it actually worked.  I'd 
argue that it worked better than Unix would have worked on that 
miserable processor.

QNX made it work.  I think they slowed down when they put full posix in
but they made it work.

The problem is that most people / companies are not that disciplined.
Oh, we need this for $CUSTOMER and this for $BENCHMARK and this for
$STANDARD and the easiest way to get it is to shove it into the kernel.

I'd argue that microkernels are indeed the best answer but only if you
have the best programmers.  Which nobody does even though everyone claims
they do.

Monolithic kernels are far more amenable to less than awesome people
messing with them.  Sad but true, I'd love a microkernel world but I
fear we are too stupid to get it.  Something, something, something,
this is why we can't have nice things.

--lm

[TUHS] OT: critical Intel design flaw

[Bakul Shah]

On Wed, 03 Jan 2018 16:51:03 -0800 Larry McVoy <lm at mcvoy.com> wrote:
Larry McVoy writes:
> On Wed, Jan 03, 2018 at 06:40:25PM -0500, Theodore Ts'o wrote:
> > On Wed, Jan 03, 2018 at 01:27:19PM -0500, Clem Cole 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  wit
> h
> > > 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.
> > 
> > It's possible to keep the slowdown at 5%, but how much extra
> > engineering work does it take to get the performance gap down to that
> > level?  And during that time while the micro kernel team is playing
> > catchup, if the OS with the monolithic kernel adds new features to the
> > OS, how much additional time does it take to add those features to the
> > OS?  (Regardless of whether the features are implemented in userspace,
> > or in the kernel, or some combination of the two.)

I can't find the specific paper that mentions 5% but see
Liedke's SOSP97 paper:
  https://os.inf.tu-dresden.de/pubs/sosp97/ 
He specifically mentions keeping porting effort low:
  "In particular, we felt that it was beyond our means to tune
  Linux to our -kernel in the way the Mach team tuned their
  single-server Unix to the features of Mach."

Also see  
  http://os.inf.tu-dresden.de/papers_ps/adam-diplom.pdf
Where the author reports overall about 17-22% slow down
compared to native versions of Linux 2.4 or 2.6. Not sure if
these are multicore version or not.

https://l4linux.org/ shows L4Linux has been ported to
Linux-4.13.  It would be interesting to see its performance.
Port of 4.6 was announced in May 2016 and 4.7 in August 2016
so my guess is porting is more than just recompile but not a
very significant effort.

> To add to Ted's points.  I was good friends with one of the core guys
> on the QNX team a long time ago (he died early in 1998 of brain cancer.

Dan Hildebrand? I used QNX in 86 and had read his papers but never
met him.

> The problem is that most people / companies are not that disciplined.

The whole idea is not to hack on the ukernel endlessly but to
build apps on top of it. On something like Mill you won't even
need most of the features of ukernels like L4 or QNX. Best to
think of them as s/w emulation of needed h/w instructions
(just like we used to use s/w emulation of floating point math
on early 68K machines).

> Oh, we need this for $CUSTOMER and this for $BENCHMARK and this for
> $STANDARD and the easiest way to get it is to shove it into the kernel.

In my view this is a losing game - particularly it if is
played using performance as the main metric. The the single
most critical problem today is that of lax security, not a
lack of performance. It is no longer just the NSA or CIA
or banks that have to worry about bad guys stealing their
stuff. We all have to. Even stealing has been
democratized/massively empowered by the Internet!

My first unix box's CPU was 16 bit unicore cpu running at
5.6Mhz on a 256KB machine.  Today I am using 4 physical core,
8 hyperthreaded 64 bit CPU running at 2.5Ghz on a 16GB
machine.  But I certainly don't feel my productivity has gone
up even by a factor of 10.  Will I notice if the machine runs
10% slower if I can get more security? As I mentioned services
running in the cloud aren't necessary running most effciently.
So far just the single slowdown due to the Meltdown bug is
bigger than due to implementing unix on top of a ukernel. And
we don't even have a solution yet for Spectre.

> I'd argue that microkernels are indeed the best answer but only if you
> have the best programmers.  Which nobody does even though everyone claims
> they do.
> 
> Monolithic kernels are far more amenable to less than awesome people
> messing with them.  Sad but true, I'd love a microkernel world but I
> fear we are too stupid to get it.  Something, something, something,
> this is why we can't have nice things.

A monlithic kernel reimplemented as a set of services on top
of ukernel would be even more amenable. But there are too many
vested interests in the current state of the computer world.
This is the same point Roger Schell made near the end of his
interview (see the link in Noel Chiappa's message today).

[TUHS] OT: critical Intel design flaw

[Larry McVoy]

On Wed, Jan 03, 2018 at 06:13:59PM -0800, Bakul Shah wrote:
> > To add to Ted's points.  I was good friends with one of the core guys
> > on the QNX team a long time ago (he died early in 1998 of brain cancer.
> 
> Dan Hildebrand? I used QNX in 86 and had read his papers but never
> met him.

Yep, great guy.  We could argue long and hard but it was always about
the tech, never about the person.  An engineer's engineer.

> > The problem is that most people / companies are not that disciplined.
> 
> The whole idea is not to hack on the ukernel endlessly but to
> build apps on top of it. On something like Mill you won't even

Um, I've been reading about Mill for at least a decade.  It's not 
real until it ships.  It's still vaporware, no?

> > I'd argue that microkernels are indeed the best answer but only if you
> > have the best programmers.  Which nobody does even though everyone claims
> > they do.
> > 
> > Monolithic kernels are far more amenable to less than awesome people
> > messing with them.  Sad but true, I'd love a microkernel world but I
> > fear we are too stupid to get it.  Something, something, something,
> > this is why we can't have nice things.
> 
> A monlithic kernel reimplemented as a set of services on top
> of ukernel would be even more amenable. 

That's been the claim but there is no data to support that claim.  In fact
the opposite.  History has shown that microkernels can work if you are 
super super careful.  Monolithic kernels work in spite of all the idiots
checking in stupid stuff.

I *love* the idea of a microkernel with a bunch of processes implementing
the OS, it's so much a better design.  I also have been in the real world
long enough to think that I'm not going to see Linux replaced with a 
microkernel in my lifetime.  I wish, but I don't see it happening.

--lm

[TUHS] OT: critical Intel design flaw

[Bakul Shah]

On Wed, 03 Jan 2018 18:26:04 -0800 Larry McVoy <lm at mcvoy.com> wrote:
Larry McVoy writes:
> 
> > > The problem is that most people / companies are not that disciplined.
> > 
> > The whole idea is not to hack on the ukernel endlessly but to
> > build apps on top of it. On something like Mill you won't even
> 
> Um, I've been reading about Mill for at least a decade.  It's not 
> real until it ships.  It's still vaporware, no?

It is vaporware mainly because it's a largely self/unfunded
effort led by one guy and a very lean volunteer team.  I don't
know if it will actually get funded -- in my view there are
enough interesting things in it that it is worth supporting by
one of the big 3 or 4 companies (or a 3 letter govt agency).
Its architecture certainly seems realizable (of course, proof
is in the pudding etc).  But even just with ukernels we can
achieve similar isolation & security.

Here is a recent paper:
  http://ssrg.nicta.com.au/publications/csiro_full_text//Elphinstone_ZMH_17.pdf
They show that seL4+rumpkernel is actually faster than native NetBSD on
the same hardware (atleast on some TCP throughput tests).

> I *love* the idea of a microkernel with a bunch of processes implementing
> the OS, it's so much a better design.  I also have been in the real world
> long enough to think that I'm not going to see Linux replaced with a 
> microkernel in my lifetime.  I wish, but I don't see it happening.

It won't *replace* linux but linux API can be made available
via such processes and a shared lib.  You may be right about
real world inertia. And Security is simply not taken seriously
enough.  I still think it would be well worth it for
knowledgeable OS folks like you to /actually/ explore this
design space and see what is possible.  It would certainly be
more fun than hacking on Linux or FreeBSD! 

[TUHS] OT: critical Intel design flaw

[Arthur Krewat]

On 1/3/2018 6:40 PM, Theodore Ts'o wrote:
> It's the 21st century, except for big data centers at Google,
> Facebook, Microsoft, et. al, who uses disk drives in this day and
> age?
Have you actually priced "Enterprise" level SSD's lately that come with 
a support contract so that when they hit their end of life, the VAR will 
replace them?

Dell 400GB SLC (Hitachi) in a Compellent, $5K, and that's with an 
educational discount a couple of years ago.

Sure, if you're doing an IOPS/$ comparison, they shine. But for the most 
part, a Compellent with a few SLC SSDs, and a few MLC SSDs, still needs 
spinning rust to make the bulk of the storage.

And this is a tiny 70TB installation mostly for VMware and Oracle DB.

ak

[TUHS] OT: critical Intel design flaw

[Dan Cross]

On Wed, Jan 3, 2018 at 9:09 PM, Arthur Krewat <krewat at kilonet.net> wrote:

> On 1/3/2018 6:40 PM, Theodore Ts'o wrote:
>
>> It's the 21st century, except for big data centers at Google,
>> Facebook, Microsoft, et. al, who uses disk drives in this day and
>> age?
>>
> Have you actually priced "Enterprise" level SSD's lately that come with a
> support contract so that when they hit their end of life, the VAR will
> replace them?
>
> Dell 400GB SLC (Hitachi) in a Compellent, $5K, and that's with an
> educational discount a couple of years ago.
>
> Sure, if you're doing an IOPS/$ comparison, they shine. But for the most
> part, a Compellent with a few SLC SSDs, and a few MLC SSDs, still needs
> spinning rust to make the bulk of the storage.
>
> And this is a tiny 70TB installation mostly for VMware and Oracle DB.
>

Well sure, but I think this sort of reinforced Ted's point: you're not
going to run Fuschia on that machine. The machine you are describing is,
conceptually, more in the camp of the things you'd find in a big company's
datacenter rather than in an end-user's cell phone or laptop.

One of the issues with Unix/Linux-style kernels is that they try to be
"general-purpose": suitable for any number of tasks. A new direction in
systems is the realization that the software we run in datacenters doesn't
need to be the same as the software we run on our desktop machines. The big
iron in the rack doesn't necessarily need a graphics subsystem or USB
drivers for keyboards, mice, or other data-entry things, for instance; it
certainly doesn't need X11, GNOME, and on-and-on.

Fuschia's approach is the dual of this: the kernel to drive the cell phone
doesn't need datacenter-class storage support or 10Gbps networking.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180103/2acbfd55/attachment.html>

[TUHS] OT: critical Intel design flaw

[Arthur Krewat]

On 1/3/2018 10:21 PM, Dan Cross wrote:
> Well sure, but I think this sort of reinforced Ted's point: you're not 
> going to run Fuschia on that machine. The machine you are describing 
> is, conceptually, more in the camp of the things you'd find in a big 
> company's datacenter rather than in an end-user's cell phone or laptop.
Quite true, didn't realize that the context was small-form-factor.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180104/1ac647da/attachment.html>

[TUHS] OT: critical Intel design flaw

[Harald Arnesen]

Theodore Ts'o [2018-01-04 00:40]:

> (There are those who have argued that the *BSD's were delayed by
> around six months due to the AT&T / Berkeley lawsuit, and if it were
> but for that, Linux would not have gained the prominence that it
> had/has.

Didn't Linus say that if there had been an affordable BSD available at
the time, he wouldn't have started the Linux project?

[TUHS] OT: critical Intel design flaw

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1754 bytes --]

On Thu, Jan 4, 2018 at 6:53 AM, Harald Arnesen <harald at skogtun.org> wrote:

> Didn't Linus say that if there had been an affordable BSD available at
> the time, he wouldn't have started the Linux project?


​You need to add >>and that he knew about and had access<<.

The truth is there was and it had networking and X windows already.  Bill
Jolitz had completed the original 386 BSD port (and actually started to
publish about it in DDJ).  The 386BSD sources were available to all BSD
licensees - as CSRG had put them on the ucbvax ftp server (truth is they
were actually available to anyone there knew how to grab it -- the attempt
to keep the ftp address 'secret' was pretty shallow - not quite announced
on net.noise but it certainly was passed hacker to hacker if you went to a
USENIX conference in those days).​  The funny part was that Linus
university was a BSD licensee and could have gotten it (although I've
personally never seen or heard of evidence that they did).

So this was an example of ignorance of something, not true in fact - That
said, Linus solved the problem he had.  More power to him.  Although his
original kernel was a far cry from '386BSD' - but that was the point.
 When the AT&T case came out, hackers like me were worried 386BSD was going
to go away and started to help make Linux more complete.

I should (as Larry has pointed out) at the time of Linus original work,
some institutions were far more liberal about source access than others.
So even if Linus has known about Jolitz's work, its not clear he
would/could have had access to it.

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

[TUHS] OT: critical Intel design flaw

[Larry McVoy]

On Thu, Jan 04, 2018 at 09:03:09AM -0500, Clem Cole wrote:
> On Thu, Jan 4, 2018 at 6:53 AM, Harald Arnesen <harald at skogtun.org> wrote:
> > Didn't Linus say that if there had been an affordable BSD available at
> > the time, he wouldn't have started the Linux project?
> 
> ???You need to add >>and that he knew about and had access<<.
> 
> The truth is there was and it had networking and X windows already.  Bill
> Jolitz had completed the original 386 BSD port (and actually started to
> publish about it in DDJ).  The 386BSD sources were available to all BSD
> licensees 

But that's not what Linus (or anyone) wanted.  They wanted it under some
sort of clearly open source license.  None of us knew what the penalty
was for violating the license, we just knew that at one end was us, with
no means to fight a court battle, and at the other end were big entities
that viewed court battles as a cost of doing business.

I didn't know at the time that Bell Labs had to license their stuff as
part of the monopoly deal, that was something I learned here.  So I, and
I suspect lots of other people, most people, the best people :) all 
thought that our access to the source was at the whim of AT&T, it could
be taken away at any time.

That wasn't the rosy "everybody who wanted it could get it" world that
Clem lived in.  Clem was in a special club, heck, he was president of
Usenix at one point, that's sort of the epitome of being in the club.
Not being in the club was a far less rosy place and it made perfect
sense for Linus to start Linux.  I'd argue that if he hadn't, someone
else would have.

Stupid lawsuit means we're mostly running a Unix-clone, not actual Unix.

--lm

[TUHS] OT: critical Intel design flaw

[Theodore Ts'o]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1379 bytes --]

On Thu, Jan 04, 2018 at 09:03:09AM -0500, Clem Cole wrote:
> ​You need to add >>and that he knew about and had access<<.
> 
> The truth is there was and it had networking and X windows already.  Bill
> Jolitz had completed the original 386 BSD port (and actually started to
> publish about it in DDJ).

How real was it in June 1991, when he demo'ed it in Usenix Anaheim?
Was it at the level of a "MIT Media Lab demo", or was it actually
something that could be used in anger?

The official history states that 386 BSD version 0.0 was released in
March 1992, and the "much more usable" 0.1 version was released in
July 1992.

The biggest problem with Jolitz's work seems to have been more social
than anything else.  The writeups from that era seem to indicate that
the Jolitz's wanted to keep a much tighter control over things, and
this discouraged collaboration and contributions, which led to the
first of *BSD fragmentation/spin-offs, starting with FreeBSD and
NetBSD.

Contrast that to Linus, where I started playing with Linux in
September 1991 (Linux 0.09), and in three months he accepted fairly
major patches from me to implement all of the new syscalls and changes
needed to implement POSIX Job Control and POSIX termios (Linux 0.12).
The Linux developers were not spending time fighting over who would
get commit bits; we were having fun writing code.

						- Ted

[TUHS] OT: critical Intel design flaw

[Andy Kosela]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2242 bytes --]

On Thursday, January 4, 2018, Theodore Ts'o <tytso at mit.edu> wrote:

> On Thu, Jan 04, 2018 at 09:03:09AM -0500, Clem Cole wrote:
> > ​You need to add >>and that he knew about and had access<<.
> >
> > The truth is there was and it had networking and X windows already.  Bill
> > Jolitz had completed the original 386 BSD port (and actually started to
> > publish about it in DDJ).
>
> How real was it in June 1991, when he demo'ed it in Usenix Anaheim?
> Was it at the level of a "MIT Media Lab demo", or was it actually
> something that could be used in anger?
>
> The official history states that 386 BSD version 0.0 was released in
> March 1992, and the "much more usable" 0.1 version was released in
> July 1992.
>
> The biggest problem with Jolitz's work seems to have been more social
> than anything else.  The writeups from that era seem to indicate that
> the Jolitz's wanted to keep a much tighter control over things, and
> this discouraged collaboration and contributions, which led to the
> first of *BSD fragmentation/spin-offs, starting with FreeBSD and
> NetBSD.
>
> Contrast that to Linus, where I started playing with Linux in
> September 1991 (Linux 0.09), and in three months he accepted fairly
> major patches from me to implement all of the new syscalls and changes
> needed to implement POSIX Job Control and POSIX termios (Linux 0.12).
> The Linux developers were not spending time fighting over who would
> get commit bits; we were having fun writing code.
>
>                                                  - Ted


My understanding is that initially Linux project was much simpler
and minimalistic than BSD, which in the late 80s was already a very bloated
O/S as compared to UNIX V6/V7.  And it was also one of the reasons some
folks preferred it.  It was kind of like moving back in time to times of
hacking on V6 for new generation of hackers.  Pure fun.  Minimalism is what
initially brought me to Unix.

Of course today Linux is as bloated Windows, thats why some people prefer
to hack on simpler projects like FUZIX (Alan Cox).

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180104/fdc3e80f/attachment.html>

[TUHS] OT: critical Intel design flaw

[Larry McVoy]

On Thu, Jan 04, 2018 at 11:45:57AM -0500, Theodore Ts'o wrote:
> On Thu, Jan 04, 2018 at 09:03:09AM -0500, Clem Cole wrote:
> > ???You need to add >>and that he knew about and had access<<.
> > 
> > The truth is there was and it had networking and X windows already.  Bill
> > Jolitz had completed the original 386 BSD port (and actually started to
> > publish about it in DDJ).
> 
> How real was it in June 1991, when he demo'ed it in Usenix Anaheim?
> Was it at the level of a "MIT Media Lab demo", or was it actually
> something that could be used in anger?

I dunno what "used in anger" means but it worked.  I used it.  I know
Joltiz pretty well, he worked for me around this time period.  I hired
him just to give him some money, he had gotten sort of screwed by the
in crowd in the BSD/Usenix world, I didn't see that as reasonable.

> The biggest problem with Jolitz's work seems to have been more social
> than anything else.  The writeups from that era seem to indicate that
> the Jolitz's wanted to keep a much tighter control over things, and
> this discouraged collaboration and contributions, which led to the
> first of *BSD fragmentation/spin-offs, starting with FreeBSD and
> NetBSD.

Yep.  Leading to the famous (to me) quote: The BSD guys can't decide
who is going to drive the big red fire truck so they each get to drive
their very own toy fire truck.  (I think Linus said that but not sure).

[TUHS] OT: critical Intel design flaw

[Bakul Shah]

On Thu, 04 Jan 2018 09:17:40 -0800 Larry McVoy <lm at mcvoy.com> wrote:
Larry McVoy writes:
> 
> I dunno what "used in anger" means but it worked.  I used it.  I know
> Joltiz pretty well, he worked for me around this time period.  I hired
> him just to give him some money, he had gotten sort of screwed by the
> in crowd in the BSD/Usenix world, I didn't see that as reasonable.

Not part of any in crowd but I am curious.  How was Jolitz
"screwed by the in crowd in the BSD/Usenix world"?

I got 38BSD on a set of floppies from someone in 92 or 93  -
can't remember - and I recall meeting Jolitz at some meetup
back then.  At the time I was using a Sun 3/50 (BSD) & a
Fortune Box (V7) but promptly bought a 386 box (with a full
16MB of memory) and installed 386bsd. I also played with
linux-0.11 but I recall reading something about Linus using
SysV as a reference and that was the end of my interest in
linux! Also because 386BSD was already available and did what
I wanted. Later BSD splits were distressing but so it goes.

[TUHS] OT: critical Intel design flaw

[Larry McVoy]

On Thu, Jan 04, 2018 at 10:29:59AM -0800, Bakul Shah wrote:
> On Thu, 04 Jan 2018 09:17:40 -0800 Larry McVoy <lm at mcvoy.com> wrote:
> Larry McVoy writes:
> > 
> > I dunno what "used in anger" means but it worked.  I used it.  I know
> > Joltiz pretty well, he worked for me around this time period.  I hired
> > him just to give him some money, he had gotten sort of screwed by the
> > in crowd in the BSD/Usenix world, I didn't see that as reasonable.
> 
> Not part of any in crowd but I am curious.  How was Jolitz
> "screwed by the in crowd in the BSD/Usenix world"?

I'll answer off list, not interested in ruffling feathers.

[TUHS] OT: critical Intel design flaw

[Warner Losh]

On Jan 4, 2018 11:50 AM, "Larry McVoy" <lm at mcvoy.com> wrote:

On Thu, Jan 04, 2018 at 10:29:59AM -0800, Bakul Shah wrote:
> On Thu, 04 Jan 2018 09:17:40 -0800 Larry McVoy <lm at mcvoy.com> wrote:
> Larry McVoy writes:
> >
> > I dunno what "used in anger" means but it worked.  I used it.  I know
> > Joltiz pretty well, he worked for me around this time period.  I hired
> > him just to give him some money, he had gotten sort of screwed by the
> > in crowd in the BSD/Usenix world, I didn't see that as reasonable.
>
> Not part of any in crowd but I am curious.  How was Jolitz
> "screwed by the in crowd in the BSD/Usenix world"?

I'll answer off list, not interested in ruffling feathers.


Probably best... as someone on the other side during that time, I have a
different perspective on who got screwed when... and what beds were made
and who had to sleep in them...

But I agree rehashing all that now is not beneficial to anybody...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180104/57d6ebae/attachment.html>

[TUHS] OT: critical Intel design flaw

[Bakul Shah]

> On Jan 4, 2018, at 12:52 PM, Warner Losh <imp at bsdimp.com> wrote:
> 
> 
> 
> On Jan 4, 2018 11:50 AM, "Larry McVoy" <lm at mcvoy.com <mailto:lm at mcvoy.com>> wrote:
> On Thu, Jan 04, 2018 at 10:29:59AM -0800, Bakul Shah wrote:
> > On Thu, 04 Jan 2018 09:17:40 -0800 Larry McVoy <lm at mcvoy.com <mailto:lm at mcvoy.com>> wrote:
> > Larry McVoy writes:
> > >
> > > I dunno what "used in anger" means but it worked.  I used it.  I know
> > > Joltiz pretty well, he worked for me around this time period.  I hired
> > > him just to give him some money, he had gotten sort of screwed by the
> > > in crowd in the BSD/Usenix world, I didn't see that as reasonable.
> >
> > Not part of any in crowd but I am curious.  How was Jolitz
> > "screwed by the in crowd in the BSD/Usenix world"?
> 
> I'll answer off list, not interested in ruffling feathers.
> 
> Probably best... as someone on the other side during that time, I have a different perspective on who got screwed when... and what beds were made and who had to sleep in them...  
> 
> But I agree rehashing all that now is not beneficial to anybody...

My fault. I had meant to reply to just Larry but forgot to remove cc: to the list.
Apologies.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180104/61d65490/attachment.html>

[TUHS] OT: critical Intel design flaw

[Theodore Ts'o]

On Thu, Jan 04, 2018 at 10:29:59AM -0800, Bakul Shah wrote:
> 16MB of memory) and installed 386bsd. I also played with
> linux-0.11 but I recall reading something about Linus using
> SysV as a reference and that was the end of my interest in
> linux!

As far as I know that was never true.  We used used POSIX as a
reference mainly because it was more easily available as a
specification.  So that meant that we implemented termios support, and
not termio, or the BSD variant.  The networking layer was all BSD
sockets; we certainly never implemented STREAMS, for goodness sake!  :-)

	    	      	    			 - Ted

[TUHS] OT: critical Intel design flaw

[Warner Losh]

On Thu, Jan 4, 2018 at 1:56 PM, Theodore Ts'o <tytso at mit.edu> wrote:

> On Thu, Jan 04, 2018 at 10:29:59AM -0800, Bakul Shah wrote:
> > 16MB of memory) and installed 386bsd. I also played with
> > linux-0.11 but I recall reading something about Linus using
> > SysV as a reference and that was the end of my interest in
> > linux!
>
> As far as I know that was never true.  We used used POSIX as a
> reference mainly because it was more easily available as a
> specification.  So that meant that we implemented termios support, and
> not termio, or the BSD variant.  The networking layer was all BSD
> sockets; we certainly never implemented STREAMS, for goodness sake!  :-)
>

There was a natural bias towards SysV interfaces, which highlighted the
differences with BSD interfaces in some areas and may have left that
impression...

Linus certainly had access to SysV or SysV derived systems, but there
wasn't even a whisper at the time he copied code from there. And the few
maybe less than completely legit versions of SysV that are now available
bear this out: they look nothing at all like the 0.11-linux tree.

Thank goodness for the sockets thing... Even though it's a horrible
interface, it was less horrible than STREAMS...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180104/c29cb5ef/attachment.html>

[TUHS] OT: critical Intel design flaw

[Andy Kosela]

On Thursday, January 4, 2018, Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Thu, Jan 4, 2018 at 1:56 PM, Theodore Ts'o <tytso at mit.edu> wrote:
>
>> On Thu, Jan 04, 2018 at 10:29:59AM -0800, Bakul Shah wrote:
>> > 16MB of memory) and installed 386bsd. I also played with
>> > linux-0.11 but I recall reading something about Linus using
>> > SysV as a reference and that was the end of my interest in
>> > linux!
>>
>> As far as I know that was never true.  We used used POSIX as a
>> reference mainly because it was more easily available as a
>> specification.  So that meant that we implemented termios support, and
>> not termio, or the BSD variant.  The networking layer was all BSD
>> sockets; we certainly never implemented STREAMS, for goodness sake!  :-)
>>
>
> There was a natural bias towards SysV interfaces, which highlighted the
> differences with BSD interfaces in some areas and may have left that
> impression...
>
> Linus certainly had access to SysV or SysV derived systems <snip>
>
>

First and foremost Linus was a MINIX user which was based on UNIX V7.  That
could explain his preference for SysV.  People tend to forget that it was
MINIX that sparked Linus' interest in the operating systems.  The first
public announcement of Linux was posted on the MINIX newsgroup.

Linux was basically a continuation of MINIX -- small, simple project, but
heavily optimized for i386 and with a vision to become a production ready
system instead of educational one.  Its simplicity and freshness definitely
attracted many people who wanted to have a small, simple Unix-like system
on their PC.  Sometimes it is just better to start something from scratch
instead of relying on legacy and bloated solutions from the past.

BSD was already bloated and big. It was technically superior at that time,
but at the cost of complexity.  And it took a lot of effort to polish
386BSD to the point it was stable -- it definitely wasnt in the beginning.

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180104/0de8a162/attachment.html>

[TUHS] OT: critical Intel design flaw

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1989 bytes --]

On Thu, Jan 4, 2018 at 5:55 PM, Andy Kosela <akosela at andykosela.com> wrote:

> First and foremost Linus was a MINIX user which was based on UNIX V7.
> That could explain his preference for SysV.
>

​Andy - please explain that connection, as it seem a tad tenuous to me.
Sorry for my thickness, but I don't see how being based on V7 reflected on
being System V based or not.  System V was released many years after
Seventh edition (1984 vs 1979).  BSD had been out for years by the time
Linus started his work and most everything from Seventh Edition (ney
UNIX/TS) has been taken into PWB 3.0 @ Summit which was renamed System III
in 1981/82ish by the North Carolina weenies at AT&T.

I'm trying to think of a program I wrote for Seventh Edition that other
than compiler and architectural differences, would not run with a "make
clean; make" incantation (I can think of a few but not many).   I guess the
primary differences was init(8) had changed at that point, /etc/rc had been
restructured, and the terminal handlers (termio vs {g,s}tty); but from an
kernel interface standard point except for the terminal handler, System III
was pretty much based on Seventh Edition and System V was a superset of
that.

If I remember a number of the emails/notes from the time, Linus was using
SunOS on Sun3 at school.   So he seen all of the BSD extensions to Seventh
Edition, and in particular networking and the sockets API.   As Ted noted,
POSIX had more of an influence since it was at least formally described,
while BSD was only defined by 'trusting the source.'  POSIX had not yet
been able to broach the Networking API at this point, but things like
termios had begun to appear.   In fact, Bostic was in the process of
redoing BSD's terminal handler to add that API IIRC [I can ask him of the
actually date].

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

[TUHS] OT: critical Intel design flaw

[Bakul Shah]

On Jan 4, 2018, at 12:56 PM, Theodore Ts'o <tytso at mit.edu> wrote:
> 
> On Thu, Jan 04, 2018 at 10:29:59AM -0800, Bakul Shah wrote:
>> 16MB of memory) and installed 386bsd. I also played with
>> linux-0.11 but I recall reading something about Linus using
>> SysV as a reference and that was the end of my interest in
>> linux!
> 
> As far as I know that was never true.  We used used POSIX as a
> reference mainly because it was more easily available as a
> specification.  So that meant that we implemented termios support, and
> not termio, or the BSD variant.  The networking layer was all BSD
> sockets; we certainly never implemented STREAMS, for goodness sake!  :-)

I remember sysV coming up in connection with Linux....
Ok, found it:

https://groups.google.com/forum/#!searchin/comp.os.minix/linus$201991%7Csort:date/comp.os.minix/3dSbdErXdUc/uoBUzk9NEEsJ

1. WHAT IS LINUX 0.11
  LINUX 0.11 is a freely distributable UNIX clone.  It implements a
subset of System V and POSIX functionality.
...
2. LINUX features
  - System call compatible with a subset of System V and POSIX
...
8. FUTURE PLANS
...
     - STREAMS

The only mention of BSD is WRT pmake.

[TUHS] OT: critical Intel design flaw

[Tom Ivar Helbekkmo]

Theodore Ts'o <tytso at mit.edu> writes:

> The biggest problem with Jolitz's work seems to have been more social
> than anything else.  The writeups from that era seem to indicate that
> the Jolitz's wanted to keep a much tighter control over things, and
> this discouraged collaboration and contributions, which led to the
> first of *BSD fragmentation/spin-offs, starting with FreeBSD and
> NetBSD.

Indeed.  I've used NetBSD since it was called 386bsd 0.0, and the way I
remember it, we grabbed that when Jolitz made it available, and had an
Internet community playing with it and improving it.  Patches were
accumulated, and sent back to Jolitz.  Then he released 0.1, with none
of the patches from the 'net.  Some of the more active people ported our
existing patches to that, and we kept on going.  Again, patches were
sent back.  When Jolitz released 0.2, again with no patches from the
Internet community included, it was decided to part ways, and start a
forked project on the 'net.  This became NetBSD.  After a short time, it
was obvious that there were two camps: one wanted to keep the OS
multi-platform, while the other felt it was smarter to ditch that in
favor of maximizing performance and utility on the Intel platform.  The
latter group became the FreeBSD project.

And yes, the stupid lawsuit came at just the right time for the world to
adopt Linux instead of BSD, but that's the way the cookie crumbles.  The
BSD community is doing just fine, thank you, and we still have the
better product, so there!  ;)

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

[TUHS] OT: critical Intel design flaw

[Warner Losh]

On Thu, Jan 4, 2018 at 10:20 AM, Tom Ivar Helbekkmo via TUHS <
tuhs at minnie.tuhs.org> wrote:

> Theodore Ts'o <tytso at mit.edu> writes:
>
> > The biggest problem with Jolitz's work seems to have been more social
> > than anything else.  The writeups from that era seem to indicate that
> > the Jolitz's wanted to keep a much tighter control over things, and
> > this discouraged collaboration and contributions, which led to the
> > first of *BSD fragmentation/spin-offs, starting with FreeBSD and
> > NetBSD.
>
> Indeed.  I've used NetBSD since it was called 386bsd 0.0, and the way I
> remember it, we grabbed that when Jolitz made it available, and had an
> Internet community playing with it and improving it.  Patches were
> accumulated, and sent back to Jolitz.  Then he released 0.1, with none
> of the patches from the 'net.  Some of the more active people ported our
> existing patches to that, and we kept on going.  Again, patches were
> sent back.  When Jolitz released 0.2, again with no patches from the
> Internet community included, it was decided to part ways, and start a
> forked project on the 'net.  This became NetBSD.  After a short time, it
> was obvious that there were two camps: one wanted to keep the OS
> multi-platform, while the other felt it was smarter to ditch that in
> favor of maximizing performance and utility on the Intel platform.  The
> latter group became the FreeBSD project.
>

Both NetBSD and FreeBSD emerged from the 'patchkit' efforts that would take
the good accumulated patches from the net to 386BSD and apply them to try
to cobble together some kind of distribution. It was after Jolitz refused
to play ball with other people at all. It's unfortunate he was the one to
bring 386BSD to market from the net2 distribution in many ways, since it
spawned a Diaspora that's been a mixed blessing: A diversity of platforms
has has lead to more experimentation. It's also lead to a bunch of
duplicated effort when that experimentation lead to a system that made it
hard to share.

Of course, Jolitz wasn't the only strong personality in the early days that
had issues working with others, which also contributed to the Net/Free
split, the later Open/Net split and the even later Free/Dragonfly split...

Then again, Linux is no paragon of people working together either...
There's numerous examples where stupid technical things were done because
of personality disputes (exhibit A: systemd, even Linus can't stop it).


> And yes, the stupid lawsuit came at just the right time for the world to
> adopt Linux instead of BSD, but that's the way the cookie crumbles.  The
> BSD community is doing just fine, thank you, and we still have the
> better product, so there!  ;)
>

I'm with you there, even if we have some denominational differences :)

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180104/c9778a60/attachment.html>

[TUHS] OT: critical Intel design flaw

[Bakul Shah]

On Jan 3, 2018, at 5:43 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> 
> I'm highly amused by the irony. Intel throws bazillions of transistors at
> these hyper-complex CPUs in an attempt to make them as fast as possible - and
> (probably because of the complexity) missed a bug, the fix for which
> involves... slowing things way down!

This bug appears to be the result of taking a shortcut rather
than complexity. I suspect this shortcut was taken consciously,
not realizing it could be misused. And the "Rowhammer" problem
is certainly not due to complexity but (again) playing close to
the edge -- the cell geometry is too small to not fail!

> I wonder how many other bugs are lurking in these hyper-complex designs?
> Didn't anyone at Intel stop to think that complexity is bad, in and of itself?

They did try a newer architecture (itanium) but the market
rejected it. The same reason we still continue to use buffer
overflow inducing languages. Inertia & the cost of change.

>  http://conservancy.umn.edu/bitstream/11299/133439/1/oh405rrs.pdf

This was a fascinating read! Thanks for the reference.

[TUHS] OT: critical Intel design flaw

[Norman Wilson]

Clem Cole:

  IIRC this is part of the argument Dykstra made with the THE paper years
  ago, Parnas in his information hiding paper -- i.e. why microkernels and
  proper layering are a good idea.   Keep is simple and do one thing
  well/protect yourself against other subsystems not being 100%.

=====

Indeed.  Complexity creates needless RISC, er, risk.

Norman Wilson
Toronto ON

[TUHS] OT: critical Intel design flaw

[Andy Kosela]

http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

Including here as it concerns Unix kernel and leaking memory from kernel
space to userland.

This is big -- it appears this is a fundamental Intel bug that exists in
all x86_64 CPUs.

It will be interesting to watch the ramifications and impact of this on the
industry as a whole.

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

[TUHS] OT: critical Intel design flaw

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]

I think it’s much ado about nothing.   In fact, nearly the same bug cropped up in the 386 and we had to hack around it in UNIX then (in the 32 bit pentiums you can use one of the segment registers to provide a second layer of security over paging.   Alas, this doesn’t work on the 64 bit addressing mode).

 

From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Andy Kosela
Sent: Wednesday, January 3, 2018 2:54 AM
To: The Eunuchs Hysterical Society
Subject: [TUHS] OT: critical Intel design flaw

 

http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

 

Including here as it concerns Unix kernel and leaking memory from kernel space to userland.

 

This is big -- it appears this is a fundamental Intel bug that exists in all x86_64 CPUs.

 

It will be interesting to watch the ramifications and impact of this on the industry as a whole.

 

--Andy

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

[TUHS] OT: critical Intel design flaw

[Random832]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 591 bytes --]

On Wed, Jan 3, 2018, at 06:57, Ron Natalie wrote:
> I think it’s much ado about nothing.   In fact, nearly the same bug 
> cropped up in the 386 and we had to hack around it in UNIX then (in the 
> 32 bit pentiums you can use one of the segment registers to provide a 
> second layer of security over paging.   Alas, this doesn’t work on the 
> 64 bit addressing mode).

To my understanding, what's leaking is the addresses (and possibly physical addresses), which are in turn usable in a "rowhammer"-style attack - something that didn't exist (or wasn't known, anyway) in the 386 era.