From steve at quintile.net  Mon Jan  1 01:03:49 2018
From: steve at quintile.net (Steve Simon)
Date: Sun, 31 Dec 2017 15:03:49 +0000
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <456D24C3-022E-4D04-92A4-31496B408E7A@ccc.com>
References: <CAMYpm85uJvDK6rdKUu9G5hDFThtuTv0tJRmUbw-MjJe0774e_w@mail.gmail.com>
 <456D24C3-022E-4D04-92A4-31496B408E7A@ccc.com>
Message-ID: <40A54DC5-2288-4F0D-A222-BD7EA9E7673E@quintile.net>

The Plan9 c Alpha compiler also uses 64bit pointers and 32bit ints. For several
years Bell labs kept the port alive, checking builds on real Alpha hardware long
after it was no-longer competitive on the basis that “It keeps us honest”.

-Steve

PS:  Gimple’s Llint is a truly wonderful tool, it has saved me from myself many times.

> On 31 Dec 2017, at 12:56, Clement T. Cole <clemc at ccc.com> wrote:
> 
> 
> 
>> On Dec 31, 2017, at 12:20 AM, Rudi Blom <rudi.j.blom at gmail.com> wrote:
>> 
>> .With the
>> Compaq C compiler and HP-UX ANSI C I mostly get pages of warning and a
>> few errors. By the time I 'corrected' what I think is relevant some
>> nasty coredumps tend to disappear :-)
> 
> I had to chuckle when we read these two lines.   As Paul I’m sure also remembers and mentioned about the 32/64 bit issues, when we released Alpha there we very few to zero tools available to help find errors in ISV or customer created C code that was caused by assumptions of size.   As you point out with the new ‘Gem’ compilers a great deal of work was spent by Paul and his brothers and sisters in the compiler group putting in just those messages.  For C++ it was worse than C because the language was so new at the time few tools for it existed.  So one of our engineers, Judy Ward, lead the effort to make the C++ front end be extremely useful and offered extremely good errors and warnings (she also had worked on the C FE before that).
> 
> When people complained about the compiler before no so “noisy” my response was “Listen to Judy’s advise.  She’s seeing something you are not and she knows more about C and C++ that all of the rest of us.”
> 
> We discovered a curious thing.  The ISVs reported way fewer bugs after the Alpha port because Judy’s messages forced them to clean up long standing issues that were silently causing problem on other systems.    I’ve always said Alpha C and C++ compilers was the greatest gift to the Sparc ISVs there was.
> 
> Like you to this day, except for possibly Gimple’s Flexilint product, the old DEC compilers are still the best tools I have ever used to clean up code.
> 
> I’ve reminded and thanked Judy for this many times when I seen her.  That was a labor of love by some folks that really cared to make a great product as useful as it could be.
> 
> Clem



From paul.winalski at gmail.com  Mon Jan  1 01:55:54 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Sun, 31 Dec 2017 10:55:54 -0500
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <CAEdTPBf40grB_nCqXgyB8-yJbJx3oCY7Yva9-W2PQQVCeH0qTw@mail.gmail.com>
References: <20171229163832.GA17231@mcvoy.com>
 <CAK7dMtAmCKUUasYdL6f761RDvBuB9XHM3DJ6rYn_9FDFEJiYdQ@mail.gmail.com>
 <091301d3810a$9df2d6b0$d9d88410$@ronnatalie.com>
 <CABH=_VRwNXUctFPav5rHX83wfUS0twMQuBhinRZ6QEY1cB3TNQ@mail.gmail.com>
 <CAEdTPBf40grB_nCqXgyB8-yJbJx3oCY7Yva9-W2PQQVCeH0qTw@mail.gmail.com>
Message-ID: <CABH=_VS14L2=MeVNZO-gLX5z_2-63xWnSoN6phVWjpe5xNew4A@mail.gmail.com>

On 12/30/17, Henry Bent <henry.r.bent at gmail.com> wrote:
> On 29 December 2017 at 21:30, Paul Winalski <paul.winalski at gmail.com>
> wrote:
>
> I'm curious about this.  As far as I know the development of the released
> OS for the Alpha went this way:
> (OSF/1 reference) -> (OSF/1 for MIPS) -> OSF/1 V[1.2, 2, 3.0] -> Digital
> UNIX [3.2, 4] -> Tru64[5].  Was there ever a branch of this for the VAX?

No, you are correct; I was misremembering.  I wasn't paying much
attention to UNIX at the time.

-Paul W.


From dave at horsfall.org  Mon Jan  1 08:51:57 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 1 Jan 2018 09:51:57 +1100 (EST)
Subject: [TUHS] OT: Grace Hopper, Unix epoch, ARPAnet converted to TCP/IP
Message-ID: <alpine.BSF.2.21.1801010927100.99776@aneurin.horsfall.org>

Some interesting historical stuff today...

We lost Rear Admiral Dr. Grace Hopper USN (Retd) in 1992; there's not much 
more than can be said about her, but I will mention that she received 
(posthumously) the Presidential Medal of Honor in 2016.

As every Unix geek knows, today is the anniversary of The Epoch[tm] back 
in 1970, and at least one nosey web site thinks that that is my birthdate 
too...

And according to my notes, the ARPAnet got converted from NCP to TCP/IP in 
1983; do any greybeards here have a more precise date?

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From jnc at mercury.lcs.mit.edu  Mon Jan  1 09:10:22 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun, 31 Dec 2017 18:10:22 -0500 (EST)
Subject: [TUHS] OT: Grace Hopper, Unix epoch, ARPAnet converted to TCP/IP
Message-ID: <20171231231022.CDC7218C09C@mercury.lcs.mit.edu>

    > From: Dave Horsfall <dave at horsfall.org>

    > the ARPAnet got converted from NCP to TCP/IP in 1983; ... have a more
    > precise date?

No, it was Jan 1.

It wasn't so much a 'conversion', as that was the date on which, except for a
few sites which got special _temporary_ dispensation to finish their
preparations, support for NCP was turned off for most ARPANET hosts. Prior to
that date, most hosts on the ARPANET had been running both, and after that,
only TCP worked. (Non-ARPANET hosts on the then-nascent Internet had always
only been using TCP before that date, of course.)

	Noel


From dave at horsfall.org  Mon Jan  1 09:22:02 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 1 Jan 2018 10:22:02 +1100 (EST)
Subject: [TUHS] OT: Grace Hopper, Unix epoch, ARPAnet converted to TCP/IP
In-Reply-To: <20171231231022.CDC7218C09C@mercury.lcs.mit.edu>
References: <20171231231022.CDC7218C09C@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.21.1801011014400.99776@aneurin.horsfall.org>

On Sun, 31 Dec 2017, Noel Chiappa wrote:

> > the ARPAnet got converted from NCP to TCP/IP in 1983; ... have a more 
> > precise date?
>
> No, it was Jan 1.

aneurin% date
Mon Jan  1 10:14:58 EST 2018

What timezone did you say you were in again?  This is the problem when 
expressing historical events...

> It wasn't so much a 'conversion', as that was the date on which, except 
> for a few sites which got special _temporary_ dispensation to finish 
> their preparations, support for NCP was turned off for most ARPANET 
> hosts. Prior to that date, most hosts on the ARPANET had been running 
> both, and after that, only TCP worked. (Non-ARPANET hosts on the 
> then-nascent Internet had always only been using TCP before that date, 
> of course.)

Thanks; I'll amend my notes accordingly.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From khm at sciops.net  Mon Jan  1 09:47:28 2018
From: khm at sciops.net (Kurt H Maier)
Date: Sun, 31 Dec 2017 15:47:28 -0800
Subject: [TUHS] OT: Grace Hopper, Unix epoch, ARPAnet converted to TCP/IP
In-Reply-To: <alpine.BSF.2.21.1801011014400.99776@aneurin.horsfall.org>
References: <20171231231022.CDC7218C09C@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1801011014400.99776@aneurin.horsfall.org>
Message-ID: <20171231234728.GA6542@wopr>


On Mon, Jan 01, 2018 at 10:22:02AM +1100, Dave Horsfall wrote:
> On Sun, 31 Dec 2017, Noel Chiappa wrote:
> 
> > > the ARPAnet got converted from NCP to TCP/IP in 1983; ... have a more 
> > > precise date?
> >
> > No, it was Jan 1.
> 
> aneurin% date
> Mon Jan  1 10:14:58 EST 2018
> 
> What timezone did you say you were in again?  This is the problem when 
> expressing historical events...

I am confident ARPANET did not pin time to AEDT.  Even if you go by   
UTC you've still got about fifteen minutes to wait for 1 JAN 2018.

khm


From dave at horsfall.org  Mon Jan  1 10:15:19 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 1 Jan 2018 11:15:19 +1100 (EST)
Subject: [TUHS] OT: Grace Hopper, Unix epoch, ARPAnet converted to TCP/IP
In-Reply-To: <20171231234728.GA6542@wopr>
References: <20171231231022.CDC7218C09C@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1801011014400.99776@aneurin.horsfall.org>
 <20171231234728.GA6542@wopr>
Message-ID: <alpine.BSF.2.21.1801011056290.99776@aneurin.horsfall.org>

On Sun, 31 Dec 2017, Kurt H Maier wrote:

> I am confident ARPANET did not pin time to AEDT.  Even if you go by UTC 
> you've still got about fifteen minutes to wait for 1 JAN 2018.

So am I, but what reference *am* I supposed to use, FFS?  The USA is 
several zones behind UTC[*], and almost a whole day behind Australia 
(where I live).

My "on this day" policy is to use the local time if it can be narrowed to 
a particular zone where the event happened (and if it makes sense); if it 
was universal e.g. moon landings then I'll use UTC; otherwise I'll use the 
commonly-observed date e.g. the start/end of the world wars.

I'm open to suggestions (including FOAD, in which case I'll simply find 
something better to do).

[*]
A lingering gripe that explains my latent anti-Americanism goes back to 
when I had to support Uniplus 2.2/2.4 (sorta SysIII-ish) on the WICAT 
boxes in here in Australia.  At installation time, we had to express the 
time offset as hours *west* of GMT; this left me with a lingering belief 
that Americans didn't want to be perceived as being backwards (yeah. it 
saved an entire keystroke out of the dozens that were otherwise required).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From khm at sciops.net  Mon Jan  1 10:59:07 2018
From: khm at sciops.net (Kurt H Maier)
Date: Sun, 31 Dec 2017 16:59:07 -0800
Subject: [TUHS] OT: Grace Hopper, Unix epoch, ARPAnet converted to TCP/IP
In-Reply-To: <alpine.BSF.2.21.1801011056290.99776@aneurin.horsfall.org>
References: <20171231231022.CDC7218C09C@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1801011014400.99776@aneurin.horsfall.org>
 <20171231234728.GA6542@wopr>
 <alpine.BSF.2.21.1801011056290.99776@aneurin.horsfall.org>
Message-ID: <20180101005907.GB6542@wopr>

On Mon, Jan 01, 2018 at 11:15:19AM +1100, Dave Horsfall wrote:
> 
> My "on this day" policy is to use the local time if it can be narrowed to 
> a particular zone where the event happened (and if it makes sense); if it 
> was universal e.g. moon landings then I'll use UTC; otherwise I'll use the 
> commonly-observed date e.g. the start/end of the world wars.

I support your policy, but I'd say the ARPA in ARPANET makes it at least
feasible to stick with Zulu time for related milestones.

> I'm open to suggestions (including FOAD, in which case I'll simply find 
> something better to do).

Personally, I've enjoyed your posts marking anniversaries of these
events.  

> A lingering gripe that explains my latent anti-Americanism goes back to 

The older I get, the more convinced I am that the "two hard things in
Computer Science" quote came from someone who never had to accurately
report the ages of events predating epoch time.

And I can say as a patriotic American, I did not truly understand the
desperate plight of being a foreigner until I was in Cape Town during
the Super Bowl.  After that I limited international travel to extremely
profitable endeavors; otherwise the ROI just isn't there.

khm 


From ron at ronnatalie.com  Mon Jan  1 21:59:50 2018
From: ron at ronnatalie.com (Ron Natalie)
Date: Mon, 1 Jan 2018 06:59:50 -0500
Subject: [TUHS] , ARPAnet converted to TCP/IP
Message-ID: <09f101d382f8$077d0350$167709f0$@ronnatalie.com>

It was sort of a soft change over.    All the did on January 1, 1983, is
disable link 0 on the IMPs.    This essentially blocked NCP from working
anymore.
You could (and many of us were) run IP on the Arpanet for years before that.
In fact the weeks before we were getting ready for the change and we had our
TCP/IP version of the system up.

It crashed.

We rebooted it and set about debugging it.

It crashed again.   Immediately my phone rang.    It was Louis Mamakos, then
of the University of Maryland.     He had tried to ping our system.   I
called out the information to Mike Muuss who was across the desk from me.
We set to find the bug.   It turned out that the ICMP echo handling in the
4.1c (I believe this was the version) that we'd cribbed our PDP-11/70 TCP
from had a bug where it used the incoming message to make the outgoing one,
AND it freed it, eventually causing a double free and crash.    It was at
this point we realized that BSD didn't have a ping client program.    Mike
set out to write one.   It oddly became the one piece of software he was
most known for over the years.

 The previous changeover was to long leaders on the Arpanet (Jan 1, 1981?).
This changed the IMP addressing space from eight bits (6 bits for imp
number, 2 for a host on imp) to 16 bits for imp number and 8 for a host on
imp.    While long leaders were available on a port basis for years earlier,
they didn't force the change until this date.    The one casualty we had a
PDP-11/40 playing terminal server running software out of the University of
Illinois called "ANTS."   Amusingly the normal DEC purple and red logo
panels at the top of the rack were silkscreened with orange ANTS logos (with
little ants crawling on it).    The ANTS wasn't maintained anymore and stuck
in short-leader mode.    We used that option to replace that machine with a
UNIX (we grabbed one of our ubiquitous PDP-11/34's that were kicking
around).     I kept the racks and the ANTS logo for the BRL Gateways.    I
turned in the non-MM PDP-11/40.     A year later I get a call from the
military supply people.

ME:  Yes?
GUY:   I need you to identify $65,000 of computer equipment you turned in.
ME:  What $65,000 machine?
GUY:   One PDP-11/40 and accessories.
ME:   That computer is 12 years old... and I kept all the racks and
peripherals.   Do you know how much a 12-year-old computer is worth?

The other major cut over was in October of 1984.   This was the
Arpanet-Milnet split.    I had begged the powers that be NOT to do the
change over on the Jan 1st as it always meant I had to be working the days
leading up to it.   (Oct 1 was the beginning of the "fiscal" year).    Our
site had problems.    I made a quick call to Mike Brescia of BBN.   This was
pre-EGP, and things were primarily static routed in those days.   He'd
forgotten that we had routers at BRL now on the MILNET (all the others were
on the ARPANET) and the ARPANET-MILNET "mail bridge" routers had been
configured for gateways on the MILNET side.




From jnc at mercury.lcs.mit.edu  Mon Jan  1 22:59:43 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon,  1 Jan 2018 07:59:43 -0500 (EST)
Subject: [TUHS] OT: Grace Hopper, Unix epoch, ARPAnet converted to TCP/IP
Message-ID: <20180101125943.429CE18C0A0@mercury.lcs.mit.edu>

    > From: Dave Horsfall

    > What timezone did you say you were in again?

Ah; didn't realize you wanted the exact time, not just a date! :-)

Well, according to this:

  http://www.rfc-editor.org/rfc/museum/ddn-news/ddn-news.n19.1

it was _planned_ to happen at "00:01 (EST) 1 Jan 1983". Whether it did happen
at that moment, or if in reality there was some variance, I don't know (IIRC,
I was off sailing in the Caribbean when it actually happened :-).

	Noel


From ron at ronnatalie.com  Tue Jan  2 10:57:20 2018
From: ron at ronnatalie.com (Ron Natalie)
Date: Mon, 1 Jan 2018 19:57:20 -0500
Subject: [TUHS] OT: Grace Hopper, Unix epoch, ARPAnet converted to TCP/IP
In-Reply-To: <20180101125943.429CE18C0A0@mercury.lcs.mit.edu>
References: <20180101125943.429CE18C0A0@mercury.lcs.mit.edu>
Message-ID: <0a4701d38364$a4f7fc40$eee7f4c0$@ronnatalie.com>

Heidi Heiden...now there's a name I've not heard in many a year, Noel.

I don't know if it got shut off right at midnight on Jan 1, but it certainly
was pretty close to that time.    Oddly enough as time went on we started to
get link 0 messages again.     We didn't have anything set up to process
them, but we did print a message when it happened.




From clemc at ccc.com  Wed Jan  3 02:19:03 2018
From: clemc at ccc.com (Clem Cole)
Date: Tue, 2 Jan 2018 11:19:03 -0500
Subject: [TUHS] OT: Grace Hopper, Unix epoch, ARPAnet converted to TCP/IP
In-Reply-To: <20180101125943.429CE18C0A0@mercury.lcs.mit.edu>
References: <20180101125943.429CE18C0A0@mercury.lcs.mit.edu>
Message-ID: <CAC20D2OB_kZcG006++T-We6w6ikP6iVFgrMziQV_zQhKvYyQHQ@mail.gmail.com>

On Mon, Jan 1, 2018 at 7:59 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

> it was _planned_ to happen at "00:01 (EST) 1 Jan 1983". Whether it did
> happen
> at that moment, or if in reality there was some variance, I don't know


​I don't remember it as being a huge event.   As Noel said most people had
cut over to TCP by then​.

People were much more spooked by Y2K a few years later.

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

From clemc at ccc.com  Wed Jan  3 02:43:59 2018
From: clemc at ccc.com (Clem Cole)
Date: Tue, 2 Jan 2018 11:43:59 -0500
Subject: [TUHS] OT: American Culture
Message-ID: <CAC20D2NnVMrQ5T-qabE+DTRLZ+9aucAW9aL6TM_sv8Fkr1BLzg@mail.gmail.com>

On Sun, Dec 31, 2017 at 7:15 PM, Dave Horsfall <dave at horsfall.org> wrote:
>
> A lingering gripe that explains my latent anti-Americanism goes back to
> when I had to support Uniplus 2.2/2.4 (sorta SysIII-ish) on the WICAT boxes
> in here in Australia.  At installation time, we had to express the time
> offset as hours *west* of GMT; this left me with a lingering belief that
> Americans didn't want to be perceived as being backwards (yeah. it saved an
> entire keystroke out of the dozens that were otherwise required).


​Dave I'm not so sure it's about being perceived as forward or backwards -
its just shallow, provincial and often lazy because the program did not
really knowing any better.  The problem is too many American',
(particularly younger ones that experience our 'excellent' educational
system), have often never travelled that much and experiences other places,
cultures or social norms.

I admit this is extreme example, but about 8 years ago, my daughter had a
friend, who was approx 16 at the time, that we took to the big city
(Boston) to play in a orchestra concert at Symphony Hall when they both
were named 'All State' for the instruments.   I don't remember why said
friends family did not/could not come - but it made sense and we said we
would take her with us.  On the drive in-town, we were talking with her and
I discovered that she had never gone to Boston before ... ever -- she was
excited to see it (we live less than 1hr North mind you.  Note quite the
boon-docks).  She had not gone to a 'Bo Sox' game or anything.   Never went
to the Science Museum, etc.   She grew up in her town (mind you happy) and
using TV as her window to world.

Which brings me to >>my complaint<<.   We, as American's, project so much
about 'us' via TV.  The said truth is most Americans are not like what they
see on TV [e.g. Rice-A-Roni is made up!!, Benihana's is an American
invention, and "the big yellow school bus" is dirty/noisy and usually
without seat belts].   Sadly, many Americans do not know any better - queue
the famous quote about never under-estimating the taste of the American
public.  But think about what folks outside the US see and think?   Many of
my European friends in particular all want to visit NYC.  [I tell them all,
visit Boston or Philadelphia first if you can.   Those cities are much more
representative of America then LA, NYC or Dallas; if for no other reason
they are more 'European' in feel].

When I run into things like what you just described (and I seem to run into
then most often with MicroSoft based tools), I think to myself, it must
have been a cold day in Redmond, WA and some programmer did not want to
make an effort to do make her/his solution really general ;-)

Clem



FWIW: Not only did we take my kids all over the world as children, we
brought the world to them by sponsoring kids from all sorts of countries.
But I fear, my wife and I are less the norm then I would wish.
ᐧ
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180102/693e0ee0/attachment.html>

From doug at cs.dartmouth.edu  Wed Jan  3 12:42:53 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Tue, 02 Jan 2018 21:42:53 -0500
Subject: [TUHS] OT: American Culture
Message-ID: <201801030242.w032grt0022600@coolidge.cs.Dartmouth.EDU>

> A lingering gripe that explains my latent anti-Americanism goes back to
> when I had to support Uniplus 2.2/2.4 (sorta SysIII-ish) on the WICAT boxes
> in here in Australia.  At installation time, we had to express the time
> offset as hours *west* of GMT; this left me with a lingering belief that
> Americans didn't want to be perceived as being backwards (yeah. it saved an
> entire keystroke out of the dozens that were otherwise required).

But east postive is an artifact of north up.  I remember Australian
souvenir shops selling maps on "MacQuarrie's corrective projection",
in which south is up.  In fact this orientation was not uncommon in
Europe between medieval maps that really were oriented, with east up,
and later convention that put north up and shoved Australia down under.

Surely an Aussie would prefer south up and west positive!

Doug


From akosela at andykosela.com  Wed Jan  3 17:53:56 2018
From: akosela at andykosela.com (Andy Kosela)
Date: Wed, 3 Jan 2018 01:53:56 -0600
Subject: [TUHS] OT: critical Intel design flaw
Message-ID: <CALMnNGh7FJ7LYgna1LKJUSW9+bE5O7cSEK8PViqqogwe08V8ow@mail.gmail.com>

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>

From ron at ronnatalie.com  Wed Jan  3 21:57:20 2018
From: ron at ronnatalie.com (Ron Natalie)
Date: Wed, 3 Jan 2018 06:57:20 -0500
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <CALMnNGh7FJ7LYgna1LKJUSW9+bE5O7cSEK8PViqqogwe08V8ow@mail.gmail.com>
References: <CALMnNGh7FJ7LYgna1LKJUSW9+bE5O7cSEK8PViqqogwe08V8ow@mail.gmail.com>
Message-ID: <0b2201d3848a$02ba8d90$082fa8b0$@ronnatalie.com>

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

From arnold at skeeve.com  Wed Jan  3 23:25:05 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 03 Jan 2018 06:25:05 -0700
Subject: [TUHS] OT: American Culture
In-Reply-To: <CAC20D2NnVMrQ5T-qabE+DTRLZ+9aucAW9aL6TM_sv8Fkr1BLzg@mail.gmail.com>
References: <CAC20D2NnVMrQ5T-qabE+DTRLZ+9aucAW9aL6TM_sv8Fkr1BLzg@mail.gmail.com>
Message-ID: <201801031325.w03DP567014114@freefriends.org>

Yes, this really is OT ...

> The problem is too many American',
> (particularly younger ones that experience our 'excellent' educational
> system), have often never travelled that much and experiences other places,
> cultures or social norms.

This is very true. I discovered this when, at the age of 18, I came to spend
a year studying in Israel. At that point I realized that Americans are
terribly parochial.  ("Whaddaya mean you don't speak English?!?  Whaddaya
mean I can't get a hmaburger here?" etc.)

> Which brings me to >>my complaint<<.   We, as American's, project so much
> about 'us' via TV.  The said truth is most Americans are not like what they
> see on TV

It's worse than just TV (and movies). It's huge parts of the culture. We
moved to Israel 20 years ago, and on the highways are signs for: Ace
Hardware, Toys 'R' Us, Office Depot, McDonald's ...  UPS and FedEx trucks
are common sights.  As well as the culture, many of the values (that
I personally moved to Israel to get away from) have seeped in as well.
"Cultural Pollution" wouldn't be too strong a term.

> When I run into things like what you just described (and I seem to run into
> then most often with MicroSoft based tools), I think to myself, it must
> have been a cold day in Redmond, WA and some programmer did not want to
> make an effort to do make her/his solution really general ;-)

I suspect that said programmer didn't even know enough to think about
making it general.

FWIW,

Arnold


From jnc at mercury.lcs.mit.edu  Wed Jan  3 23:43:58 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed,  3 Jan 2018 08:43:58 -0500 (EST)
Subject: [TUHS] OT: critical Intel design flaw
Message-ID: <20180103134358.3F16818C098@mercury.lcs.mit.edu>

    > 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


From random832 at fastmail.com  Thu Jan  4 00:19:01 2018
From: random832 at fastmail.com (Random832)
Date: Wed, 03 Jan 2018 09:19:01 -0500
Subject: [TUHS] OT: American Culture
In-Reply-To: <201801030242.w032grt0022600@coolidge.cs.Dartmouth.EDU>
References: <201801030242.w032grt0022600@coolidge.cs.Dartmouth.EDU>
Message-ID: <1514989141.883521.1222880744.6EE78710@webmail.messagingengine.com>

On Tue, Jan 2, 2018, at 21:42, Doug McIlroy wrote:
> > A lingering gripe that explains my latent anti-Americanism goes back to
> > when I had to support Uniplus 2.2/2.4 (sorta SysIII-ish) on the WICAT boxes
> > in here in Australia.  At installation time, we had to express the time
> > offset as hours *west* of GMT; this left me with a lingering belief that
> > Americans didn't want to be perceived as being backwards (yeah. it saved an
> > entire keystroke out of the dozens that were otherwise required).
> 
> But east postive is an artifact of north up.

Who says right is positive? Anyway, there's a natural reason to want east to be positive in this case completely independent of maps - so that your timezone offset is the number that you add to UTC to get the current local time, rather than subtracting.

Incidentally, the V6 code for ctime has the number of *seconds* west of UTC as an *int* - a situation rather worse for parts of Australia than simply requiring a negative number.

I'm not exactly sure what AUSAM does. The archive shows ctime.s (its own implementation) with "timezone" as zero, with a note saying to set it to 1*60.*60. for daylight saving. This suggests that the time was simply maintained with an epoch of 1970-01-01 00:00 AEST, but the time(II) manpage says GMT.


From random832 at fastmail.com  Thu Jan  4 00:22:23 2018
From: random832 at fastmail.com (Random832)
Date: Wed, 03 Jan 2018 09:22:23 -0500
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <0b2201d3848a$02ba8d90$082fa8b0$@ronnatalie.com>
References: <CALMnNGh7FJ7LYgna1LKJUSW9+bE5O7cSEK8PViqqogwe08V8ow@mail.gmail.com>
 <0b2201d3848a$02ba8d90$082fa8b0$@ronnatalie.com>
Message-ID: <1514989343.884423.1222903600.4579DCEA@webmail.messagingengine.com>

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.


From clemc at ccc.com  Thu Jan  4 00:26:40 2018
From: clemc at ccc.com (Clem Cole)
Date: Wed, 3 Jan 2018 09:26:40 -0500
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
Message-ID: <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>

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>

From norman at oclsc.org  Thu Jan  4 03:06:15 2018
From: norman at oclsc.org (Norman Wilson)
Date: Wed, 03 Jan 2018 12:06:15 -0500
Subject: [TUHS] OT: critical Intel design flaw
Message-ID: <1514999178.27517.for-standards-violators@oclsc.org>

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


From bakul at bitblocks.com  Thu Jan  4 03:07:41 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 3 Jan 2018 09:07:41 -0800
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
Message-ID: <51CA1A1A-F9AE-4A20-A431-4BF904DAA04D@bitblocks.com>

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.

From bakul at bitblocks.com  Thu Jan  4 03:28:40 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 3 Jan 2018 09:28:40 -0800
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
Message-ID: <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>

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.



From rminnich at gmail.com  Thu Jan  4 03:46:03 2018
From: rminnich at gmail.com (ron minnich)
Date: Wed, 03 Jan 2018 17:46:03 +0000
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
Message-ID: <CAP6exYJUvNuXi1o=wOX+cdkgLx-oDmttJTunzy5zsaMhLxd42g@mail.gmail.com>

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>

From clemc at ccc.com  Thu Jan  4 04:27:19 2018
From: clemc at ccc.com (Clem Cole)
Date: Wed, 3 Jan 2018 13:27:19 -0500
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
Message-ID: <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>

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>

From bakul at bitblocks.com  Thu Jan  4 04:28:25 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 3 Jan 2018 10:28:25 -0800
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <CAP6exYJUvNuXi1o=wOX+cdkgLx-oDmttJTunzy5zsaMhLxd42g@mail.gmail.com>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAP6exYJUvNuXi1o=wOX+cdkgLx-oDmttJTunzy5zsaMhLxd42g@mail.gmail.com>
Message-ID: <483D45E8-9F95-4A8E-8F19-05D1CF1F7FEF@bitblocks.com>

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



From nobozo at gmail.com  Thu Jan  4 04:39:06 2018
From: nobozo at gmail.com (Forrest, Jon)
Date: Wed, 3 Jan 2018 10:39:06 -0800
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
Message-ID: <fa15a41f-a06d-e616-376e-226375a8b4f5@gmail.com>


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


From rminnich at gmail.com  Thu Jan  4 04:50:42 2018
From: rminnich at gmail.com (ron minnich)
Date: Wed, 03 Jan 2018 18:50:42 +0000
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <fa15a41f-a06d-e616-376e-226375a8b4f5@gmail.com>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
 <fa15a41f-a06d-e616-376e-226375a8b4f5@gmail.com>
Message-ID: <CAP6exYJN_ED9CnD4-pfkaDzZq7SP0GxCTPqEQiMP6nBTrBqyFw@mail.gmail.com>

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>

From paul.winalski at gmail.com  Thu Jan  4 05:56:59 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Wed, 3 Jan 2018 14:56:59 -0500
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
Message-ID: <CABH=_VSy6wfxm0hQT-8004mp6Rqgy6vOvXHO1itv69Jqw7eceg@mail.gmail.com>

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.


From bakul at bitblocks.com  Thu Jan  4 06:24:40 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 3 Jan 2018 12:24:40 -0800
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
Message-ID: <C507BCDC-B7D1-4B54-9708-F4F07DC9392E@bitblocks.com>

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



From norman at oclsc.org  Thu Jan  4 08:49:31 2018
From: norman at oclsc.org (Norman Wilson)
Date: Wed, 03 Jan 2018 17:49:31 -0500
Subject: [TUHS] OT: American Culture
Message-ID: <1515019775.7311.for-standards-violators@oclsc.org>

Random832 (a good year for randomness, that):

  Who says right is positive?

=====

Good question.

Norman Wilson
Toronto ON
Left-handed


From tytso at mit.edu  Thu Jan  4 09:40:25 2018
From: tytso at mit.edu (Theodore Ts'o)
Date: Wed, 3 Jan 2018 18:40:25 -0500
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
Message-ID: <20180103234025.GA23371@thunk.org>

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


From lm at mcvoy.com  Thu Jan  4 10:51:03 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 3 Jan 2018 16:51:03 -0800
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <20180103234025.GA23371@thunk.org>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
 <20180103234025.GA23371@thunk.org>
Message-ID: <20180104005103.GF1534@mcvoy.com>

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


From krewat at kilonet.net  Thu Jan  4 12:09:15 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 3 Jan 2018 21:09:15 -0500
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <20180103234025.GA23371@thunk.org>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
 <20180103234025.GA23371@thunk.org>
Message-ID: <a289ef86-3b07-1560-4e5d-e3007d33c21d@kilonet.net>

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


From bakul at bitblocks.com  Thu Jan  4 12:13:59 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 03 Jan 2018 18:13:59 -0800
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: Your message of "Wed, 03 Jan 2018 16:51:03 -0800."
 <20180104005103.GF1534@mcvoy.com>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
 <20180103234025.GA23371@thunk.org> <20180104005103.GF1534@mcvoy.com>
Message-ID: <20180104021414.6EF88156E523@mail.bitblocks.com>

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


From lm at mcvoy.com  Thu Jan  4 12:26:04 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 3 Jan 2018 18:26:04 -0800
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <20180104021414.6EF88156E523@mail.bitblocks.com>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
 <20180103234025.GA23371@thunk.org>
 <20180104005103.GF1534@mcvoy.com>
 <20180104021414.6EF88156E523@mail.bitblocks.com>
Message-ID: <20180104022604.GL1534@mcvoy.com>

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


From grog at lemis.com  Thu Jan  4 12:59:59 2018
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Thu, 4 Jan 2018 13:59:59 +1100
Subject: [TUHS] OT: American Culture
In-Reply-To: <1515019775.7311.for-standards-violators@oclsc.org>
References: <1515019775.7311.for-standards-violators@oclsc.org>
Message-ID: <20180104025959.GA34418@eureka.lemis.com>

On Wednesday,  3 January 2018 at 17:49:31 -0500, Norman Wilson wrote:
> Random832 (a good year for randomness, that):
>
>>   Who says right is positive?
>
> Good question.

Time here is round 14:00 UTC+11.  UTC time is 3:00, so UTC+11 = 14:00
makes sense to me.  UTC-11 = 14:00 doesn't.

A thing that nobody has mentioned, and for which I can't find a
reference easily: didn't System V have time zone offsets the wrong way
round?  I have some recollection from about 1988.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180104/2f619b7e/attachment.sig>

From crossd at gmail.com  Thu Jan  4 13:21:02 2018
From: crossd at gmail.com (Dan Cross)
Date: Wed, 3 Jan 2018 22:21:02 -0500
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <a289ef86-3b07-1560-4e5d-e3007d33c21d@kilonet.net>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
 <20180103234025.GA23371@thunk.org>
 <a289ef86-3b07-1560-4e5d-e3007d33c21d@kilonet.net>
Message-ID: <CAEoi9W6witKBBzv0H+TdB7cvzPbEW1_N0XNknn9c=U=OAPo7LQ@mail.gmail.com>

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>

From bakul at bitblocks.com  Thu Jan  4 13:31:35 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 03 Jan 2018 19:31:35 -0800
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: Your message of "Wed, 03 Jan 2018 18:26:04 -0800."
 <20180104022604.GL1534@mcvoy.com>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
 <20180103234025.GA23371@thunk.org> <20180104005103.GF1534@mcvoy.com>
 <20180104021414.6EF88156E523@mail.bitblocks.com>
 <20180104022604.GL1534@mcvoy.com>
Message-ID: <20180104033151.04D5A156E523@mail.bitblocks.com>

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! 


From harald at skogtun.org  Thu Jan  4 21:53:26 2018
From: harald at skogtun.org (Harald Arnesen)
Date: Thu, 4 Jan 2018 12:53:26 +0100
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <20180103234025.GA23371@thunk.org>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
 <20180103234025.GA23371@thunk.org>
Message-ID: <c861d001-48b2-92a9-eef9-fd1cf402a15c@skogtun.org>

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?


From clemc at ccc.com  Fri Jan  5 00:03:09 2018
From: clemc at ccc.com (Clem Cole)
Date: Thu, 4 Jan 2018 09:03:09 -0500
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <c861d001-48b2-92a9-eef9-fd1cf402a15c@skogtun.org>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
 <20180103234025.GA23371@thunk.org>
 <c861d001-48b2-92a9-eef9-fd1cf402a15c@skogtun.org>
Message-ID: <CAC20D2OZ4ZvbJSfzZxBWLanfzZgg3XBTiMNVzHK_0yV9tEbmvg@mail.gmail.com>

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>

From lm at mcvoy.com  Fri Jan  5 01:54:25 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 4 Jan 2018 07:54:25 -0800
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <CAC20D2OZ4ZvbJSfzZxBWLanfzZgg3XBTiMNVzHK_0yV9tEbmvg@mail.gmail.com>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
 <20180103234025.GA23371@thunk.org>
 <c861d001-48b2-92a9-eef9-fd1cf402a15c@skogtun.org>
 <CAC20D2OZ4ZvbJSfzZxBWLanfzZgg3XBTiMNVzHK_0yV9tEbmvg@mail.gmail.com>
Message-ID: <20180104155425.GC8574@mcvoy.com>

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


From tytso at mit.edu  Fri Jan  5 02:45:57 2018
From: tytso at mit.edu (Theodore Ts'o)
Date: Thu, 4 Jan 2018 11:45:57 -0500
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <CAC20D2OZ4ZvbJSfzZxBWLanfzZgg3XBTiMNVzHK_0yV9tEbmvg@mail.gmail.com>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
 <20180103234025.GA23371@thunk.org>
 <c861d001-48b2-92a9-eef9-fd1cf402a15c@skogtun.org>
 <CAC20D2OZ4ZvbJSfzZxBWLanfzZgg3XBTiMNVzHK_0yV9tEbmvg@mail.gmail.com>
Message-ID: <20180104164557.GI23371@thunk.org>

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


From dot at dotat.at  Fri Jan  5 02:48:48 2018
From: dot at dotat.at (Tony Finch)
Date: Thu, 4 Jan 2018 16:48:48 +0000
Subject: [TUHS] OT: American Culture
In-Reply-To: <20180104025959.GA34418@eureka.lemis.com>
References: <1515019775.7311.for-standards-violators@oclsc.org>
 <20180104025959.GA34418@eureka.lemis.com>
Message-ID: <alpine.DEB.2.11.1801041642570.18998@grey.csi.cam.ac.uk>

Greg 'groggy' Lehey <grog at lemis.com> wrote:
>
> A thing that nobody has mentioned, and for which I can't find a
> reference easily: didn't System V have time zone offsets the wrong way
> round?  I have some recollection from about 1988.

It's enshrined in POSIX but I believe it goes back earlier than that.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/tzset.html

As I understand it, POSIX TZ offsets are the wrong way round because it
was more convenient to omit the sign on the TZ offsets, and because Unix
comes from America that meant no sign -> west, negative -> east.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Rockall, Malin: Cyclonic, becoming mainly northeast later , 5 to 7, increasing
gale 8 or severe gale 9 later in Rockall. Very rough or high. Rain or showers.
Moderate or poor, occasionally good.


From akosela at andykosela.com  Fri Jan  5 03:10:14 2018
From: akosela at andykosela.com (Andy Kosela)
Date: Thu, 4 Jan 2018 11:10:14 -0600
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <20180104164557.GI23371@thunk.org>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
 <20180103234025.GA23371@thunk.org>
 <c861d001-48b2-92a9-eef9-fd1cf402a15c@skogtun.org>
 <CAC20D2OZ4ZvbJSfzZxBWLanfzZgg3XBTiMNVzHK_0yV9tEbmvg@mail.gmail.com>
 <20180104164557.GI23371@thunk.org>
Message-ID: <CALMnNGj_K4aE2ebNPbr4OVXJP=wgT6UN9eCtOZRcg3RevA8a4w@mail.gmail.com>

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>

From lm at mcvoy.com  Fri Jan  5 03:17:40 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 4 Jan 2018 09:17:40 -0800
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <20180104164557.GI23371@thunk.org>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
 <20180103234025.GA23371@thunk.org>
 <c861d001-48b2-92a9-eef9-fd1cf402a15c@skogtun.org>
 <CAC20D2OZ4ZvbJSfzZxBWLanfzZgg3XBTiMNVzHK_0yV9tEbmvg@mail.gmail.com>
 <20180104164557.GI23371@thunk.org>
Message-ID: <20180104171740.GF19585@mcvoy.com>

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


From tih at hamartun.priv.no  Fri Jan  5 03:20:11 2018
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Thu, 04 Jan 2018 18:20:11 +0100
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <20180104164557.GI23371@thunk.org> (Theodore Ts'o's message of
 "Thu, 4 Jan 2018 11:45:57 -0500")
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
 <20180103234025.GA23371@thunk.org>
 <c861d001-48b2-92a9-eef9-fd1cf402a15c@skogtun.org>
 <CAC20D2OZ4ZvbJSfzZxBWLanfzZgg3XBTiMNVzHK_0yV9tEbmvg@mail.gmail.com>
 <20180104164557.GI23371@thunk.org>
Message-ID: <m2373lfsms.fsf@thuvia.hamartun.priv.no>

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


From imp at bsdimp.com  Fri Jan  5 03:20:26 2018
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 4 Jan 2018 10:20:26 -0700
Subject: [TUHS] OT: American Culture
In-Reply-To: <alpine.DEB.2.11.1801041642570.18998@grey.csi.cam.ac.uk>
References: <1515019775.7311.for-standards-violators@oclsc.org>
 <20180104025959.GA34418@eureka.lemis.com>
 <alpine.DEB.2.11.1801041642570.18998@grey.csi.cam.ac.uk>
Message-ID: <CANCZdfpdU+6WET5fNzGY=9vxCOaS9TwrvNe0W0pS5u_3S36mgg@mail.gmail.com>

On Thu, Jan 4, 2018 at 9:48 AM, Tony Finch <dot at dotat.at> wrote:

> Greg 'groggy' Lehey <grog at lemis.com> wrote:
> >
> > A thing that nobody has mentioned, and for which I can't find a
> > reference easily: didn't System V have time zone offsets the wrong way
> > round?  I have some recollection from about 1988.
>
> It's enshrined in POSIX but I believe it goes back earlier than that.
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/tzset.html
>
> As I understand it, POSIX TZ offsets are the wrong way round because it
> was more convenient to omit the sign on the TZ offsets, and because Unix
> comes from America that meant no sign -> west, negative -> east.
>

There's also a time interval measurement convention from the high precision
time keeping world that has negative offsets 'forwards' and positive
offsets 'backwards' which this matches. It sure was confusing to me when I
first encountered it when the time scientists were telling me the
measurements were backwards...

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

From imp at bsdimp.com  Fri Jan  5 03:28:45 2018
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 4 Jan 2018 10:28:45 -0700
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <m2373lfsms.fsf@thuvia.hamartun.priv.no>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
 <20180103234025.GA23371@thunk.org>
 <c861d001-48b2-92a9-eef9-fd1cf402a15c@skogtun.org>
 <CAC20D2OZ4ZvbJSfzZxBWLanfzZgg3XBTiMNVzHK_0yV9tEbmvg@mail.gmail.com>
 <20180104164557.GI23371@thunk.org> <m2373lfsms.fsf@thuvia.hamartun.priv.no>
Message-ID: <CANCZdfrG-0cmU9A6PDm72uwqcP1wS47e0rVJPotT-LiFVk6Dmg@mail.gmail.com>

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>

From krewat at kilonet.net  Fri Jan  5 03:42:32 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Thu, 4 Jan 2018 12:42:32 -0500
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <CAEoi9W6witKBBzv0H+TdB7cvzPbEW1_N0XNknn9c=U=OAPo7LQ@mail.gmail.com>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
 <20180103234025.GA23371@thunk.org>
 <a289ef86-3b07-1560-4e5d-e3007d33c21d@kilonet.net>
 <CAEoi9W6witKBBzv0H+TdB7cvzPbEW1_N0XNknn9c=U=OAPo7LQ@mail.gmail.com>
Message-ID: <6886c3b5-5778-9691-a3b6-3a5523952c05@kilonet.net>

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>

From bakul at bitblocks.com  Fri Jan  5 04:29:59 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Thu, 04 Jan 2018 10:29:59 -0800
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: Your message of "Thu, 04 Jan 2018 09:17:40 -0800."
 <20180104171740.GF19585@mcvoy.com>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
 <20180103234025.GA23371@thunk.org>
 <c861d001-48b2-92a9-eef9-fd1cf402a15c@skogtun.org>
 <CAC20D2OZ4ZvbJSfzZxBWLanfzZgg3XBTiMNVzHK_0yV9tEbmvg@mail.gmail.com>
 <20180104164557.GI23371@thunk.org> <20180104171740.GF19585@mcvoy.com>
Message-ID: <20180104183014.99912156E523@mail.bitblocks.com>

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.


From lm at mcvoy.com  Fri Jan  5 04:50:01 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 4 Jan 2018 10:50:01 -0800
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <20180104183014.99912156E523@mail.bitblocks.com>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
 <20180103234025.GA23371@thunk.org>
 <c861d001-48b2-92a9-eef9-fd1cf402a15c@skogtun.org>
 <CAC20D2OZ4ZvbJSfzZxBWLanfzZgg3XBTiMNVzHK_0yV9tEbmvg@mail.gmail.com>
 <20180104164557.GI23371@thunk.org>
 <20180104171740.GF19585@mcvoy.com>
 <20180104183014.99912156E523@mail.bitblocks.com>
Message-ID: <20180104185001.GI19585@mcvoy.com>

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.


From imp at bsdimp.com  Fri Jan  5 06:52:33 2018
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 4 Jan 2018 13:52:33 -0700
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <20180104185001.GI19585@mcvoy.com>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
 <20180103234025.GA23371@thunk.org>
 <c861d001-48b2-92a9-eef9-fd1cf402a15c@skogtun.org>
 <CAC20D2OZ4ZvbJSfzZxBWLanfzZgg3XBTiMNVzHK_0yV9tEbmvg@mail.gmail.com>
 <20180104164557.GI23371@thunk.org> <20180104171740.GF19585@mcvoy.com>
 <20180104183014.99912156E523@mail.bitblocks.com>
 <20180104185001.GI19585@mcvoy.com>
Message-ID: <CANCZdfqMtaTQRvgEUP7d5HTk3iCibbPYnK5ytT1VxcHDqYq31Q@mail.gmail.com>

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>

From tytso at mit.edu  Fri Jan  5 06:56:31 2018
From: tytso at mit.edu (Theodore Ts'o)
Date: Thu, 4 Jan 2018 15:56:31 -0500
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <20180104183014.99912156E523@mail.bitblocks.com>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
 <20180103234025.GA23371@thunk.org>
 <c861d001-48b2-92a9-eef9-fd1cf402a15c@skogtun.org>
 <CAC20D2OZ4ZvbJSfzZxBWLanfzZgg3XBTiMNVzHK_0yV9tEbmvg@mail.gmail.com>
 <20180104164557.GI23371@thunk.org>
 <20180104171740.GF19585@mcvoy.com>
 <20180104183014.99912156E523@mail.bitblocks.com>
Message-ID: <20180104205631.GL23371@thunk.org>

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


From bakul at bitblocks.com  Fri Jan  5 06:56:53 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Thu, 4 Jan 2018 12:56:53 -0800
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <CANCZdfqMtaTQRvgEUP7d5HTk3iCibbPYnK5ytT1VxcHDqYq31Q@mail.gmail.com>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
 <20180103234025.GA23371@thunk.org>
 <c861d001-48b2-92a9-eef9-fd1cf402a15c@skogtun.org>
 <CAC20D2OZ4ZvbJSfzZxBWLanfzZgg3XBTiMNVzHK_0yV9tEbmvg@mail.gmail.com>
 <20180104164557.GI23371@thunk.org> <20180104171740.GF19585@mcvoy.com>
 <20180104183014.99912156E523@mail.bitblocks.com>
 <20180104185001.GI19585@mcvoy.com>
 <CANCZdfqMtaTQRvgEUP7d5HTk3iCibbPYnK5ytT1VxcHDqYq31Q@mail.gmail.com>
Message-ID: <699C77DA-7685-413F-BAFD-D7C40E06090E@bitblocks.com>



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

From imp at bsdimp.com  Fri Jan  5 07:16:46 2018
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 4 Jan 2018 14:16:46 -0700
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <20180104205631.GL23371@thunk.org>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
 <20180103234025.GA23371@thunk.org>
 <c861d001-48b2-92a9-eef9-fd1cf402a15c@skogtun.org>
 <CAC20D2OZ4ZvbJSfzZxBWLanfzZgg3XBTiMNVzHK_0yV9tEbmvg@mail.gmail.com>
 <20180104164557.GI23371@thunk.org> <20180104171740.GF19585@mcvoy.com>
 <20180104183014.99912156E523@mail.bitblocks.com>
 <20180104205631.GL23371@thunk.org>
Message-ID: <CANCZdfqTOYata4LwqsSe4oC2sU_Sd0gitx3DeGikUe78tkLFhQ@mail.gmail.com>

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>

From bakul at bitblocks.com  Fri Jan  5 07:17:40 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Thu, 4 Jan 2018 13:17:40 -0800
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <20180104205631.GL23371@thunk.org>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
 <20180103234025.GA23371@thunk.org>
 <c861d001-48b2-92a9-eef9-fd1cf402a15c@skogtun.org>
 <CAC20D2OZ4ZvbJSfzZxBWLanfzZgg3XBTiMNVzHK_0yV9tEbmvg@mail.gmail.com>
 <20180104164557.GI23371@thunk.org> <20180104171740.GF19585@mcvoy.com>
 <20180104183014.99912156E523@mail.bitblocks.com>
 <20180104205631.GL23371@thunk.org>
Message-ID: <4DA9612F-4459-4026-9E1C-23F32BCCFB6A@bitblocks.com>

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.

From akosela at andykosela.com  Fri Jan  5 08:55:11 2018
From: akosela at andykosela.com (Andy Kosela)
Date: Thu, 4 Jan 2018 16:55:11 -0600
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <CANCZdfqTOYata4LwqsSe4oC2sU_Sd0gitx3DeGikUe78tkLFhQ@mail.gmail.com>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
 <20180103234025.GA23371@thunk.org>
 <c861d001-48b2-92a9-eef9-fd1cf402a15c@skogtun.org>
 <CAC20D2OZ4ZvbJSfzZxBWLanfzZgg3XBTiMNVzHK_0yV9tEbmvg@mail.gmail.com>
 <20180104164557.GI23371@thunk.org> <20180104171740.GF19585@mcvoy.com>
 <20180104183014.99912156E523@mail.bitblocks.com>
 <20180104205631.GL23371@thunk.org>
 <CANCZdfqTOYata4LwqsSe4oC2sU_Sd0gitx3DeGikUe78tkLFhQ@mail.gmail.com>
Message-ID: <CALMnNGiOtp47_LKRufKRsynwL6iW7wFod-XKU_1W+Q_-4s8CrA@mail.gmail.com>

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>

From clemc at ccc.com  Sat Jan  6 00:27:33 2018
From: clemc at ccc.com (Clem Cole)
Date: Fri, 5 Jan 2018 09:27:33 -0500
Subject: [TUHS] OT: critical Intel design flaw
In-Reply-To: <CALMnNGiOtp47_LKRufKRsynwL6iW7wFod-XKU_1W+Q_-4s8CrA@mail.gmail.com>
References: <20180103134358.3F16818C098@mercury.lcs.mit.edu>
 <CAC20D2NEvx_3R_HjzO6r3h6OaAcrpkmWuTRNX7-ApoEz8+KxTg@mail.gmail.com>
 <C30F8795-EBB0-4734-8550-0BE2B77F07F0@bitblocks.com>
 <CAC20D2NUfSHt36bSy4HL5A9ZXOL3QSP26ZT4bKxYcmHb0YLx5w@mail.gmail.com>
 <20180103234025.GA23371@thunk.org>
 <c861d001-48b2-92a9-eef9-fd1cf402a15c@skogtun.org>
 <CAC20D2OZ4ZvbJSfzZxBWLanfzZgg3XBTiMNVzHK_0yV9tEbmvg@mail.gmail.com>
 <20180104164557.GI23371@thunk.org> <20180104171740.GF19585@mcvoy.com>
 <20180104183014.99912156E523@mail.bitblocks.com>
 <20180104205631.GL23371@thunk.org>
 <CANCZdfqTOYata4LwqsSe4oC2sU_Sd0gitx3DeGikUe78tkLFhQ@mail.gmail.com>
 <CALMnNGiOtp47_LKRufKRsynwL6iW7wFod-XKU_1W+Q_-4s8CrA@mail.gmail.com>
Message-ID: <CAC20D2NCK11tSnHUgSqJhjJddYLjO-oBDwLAXDv=negX7CYwxg@mail.gmail.com>

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>

From dave at horsfall.org  Mon Jan  8 11:07:38 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 8 Jan 2018 12:07:38 +1100 (EST)
Subject: [TUHS] RIP John Mauchly
Message-ID: <alpine.BSF.2.21.1801081146400.53831@aneurin.horsfall.org>

We lost a co-inventor of ENIAC, John Mauchly, on this day (that's 8th 
January like my headers say) in 1980.  ENIAC is claimed to be the "first 
general purpose electronic digital computer", but I guess it comes down to 
a matter of definition[*], as every culture likes to be the "first" (just 
ask the Penguins, for example); for "computer" you could go all the way 
back to the Mk-I Antikythera (Hellenic variation, from about the 100BC 
production run)...

[*]
Analogue/digital/hybrid
Mechanical/electrical/electronic/hybrid
General/special
Wired/programmable/Turing
Prototype/production
Harvard/Neumann/quantum
Etc...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From wkt at tuhs.org  Tue Jan  9 10:30:18 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 9 Jan 2018 10:30:18 +1000
Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary
Message-ID: <20180109003018.GB29792@minnie.tuhs.org>

Hi all, Happy New Year. As it's now only eighteen months to the Unix 50th 
Anniversary, I thought I'd poll you all to get an update of what is being
done to celebrate the anniversary, and/or what could we organise that has
not yet been organised.

Cheers, Warren


From dave at horsfall.org  Tue Jan  9 10:39:46 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 9 Jan 2018 11:39:46 +1100 (EST)
Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary
In-Reply-To: <20180109003018.GB29792@minnie.tuhs.org>
References: <20180109003018.GB29792@minnie.tuhs.org>
Message-ID: <alpine.BSF.2.21.1801091135500.53831@aneurin.horsfall.org>

On Tue, 9 Jan 2018, Warren Toomey wrote:

> Hi all, Happy New Year. As it's now only eighteen months to the Unix 
> 50th Anniversary, I thought I'd poll you all to get an update of what is 
> being done to celebrate the anniversary, and/or what could we organise 
> that has not yet been organised.

Gawd; I'd better get started on ACSnet then...  As I recall, Piers did the 
MHSnet stuff, but I don't recall whether it interoperates with ACSnet (too 
long ago!).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From noel.hunt at gmail.com  Tue Jan  9 12:16:01 2018
From: noel.hunt at gmail.com (Noel Hunt)
Date: Tue, 9 Jan 2018 13:16:01 +1100
Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary
In-Reply-To: <alpine.BSF.2.21.1801091135500.53831@aneurin.horsfall.org>
References: <20180109003018.GB29792@minnie.tuhs.org>
 <alpine.BSF.2.21.1801091135500.53831@aneurin.horsfall.org>
Message-ID: <CAGfO01xUd2a=bAkRR2T6mMHsM5--AuKi493oZVjO0KHDanJr6g@mail.gmail.com>

Didn't Piers write ACSnet too?


On Tue, Jan 9, 2018 at 11:39 AM, Dave Horsfall <dave at horsfall.org> wrote:

> On Tue, 9 Jan 2018, Warren Toomey wrote:
>
> Hi all, Happy New Year. As it's now only eighteen months to the Unix 50th
>> Anniversary, I thought I'd poll you all to get an update of what is being
>> done to celebrate the anniversary, and/or what could we organise that has
>> not yet been organised.
>>
>
> Gawd; I'd better get started on ACSnet then...  As I recall, Piers did the
> MHSnet stuff, but I don't recall whether it interoperates with ACSnet (too
> long ago!).
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180109/d3fe1341/attachment.html>

From dave at horsfall.org  Tue Jan  9 12:38:02 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 9 Jan 2018 13:38:02 +1100 (EST)
Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary
In-Reply-To: <CAGfO01xUd2a=bAkRR2T6mMHsM5--AuKi493oZVjO0KHDanJr6g@mail.gmail.com>
References: <20180109003018.GB29792@minnie.tuhs.org>
 <alpine.BSF.2.21.1801091135500.53831@aneurin.horsfall.org>
 <CAGfO01xUd2a=bAkRR2T6mMHsM5--AuKi493oZVjO0KHDanJr6g@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.1801091336070.53831@aneurin.horsfall.org>

On Tue, 9 Jan 2018, Noel Hunt wrote:

> Didn't Piers write ACSnet too?

He was part of it, yes; the reference was to Piers getting an MHSnet node 
ready for The Event.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From kevin.bowling at kev009.com  Tue Jan  9 17:30:47 2018
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Tue, 9 Jan 2018 00:30:47 -0700
Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary
In-Reply-To: <20180109003018.GB29792@minnie.tuhs.org>
References: <20180109003018.GB29792@minnie.tuhs.org>
Message-ID: <CAK7dMtC1ZnX1LLsveWnJETe5uwPyg45uALMpH_ZibQO4TRcPtQ@mail.gmail.com>

I would like to see an in person event somewhere

On Mon, Jan 8, 2018 at 5:30 PM, Warren Toomey <wkt at tuhs.org> wrote:
> Hi all, Happy New Year. As it's now only eighteen months to the Unix 50th
> Anniversary, I thought I'd poll you all to get an update of what is being
> done to celebrate the anniversary, and/or what could we organise that has
> not yet been organised.
>
> Cheers, Warren


From helbig at mailbox.org  Wed Jan 10 04:05:56 2018
From: helbig at mailbox.org (Wolfgang Helbig)
Date: Tue, 9 Jan 2018 19:05:56 +0100
Subject: [TUHS] Some resources for V6/PDP/SIMH newbs like me
In-Reply-To: <e666aa55-3214-464e-18e3-c03348fda057@gmail.com>
References: <e666aa55-3214-464e-18e3-c03348fda057@gmail.com>
Message-ID: <B376C0C5-55F9-48BC-A082-9527F6DDEA5F@mailbox.org>

Hi, Will

may I point to chapter 1.0 of my operating system lecture notes at:
http://doc.cat-v.org/unix/v6/operating-systems-lecture-notes/script/

among others, it explains the assembler language, together with the description of the instruction set

http://doc.cat-v.org/unix/v6/operating-systems-lecture-notes/pdp11/doc/cpu

and finally the Unix Assembler Reference Manual(1) at
http://doc.cat-v.org/unix/v6/operating-systems-lecture-notes/v6/doc/index.html

might help.

Greetings,
Wolfgang
> Am 20.11.2017 um 20:20 schrieb Will Senn <will.senn at gmail.com>:
> 
> All,
> 
> While it's fresh, I thought I'd share some resources I've found helpful in learning about the venerable v6 as a relative newb...
> 
> Learning Unix V6 in the modern era is an interesting and enormously educational experience. In the process of using it I have had to learn how to host it in a simulator (SimH in my case, but there are others), install it, communicate with it, configure it, build special files for it, attach devices to it, communicate with the devices attached to it and to SimH, build a kernel, install the kernel, boot the kernel, work with a variety of media intended to work with it, extend it, and so on. In addition, I have had to learn a bit about the PDP-11 (as arguably the most convenient architecture for learning about V6), about its architecture, its instruction set, its devices, its memory structure, and so on.
> 
> None of this exploration would have been possible without the excellent work of Bob Supnik, Mark Pizzolato, and co. on the SimH pdp-11 simulator, the Simh mailing list, Warren Toomey and TUHS for making the bits available, the TUHS mailing list, PUPS, Bitsavers, and a slew of readily available documentation and texts including these notables:
> 
> Setting Up Unix 6th Edition from the V6 Programmer's Manual
> The Unix V6 Programmer's Manual in its entirety
> The SimH and SimH PDP-11 Manuals
> A large number of blogs with SimH specific V6 installation logs
> The V6 Source Code and man pages (don't forget to install man - the 1bsd version works, and is superior)!
> The DEC PDP-11/05-10-35-40 1973 Handbook (the 11/40 handbook is not as detailed with respect to memory management)
> Lions's Commentary on the Sixth Edition source code
> 
> Now that I'm over the beginner's hump, so to speak, I'm exploring things differently and I thought I'd share some resources that I am currently finding useful and interesting in my explorations...
> 
> To bone up on assembly language, Lions's commentary is exceptionally helpful in explaining assembly as it is implemented in V6. The manual itself is really thin, and the source is a bit cryptic, for the newcomer. Lions explains the idioms used in the main source of V6. However, without a background in assembly language, Lions is pretty meaningless, so I went looking for something that was PDP specific that would bridge the gap and help me understand Lions's words. I found a number of texts that were really good. Most require a working RT11 instance to actually try out the coding examples and do the exercises (SimH and Bitsavers to the rescue):
> 
> Arthur Gill - Machine and Assembly Language Programming of the Pdp-11
> Charles A. Kapps and Robert L. Stafford - Assembly Language for the PDP-11
> Glenn H. MacEwan - Introduction to Computer Systems: Using the PDP-11 and Pascal
> James F. Peters - The Digital Way: Macro-11 Assembler Programming (PDP-11)
> Michael G. Schneider - The Principles of Computer Organization: With Assembly Language Programming for the PDP-11
> PDP-11 Processor Handbook (pretty much any edition)
> Thomas A. Frank - Introduction to the PDP-11 and its Assembly Language
> 
> All of these are useable with a running RT11 instance. But, I think the Peters and Frank books are the standouts. Peters because all of the exercises that I have tried (dozens) have worked as printed and Frank because he is rigorous in his treatment of the subject and builds up from digital logic all the way through program execution. Frank is an excellent complement to Lions work because he explains the details that Lions assumes.
> 
> To learn about digital logic, and a special thanks to Warren for his work on Crazy Small CPU, I have been introduced to logisim. It is a great playground for exploring digital logic. I had no idea that a sketchpad for digital logic simulation was available and accessible to the layperson. Logisim development stopped around 2014 and while there are a number of successors out there, I am using logisim-evolution:
> 
> https://github.com/reds-heig/logisim-evolution
> 
> The rabbit trails never seem to end... in order to learn how to use logisim, I went through the excellent tutorial and then went looking for a book of experiments in digital logic and found:
> 
> digital computer lab workbook from 1969
> http://bitsavers.trailing-edge.com/pdf/dec/handbooks/Digital_Computer_Lab_Workbook_1969.pdf
> 
> digital equipment corporation computer lab teacher's guide from 1968
> http://www.so-much-stuff.com/pdp8/pdf/ComputerLabTeachersGuide.pdf
> 
> These two are useable with very little modification as a source of digital logic exercises that work great with logisim and are related to the architectural lineage of the PDP-11.
> 
> These resources fit together nicely in my pursuit to better understand digital logic, the pdp-11, assembly language, and unix v6. In sum:
> 
> Source code for v6 for what really is supposed to happen in v6 operation
> Lions for understanding Unix V6 sources and for unix assembly language information
> PDP-11 Hanbook for quick reference on PDP-11 assembly language instruction set
> Frank for assembly language details and for details on digital logic and its relationship to the PDP-11 architecture.
> Logisim to test logic constructs
> The digital lab workbook for practice with digital logic
> 
> Later,
> 
> Will
> 
> 
> 
> -- 
> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
> 

Wolfgang Helbig
Stauferstr. 22

71334 Waiblingen






From imp at bsdimp.com  Wed Jan 10 04:09:37 2018
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 9 Jan 2018 11:09:37 -0700
Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary
In-Reply-To: <20180109003018.GB29792@minnie.tuhs.org>
References: <20180109003018.GB29792@minnie.tuhs.org>
Message-ID: <CANCZdfoXhFvFVZRWBjQKuexrbjRVL2ntmY5cDyN+TqyScgK0=A@mail.gmail.com>

I'm working on a long-term project to reverse engineer the sources to Venix
on my Rainbow based off the now-publicly available v7 sources and recently
re-surfaced disks... I suspect that the compiler is not going to happen...
But lots of the rest of it might...  Will make an interesting
presentation...

On Mon, Jan 8, 2018 at 5:30 PM, Warren Toomey <wkt at tuhs.org> wrote:

> Hi all, Happy New Year. As it's now only eighteen months to the Unix 50th
> Anniversary, I thought I'd poll you all to get an update of what is being
> done to celebrate the anniversary, and/or what could we organise that has
> not yet been organised.
>
> Cheers, Warren
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180109/b1fe71ef/attachment.html>

From doug at cs.dartmouth.edu  Wed Jan 10 06:17:28 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Tue, 09 Jan 2018 15:17:28 -0500
Subject: [TUHS] [TUHS} 2018: eighteen months of the Unix 50th anniversary
Message-ID: <201801092017.w09KHSoc023473@coolidge.cs.Dartmouth.EDU>

I don't think I'm violating anyone's confidentiality by revealing that
Marcus Weldon, current president of the Labs, at the suggestion of
Martin Carroll, expects the Labs to embark soon on plans to mark
the occasion. I, and no doubt Martin, will keep you posted. Meanwhile
I will be happy to forward pertinent suggestions.

Doug


From doug at cs.dartmouth.edu  Wed Jan 10 06:39:31 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Tue, 09 Jan 2018 15:39:31 -0500
Subject: [TUHS] [TUHS} 2018: eighteen months of the Unix 50th anniversary
Message-ID: <201801092039.w09KdVDd023506@coolidge.cs.Dartmouth.EDU>

> I will be happy to forward pertinent suggestions.

Here's one. If Bell Labs holds some kind of symposium on
the lines of the dmr memorial, how about a plenary
session with TV participation from remote venues (think
Berkeley/Silicon Valley and Wollongong/Sydney--a nine-hour
span of time zones).

Any thoughts about this or other possibilities?

Doug


From dave at horsfall.org  Wed Jan 10 07:31:17 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 10 Jan 2018 08:31:17 +1100 (EST)
Subject: [TUHS] Happy birthday, Donald Knuth!
Message-ID: <alpine.BSF.2.21.1801100800010.53831@aneurin.horsfall.org>

Computer pioneer Donald Knuth was born on this day in 1938; amongst other 
things he gave us the TeX typesetting language, and he's still working on 
"The Art Of Computer Programming" fascicles (I only got as far as the 
first two volumes).

I really must have a look at his new MMIX, too; I love learning new 
programming languages (I've used about 50 the last time I looked, and I'm 
happy to post a list for my coterie of disbelievers).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From crossd at gmail.com  Wed Jan 10 08:56:45 2018
From: crossd at gmail.com (Dan Cross)
Date: Tue, 9 Jan 2018 17:56:45 -0500
Subject: [TUHS] [TUHS} 2018: eighteen months of the Unix 50th anniversary
In-Reply-To: <201801092039.w09KdVDd023506@coolidge.cs.Dartmouth.EDU>
References: <201801092039.w09KdVDd023506@coolidge.cs.Dartmouth.EDU>
Message-ID: <CAEoi9W4a790Au8cgkbHoYTzt3jbBAPX9+mRZsMRDRthJZn48yQ@mail.gmail.com>

I think that would be wonderful.

On Tue, Jan 9, 2018 at 3:39 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> > I will be happy to forward pertinent suggestions.
>
> Here's one. If Bell Labs holds some kind of symposium on
> the lines of the dmr memorial, how about a plenary
> session with TV participation from remote venues (think
> Berkeley/Silicon Valley and Wollongong/Sydney--a nine-hour
> span of time zones).
>
> Any thoughts about this or other possibilities?
>
> Doug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180109/abcd3b6d/attachment.html>

From grog at lemis.com  Wed Jan 10 13:34:59 2018
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Wed, 10 Jan 2018 14:34:59 +1100
Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary
In-Reply-To: <20180109003018.GB29792@minnie.tuhs.org>
References: <20180109003018.GB29792@minnie.tuhs.org>
Message-ID: <20180110033459.GB27612@eureka.lemis.com>

On Tuesday,  9 January 2018 at 10:30:18 +1000, Warren Toomey wrote:
> Hi all, Happy New Year. As it's now only eighteen months to the Unix 50th
> Anniversary, ...

So we have an exact date?  What happened on that day?

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180110/ce1724ae/attachment.sig>

From imp at bsdimp.com  Wed Jan 10 14:11:39 2018
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 9 Jan 2018 21:11:39 -0700
Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary
In-Reply-To: <20180110033459.GB27612@eureka.lemis.com>
References: <20180109003018.GB29792@minnie.tuhs.org>
 <20180110033459.GB27612@eureka.lemis.com>
Message-ID: <CANCZdfojZpZMk4Cu-gy2_XX_6gySCg67xEMx_-sZtoU5dATTkQ@mail.gmail.com>

On Tue, Jan 9, 2018 at 8:34 PM, Greg 'groggy' Lehey <grog at lemis.com> wrote:

> On Tuesday,  9 January 2018 at 10:30:18 +1000, Warren Toomey wrote:
> > Hi all, Happy New Year. As it's now only eighteen months to the Unix 50th
> > Anniversary, ...
>
> So we have an exact date?  What happened on that day?
>

PDP-7 Unix has a date of Jan 1, 1970 date in the TUHS tree. Wikipedia cites
http://www.faqs.org/docs/artu/ch02s01.html as saying it was developed in
1969, but is not more specific. I've seen references to the summer of 1969
Ken starting to write the paper filesystem.

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

From ggm at algebras.org  Wed Jan 10 15:23:04 2018
From: ggm at algebras.org (George Michaelson)
Date: Wed, 10 Jan 2018 15:23:04 +1000
Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary
In-Reply-To: <CANCZdfojZpZMk4Cu-gy2_XX_6gySCg67xEMx_-sZtoU5dATTkQ@mail.gmail.com>
References: <20180109003018.GB29792@minnie.tuhs.org>
 <20180110033459.GB27612@eureka.lemis.com>
 <CANCZdfojZpZMk4Cu-gy2_XX_6gySCg67xEMx_-sZtoU5dATTkQ@mail.gmail.com>
Message-ID: <CAKr6gn3Cr4mcuxyE9+r=Q1rffpE5-TvsVdfePDw+u+F-c-5=6g@mail.gmail.com>

I'm probably a bit of a simpleton about this stuff. I feel like my
engagement with UNIX has been a succession of mind-blown moments.

1978: shown a piped command. mind blown. What.The.Holy.Hell. I cannot
understand this. I entered the room with punched cards. How does this
even work.

1979: shown how to write macros. mind blown.
This.Is.Not.A.Program.This.is.a.meta.program. What reads this? a pre
processor. whats that. mind officially blown. I cannot understand.
WHERE IS MY CODE

1981: made to read about the design of the IBM 360 monotonically
rising clock. mind blown. How.Can.Every.Computer.Not.Have.Had.This.
What does time even mean? what is negative time? Whats the granularity
of time? I DONT UNDERSTAND WHY I DONT UNDERSTAND

1982: I start work on systems where I have su privilege and can change
the time. Mind blown I.Can.Tell.Lies.About.Time How come? How come
there isn't some magic once-only pass through hardware abacus
rat-in-a-cage machine I can't lie about ITS ALL LIES mind blown.

1984: I start doing NTP and see emails from Dave Mills. Mind blown.
He.Is.Not.Typing.English.As.I.Understand.It.This.Is.The.Goon.Show mind
blown. But.. in a good way. People can make fun of themselves and
write real code? Time is fuzzy? Time has properties? People are
thinking about 2039? Mind blown. I don't even believe I will be alive
in 2039 given "star wars" and "protect and survive"

I really like 1/1/1970. its been like a constant in my life. If it
turned out to be 1969 I'd be ok but I have to say.. a bit .. somewhere
inside.. a small squirrel inside Searles  'chinese box' is saying...

   mind... blown...


From kevin.bowling at kev009.com  Wed Jan 10 16:25:32 2018
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Tue, 9 Jan 2018 23:25:32 -0700
Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary
In-Reply-To: <CAKr6gn3Cr4mcuxyE9+r=Q1rffpE5-TvsVdfePDw+u+F-c-5=6g@mail.gmail.com>
References: <20180109003018.GB29792@minnie.tuhs.org>
 <20180110033459.GB27612@eureka.lemis.com>
 <CANCZdfojZpZMk4Cu-gy2_XX_6gySCg67xEMx_-sZtoU5dATTkQ@mail.gmail.com>
 <CAKr6gn3Cr4mcuxyE9+r=Q1rffpE5-TvsVdfePDw+u+F-c-5=6g@mail.gmail.com>
Message-ID: <CAK7dMtAioNzrSh+M0OqxjqAJ-DACvsVpaeO2b7m0WNtnfw9gAQ@mail.gmail.com>

Things like this don't really occur in one day [1]  "Unix was born in
1969 not 1974" - dmr

Is it fair to say 1/1/1970 is the spiritual christening and the day to
celebrate?

[1] http://webarchive.loc.gov/all/20100506231949/http://cm.bell-labs.com/cm/cs/who/dmr/hist.html

On Tue, Jan 9, 2018 at 10:23 PM, George Michaelson <ggm at algebras.org> wrote:
> I'm probably a bit of a simpleton about this stuff. I feel like my
> engagement with UNIX has been a succession of mind-blown moments.
>
> 1978: shown a piped command. mind blown. What.The.Holy.Hell. I cannot
> understand this. I entered the room with punched cards. How does this
> even work.
>
> 1979: shown how to write macros. mind blown.
> This.Is.Not.A.Program.This.is.a.meta.program. What reads this? a pre
> processor. whats that. mind officially blown. I cannot understand.
> WHERE IS MY CODE
>
> 1981: made to read about the design of the IBM 360 monotonically
> rising clock. mind blown. How.Can.Every.Computer.Not.Have.Had.This.
> What does time even mean? what is negative time? Whats the granularity
> of time? I DONT UNDERSTAND WHY I DONT UNDERSTAND
>
> 1982: I start work on systems where I have su privilege and can change
> the time. Mind blown I.Can.Tell.Lies.About.Time How come? How come
> there isn't some magic once-only pass through hardware abacus
> rat-in-a-cage machine I can't lie about ITS ALL LIES mind blown.
>
> 1984: I start doing NTP and see emails from Dave Mills. Mind blown.
> He.Is.Not.Typing.English.As.I.Understand.It.This.Is.The.Goon.Show mind
> blown. But.. in a good way. People can make fun of themselves and
> write real code? Time is fuzzy? Time has properties? People are
> thinking about 2039? Mind blown. I don't even believe I will be alive
> in 2039 given "star wars" and "protect and survive"
>
> I really like 1/1/1970. its been like a constant in my life. If it
> turned out to be 1969 I'd be ok but I have to say.. a bit .. somewhere
> inside.. a small squirrel inside Searles  'chinese box' is saying...
>
>    mind... blown...


From kevin.bowling at kev009.com  Wed Jan 10 16:29:23 2018
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Tue, 9 Jan 2018 23:29:23 -0700
Subject: [TUHS] Happy birthday, Donald Knuth!
In-Reply-To: <alpine.BSF.2.21.1801100800010.53831@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1801100800010.53831@aneurin.horsfall.org>
Message-ID: <CAK7dMtDz-qR=fBTCF53TjER3-okcscpvdabevgRWC9nUnwyw8g@mail.gmail.com>

I think it's phenomenal that he is still working on his books.  It's
good to have people to look up to :}

On Tue, Jan 9, 2018 at 2:31 PM, Dave Horsfall <dave at horsfall.org> wrote:
> Computer pioneer Donald Knuth was born on this day in 1938; amongst other
> things he gave us the TeX typesetting language, and he's still working on
> "The Art Of Computer Programming" fascicles (I only got as far as the first
> two volumes).
>
> I really must have a look at his new MMIX, too; I love learning new
> programming languages (I've used about 50 the last time I looked, and I'm
> happy to post a list for my coterie of disbelievers).
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."


From grog at lemis.com  Wed Jan 10 16:53:51 2018
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Wed, 10 Jan 2018 17:53:51 +1100
Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary
In-Reply-To: <CAK7dMtAioNzrSh+M0OqxjqAJ-DACvsVpaeO2b7m0WNtnfw9gAQ@mail.gmail.com>
References: <20180109003018.GB29792@minnie.tuhs.org>
 <20180110033459.GB27612@eureka.lemis.com>
 <CANCZdfojZpZMk4Cu-gy2_XX_6gySCg67xEMx_-sZtoU5dATTkQ@mail.gmail.com>
 <CAKr6gn3Cr4mcuxyE9+r=Q1rffpE5-TvsVdfePDw+u+F-c-5=6g@mail.gmail.com>
 <CAK7dMtAioNzrSh+M0OqxjqAJ-DACvsVpaeO2b7m0WNtnfw9gAQ@mail.gmail.com>
Message-ID: <20180110065351.GD27612@eureka.lemis.com>

On Tuesday,  9 January 2018 at 23:25:32 -0700, Kevin Bowling wrote:
> Things like this don't really occur in one day [1]  "Unix was born in
> 1969 not 1974" - dmr
>
> Is it fair to say 1/1/1970 is the spiritual christening and the day to
> celebrate?

Clearly wkt has something else in mind if he wrote "18 months".  I
don't think 1 January 1970 had any meaning until it became the
(currently last) epoch.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180110/8e788377/attachment.sig>

From wkt at tuhs.org  Wed Jan 10 20:57:58 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 10 Jan 2018 20:57:58 +1000
Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary
In-Reply-To: <20180110065351.GD27612@eureka.lemis.com>
References: <20180109003018.GB29792@minnie.tuhs.org>
 <20180110033459.GB27612@eureka.lemis.com>
 <CANCZdfojZpZMk4Cu-gy2_XX_6gySCg67xEMx_-sZtoU5dATTkQ@mail.gmail.com>
 <CAKr6gn3Cr4mcuxyE9+r=Q1rffpE5-TvsVdfePDw+u+F-c-5=6g@mail.gmail.com>
 <CAK7dMtAioNzrSh+M0OqxjqAJ-DACvsVpaeO2b7m0WNtnfw9gAQ@mail.gmail.com>
 <20180110065351.GD27612@eureka.lemis.com>
Message-ID: <20180110105758.GA2099@minnie.tuhs.org>

On Wed, Jan 10, 2018 at 05:53:51PM +1100, Greg 'groggy' Lehey wrote:
>> Is it fair to say 1/1/1970 is the spiritual christening and the day to
>> celebrate?
>
>Clearly wkt has something else in mind if he wrote "18 months".  I
>don't think 1 January 1970 had any meaning until it became the
>(currently last) epoch.

HI all, and apologies for the delay in responding. Here's a quote
from an interview that Mike Mahoney did with Ken Thompson:

(http://www.tuhs.org/Archive/Documentation/OralHistory/transcripts/thompson.htm)

    MSM: At what point did you feel you had something here?
    
    Thompson: Um, well, the first one was not at all multiprogrammed,
    and was almost like subroutines on the file system. The read call, the
    system read call, was in fact the call "read" of the file system and it
    was very synchronous, just subroutine call to the file systems for these
    applications. And um there was a very quick rewrite that admitted it was
    an operating system, and it had a kernel user interface that you trapped
    across. I really can’t remember what the realization was, I mean,
    the whole time span, from initially starting with...walking downstairs,
    down there with the idea that we were going to build a file system.
    
    MSM: When was this, do you remember the time?
    
    Thompson: Yeah, it was the summer of ‘69.
    
    MSM: Summer of ‘69 ok
    
    Thompson: In fact um my wife went on vacation to my family’s place
    in California to visit my parents -- we’d just had a new son in August
    ‘68 -- and uh they hadn’t seen the kid so (unclear) took the kid to
    visit my family and she was gone a month to California and I allocated a
    week each to the shell, to the operating system, the shell, the editor,
    and the assembler, to reproduce itself. During the month she was gone,
    which was in the summer of ‘69, it was totally rewritten in a form that
    looked like an operating system, with tools that were sort of known, you
    know, an assembler, an editor and a shell. If not maintaining itself,
    right on the verge of maintaining itself, to totally sever the GECOS
    connection.
    
So, while we don't have an exact date, it's reasonable to assume that,
sometime around July 1969, Unix was at a point where it was self-hosting.

Ken is a subscriber to this list, so maybe he might be able to help 
narrow down the date.

Cheers all,
	Warren


From akosela at andykosela.com  Wed Jan 10 23:23:26 2018
From: akosela at andykosela.com (Andy Kosela)
Date: Wed, 10 Jan 2018 07:23:26 -0600
Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary
In-Reply-To: <CAK7dMtAioNzrSh+M0OqxjqAJ-DACvsVpaeO2b7m0WNtnfw9gAQ@mail.gmail.com>
References: <20180109003018.GB29792@minnie.tuhs.org>
 <20180110033459.GB27612@eureka.lemis.com>
 <CANCZdfojZpZMk4Cu-gy2_XX_6gySCg67xEMx_-sZtoU5dATTkQ@mail.gmail.com>
 <CAKr6gn3Cr4mcuxyE9+r=Q1rffpE5-TvsVdfePDw+u+F-c-5=6g@mail.gmail.com>
 <CAK7dMtAioNzrSh+M0OqxjqAJ-DACvsVpaeO2b7m0WNtnfw9gAQ@mail.gmail.com>
Message-ID: <CALMnNGgO0Qfy9i1wOyvNM9f8g4+xHCQw3QZsUXDJq-83mK1Ciw@mail.gmail.com>

On Wednesday, January 10, 2018, Kevin Bowling <kevin.bowling at kev009.com>
wrote:

> Things like this don't really occur in one day [1]  "Unix was born in
> 1969 not 1974" - dmr
>
> Is it fair to say 1/1/1970 is the spiritual christening and the day to
> celebrate?


>

Christians also do not know the _exact_ year when Jesus was born, but they
arbitrary chose the date as the start of their Epoch.

The Roman calendar before was counted ab urbe condita (from the foundation
of the city, i.e., Rome) in 753 BC, so that year was the start of their
Epoch.

I think it is fair to say that our calendar started on 1/1/1970, and not
because UNIX was born on that day, but because that day was chosen
arbitrary by the Fathers of UNIX.

We, as UNIX disciples, should start counting our calendar starting with the
UNIX Epoch, so we have 48 and not 2018 now...

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

From gtaylor at tnetconsulting.net  Thu Jan 11 02:53:57 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 10 Jan 2018 09:53:57 -0700
Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary
In-Reply-To: <20180110105758.GA2099@minnie.tuhs.org>
References: <20180109003018.GB29792@minnie.tuhs.org>
 <20180110033459.GB27612@eureka.lemis.com>
 <CANCZdfojZpZMk4Cu-gy2_XX_6gySCg67xEMx_-sZtoU5dATTkQ@mail.gmail.com>
 <CAKr6gn3Cr4mcuxyE9+r=Q1rffpE5-TvsVdfePDw+u+F-c-5=6g@mail.gmail.com>
 <CAK7dMtAioNzrSh+M0OqxjqAJ-DACvsVpaeO2b7m0WNtnfw9gAQ@mail.gmail.com>
 <20180110065351.GD27612@eureka.lemis.com>
 <20180110105758.GA2099@minnie.tuhs.org>
Message-ID: <4c313c07-9a36-b6f9-2e90-5992c60d263a@spamtrap.tnetconsulting.net>

On 01/10/2018 03:57 AM, Warren Toomey wrote:
>> If not maintaining itself, right on the verge of maintaining itself, 
>> to totally sever the GECOS connection.
> 
> So, while we don't have an exact date, it's reasonable to assume that, 
> sometime around July 1969, Unix was at a point where it was self-hosting.

Somehow I was not aware that Unix was ever dependent on another OS.

I get the impression that GECOS was more integral with early Unix than I 
had ever imagined.  It sounds like more than just the GECOS field in 
/etc/passwd for associating Unix accounts with GECOS accounts on other 
machines.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180110/0066dd22/attachment.bin>

From dave at horsfall.org  Thu Jan 11 07:33:20 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 11 Jan 2018 08:33:20 +1100 (EST)
Subject: [TUHS] Happy birthday, C.A.R. Hoare!
Message-ID: <alpine.BSF.2.21.1801110830410.53831@aneurin.horsfall.org>

Sir Charles Antony Richard Hoare FRS FREng was born on this day in 1934; a 
computer pioneer (one of the greats) he gave us things like the quicksort 
algorithm and ALGOLW (a neat language).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From dave at horsfall.org  Thu Jan 11 09:48:15 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 11 Jan 2018 10:48:15 +1100 (EST)
Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary
In-Reply-To: <CALMnNGgO0Qfy9i1wOyvNM9f8g4+xHCQw3QZsUXDJq-83mK1Ciw@mail.gmail.com>
References: <20180109003018.GB29792@minnie.tuhs.org>
 <20180110033459.GB27612@eureka.lemis.com>
 <CANCZdfojZpZMk4Cu-gy2_XX_6gySCg67xEMx_-sZtoU5dATTkQ@mail.gmail.com>
 <CAKr6gn3Cr4mcuxyE9+r=Q1rffpE5-TvsVdfePDw+u+F-c-5=6g@mail.gmail.com>
 <CAK7dMtAioNzrSh+M0OqxjqAJ-DACvsVpaeO2b7m0WNtnfw9gAQ@mail.gmail.com>
 <CALMnNGgO0Qfy9i1wOyvNM9f8g4+xHCQw3QZsUXDJq-83mK1Ciw@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.1801111043140.53831@aneurin.horsfall.org>

On Wed, 10 Jan 2018, Andy Kosela wrote:

> Christians also do not know the _exact_ year when Jesus was born, but 
> they arbitrary chose the date as the start of their Epoch.

Not really arbitrary; the dates were chosen to hijack pagan festivals, so 
we have Christmas at Yuletide, Easter at the Spring fertility rites, etc.

No way the big JC could've been born in the middle of winter in that part 
of the world; try about 4BC (Halley's comet) around Spring in March or so.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From ggm at algebras.org  Thu Jan 11 10:06:33 2018
From: ggm at algebras.org (George Michaelson)
Date: Thu, 11 Jan 2018 10:06:33 +1000
Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary
In-Reply-To: <alpine.BSF.2.21.1801111043140.53831@aneurin.horsfall.org>
References: <20180109003018.GB29792@minnie.tuhs.org>
 <20180110033459.GB27612@eureka.lemis.com>
 <CANCZdfojZpZMk4Cu-gy2_XX_6gySCg67xEMx_-sZtoU5dATTkQ@mail.gmail.com>
 <CAKr6gn3Cr4mcuxyE9+r=Q1rffpE5-TvsVdfePDw+u+F-c-5=6g@mail.gmail.com>
 <CAK7dMtAioNzrSh+M0OqxjqAJ-DACvsVpaeO2b7m0WNtnfw9gAQ@mail.gmail.com>
 <CALMnNGgO0Qfy9i1wOyvNM9f8g4+xHCQw3QZsUXDJq-83mK1Ciw@mail.gmail.com>
 <alpine.BSF.2.21.1801111043140.53831@aneurin.horsfall.org>
Message-ID: <CAKr6gn3sCD75HD+wOK9-5kq6TzH6-r8pisoZdZJM+vnF6-XOPw@mail.gmail.com>

If you're going to bring religion into it... Try this on the birth of
the ICL 2900..

(by D.W. barron, 1976)

http://algebras.org/ggm/oldtestament.html

On Thu, Jan 11, 2018 at 9:48 AM, Dave Horsfall <dave at horsfall.org> wrote:
> On Wed, 10 Jan 2018, Andy Kosela wrote:
>
>> Christians also do not know the _exact_ year when Jesus was born, but they
>> arbitrary chose the date as the start of their Epoch.
>
>
> Not really arbitrary; the dates were chosen to hijack pagan festivals, so we
> have Christmas at Yuletide, Easter at the Spring fertility rites, etc.
>
> No way the big JC could've been born in the middle of winter in that part of
> the world; try about 4BC (Halley's comet) around Spring in March or so.
>
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."


From cym224 at gmail.com  Thu Jan 11 10:20:23 2018
From: cym224 at gmail.com (Nemo)
Date: Wed, 10 Jan 2018 19:20:23 -0500
Subject: [TUHS] Happy birthday, C.A.R. Hoare!
In-Reply-To: <alpine.BSF.2.21.1801110830410.53831@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1801110830410.53831@aneurin.horsfall.org>
Message-ID: <CAJfiPzx-PrMHAt_8FVSwtZEkOzWbrrKAXk2iezmoef_kotmNag@mail.gmail.com>

On 10 January 2018 at 16:33, Dave Horsfall <dave at horsfall.org> wrote:
> Sir Charles Antony Richard Hoare FRS FREng was born on this day in 1934; a
> computer pioneer (one of the greats) he gave us things like the quicksort
> algorithm and ALGOLW (a neat language).

Certainly agree with your opinion of Hoare but did the "W" in ALGOLW
not stand for Wirth?

N.


From bakul at bitblocks.com  Thu Jan 11 10:49:55 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 10 Jan 2018 16:49:55 -0800
Subject: [TUHS] Happy birthday, C.A.R. Hoare!
In-Reply-To: Your message of "Thu, 11 Jan 2018 08:33:20 +1100."
 <alpine.BSF.2.21.1801110830410.53831@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1801110830410.53831@aneurin.horsfall.org>
Message-ID: <20180111005010.8309F156E523@mail.bitblocks.com>

On Thu, 11 Jan 2018 08:33:20 +1100 Dave Horsfall <dave at horsfall.org> wrote:
Dave Horsfall writes:
> Sir Charles Antony Richard Hoare FRS FREng was born on this day in 1934; a 
> computer pioneer (one of the greats) he gave us things like the quicksort 
> algorithm and ALGOLW (a neat language).

And conditional critical regions.  And Monitors (jointly with
Per Brinch Hansen).  And CSP. And much more. His "an axiomatic
basis for computer programming" paper was quite influential.
His Turing Award lecture "Emperor's Old Clothes" is well worth
(re)reading.

  http://zoo.cs.yale.edu/classes/cs422/2014/bib/hoare81emperor.pdf



From jnc at mercury.lcs.mit.edu  Thu Jan 11 11:22:48 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 10 Jan 2018 20:22:48 -0500 (EST)
Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary
Message-ID: <20180111012248.9B7DF18C098@mercury.lcs.mit.edu>

    > From: George Michaelson

    > Try this on the birth of the ICL 2900.

Along the same lines, there's this:

  https://www.netjeff.com/humor/item.cgi?file=GenesisForProjects

with its great closing line..

  Noel


From dave at horsfall.org  Thu Jan 11 11:24:15 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 11 Jan 2018 12:24:15 +1100 (EST)
Subject: [TUHS] Happy birthday, C.A.R. Hoare!
In-Reply-To: <CAJfiPzx-PrMHAt_8FVSwtZEkOzWbrrKAXk2iezmoef_kotmNag@mail.gmail.com>
References: <alpine.BSF.2.21.1801110830410.53831@aneurin.horsfall.org>
 <CAJfiPzx-PrMHAt_8FVSwtZEkOzWbrrKAXk2iezmoef_kotmNag@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.1801111215320.53831@aneurin.horsfall.org>

On Wed, 10 Jan 2018, Nemo wrote:

> Certainly agree with your opinion of Hoare but did the "W" in ALGOLW not 
> stand for Wirth?

Dunno, but according to https://en.wikipedia.org/wiki/ALGOL_W we have:

``ALGOL W is a programming language. It is based on a proposal for ALGOL X
   by Niklaus Wirth and Tony Hoare as a successor to ALGOL 60 in IFIP
   Working Group 2.1.''

It was a brilliant language, and it got me hooked on structural 
programming etc; hitherto my knowledge was confined to BASIC (shudder) and 
FORTRAN (double shudder).  And then SNOBOL blew my mind, and PL/I, and 
PL/360, and Pascal, and...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From arnold at skeeve.com  Thu Jan 11 18:05:03 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 11 Jan 2018 01:05:03 -0700
Subject: [TUHS] Happy birthday, C.A.R. Hoare!
In-Reply-To: <CAJfiPzx-PrMHAt_8FVSwtZEkOzWbrrKAXk2iezmoef_kotmNag@mail.gmail.com>
References: <alpine.BSF.2.21.1801110830410.53831@aneurin.horsfall.org>
 <CAJfiPzx-PrMHAt_8FVSwtZEkOzWbrrKAXk2iezmoef_kotmNag@mail.gmail.com>
Message-ID: <201801110805.w0B853sG001874@freefriends.org>

Nemo <cym224 at gmail.com> wrote:

> On 10 January 2018 at 16:33, Dave Horsfall <dave at horsfall.org> wrote:
> > Sir Charles Antony Richard Hoare FRS FREng was born on this day in 1934; a
> > computer pioneer (one of the greats) he gave us things like the quicksort
> > algorithm and ALGOLW (a neat language).
>
> Certainly agree with your opinion of Hoare but did the "W" in ALGOLW
> not stand for Wirth?
>
> N.

Indeed it did. Wirth did AlgolW before he did Pascal.

Arnold


From helbig at mailbox.org  Thu Jan 11 20:21:42 2018
From: helbig at mailbox.org (helbig at mailbox.org)
Date: Thu, 11 Jan 2018 11:21:42 +0100
Subject: [TUHS] Happy birthday, C.A.R. Hoare!
In-Reply-To: <alpine.BSF.2.21.1801111215320.53831@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1801110830410.53831@aneurin.horsfall.org>
 <CAJfiPzx-PrMHAt_8FVSwtZEkOzWbrrKAXk2iezmoef_kotmNag@mail.gmail.com>
 <alpine.BSF.2.21.1801111215320.53831@aneurin.horsfall.org>
Message-ID: <C5367682-5BE4-43FA-AB10-B835E35C638D@mailbox.org>

Hi Dave,


Am 11.01.2018 um 02:24 schrieb Dave Horsfall <dave at horsfall.org>:

> On Wed, 10 Jan 2018, Nemo wrote:
> 
>> Certainly agree with your opinion of Hoare but did the "W" in ALGOLW not stand for Wirth?
> 
> Dunno, but according to https://en.wikipedia.org/wiki/ALGOL_W we have:
> 
> ``ALGOL W is a programming language. It is based on a proposal for ALGOL X
>  by Niklaus Wirth and Tony Hoare as a successor to ALGOL 60 in IFIP
>  Working Group 2.1.''

As Hoare reported in his Turing Award Lecture "The Emperors Old Clothes"

http://zoo.cs.yale.edu/classes/cs422/2014/bib/hoare81emperor.pdf,

Wirth soley designed Algol W based on proposals of a small group of which Hoare was a member. 

Greetings

Wolfgang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180111/42d66e44/attachment.html>

From clemc at ccc.com  Fri Jan 12 07:45:30 2018
From: clemc at ccc.com (Clem Cole)
Date: Thu, 11 Jan 2018 16:45:30 -0500
Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary
In-Reply-To: <20180111012248.9B7DF18C098@mercury.lcs.mit.edu>
References: <20180111012248.9B7DF18C098@mercury.lcs.mit.edu>
Message-ID: <CAC20D2Of-iA72qrg1i6SfvOSQvi7=RMgcmh80vm-kA_e80GaYA@mail.gmail.com>

Definitely a classic.
ᐧ

On Wed, Jan 10, 2018 at 8:22 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: George Michaelson
>
>     > Try this on the birth of the ICL 2900.
>
> Along the same lines, there's this:
>
>   https://www.netjeff.com/humor/item.cgi?file=GenesisForProjects
>
> with its great closing line..
>
>   Noel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180111/ba55135b/attachment.html>

From dave at horsfall.org  Fri Jan 12 07:50:40 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 12 Jan 2018 08:50:40 +1100 (EST)
Subject: [TUHS] Happy birthday, C.A.R. Hoare!
In-Reply-To: <20180111005010.8309F156E523@mail.bitblocks.com>
References: <alpine.BSF.2.21.1801110830410.53831@aneurin.horsfall.org>
 <20180111005010.8309F156E523@mail.bitblocks.com>
Message-ID: <alpine.BSF.2.21.1801120839010.53831@aneurin.horsfall.org>

On Wed, 10 Jan 2018, Bakul Shah wrote:

> And conditional critical regions.  And Monitors (jointly with Per Brinch 
> Hansen).  And CSP. And much more. His "an axiomatic basis for computer 
> programming" paper was quite influential. His Turing Award lecture 
> "Emperor's Old Clothes" is well worth (re)reading.

Noted; thanks.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From robert at timetraveller.org  Fri Jan 12 08:08:32 2018
From: robert at timetraveller.org (Robert Brockway)
Date: Fri, 12 Jan 2018 08:08:32 +1000 (AEST)
Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary
In-Reply-To: <alpine.BSF.2.21.1801111043140.53831@aneurin.horsfall.org>
References: <20180109003018.GB29792@minnie.tuhs.org>
 <20180110033459.GB27612@eureka.lemis.com>
 <CANCZdfojZpZMk4Cu-gy2_XX_6gySCg67xEMx_-sZtoU5dATTkQ@mail.gmail.com>
 <CAKr6gn3Cr4mcuxyE9+r=Q1rffpE5-TvsVdfePDw+u+F-c-5=6g@mail.gmail.com>
 <CAK7dMtAioNzrSh+M0OqxjqAJ-DACvsVpaeO2b7m0WNtnfw9gAQ@mail.gmail.com>
 <CALMnNGgO0Qfy9i1wOyvNM9f8g4+xHCQw3QZsUXDJq-83mK1Ciw@mail.gmail.com>
 <alpine.BSF.2.21.1801111043140.53831@aneurin.horsfall.org>
Message-ID: <alpine.DEB.2.20.1801120800140.13330@sirius.opentrend.net>

On Thu, 11 Jan 2018, Dave Horsfall wrote:

> No way the big JC could've been born in the middle of winter in that part of 
> the world; try about 4BC (Halley's comet) around Spring in March or so.

Quite right.  I was there in winter and got snowed in for 3 days at a 
kibbutz near Jerusalem.

I'd also like to endorse the Holocene Calendar at this point since it 
results in all events since the development of agriculture having a 
positive date.  Much easier for comparison.

https://en.wikipedia.org/wiki/Holocene_calendar

OnUNIX: Development of UNIX started in 11969HE.  See, perfectly sensible.

Rob


From lars at nocrew.org  Fri Jan 12 18:44:26 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Fri, 12 Jan 2018 08:44:26 +0000
Subject: [TUHS] origin of C header files
Message-ID: <7w1sivv53p.fsf@junk.nocrew.org>

The book "Expert C Programming" claims Alan Snyder suggested the
addition of a preprocessor.


From will.senn at gmail.com  Mon Jan 15 05:56:34 2018
From: will.senn at gmail.com (Will Senn)
Date: Sun, 14 Jan 2018 13:56:34 -0600
Subject: [TUHS] Some resources for V6/PDP/SIMH newbs like me
In-Reply-To: <B376C0C5-55F9-48BC-A082-9527F6DDEA5F@mailbox.org>
References: <e666aa55-3214-464e-18e3-c03348fda057@gmail.com>
 <B376C0C5-55F9-48BC-A082-9527F6DDEA5F@mailbox.org>
Message-ID: <11cf6036-0863-7219-1fbe-84ed824fa0bb@gmail.com>

On 1/9/18 12:05 PM, Wolfgang Helbig wrote:
> Hi, Will
>
> may I point to chapter 1.0 of my operating system lecture notes at:
> http://doc.cat-v.org/unix/v6/operating-systems-lecture-notes/script/
>
> among others, it explains the assembler language, together with the description of the instruction set
>
> http://doc.cat-v.org/unix/v6/operating-systems-lecture-notes/pdp11/doc/cpu
>
> and finally the Unix Assembler Reference Manual(1) at
> http://doc.cat-v.org/unix/v6/operating-systems-lecture-notes/v6/doc/index.html
>
> might help.
>
> Greetings,
> Wolfgang
Wolfgang,

Your notes are great references. When I first started learning about v6, 
yours was the first truly helpful site that I came across. In addition 
to the enormously useful UPM and notes above, I really appreciate your 
PDP 11 devices note:

http://doc.cat-v.org/unix/v6/operating-systems-lecture-notes/pdp11/doc/devs

Later,

Will





From arrigo at alchemistowl.org  Wed Jan 17 20:26:50 2018
From: arrigo at alchemistowl.org (Arrigo Triulzi)
Date: Wed, 17 Jan 2018 11:26:50 +0100
Subject: [TUHS] Scot Hacker's 1999-2001 "BeView" columns for Byte.com (BeOS)
Message-ID: <9AC6DC0A-6494-4B59-BD94-DD24203E6354@alchemistowl.org>

Scot Hacker has re-published his BeOS columns for Byte. BeOS was an interesting operating system with a clear Unix inheritance built for a dual-PowerPC system, similar to the Macs of that era.

http://birdhouse.org/beos/byte/

Its inheritance can be found in Haiku (https://www.haiku-os.org).

Arrigo



From cym224 at gmail.com  Thu Jan 18 04:32:23 2018
From: cym224 at gmail.com (Nemo)
Date: Wed, 17 Jan 2018 13:32:23 -0500
Subject: [TUHS] Scot Hacker's 1999-2001 "BeView" columns for Byte.com
	(BeOS)
In-Reply-To: <9AC6DC0A-6494-4B59-BD94-DD24203E6354@alchemistowl.org>
References: <9AC6DC0A-6494-4B59-BD94-DD24203E6354@alchemistowl.org>
Message-ID: <CAJfiPzycHUUnmWRDgsYRT1y5KqxMcriTG0bU=0x0_ROCwuhipA@mail.gmail.com>

On 17 January 2018 at 05:26, Arrigo Triulzi <arrigo at alchemistowl.org> wrote:
> Scot Hacker has re-published his BeOS columns for Byte. BeOS was an interesting
> operating system with a clear Unix inheritance built for a dual-PowerPC system,
> similar to the Macs of that era.

Not just dual-PPC.  I ran an early copy on my Motorola Apple-clone.

N.

> http://birdhouse.org/beos/byte/
>
> Its inheritance can be found in Haiku (https://www.haiku-os.org).
>
> Arrigo
>


From arrigo at alchemistowl.org  Thu Jan 18 04:54:19 2018
From: arrigo at alchemistowl.org (Arrigo Triulzi)
Date: Wed, 17 Jan 2018 19:54:19 +0100
Subject: [TUHS] Scot Hacker's 1999-2001 "BeView" columns for Byte.com
	(BeOS)
In-Reply-To: <CAJfiPzycHUUnmWRDgsYRT1y5KqxMcriTG0bU=0x0_ROCwuhipA@mail.gmail.com>
References: <9AC6DC0A-6494-4B59-BD94-DD24203E6354@alchemistowl.org>
 <CAJfiPzycHUUnmWRDgsYRT1y5KqxMcriTG0bU=0x0_ROCwuhipA@mail.gmail.com>
Message-ID: <507B30A4-6923-4DA3-A7CE-3E0AEE991791@alchemistowl.org>

On 17 Jan 2018, at 19:32, Nemo <cym224 at gmail.com> wrote:
> 
>> On 17 January 2018 at 05:26, Arrigo Triulzi <arrigo at alchemistowl.org> wrote:
>> Scot Hacker has re-published his BeOS columns for Byte. BeOS was an interesting
>> operating system with a clear Unix inheritance built for a dual-PowerPC system,
>> similar to the Macs of that era.
> 
> Not just dual-PPC.  I ran an early copy on my Motorola Apple-clone.

Should have clarified: the original BeBox was a dual-PPC system. BeOS also ran on PREP and other Mac clones (as did, briefly, MacOS…).

Arrigo 





From dave at horsfall.org  Fri Jan 19 08:44:10 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 19 Jan 2018 09:44:10 +1100 (EST)
Subject: [TUHS] Happy birthday, John Lions!
Message-ID: <alpine.BSF.2.21.1801190920030.74252@aneurin.horsfall.org>

Dr. Prof. John Lions was born on this day in 1937; I had the pleasure of 
having him as one of my Computer Science lecturers in the early 70s, and 
he drilled into us the Principle of Least Astonishment (or POLA), better 
known as "why the fsck did it do that?" (but he was far too genteel to 
express it that way).  And yes, that's my name in the credits; I helped 
with the proof-reading and provided the use of the high-quality printer in 
the CSU.

You are not expected to understand this.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From wkt at tuhs.org  Fri Jan 19 08:50:09 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 19 Jan 2018 08:50:09 +1000
Subject: [TUHS] Happy birthday, John Lions!
In-Reply-To: <alpine.BSF.2.21.1801190920030.74252@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1801190920030.74252@aneurin.horsfall.org>
Message-ID: <9C91DBF6-E535-48A1-8DDF-8AFCF56C23AF@tuhs.org>

I do :-)
   Warren

On 19 January 2018 8:44:10 am AEST, Dave Horsfall <dave at horsfall.org> wrote:
>Dr. Prof. John Lions was born on this day in 1937; I had the pleasure
>of 
>having him as one of my Computer Science lecturers in the early 70s,
>and 
>he drilled into us the Principle of Least Astonishment (or POLA),
>better 
>known as "why the fsck did it do that?" (but he was far too genteel to 
>express it that way).  And yes, that's my name in the credits; I helped
>
>with the proof-reading and provided the use of the high-quality printer
>in 
>the CSU.
>
>You are not expected to understand this.
>
>-- 
>Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
>suffer."

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180119/1f335ae7/attachment.html>

From dave at horsfall.org  Sat Jan 20 09:06:43 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 20 Jan 2018 10:06:43 +1100 (EST)
Subject: [TUHS] RIP Ed Yourdon
Message-ID: <alpine.BSF.2.21.1801201004480.74252@aneurin.horsfall.org>

We lost Ed Yourdon on this day in 2016; a computer pioneer, he helped to 
design the underpinnings of relational databases, and pretty much wrote 
the book.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From cym224 at gmail.com  Sat Jan 20 12:51:58 2018
From: cym224 at gmail.com (Nemo)
Date: Fri, 19 Jan 2018 21:51:58 -0500
Subject: [TUHS] RIP Ed Yourdon
In-Reply-To: <alpine.BSF.2.21.1801201004480.74252@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1801201004480.74252@aneurin.horsfall.org>
Message-ID: <CAJfiPzyZOgnbbDT8t0jmH4Zu1YhhtmHxJKSNTni7nT+gZG8G-A@mail.gmail.com>

On 19/01/2018, Dave Horsfall <dave at horsfall.org> wrote:
> We lost Ed Yourdon on this day in 2016; a computer pioneer, he helped to
> design the underpinnings of relational databases, and pretty much wrote
> the book.

Oh. somehow I missed this sad event.  Last week, I was organising my
library and found his book on YSM.

N.


> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."
>


From imp at bsdimp.com  Sun Jan 21 04:11:24 2018
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 20 Jan 2018 11:11:24 -0700
Subject: [TUHS] Kernel Sizes
Message-ID: <CANCZdfoG5nEBtYefo=W3nOEY4FSoqixRMPh_4JncY=JyPAR8Lw@mail.gmail.com>

For a presentation I'm doing this summer on FreeBSD, I thought it would be
cool to get the kernel sizes for various old flavors of Unix. I see numbers
for v5, v6 and v7 in the tuhs tree view, and it appears these versions are
complete enough for me to extract the kernels themselves. However, I see
nothing prior to that. The archives seem to be somewhat incomplete, but I'm
wondering if people have sizes for earlier versions. Later versions are
more problematic because they move to new hardware, instruction sets, etc.
For this graph to be meaningful, it would need to be pdp-11 only, though
I'm of the opinion more data is better than less. I'll also be extracting
the different V7 commercial kernels: V7M, Ultrix and Venix and the BSD 2.x
releases, but those appear to be intact enough in the archives to extract
data on my own. I've heard rumors there's a SysV for the pdp-11, but I've
not been able to locate images for that. I don't need the actual images,
just sizes with some reference for the source of the data. It's just for
one slide in the talk, so I don't want to burn a ton of time on it...

The larger picture is that I've written what's effectively modprobe for
FreeBSD and will be talking about it in detail. How it's like modprobe, how
it's different, how all the pieces fit together, history of similar
efforts, etc. Part of the driving force here is the bloated FreeBSD GENERIC
kernel.

Of course, I'll share the final report I'm planning on sizes with the group.

Thanks for any data you can provide.

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

From mutiny.mutiny at india.com  Sun Jan 21 04:33:34 2018
From: mutiny.mutiny at india.com (Donald ODona)
Date: Sat, 20 Jan 2018 18:33:34 +0000 (UTC)
Subject: [TUHS] Kernel Sizes
In-Reply-To: <CANCZdfoG5nEBtYefo=W3nOEY4FSoqixRMPh_4JncY=JyPAR8Lw@mail.gmail.com>
References: <CANCZdfoG5nEBtYefo=W3nOEY4FSoqixRMPh_4JncY=JyPAR8Lw@mail.gmail.com>
Message-ID: <778551886.7260.1516473214699.JavaMail.tomcat@india-live-be03>


At 20 Jan 2018 18:12:45 +0000 (+00:00) from Warner Losh <imp at bsdimp.com>:
> For a presentation I'm doing this summer on FreeBSD, I thought it would be

bsd4.3 289792
V7 55876
SysVr3 702832


From random832 at fastmail.com  Sun Jan 21 05:22:27 2018
From: random832 at fastmail.com (Random832)
Date: Sat, 20 Jan 2018 14:22:27 -0500
Subject: [TUHS] Kernel Sizes
In-Reply-To: <CANCZdfoG5nEBtYefo=W3nOEY4FSoqixRMPh_4JncY=JyPAR8Lw@mail.gmail.com>
References: <CANCZdfoG5nEBtYefo=W3nOEY4FSoqixRMPh_4JncY=JyPAR8Lw@mail.gmail.com>
Message-ID: <1516476147.3105555.1242251720.684D327E@webmail.messagingengine.com>

On Sat, Jan 20, 2018, at 13:11, Warner Losh wrote:
> For a presentation I'm doing this summer on FreeBSD, I thought it would be
> cool to get the kernel sizes for various old flavors of Unix. I see numbers
> for v5, v6 and v7 in the tuhs tree view, and it appears these versions are
> complete enough for me to extract the kernels themselves. However, I see
> nothing prior to that.

There is a possibly V2 era kernel (two, actually) on the s1-bits tape image, but it's been too long since I looked at this and I don't recall exactly how to extract them. I posted about this at the time, but there wasn't any interest - I'd determined that s1 was in fact an "init tape" as described in V1 boot.7 and V3 bproc.8. Those manpages do mention the size that was allocated on disk/tape for each kernel in those eras: 6K and 7-8K words [so twice that number of bytes], respectively.

To determine how much headroom was in this allocation, I just now went through and checked the s1-bits file for empty 512-byte blocks. It consists of 25 blocks of data (12800 bytes), followed by 4 blocks of zeros. I think that region of the tape was the bootloaders followed by the "cold boot" kernel. Then there are 22 blocks (11264 bytes) of data [then 10 blocks zeros], which was IIRC the other kernel (the "warm boot" kernel, which did not contain code for reinitializing the filesystem). The rest of the tape (not kernel images) is 490 blocks (245 KB) of data, followed by 27 blocks of 0xFF.


From michael at kjorling.se  Sun Jan 21 07:14:16 2018
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Sat, 20 Jan 2018 21:14:16 +0000
Subject: [TUHS] Kernel Sizes
In-Reply-To: <CANCZdfoG5nEBtYefo=W3nOEY4FSoqixRMPh_4JncY=JyPAR8Lw@mail.gmail.com>
References: <CANCZdfoG5nEBtYefo=W3nOEY4FSoqixRMPh_4JncY=JyPAR8Lw@mail.gmail.com>
Message-ID: <20180120211416.GA13685@h-174-65.A328.priv.bahnhof.se>

On 20 Jan 2018 11:11 -0700, from imp at bsdimp.com (Warner Losh):
> For a presentation I'm doing this summer on FreeBSD, I thought it would be
> cool to get the kernel sizes for various old flavors of Unix. I see numbers
> for v5, v6 and v7 in the tuhs tree view, and it appears these versions are
> complete enough for me to extract the kernels themselves. However, I see
> nothing prior to that. The archives seem to be somewhat incomplete, but I'm
> wondering if people have sizes for earlier versions.

https://github.com/dspinellis/unix-history-repo/tree/Research-V1-Snapshot-Development
looks like it might be useful.

It's possible that Warren might want to add some of that to the TUHS
archives as well.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
  “The most dangerous thought that you can have as a creative person
              is to think you know what you’re doing.” (Bret Victor)


From wkt at tuhs.org  Sun Jan 21 10:19:28 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 21 Jan 2018 10:19:28 +1000
Subject: [TUHS] Kernel Sizes
In-Reply-To: <CANCZdfoG5nEBtYefo=W3nOEY4FSoqixRMPh_4JncY=JyPAR8Lw@mail.gmail.com>
References: <CANCZdfoG5nEBtYefo=W3nOEY4FSoqixRMPh_4JncY=JyPAR8Lw@mail.gmail.com>
Message-ID: <20180121001928.GA6495@minnie.tuhs.org>

On Sat, Jan 20, 2018 at 11:11:24AM -0700, Warner Losh wrote:
>   For a presentation I'm doing this summer on FreeBSD, I thought it would
>   be cool to get the kernel sizes for various old flavors of Unix. I see
>   numbers for v5, v6 and v7 in the tuhs tree view, and it appears these
>   versions are complete enough for me to extract the kernels themselves.
>   However, I see nothing prior to that.

Github has this project: https://github.com/DoctorWkt/unix-jun72
with a June 1972 Unix kernel. Doing a "make", the generated build/unix is:

-rwxrwxrwx 1 wkt wkt 36432 Jan 21 10:10 build/unix

but I don't have a PDP-11 "size" command to give details.

http://www.tuhs.org/Archive/Distributions/Research/Dennis_v3/ has a Unix
system written in C, timestamped August 31, 1973 (just before Fourth Edition).
Inside nsys.tar.gz you will find:

-rw-r--r-- 0/0           26820 1973-09-24 03:41 u

which is the kernel image.

Unfortunately, we don't have a kernel from 1st Edition or 4th Edition.

Cheers, Warren


From akosela at andykosela.com  Sun Jan 21 11:41:45 2018
From: akosela at andykosela.com (Andy Kosela)
Date: Sat, 20 Jan 2018 19:41:45 -0600
Subject: [TUHS] Kernel Sizes
In-Reply-To: <20180121001928.GA6495@minnie.tuhs.org>
References: <CANCZdfoG5nEBtYefo=W3nOEY4FSoqixRMPh_4JncY=JyPAR8Lw@mail.gmail.com>
 <20180121001928.GA6495@minnie.tuhs.org>
Message-ID: <CALMnNGgGRnwN8LSvX30wmjCR8MC4xB1dE9sCfvDposOm8+RMjw@mail.gmail.com>

On Saturday, January 20, 2018, Warren Toomey <wkt at tuhs.org> wrote:

> On Sat, Jan 20, 2018 at 11:11:24AM -0700, Warner Losh wrote:
>
>>   For a presentation I'm doing this summer on FreeBSD, I thought it would
>>   be cool to get the kernel sizes for various old flavors of Unix. I see
>>   numbers for v5, v6 and v7 in the tuhs tree view, and it appears these
>>   versions are complete enough for me to extract the kernels themselves.
>>   However, I see nothing prior to that.
>>
>
> Github has this project: https://github.com/DoctorWkt/unix-jun72
> with a June 1972 Unix kernel. Doing a "make", the generated build/unix is:
>
> -rwxrwxrwx 1 wkt wkt 36432 Jan 21 10:10 build/unix
>
> but I don't have a PDP-11 "size" command to give details.
>
> http://www.tuhs.org/Archive/Distributions/Research/Dennis_v3/ has a Unix
> system written in C, timestamped August 31, 1973 (just before Fourth
> Edition).
> Inside nsys.tar.gz you will find:
>
> -rw-r--r-- 0/0           26820 1973-09-24 03:41 u
>
> which is the kernel image.
>
> Unfortunately, we don't have a kernel from 1st Edition or 4th Edition.
>
>
>
Comparing size of kernels is cool and fun, but IMHO comparing system calls
is a more valuable metric as to measure the kernel bloat.

It would be interesting to compare number of implemented system calls in
various UNIX operating systems along with those kernel sizes, e.g., V7 had
around 50 system calls, current FreeBSD and Linux have more than 500...

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

From gtaylor at tnetconsulting.net  Sun Jan 21 11:51:55 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Sat, 20 Jan 2018 18:51:55 -0700
Subject: [TUHS] OT - Has anyone seen / have a copy of computer lore story
 about a DC consolidation?
Message-ID: <a918ccfe-8228-3181-0aae-11f07e616fc6@spamtrap.tnetconsulting.net>

Sorry for the off topic post.

I'm hoping that someone here might have seen a (what I consider to be) a 
computer lore type story about a contractor that was brought in part way 
through a project to consolidate three DCs into one.  -  In the end he 
managed to do it early and under budget.  The kicker is that they quite 
literally physically moved and re-connected everything the way that it 
was.  Meaning that there were still WAN circuits (local only of course) 
between equipment that was previously in different DCs.

I would like to find a copy of this story and save it in my archive. But 
I've not been able to do so.  Thus I'm asking a wider audience to see if 
anyone might be able to give me a pointer.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180120/23aa37ab/attachment.bin>

From drsalists at gmail.com  Sun Jan 21 12:08:43 2018
From: drsalists at gmail.com (Dan Stromberg)
Date: Sat, 20 Jan 2018 18:08:43 -0800
Subject: [TUHS] Kernel Sizes
In-Reply-To: <CANCZdfoG5nEBtYefo=W3nOEY4FSoqixRMPh_4JncY=JyPAR8Lw@mail.gmail.com>
References: <CANCZdfoG5nEBtYefo=W3nOEY4FSoqixRMPh_4JncY=JyPAR8Lw@mail.gmail.com>
Message-ID: <CAGGBd_pQ13PRPYukD=vTCLu+WCOMQtOiVk5-UGJGY0M+QQN9UA@mail.gmail.com>

On Sat, Jan 20, 2018 at 10:11 AM, Warner Losh <imp at bsdimp.com> wrote:
> For a presentation I'm doing this summer on FreeBSD, I thought it would be
> cool to get the kernel sizes for various old flavors of Unix. I see numbers

You might find http://stromberg.dnsalias.org/~strombrg/working-set/ interesting.

It intentionally fills virtual memory, and measures how much must must
be malloc'd and filled with gibberish, to cause thrashing.

Subtracting that from the amount of physmem in the machine, gives a
sort of measure of OS overhead.


From imp at bsdimp.com  Sun Jan 21 14:24:27 2018
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 20 Jan 2018 21:24:27 -0700
Subject: [TUHS] Kernel Sizes
In-Reply-To: <f70ec6141322d6c52ed849e63b13e00e85ce317d@webmail.yaccman.com>
References: <CAGGBd_pQ13PRPYukD=vTCLu+WCOMQtOiVk5-UGJGY0M+QQN9UA@mail.gmail.com>
 <f70ec6141322d6c52ed849e63b13e00e85ce317d@webmail.yaccman.com>
Message-ID: <CANCZdfrJZveGz5V8UAcewFGi-vOZLy2LYKasoWXBw-BR0tvSPQ@mail.gmail.com>

On Sat, Jan 20, 2018 at 7:13 PM, Steve Johnson <scj at yaccman.com> wrote:

> While you're at it, I heard once that the latest GCC *manual* (>500 pp at
> last look) was larger than "the whole Unix distribution".  Is there any
> truth to that?
>

compressed (gz), the entire v7 tape 3.5MB. The compressed (gz) source is
250k. Uncompressed tape is 11.5MB while the source is 1.1MB.

gcc 7.2.0 compressed (gz) is 105MB. gcc/doc directory is 13.5MB:

% tar tvf gcc-7.2.0.tar.xz gcc-7.2.0/gcc/doc | awk '{a += $5;} END {print
a;}'
13,470,317

So yea, gcc 7.2 manual is larger than the v7 distribution tapes.

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

From scj at yaccman.com  Sun Jan 21 12:13:55 2018
From: scj at yaccman.com (Steve Johnson)
Date: Sat, 20 Jan 2018 18:13:55 -0800
Subject: [TUHS] Kernel Sizes
In-Reply-To: <CAGGBd_pQ13PRPYukD=vTCLu+WCOMQtOiVk5-UGJGY0M+QQN9UA@mail.gmail.com>
Message-ID: <f70ec6141322d6c52ed849e63b13e00e85ce317d@webmail.yaccman.com>

While you're at it, I heard once that the latest GCC *manual* (>500 pp
at last look) was larger than "the whole Unix distribution".  Is
there any truth to that?

Steve

----- Original Message -----
From: "Dan Stromberg" <drsalists at gmail.com>
To:"Warner Losh" <imp at bsdimp.com>
Cc:"The Eunuchs Hysterical Society" <tuhs at tuhs.org>
Sent:Sat, 20 Jan 2018 18:08:43 -0800
Subject:Re: [TUHS] Kernel Sizes

 On Sat, Jan 20, 2018 at 10:11 AM, Warner Losh <imp at bsdimp.com> wrote:
 > For a presentation I'm doing this summer on FreeBSD, I thought it
would be
 > cool to get the kernel sizes for various old flavors of Unix. I see
numbers

 You might find http://stromberg.dnsalias.org/~strombrg/working-set/
interesting.

 It intentionally fills virtual memory, and measures how much must
must
 be malloc'd and filled with gibberish, to cause thrashing.

 Subtracting that from the amount of physmem in the machine, gives a
 sort of measure of OS overhead.

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

From doug at cs.dartmouth.edu  Mon Jan 22 02:51:29 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sun, 21 Jan 2018 11:51:29 -0500
Subject: [TUHS] Subject: Re: KernelSizesA self-imposed limit of 16K held in
 v1, and was quite fullyutilized.Subject:Re:  Kernel Sizes
Message-ID: <201801211651.w0LGpTx4011480@coolidge.cs.Dartmouth.EDU>


A self-imposed limit of 16K held in v1, and was quite fully utilized.
When the iernel was rewritten in C, the limit (perhaps larger by then)
influenced the C compiler. More than one optimization was stimulated
by the need to keep the kernel in bounds.

Doug


From imp at bsdimp.com  Mon Jan 22 05:44:53 2018
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 21 Jan 2018 12:44:53 -0700
Subject: [TUHS] Subject: Re: KernelSizesA self-imposed limit of 16K held
 in v1, and was quite fullyutilized.Subject:Re: Kernel Sizes
In-Reply-To: <201801211651.w0LGpTx4011480@coolidge.cs.Dartmouth.EDU>
References: <201801211651.w0LGpTx4011480@coolidge.cs.Dartmouth.EDU>
Message-ID: <CANCZdfrZ76sfHi4Ps3-shoR4Rv5rN+hwZPBvfKC15LDvfqGFZw@mail.gmail.com>

On Sun, Jan 21, 2018 at 9:51 AM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:

>
> A self-imposed limit of 16K held in v1, and was quite fully utilized.
> When the iernel was rewritten in C, the limit (perhaps larger by then)
> influenced the C compiler. More than one optimization was stimulated
> by the need to keep the kernel in bounds.
>

16k words or 16k bytes? Given some of the other reported sizes I'm guessing
it's bytes.

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

From scj at yaccman.com  Mon Jan 22 06:48:15 2018
From: scj at yaccman.com (Steve Johnson)
Date: Sun, 21 Jan 2018 12:48:15 -0800
Subject: [TUHS] Subject: Re: KernelSizesA self-imposed limit of 16K held
	in v1, and was quite fullyutilized.Subject:Re:  Kernel Sizes
In-Reply-To: <201801211651.w0LGpTx4011480@coolidge.cs.Dartmouth.EDU>
Message-ID: <b882ab42937551a61421354fd51a176d15715082@webmail.yaccman.com>

I seem to remember that at some point early on, we spent some of our
capital budget on buying another 16K bytes for the PDP-11.  As I
recall, the deal was that the OS got 8K and users got 8K.  I also
recall that that purchase was 20% of our capital budget for the
year...

Doug, did I remember this correctly?

Steve

----- Original Message -----
From: "Doug McIlroy" <doug at cs.dartmouth.edu>
To:<tuhs at minnie.tuhs.org>
Cc:
Sent:Sun, 21 Jan 2018 11:51:29 -0500
Subject:[TUHS] Subject: Re: KernelSizesA self-imposed limit of 16K
held in v1, and was quite fullyutilized.Subject:Re: Kernel Sizes

 A self-imposed limit of 16K held in v1, and was quite fully utilized.
 When the iernel was rewritten in C, the limit (perhaps larger by
then)
 influenced the C compiler. More than one optimization was stimulated
 by the need to keep the kernel in bounds.

 Doug

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

From doug at cs.dartmouth.edu  Mon Jan 22 08:03:17 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sun, 21 Jan 2018 17:03:17 -0500
Subject: [TUHS] Kernel Sizes
Message-ID: <201801212203.w0LM3Haq013769@coolidge.cs.Dartmouth.EDU>

>> A self-imposed limit of 16K held in v1

> 16k words or 16k bytes?

Bytes.

doug


From doug at cs.dartmouth.edu  Mon Jan 22 08:36:05 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sun, 21 Jan 2018 17:36:05 -0500
Subject: [TUHS] Kernel Sizes
Message-ID: <201801212236.w0LMa5qG013807@coolidge.cs.Dartmouth.EDU>

> I seem to remember that at some point early on, we spent some of our
> capital budget on buying another 16K bytes for the PDP-11.  As I
> recall, the deal was that the OS got 8K and users got 8K.  I also
> recall that that purchase was 20% of our capital budget for the
> year...

> Doug, did I remember this correctly?

> Steve

Things did happen that way. I don't specifically remember the
numbers, but those you state have the ring of truth.

Memory came in (expensive) 4K increments. When the keepers of
Unix in the Charlotte wire center wanted to add 4K, their
management consented only on the condition that the wizards
in Research would confirm that roposed new functionality
really required it.

doug


From grog at lemis.com  Mon Jan 22 08:53:08 2018
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Mon, 22 Jan 2018 09:53:08 +1100
Subject: [TUHS] Kernel Sizes
In-Reply-To: <CANCZdfrJZveGz5V8UAcewFGi-vOZLy2LYKasoWXBw-BR0tvSPQ@mail.gmail.com>
References: <CAGGBd_pQ13PRPYukD=vTCLu+WCOMQtOiVk5-UGJGY0M+QQN9UA@mail.gmail.com>
 <f70ec6141322d6c52ed849e63b13e00e85ce317d@webmail.yaccman.com>
 <CANCZdfrJZveGz5V8UAcewFGi-vOZLy2LYKasoWXBw-BR0tvSPQ@mail.gmail.com>
Message-ID: <20180121225308.GD14536@eureka.lemis.com>

On Saturday, 20 January 2018 at 21:24:27 -0700, Warner Losh wrote:
> On Sat, Jan 20, 2018 at 7:13 PM, Steve Johnson <scj at yaccman.com> wrote:
>
>> While you're at it, I heard once that the latest GCC *manual* (>500 pp at
>> last look) was larger than "the whole Unix distribution".  Is there any
>> truth to that?
>>
>
> compressed (gz), the entire v7 tape 3.5MB. The compressed (gz) source is
> 250k. Uncompressed tape is 11.5MB while the source is 1.1MB.
>
> gcc 7.2.0 compressed (gz) is 105MB. gcc/doc directory is 13.5MB:
>
>> tar tvf gcc-7.2.0.tar.xz gcc-7.2.0/gcc/doc | awk '{a += $5;} END {print
> a;}'
> 13,470,317
>
> So yea, gcc 7.2 manual is larger than the v7 distribution tapes.

It would be interesting to compare llvm.  Here are the most recent
FreeBSD packages (effectively installation tarballs).  gcc pales by
comparison:

-rw-r--r--  1 root  wheel  90,805,148 23 Sep 15:53 /var/cache/pkg/gcc6-6.4.0_1-13072ceeab.txz
-rw-r--r--  1 root  wheel  90,819,108 30 Sep 15:18 /var/cache/pkg/gcc6-6.4.0_2-d83317c1d0.txz
-rw-r--r--  1 root  wheel  305,101,072 16 Nov 18:30 /var/cache/pkg/llvm40-4.0.1_4-06c71eb2eb.txz
-rw-r--r--  1 root  wheel  341,208,492 19 Dec 17:05 /var/cache/pkg/llvm50-5.0.0_6-b3fff834c7.txz

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180122/fdc292bc/attachment.sig>

From pnr at planet.nl  Mon Jan 22 09:42:53 2018
From: pnr at planet.nl (Paul Ruizendaal)
Date: Mon, 22 Jan 2018 00:42:53 +0100
Subject: [TUHS] Kernel Sizes
In-Reply-To: <mailman.4.1516572202.3873.tuhs@minnie.tuhs.org>
References: <mailman.4.1516572202.3873.tuhs@minnie.tuhs.org>
Message-ID: <39C0AA03-1D57-470E-8D40-58DF7EEC0EFE@planet.nl>


> A self-imposed limit of 16K held in v1, and was quite fully utilized.
> When the iernel was rewritten in C, the limit (perhaps larger by then)
> influenced the C compiler. More than one optimization was stimulated
> by the need to keep the kernel in bounds.
> 
> Doug


The LSX kernel was kept within a self-imposed limit of 16KB as well.

I've often thought that LSX was V5 'regressed' to the concepts of
V1, which was facing similar hardware constraints. Is that a
reasonable view?

For example, LSX has a maximum of three processes that are swapped
in and out in a stack-like fashion. Only one process is ever in core.

Is that how V1 was organized?

I realize that LSX was API compatible with V5/V6 and I don't mean
'regressed' in that sense.

Paul



From usotsuki at buric.co  Mon Jan 22 11:19:08 2018
From: usotsuki at buric.co (Steve Nickolas)
Date: Sun, 21 Jan 2018 20:19:08 -0500 (EST)
Subject: [TUHS] Kernel Sizes
In-Reply-To: <20180121225308.GD14536@eureka.lemis.com>
References: <CAGGBd_pQ13PRPYukD=vTCLu+WCOMQtOiVk5-UGJGY0M+QQN9UA@mail.gmail.com>
 <f70ec6141322d6c52ed849e63b13e00e85ce317d@webmail.yaccman.com>
 <CANCZdfrJZveGz5V8UAcewFGi-vOZLy2LYKasoWXBw-BR0tvSPQ@mail.gmail.com>
 <20180121225308.GD14536@eureka.lemis.com>
Message-ID: <alpine.BSF.2.02.1801212018100.56774@frieza.hoshinet.org>

On Mon, 22 Jan 2018, Greg 'groggy' Lehey wrote:

> On Saturday, 20 January 2018 at 21:24:27 -0700, Warner Losh wrote:
>> On Sat, Jan 20, 2018 at 7:13 PM, Steve Johnson <scj at yaccman.com> wrote:
>>
>>> While you're at it, I heard once that the latest GCC *manual* (>500 pp at
>>> last look) was larger than "the whole Unix distribution".  Is there any
>>> truth to that?
>>>
>>
>> compressed (gz), the entire v7 tape 3.5MB. The compressed (gz) source is
>> 250k. Uncompressed tape is 11.5MB while the source is 1.1MB.
>>
>> gcc 7.2.0 compressed (gz) is 105MB. gcc/doc directory is 13.5MB:
>>
>>> tar tvf gcc-7.2.0.tar.xz gcc-7.2.0/gcc/doc | awk '{a += $5;} END {print
>> a;}'
>> 13,470,317
>>
>> So yea, gcc 7.2 manual is larger than the v7 distribution tapes.
>
> It would be interesting to compare llvm.  Here are the most recent
> FreeBSD packages (effectively installation tarballs).  gcc pales by
> comparison:
>
> -rw-r--r--  1 root  wheel  90,805,148 23 Sep 15:53 /var/cache/pkg/gcc6-6.4.0_1-13072ceeab.txz
> -rw-r--r--  1 root  wheel  90,819,108 30 Sep 15:18 /var/cache/pkg/gcc6-6.4.0_2-d83317c1d0.txz
> -rw-r--r--  1 root  wheel  305,101,072 16 Nov 18:30 /var/cache/pkg/llvm40-4.0.1_4-06c71eb2eb.txz
> -rw-r--r--  1 root  wheel  341,208,492 19 Dec 17:05 /var/cache/pkg/llvm50-5.0.0_6-b3fff834c7.txz

Yikes, and I thought *GNU* sofware was a pig. o.O

-uso.


From imp at bsdimp.com  Mon Jan 22 13:51:01 2018
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 21 Jan 2018 20:51:01 -0700
Subject: [TUHS] Kernel Sizes
In-Reply-To: <20180121001928.GA6495@minnie.tuhs.org>
References: <CANCZdfoG5nEBtYefo=W3nOEY4FSoqixRMPh_4JncY=JyPAR8Lw@mail.gmail.com>
 <20180121001928.GA6495@minnie.tuhs.org>
Message-ID: <CANCZdfqSnZTH8bB-SAxnjUyOEr-r_eZ6Ja+WrXf6Hs2qMqJL7g@mail.gmail.com>

On Sat, Jan 20, 2018 at 5:19 PM, Warren Toomey <wkt at tuhs.org> wrote:

> Unfortunately, we don't have a kernel from 1st Edition or 4th Edition.
>

Do we have v8, v9 or v10 kernels? I looked at the tarballs in the archives
and couldn't find unix, bsd, or kernel in any of them. Is there some name
that's used that I've managed to miss out on?

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

From gtaylor at tnetconsulting.net  Mon Jan 22 14:39:52 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Sun, 21 Jan 2018 21:39:52 -0700
Subject: [TUHS] Kernel Sizes
In-Reply-To: <CANCZdfqSnZTH8bB-SAxnjUyOEr-r_eZ6Ja+WrXf6Hs2qMqJL7g@mail.gmail.com>
References: <CANCZdfoG5nEBtYefo=W3nOEY4FSoqixRMPh_4JncY=JyPAR8Lw@mail.gmail.com>
 <20180121001928.GA6495@minnie.tuhs.org>
 <CANCZdfqSnZTH8bB-SAxnjUyOEr-r_eZ6Ja+WrXf6Hs2qMqJL7g@mail.gmail.com>
Message-ID: <CDD16308-2A9C-464F-8756-EA226389DA07@tnetconsulting.net>

Weren’t these (or their source code) recently released by the IP owner?

Virtually Fun has an article about installing and running v8, including an image.

https://virtuallyfun.com/2017/03/30/research-unix-v8/

I expect you can find more there and the TUHS pages that he references.



-- 
Grant. . . .
unix || die
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180121/97e07b5f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2338 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180121/97e07b5f/attachment.bin>

From imp at bsdimp.com  Mon Jan 22 16:53:13 2018
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 21 Jan 2018 23:53:13 -0700
Subject: [TUHS] Kernel Sizes
In-Reply-To: <CDD16308-2A9C-464F-8756-EA226389DA07@tnetconsulting.net>
References: <CANCZdfoG5nEBtYefo=W3nOEY4FSoqixRMPh_4JncY=JyPAR8Lw@mail.gmail.com>
 <20180121001928.GA6495@minnie.tuhs.org>
 <CANCZdfqSnZTH8bB-SAxnjUyOEr-r_eZ6Ja+WrXf6Hs2qMqJL7g@mail.gmail.com>
 <CDD16308-2A9C-464F-8756-EA226389DA07@tnetconsulting.net>
Message-ID: <CANCZdfoz=2wx4XkxwO3Q80Se=sxtWxfmmN_7p9D5X+OeeG7w1g@mail.gmail.com>

On Jan 21, 2018 9:40 PM, "Grant Taylor via TUHS" <tuhs at minnie.tuhs.org>
wrote:

Weren’t these (or their source code) recently released by the IP owner?

Virtually Fun has an article about installing and running v8, including an
image.

https://virtuallyfun.com/2017/03/30/research-unix-v8/

I expect you can find more there and the TUHS pages that he references.


I've already looked. There is the source but no kernels...

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

From arnold at skeeve.com  Mon Jan 22 18:10:11 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 22 Jan 2018 01:10:11 -0700
Subject: [TUHS] OT: Need help from a *BSD guru
Message-ID: <201801220810.w0M8ABbq002485@freefriends.org>

Hi.

Can a modern BSD guru please contact me off-list?  I have a set of related
tests in the gawk test suite that consistently fail on just about every
*BSD system.  It has me stumped, and I'd like to see these tests working
if possible.

(They've been not working for quite a while. That I get no complaints
from BSD users tells me that gawk isn't popular in that world, but that's
another story. :-)

Thanks,

Arnold


From rudi.j.blom at gmail.com  Mon Jan 22 20:46:33 2018
From: rudi.j.blom at gmail.com (Rudi Blom)
Date: Mon, 22 Jan 2018 17:46:33 +0700
Subject: [TUHS] Kernel Sizes
Message-ID: <CAMYpm87uwmPQkS1AnPKBoFt1FwiUtJGsZ71PjyQreprnjmt-Jw@mail.gmail.com>

16K kernels?

Well, I came late to the UNIX world. I only remember getting a SCO
UNIX 3.2V4.2 kernel onto a single 3-1/2" diskette and still have all I
wanted including (with scripts on a second diskette of course :-) ).
That was 25 years ago.

Mind you, from there I moved to Digital UNIX /vmunix 9,613.712, Tru64
17.930.976 to HP-UX 11iv2  66.161.464 and HP-UX 11iv3 127.929.032

Of course, I also got lots more functionality I'm supposed to want and need :-)

Cheers,
rudi


From doug at cs.dartmouth.edu  Mon Jan 22 22:31:54 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Mon, 22 Jan 2018 07:31:54 -0500
Subject: [TUHS] !mail tuhs@minnie.tuhs.org
Message-ID: <201801221231.w0MCVsjq019507@coolidge.cs.Dartmouth.EDU>

Re: [TUHS] Kernel Sizes

> I've often thought that LSX was V5 'regressed' to the concepts of
> V1, which was facing similar hardware constraints. Is that a
> reasonable view?

> LSX has a maximum of three processes that are swapped
> in and out in a stack-like fashion. Only one process is ever in core.
> Is that how V1 was organized?

The rocess limit was higher in V1. And V1 was a time-sharing
system; for which LIFO swapping is inappropriate. So LSX
seems to have "regressed" to some pre-Unix state.

doug


From arnold at skeeve.com  Tue Jan 23 00:36:05 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 22 Jan 2018 07:36:05 -0700
Subject: [TUHS] OT: Need help from a *BSD guru
In-Reply-To: <201801220810.w0M8ABbq002485@freefriends.org>
References: <201801220810.w0M8ABbq002485@freefriends.org>
Message-ID: <201801221436.w0MEa5Jt005358@freefriends.org>

Hi All.

Looks like I solved my problem on my own; thanks to everyone who
replied privately.  I will send a short note detailing the issue 
a little later.

Thanks!

Arnold

arnold at skeeve.com wrote:

> Hi.
>
> Can a modern BSD guru please contact me off-list?  I have a set of related
> tests in the gawk test suite that consistently fail on just about every
> *BSD system.  It has me stumped, and I'd like to see these tests working
> if possible.
>
> (They've been not working for quite a while. That I get no complaints
> from BSD users tells me that gawk isn't popular in that world, but that's
> another story. :-)
>
> Thanks,
>
> Arnold


From itz at very.loosely.org  Tue Jan 23 04:03:27 2018
From: itz at very.loosely.org (Ian Zimmerman)
Date: Mon, 22 Jan 2018 10:03:27 -0800
Subject: [TUHS] OT: Need help from a *BSD guru
In-Reply-To: <201801221436.w0MEa5Jt005358@freefriends.org>
References: <201801220810.w0M8ABbq002485@freefriends.org>
 <201801221436.w0MEa5Jt005358@freefriends.org>
Message-ID: <20180122180327.njqe3z4f7bwfytln@matica.foolinux.mooo.com>

On 2018-01-22 07:36, arnold at skeeve.com wrote:

> Looks like I solved my problem on my own; thanks to everyone who
> replied privately.  I will send a short note detailing the issue 
> a little later.

Probably an unnecessary reminder, but could you post about it (the
problem and the solution) to the Usenet newsgroup comp.lang.awk as well?
Thanks.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.


From arnold at skeeve.com  Tue Jan 23 05:07:43 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 22 Jan 2018 12:07:43 -0700
Subject: [TUHS] OT: Need help from a *BSD guru
In-Reply-To: <20180122180327.njqe3z4f7bwfytln@matica.foolinux.mooo.com>
References: <201801220810.w0M8ABbq002485@freefriends.org>
 <201801221436.w0MEa5Jt005358@freefriends.org>
 <20180122180327.njqe3z4f7bwfytln@matica.foolinux.mooo.com>
Message-ID: <201801221907.w0MJ7hMb013984@freefriends.org>

Ian Zimmerman <itz at very.loosely.org> wrote:

> On 2018-01-22 07:36, arnold at skeeve.com wrote:
>
> > Looks like I solved my problem on my own; thanks to everyone who
> > replied privately.  I will send a short note detailing the issue 
> > a little later.
>
> Probably an unnecessary reminder, but could you post about it (the
> problem and the solution) to the Usenet newsgroup comp.lang.awk as well?
> Thanks.

It's totally a C issue; it merely came up in the context of gawk.

And I unsubscribed from comp.lang.awk a year or so ago. My blood
pressure has been considerably lower since doing so. :-)

Thanks,

Arnold


From arnold at skeeve.com  Tue Jan 23 05:36:17 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 22 Jan 2018 12:36:17 -0700
Subject: [TUHS] OT: Need help from a *BSD guru
In-Reply-To: <201801221436.w0MEa5Jt005358@freefriends.org>
References: <201801220810.w0M8ABbq002485@freefriends.org>
 <201801221436.w0MEa5Jt005358@freefriends.org>
Message-ID: <201801221936.w0MJaHZe017381@freefriends.org>

The problem had to do with the "inplace" extension for gawk that enables
in-place editing of files, ala perl or GNU sed -i. On BSD systems,
I was getting failures from the test suite. E.g., on a regular system,
inplace1.ok looks like:

-----------------------
before
gawk: inplace:47: warning: inplace_begin: disabling in-place editing for invalid FILENAME `-'
stdin start
is bar replaced?
stdin end
after
-----------------------

On a BSD system, I get:

-----------------------
before
gawk: inplace:47: warning: inplace_begiafter
abling in-place editing for invalid FILENAME `-'
stdin start
is bar replaced?
stdin end
-----------------------

There's some kind of buffering problem going on. The problem only
occurs when stdout and stderr are redirected to the same file:

	command line here > _out 2>&1

I tried adding all kinds of calls to fflush in all kinds of places,
but no luck. Finally, I had an "aha!" moment (an epiphany, if I'm using
the expensive word correctly :-), and made this change:

diff --git a/main.c b/main.c
index 55983789..f505c71f 100644
--- a/main.c
+++ b/main.c
@@ -246,6 +246,10 @@ main(int argc, char **argv)
 	if ((cp = getenv("GAWK_LOCALE_DIR")) != NULL)
 		locale_dir = cp;
 
+	int flags = fcntl(fileno(stderr), F_GETFL, NULL);
+	flags |= O_APPEND;
+	(void) fcntl(fileno(stderr), F_SETFL, flags);
+
 #if defined(LOCALEDEBUG)
 	initial_locale = locale;
 #endif

Forching stderr to be in append mode did the trick. WHY does that
make it work? Beats me. It's not needed on any other system.

Adventures In C Programming ...

Thanks,

Arnold




arnold at skeeve.com wrote:

> Hi All.
>
> Looks like I solved my problem on my own; thanks to everyone who
> replied privately.  I will send a short note detailing the issue 
> a little later.
>
> Thanks!
>
> Arnold


From scj at yaccman.com  Tue Jan 23 14:27:16 2018
From: scj at yaccman.com (Steve Johnson)
Date: Mon, 22 Jan 2018 20:27:16 -0800
Subject: [TUHS] origin of C header files
In-Reply-To: <CABH=_VTdaxXqsoi=YUAwChtY3=5HvPeoX4vxmpOmiTjkiYW0TQ@mail.gmail.com>
Message-ID: <c3bcb691945ad61d9d9c04be089498902c28749d@webmail.yaccman.com>

Well, the problem is not unique to C.   If Python has such a
mechanism it doesn't seem to be used by TensorFlow.   If a TF
operation finds an error, in execution, there is, so far as I know, no
way for the error to refer back to the source Python code, or even the
variable names involved.  You have to say "name=..." for any op for
which you want to know the name -- otherwise, TensorFlow gives them
internal names that, for large designs, can be very hard to decode. 
(Of course, in TensorFlow, most of the heavy lifting is done by C++
called by a Python wrapper, that further "enhances" the debugging
experience)

Steve

----- Original Message -----
From: "Paul Winalski" <paul.winalski at gmail.com>
To:"Steve Johnson" <scj at yaccman.com>
Cc:"Clem Cole" <clemc at ccc.com>, "TUHS main list"
<tuhs at minnie.tuhs.org>
Sent:Fri, 29 Dec 2017 20:52:00 -0500
Subject:Re: [TUHS] origin of C header files

 On 12/29/17, Steve Johnson <scj at yaccman.com> wrote:
 > I begged Dennis for a solution, and he came up with #line,
 > which allowed you to say to the C compiler "treat the next line as
if
 > it were line nnn in file fff, and following lines as successor
lines
 > in file fff. It instantly solved the problem, and was used multiple
 > times for various applications (probably most notably cfront). So
 > far as I know, many languages including FORTRAN, Pascal and Python
do
 > not have such a mechanism, making it awkward to use them as
 > preprocessor targets.

 Language processing systems where the preprocessor functionality is
 implemented as a part of the compiler itself never had the "associate
 the error message with the line in the original source" problem that
 you described. The compiler could keep an internal table mapping the
 lexical output of the preprocessor to the source lines/files that
went
 into the preprocessor phase. Most (all?) of DEC's and IBM's compilers
 operate this way.

 In keeping with UNIX's philosophy of "one image/one purpose", C's
 preprocessor functionality was in a separate image from the compiler
 itself. There are many advantages to this design, including that cpp
 can then be used for other languages than C. But is has the
 disadvantage of introducing the source correlation problem that
 required the introduction of #line.

 -Paul W.

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

From jnc at mercury.lcs.mit.edu  Tue Jan 23 23:04:52 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue, 23 Jan 2018 08:04:52 -0500 (EST)
Subject: [TUHS] Swapping (Was:  !mail tuhs@minnie.tuhs.org)
Message-ID: <20180123130452.257FE18C096@mercury.lcs.mit.edu>

    > From: Doug McIlroy

    >> From: Paul Ruizendaal 

    >> LSX has a maximum of three processes that are swapped in and out in a
    >> stack-like fashion. Only one process is ever in core.

I'm having a hard time working out how this works. If process A is swapped
out, and then B, B has to be swapped in before A can be? But only one process
is ever in core at a time? To get A in, B has to be moved out? But then B
would be the last one out, and would have to come in before A?

Anyway, I don't understand why the OS could/would care which order processes
we swapped in - unless it's something like the 'onion skin' memory allocation
algorithm of CTSS (which also had only a single process resident at a time,
IIRC), where, when a small process had to be swapped in, and a large one was
already in, it only swapped out enough of the large one to make room for the
small one. The process could recurse, hence the name.

    > V1 was a time-sharing system; for which LIFO swapping is
    > inappropriate.

And I don't follow that either...

V1 ran on the 11/20 without memory management hardware, though, right?
(Although there's that cryptic reference to the KS11 in "Odd Comments and
Strange Doings in Unix", although I've never been able to find out anything
else about the KS11.) So presumably one would not have wanted more than one
process resident at a time, as that decreases the odds of a buggy program
trashing another process?

	 Noel



From dave at horsfall.org  Wed Jan 24 08:33:00 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 24 Jan 2018 09:33:00 +1100 (EST)
Subject: [TUHS] RIP Marvin Minsky
Message-ID: <alpine.BSF.2.21.1801240920410.74252@aneurin.horsfall.org>

We lost AI pioneer Marvin Minsky on this day in 2016 from a cerebral 
haemorrhage, aged 88.  Amongst other things, along with John McCarthy he 
co-founded the MIT AI Lab, co-invented the Logo "turtle", was mentioned in 
Arthur C. Clarke's novel "2001: A Space Odyssey", and built the first 
randomly wired neural network learning machine, SNARC, in 1951.

He is now thought to be cryogenically preserved as "Patient 144" at Alcor 
(he started cooling on 27/1/2016).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From pnr at planet.nl  Fri Jan 26 04:20:25 2018
From: pnr at planet.nl (Paul Ruizendaal)
Date: Thu, 25 Jan 2018 19:20:25 +0100
Subject: [TUHS] LSX swapping
Message-ID: <B17A9337-A82A-4CFD-87AD-8EF7D647231F@planet.nl>


>>> LSX has a maximum of three processes that are swapped in and out in a
>>> stack-like fashion. Only one process is ever in core.
> 
> I'm having a hard time working out how this works. If process A is swapped
> out, and then B, B has to be swapped in before A can be? But only one process
> is ever in core at a time? To get A in, B has to be moved out? But then B
> would be the last one out, and would have to come in before A?
> 
> Anyway, I don't understand why the OS could/would care which order processes
> we swapped in - unless it's something like the 'onion skin' memory allocation
> algorithm of CTSS (which also had only a single process resident at a time,
> IIRC), where, when a small process had to be swapped in, and a large one was
> already in, it only swapped out enough of the large one to make room for the
> small one. The process could recurse, hence the name.

The LSI-11 had 40KB of core. The lower 16KB held the LSX kernel, the upper 24K was
for the active process.

LSX has 3 process slots and 2 swap slots (on floppy!). Optionally, LSX could
be built with an additional background process ("BGOPTION"), but this does
not work very well. Process numbers and swap slots have a 1:1 relationship.

There is a global variable, cpid, with the process number of the current
process, initially zero. Upon boot, LSX will load a shell as process 0.
(There is no swapper process and no init in LSX).

The original LSI-11 kernel code is here:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=LSX/sys
I can refer to source lines in the repository for my TI990 port of it:
https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/b6ec9496e23efe8c

When a process forks, it writes the current core image out to the
corresponding swap slot (this swaps out the parent) and the core image
is repurposed as the new process (i.e. cpid is incremented and the
proc table filled in):
https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/3617ec3245c40a69?ln=156,159

The child now runs and the parent remains suspended until the child completes.
Yes, this implies no pipes. The shell is modified to emulate pipes with files.

When the child completes, it stores its u area / exit code in its swap slot
(as it is running, the swap slot must be empty. Process 3 has a small swap slot
just for this). Next LSX decreases cpid and the parent process is reloaded from
its swap slot:
https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/b9c07dfc5add9fc5?ln=239,247

The actual swapping happens here:
https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/b6ec9496e23efe8c?ln=335,368
The original PDP11 source has code to compress the empty space between _end and the
stack pointer, which I did not get to work properly.

LSX works well enough to run the standard V6 binaries unmodified. Some need to be
tweaked (e.g. table space in cpp) and the shell needed the pipe change. It can run
the V6 c compiler, but not with a wild card argument: that requires 4 stacked processes
(sh, glob, cc and cpp/c0/..) and LSX allows only 3.

Hope the above makes it a bit more clear.



From jnc at mercury.lcs.mit.edu  Fri Jan 26 04:42:59 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu, 25 Jan 2018 13:42:59 -0500 (EST)
Subject: [TUHS] V6 UNIX main() oddness
Message-ID: <20180125184259.8B62518C0B0@mercury.lcs.mit.edu>

So, while bringing up V6 on a hardware PDP-11/23 with an RK11 emulator using
an SD card for storage which Dave Bridgham and I are doing, I found this piece
of code in main() on V6 Unix:

	rootdir = iget(rootdev, ROOTINO);
	rootdir->i_flag =& ~ILOCK;
	u.u_cdir = iget(rootdev, ROOTINO);
	u.u_cdir->i_flag =& ~ILOCK;

I don't get why two separate calls to iget(), with the same arguments;
why not replace the second pair of lines with:

	u.u_cdir = rootdir;
	rootdir->i_count++;

What am I missing?

	Noel


From ron at ronnatalie.com  Fri Jan 26 05:36:15 2018
From: ron at ronnatalie.com (Ron Natalie)
Date: Thu, 25 Jan 2018 14:36:15 -0500
Subject: [TUHS] V6 UNIX main() oddness
In-Reply-To: <20180125184259.8B62518C0B0@mercury.lcs.mit.edu>
References: <20180125184259.8B62518C0B0@mercury.lcs.mit.edu>
Message-ID: <033501d39613$c3f86fa0$4be94ee0$@ronnatalie.com>

I don't see any reason why you can't make that optimization at that point.
Nothing is going to come in and suddenly invalidate the inode between those
two lines.
I suspect it was an example of cut/paste-it is from some other part of the
kernel.

-----Original Message-----
From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Noel Chiappa
Sent: Thursday, January 25, 2018 1:43 PM
To: tuhs at minnie.tuhs.org
Cc: jnc at mercury.lcs.mit.edu
Subject: [TUHS] V6 UNIX main() oddness

So, while bringing up V6 on a hardware PDP-11/23 with an RK11 emulator using
an SD card for storage which Dave Bridgham and I are doing, I found this
piece of code in main() on V6 Unix:

	rootdir = iget(rootdev, ROOTINO);
	rootdir->i_flag =& ~ILOCK;
	u.u_cdir = iget(rootdev, ROOTINO);
	u.u_cdir->i_flag =& ~ILOCK;

I don't get why two separate calls to iget(), with the same arguments; why
not replace the second pair of lines with:

	u.u_cdir = rootdir;
	rootdir->i_count++;

What am I missing?

	Noel



From clemc at ccc.com  Fri Jan 26 05:41:16 2018
From: clemc at ccc.com (Clem Cole)
Date: Thu, 25 Jan 2018 14:41:16 -0500
Subject: [TUHS] V6 UNIX main() oddness
In-Reply-To: <20180125184259.8B62518C0B0@mercury.lcs.mit.edu>
References: <20180125184259.8B62518C0B0@mercury.lcs.mit.edu>
Message-ID: <CAC20D2MRr9ZcrLt4f6NddUUjCURqgdEygnxNAsr=QUM_Z2m29Q@mail.gmail.com>

Seems reasonable to me give the code path and time its being called.  Maybe
left over from hacking from an earlier kernel requirement and never noticed
by Ken.  I wonder if the mount table had been set up in some earlier scheme
and he wanted to make sure it was checked first.  That's the only thing
that seems logical, but we all miss optimizations.
ᐧ

On Thu, Jan 25, 2018 at 1:42 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

> So, while bringing up V6 on a hardware PDP-11/23 with an RK11 emulator
> using
> an SD card for storage which Dave Bridgham and I are doing, I found this
> piece
> of code in main() on V6 Unix:
>
>         rootdir = iget(rootdev, ROOTINO);
>         rootdir->i_flag =& ~ILOCK;
>         u.u_cdir = iget(rootdev, ROOTINO);
>         u.u_cdir->i_flag =& ~ILOCK;
>
> I don't get why two separate calls to iget(), with the same arguments;
> why not replace the second pair of lines with:
>
>         u.u_cdir = rootdir;
>         rootdir->i_count++;
>
> What am I missing?
>
>         Noel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180125/745fbeda/attachment.html>

From dave at horsfall.org  Tue Jan 30 06:03:43 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 30 Jan 2018 07:03:43 +1100 (EST)
Subject: [TUHS] Happy birthday, Douglas Engelbart!
Message-ID: <alpine.BSF.2.21.1801300700210.7787@aneurin.horsfall.org>

Born on this day in 1925, he was a pioneer in human/computer interaction, 
and invented the mouse; it wasn't exactly ergonomic, being just a square 
box with a button.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From peter at rulingia.com  Tue Jan 30 07:03:36 2018
From: peter at rulingia.com (Peter Jeremy)
Date: Tue, 30 Jan 2018 08:03:36 +1100
Subject: [TUHS] Happy birthday, Douglas Engelbart!
In-Reply-To: <alpine.BSF.2.21.1801300700210.7787@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1801300700210.7787@aneurin.horsfall.org>
Message-ID: <20180129210336.GJ75633@server.rulingia.com>

On 2018-Jan-30 07:03:43 +1100, Dave Horsfall <dave at horsfall.org> wrote:
>Born on this day in 1925, he was a pioneer in human/computer interaction, 
>and invented the mouse; it wasn't exactly ergonomic, being just a square 
>box with a button.

For anyone who hasn't seen it, https://www.youtube.com/watch?v=yJDv-zdhzMY
("The Mother of All Demos") is well worth watching even after nearly 50 years.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180130/b5f932f9/attachment.sig>

From pnr at planet.nl  Tue Jan 30 20:28:09 2018
From: pnr at planet.nl (Paul Ruizendaal)
Date: Tue, 30 Jan 2018 11:28:09 +0100
Subject: [TUHS] Calgary buffer modifications
Message-ID: <D2E297C4-EB1D-4A5F-876B-160AF8F3ABB7@planet.nl>


For a while I had been wondering about the origins of a modification to the V6 kernel that places the kernel buffers in a separately mapped area, freeing up space for other things. It is used in some of the early networking code, i.e. both the UoI code and the V6 BBN code (as available on the TUHS Unix Tree).

I came across the following reference in https://www.osti.gov/scitech/servlets/purl/12130675:

“One widely distributed (though undocumented) solution to this hardware limit on the model 40 was a version of Unix by Robert Sidebotham, Faculty of Environmental Design, University of Calgary. His solution was to move the I/O buffers out of kernel space.”

This would explain the modifications being bracketed with "#ifdef UCBUFMOD”.

Some questions for the old hands:

- Was this patch indeed widely known / distributed?

- Widely distributed is not the same as widely used: was it?




From clemc at ccc.com  Wed Jan 31 00:18:37 2018
From: clemc at ccc.com (Clem Cole)
Date: Tue, 30 Jan 2018 09:18:37 -0500
Subject: [TUHS] Calgary buffer modifications
In-Reply-To: <D2E297C4-EB1D-4A5F-876B-160AF8F3ABB7@planet.nl>
References: <D2E297C4-EB1D-4A5F-876B-160AF8F3ABB7@planet.nl>
Message-ID: <CAC20D2PX5hd5NJzzM8mt1RnahquxSFC6BRs=EU91wLKWU8GLVQ@mail.gmail.com>

On Tue, Jan 30, 2018 at 5:28 AM, Paul Ruizendaal <pnr at planet.nl> wrote:

>
> For a while I had been wondering about the origins of a modification to
> the V6 kernel that places the kernel buffers in a separately mapped area,
> freeing up space for other things. It is used in some of the early
> networking code, i.e. both the UoI code and the V6 BBN code (as available
> on the TUHS Unix Tree).
>
> I came across the following reference in https://www.osti.gov/scitech/
> servlets/purl/12130675:
>
> “One widely distributed (though undocumented) solution to this hardware
> limit on the model 40 was a version of Unix by Robert Sidebotham, Faculty
> of Environmental Design, University of Calgary. His solution was to move
> the I/O buffers out of kernel space.”
>
> This would explain the modifications being bracketed with "#ifdef
> UCBUFMOD”.
>
> Some questions for the old hands:
>
> - Was this patch indeed widely known / distributed?
>
​Hmm - a little like the halting problem I fear - how can you tell?

I can say we knew about them because Gosling brought them to CMU when he
was a grad student; but by that time, we had started to switched to Unix/TS
and Seventh edition that Ted had brought from BTL.   As I recall, it was
more hacking/surgery then I personally wanted to do in the EE 11/34 based
systems.  I don't think they got added to the SUS or IUS @ CS which were
the other heavy 11/40 machines at the time.




>
> - Widely distributed is not the same as widely used: was it?
>
​Not that I remember, but others of course may remember otherwise.

I think many of us knew that Calgary (and Toronto to an extent) was a hot
bed of Unix hacking because of Gosling, but the places outside the US that
were probably having the most effect on the community at the time were in
OZ and the UK.  ​


​Remember Net.noise had not really started as UUCP was part Seventh Edition
so the news systems are in the future.  Also the ArpaNet was limited in
reach, and not that many UNIX sites were apart (it was mostly PDP-10s).
Thus, unless someone came to a USENIX and talked about something, or a
student somehow switch schools (like to be a grad student) folks did not
know about the changes.​   For instance, I knew a little about what was
going on at MIT and UMICH because of friends that left CMU and went to
there or vise versa; and I would bring CMU things to UCB etc...

Clem


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

From dave at horsfall.org  Wed Jan 31 09:42:42 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 31 Jan 2018 10:42:42 +1100 (EST)
Subject: [TUHS] Calgary buffer modifications
In-Reply-To: <D2E297C4-EB1D-4A5F-876B-160AF8F3ABB7@planet.nl>
References: <D2E297C4-EB1D-4A5F-876B-160AF8F3ABB7@planet.nl>
Message-ID: <alpine.BSF.2.21.1801311037520.7787@aneurin.horsfall.org>

On Tue, 30 Jan 2018, Paul Ruizendaal wrote:

> “One widely distributed (though undocumented) solution to this hardware 
> limit on the model 40 was a version of Unix by Robert Sidebotham, 
> Faculty of Environmental Design, University of Calgary. His solution was 
> to move the I/O buffers out of kernel space.”

I wonder if that inspired the AUSAM buffer management?  The current buffer 
header was "b" (like "u") which got mapped by KISA5.

For the first time I was able to avoid our 11/40 deadlocking; I can't 
remember all the devices that were on it, but there were a *lot* 
(including the printer driver etc which used the buffer pool, not the 
character queue).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

From kevin.bowling at kev009.com  Wed Jan 31 18:39:25 2018
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Wed, 31 Jan 2018 01:39:25 -0700
Subject: [TUHS] Dynamics between BSD and Linux
Message-ID: <CAK7dMtDeHNZ+at_htwLZngEDzEZ+OAYZDDz5V545VmaPdTAncA@mail.gmail.com>

Hi,

Interested in some perspective here since the list has influential Linux
people like Ted Tso.

Linux has been described as influenced by Minix and System V.  The Minix
connection is well discussed.  The SysV connection something something
Linus had access to a spec manual.  But I’d guess reality would be more
gradual — new contributors that liked CSRG BSD would have mostly gravitated
to the continuations in 386/BSDi/Net/Free that were concurrent to early and
formative Linux development.. so there’d be an implicit vacuum of BSD
people for Linux development.

What I am curious about is the continuing ignorance of BSD ideas.  Linux
isn’t exactly insular; a lot of critical people and components came much
later on from other SysV flavors (lvm, jfs, xfs, RCU)

The kinds of BSD things I am talking about are ufs, kqueue, jails, pf,
Capsicum.  Linux has grown alternatives, but with sometimes willful
ignorance of other technology. It seems clear epoll was not a good design
from the start.  Despite jails not being taken to the logical conclusion of
modern containers like zones, the architecture is fundamentally closer
aligned to how people want to securely use containers versus namespaces and
cgroups. And Google ported Capscicum to Linux but it’s basically been
ignored in lieu of nebulous concepts like seccomp.  And then there seems to
be outright hostility toward other platforms from the postmodern generation
with things like systemd.

This seems strange to me as BSD people are generally open to other /ideas/,
we have to be careful with Linux code due to license incompatibility, but
the converse is does not seem true either in interest in other ideas or
license hampering code flow.

The history of UNIX is spectacularly successful because different groups
got together at the table and agreeed on the ideas.  Is there room for that
in the modern era where Linux is the monopoly OS?  The Austin Group is
still a thing but it’s not clear people in any of the Freenix communities
really care about evolving the standards.  I get that, but not so much
completely burrying ones head in the sand to what other OSes are doing.  Is
there any future for UNIX as an “open system” in this climate or are people
going to go there separate ways?

Regards,
Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180131/7c5cd178/attachment.html>

