From rodrigosloop at gmail.com  Thu Aug  1 02:49:29 2019
From: rodrigosloop at gmail.com (=?UTF-8?Q?Rodrigo_G=2E_L=C3=B3pez?=)
Date: Wed, 31 Jul 2019 18:49:29 +0200
Subject: [TUHS] Who's behind the UNIX filesystem permission
 implementation
In-Reply-To: <CAJV3Z_-JVU2Nn1nhrXOKHWQOni3ZWhRsPiAn_mQ7oH5hMnWumA@mail.gmail.com>
References: <CAJV3Z_-JVU2Nn1nhrXOKHWQOni3ZWhRsPiAn_mQ7oH5hMnWumA@mail.gmail.com>
Message-ID: <CA+cCjXrWok5DR61hA0xKEodMfVyCUgNmsksTCjS6u6Aikf-0pw@mail.gmail.com>

Multics had modes per file (https://multicians.org/fjcc4.html) but i don't
know about the origins. the simpler approach of owner/group/other is a
purely Unix creation and i would bet Ken Thompson is behind it all.

i would love to know more.


-rodri

On Wed, Jul 31, 2019, 12:00 PM Stephan Han. <xenonelive at gmail.com> wrote:

> Hello Unix enthusiasts.
>
> I'd like to know who or the group of people behind implementing this
> filesystem permission system.
> Since we are using this system for nearly 40 years and it addresses all
> the aspects of the permission matter without any hustle.
> I'm inspired to know who/how came up with this theory?
> Also if it derived from somewhere else or If there's an origin story about
> this, it would be worth to share.
>
> Cheers.
> Stephan
>
> --
> No When
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190731/a6ba874f/attachment.html>

From toby at telegraphics.com.au  Thu Aug  1 03:00:21 2019
From: toby at telegraphics.com.au (Toby Thain)
Date: Wed, 31 Jul 2019 13:00:21 -0400
Subject: [TUHS] Who's behind the UNIX filesystem permission
 implementation
In-Reply-To: <CAJV3Z_-JVU2Nn1nhrXOKHWQOni3ZWhRsPiAn_mQ7oH5hMnWumA@mail.gmail.com>
References: <CAJV3Z_-JVU2Nn1nhrXOKHWQOni3ZWhRsPiAn_mQ7oH5hMnWumA@mail.gmail.com>
Message-ID: <e28d95ae-5696-7479-d967-1b754aaa56b0@telegraphics.com.au>

On 2019-07-31 5:59 a.m., Stephan Han. wrote:
> Hello Unix enthusiasts.
> 
> I'd like to know who or the group of people behind implementing this
> filesystem permission system.
> Since we are using this system for nearly 40 years and it addresses all
> the aspects of the permission matter without any hustle.

It may not address "all aspects" since it has been necessary for some
purposes to extend the permission model substantially over time, such as
ACLs, SELinux, etc.

--Toby


> I'm inspired to know who/how came up with this theory?
> Also if it derived from somewhere else or If there's an origin story
> about this, it would be worth to share.
> 
> Cheers.
> Stephan
> 
> -- 
> No When


From imp at bsdimp.com  Thu Aug  1 03:18:08 2019
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 31 Jul 2019 12:18:08 -0500
Subject: [TUHS] Who's behind the UNIX filesystem permission
 implementation
In-Reply-To: <e28d95ae-5696-7479-d967-1b754aaa56b0@telegraphics.com.au>
References: <CAJV3Z_-JVU2Nn1nhrXOKHWQOni3ZWhRsPiAn_mQ7oH5hMnWumA@mail.gmail.com>
 <e28d95ae-5696-7479-d967-1b754aaa56b0@telegraphics.com.au>
Message-ID: <CANCZdfoF08SaZX4-693cOXHT0JK=48iza-YPcHHPF-tU_pfR1A@mail.gmail.com>

On Wed, Jul 31, 2019, 12:09 PM Toby Thain <toby at telegraphics.com.au> wrote:

> On 2019-07-31 5:59 a.m., Stephan Han. wrote:
> > Hello Unix enthusiasts.
> >
> > I'd like to know who or the group of people behind implementing this
> > filesystem permission system.
> > Since we are using this system for nearly 40 years and it addresses all
> > the aspects of the permission matter without any hustle.
>
> It may not address "all aspects" since it has been necessary for some
> purposes to extend the permission model substantially over time, such as
> ACLs, SELinux, etc.
>

He did say they solved the problem without hassle. All those other things
introduced hassle.  :) There is also all the various capacity frameworks to
self limit what you are allowed to do as any easy to administer exploits...

Warner

--Toby
>
>
> > I'm inspired to know who/how came up with this theory?
> > Also if it derived from somewhere else or If there's an origin story
> > about this, it would be worth to share.
> >
> > Cheers.
> > Stephan
> >
> > --
> > No When
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190731/1538246c/attachment.html>

From krewat at kilonet.net  Thu Aug  1 03:29:16 2019
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 31 Jul 2019 13:29:16 -0400
Subject: [TUHS] Who's behind the UNIX filesystem permission
 implementation
In-Reply-To: <CA+cCjXrWok5DR61hA0xKEodMfVyCUgNmsksTCjS6u6Aikf-0pw@mail.gmail.com>
References: <CAJV3Z_-JVU2Nn1nhrXOKHWQOni3ZWhRsPiAn_mQ7oH5hMnWumA@mail.gmail.com>
 <CA+cCjXrWok5DR61hA0xKEodMfVyCUgNmsksTCjS6u6Aikf-0pw@mail.gmail.com>
Message-ID: <e3bcb400-8405-cc0f-7d2c-eb7019215e08@kilonet.net>

On 7/31/2019 12:49 PM, Rodrigo G. López wrote:
> Multics had modes per file (https://multicians.org/fjcc4.html) but i 
> don't know about the origins. the simpler approach of 
> owner/group/other is a purely Unix creation and i would bet Ken 
> Thompson is behind it all.

TOPS-10 had a 3 octal digit file protection code:

<xxx> - <Owner, Project, Everyone else> - Logins are PPNs - [Project, 
Programmer] - So if I was [76,5], another user with [76,10] was in the 
same project. Much like UNIX groups.

Owner Protection Codes
7*, 6* - You can execute, read, or change the protection code of the file.
5* - You have unlimited access to the file, except for renaming it.
4* - You have unlimited access to the file.
3 - You can execute, read, or change the protection code of the file.
2 - You have unlimited access to the file, except for renaming it.
1, 0 - You have unlimited access.
* The File Daemon is called on a protection failure on this file (my 
memory is a little fuzzy on this, but I believe it allowed finer grained 
protections).

Protection Codes for Fields 2 and 3
7 - The user cannot access the file.
6 - The user can only execute the file.
5 - The user can execute or read the file.
4 - The user can execute, read, or append to the file.
3 - The user can execute, read, append to, or update the file.
2 - The user can execute, read, append to, update, and write to the file.
1 - The user can execute, read, append to, update, write to, and rename 
the file.
0 - Unlimited access, including changing the protection code of the file.

The name TOPS-10 was first used in 1970, but the monitor itself dates 
back to 1964. I'm not sure when these protection codes came into being, 
though.

From clemc at ccc.com  Thu Aug  1 03:58:40 2019
From: clemc at ccc.com (Clem Cole)
Date: Wed, 31 Jul 2019 13:58:40 -0400
Subject: [TUHS] Who's behind the UNIX filesystem permission
 implementation
In-Reply-To: <e3bcb400-8405-cc0f-7d2c-eb7019215e08@kilonet.net>
References: <CAJV3Z_-JVU2Nn1nhrXOKHWQOni3ZWhRsPiAn_mQ7oH5hMnWumA@mail.gmail.com>
 <CA+cCjXrWok5DR61hA0xKEodMfVyCUgNmsksTCjS6u6Aikf-0pw@mail.gmail.com>
 <e3bcb400-8405-cc0f-7d2c-eb7019215e08@kilonet.net>
Message-ID: <CAC20D2NtVy4suup4J63Y9THJ49LCoVrPxiGh=1dM7uASf9gqFg@mail.gmail.com>

FWIW: Before TOPS, there was MIT's CTSS.   The DEC Project, Programmer
Number (a.k.a. PPN) idea seems to have been similar to the People and *Problem
Number* idea of CTSS, which allowed for directories of your own files and
as well as your group (shared problem number). As Rodrigo pointed out
Multics also had a form of ACLs (UNIX used ACL's just very simplified ones).

So I'm not sure where to pin this specific idea.  I think it was a bit like
a lot of CS ideas, different people were playing with different aspects of
different ideas at the time, and brillance of Ken and Dennis was putting
some of the *best ideas *of the day *together* and adding a few of their
own into a simple implementation that was good enough to do real work.

Clem


On Wed, Jul 31, 2019 at 1:29 PM Arthur Krewat <krewat at kilonet.net> wrote:

> On 7/31/2019 12:49 PM, Rodrigo G. López wrote:
> > Multics had modes per file (https://multicians.org/fjcc4.html) but i
> > don't know about the origins. the simpler approach of
> > owner/group/other is a purely Unix creation and i would bet Ken
> > Thompson is behind it all.
>
> TOPS-10 had a 3 octal digit file protection code:
>
> <xxx> - <Owner, Project, Everyone else> - Logins are PPNs - [Project,
> Programmer] - So if I was [76,5], another user with [76,10] was in the
> same project. Much like UNIX groups.
>
> Owner Protection Codes
> 7*, 6* - You can execute, read, or change the protection code of the file.
> 5* - You have unlimited access to the file, except for renaming it.
> 4* - You have unlimited access to the file.
> 3 - You can execute, read, or change the protection code of the file.
> 2 - You have unlimited access to the file, except for renaming it.
> 1, 0 - You have unlimited access.
> * The File Daemon is called on a protection failure on this file (my
> memory is a little fuzzy on this, but I believe it allowed finer grained
> protections).
>
> Protection Codes for Fields 2 and 3
> 7 - The user cannot access the file.
> 6 - The user can only execute the file.
> 5 - The user can execute or read the file.
> 4 - The user can execute, read, or append to the file.
> 3 - The user can execute, read, append to, or update the file.
> 2 - The user can execute, read, append to, update, and write to the file.
> 1 - The user can execute, read, append to, update, write to, and rename
> the file.
> 0 - Unlimited access, including changing the protection code of the file.
>
> The name TOPS-10 was first used in 1970, but the monitor itself dates
> back to 1964. I'm not sure when these protection codes came into being,
> though.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190731/80c79c13/attachment.html>

From cbbrowne at gmail.com  Thu Aug  1 04:03:33 2019
From: cbbrowne at gmail.com (Christopher Browne)
Date: Wed, 31 Jul 2019 14:03:33 -0400
Subject: [TUHS] Who's behind the UNIX filesystem permission
 implementation
In-Reply-To: <e3bcb400-8405-cc0f-7d2c-eb7019215e08@kilonet.net>
References: <CAJV3Z_-JVU2Nn1nhrXOKHWQOni3ZWhRsPiAn_mQ7oH5hMnWumA@mail.gmail.com>
 <CA+cCjXrWok5DR61hA0xKEodMfVyCUgNmsksTCjS6u6Aikf-0pw@mail.gmail.com>
 <e3bcb400-8405-cc0f-7d2c-eb7019215e08@kilonet.net>
Message-ID: <CAFNqd5VXmgzSvy=-dfioE94HxjU74SnU8eUcdVtuHOX-Vz2Wyw@mail.gmail.com>

On Wed, 31 Jul 2019 at 13:29, Arthur Krewat <krewat at kilonet.net> wrote:

> On 7/31/2019 12:49 PM, Rodrigo G. López wrote:
> > Multics had modes per file (https://multicians.org/fjcc4.html) but i
> > don't know about the origins. the simpler approach of
> > owner/group/other is a purely Unix creation and i would bet Ken
> > Thompson is behind it all.
>
> TOPS-10 had a 3 octal digit file protection code:
>
> <xxx> - <Owner, Project, Everyone else> - Logins are PPNs - [Project,
> Programmer] - So if I was [76,5], another user with [76,10] was in the
> same project. Much like UNIX groups.
>
> Owner Protection Codes
> 7*, 6* - You can execute, read, or change the protection code of the file.
> 5* - You have unlimited access to the file, except for renaming it.
> 4* - You have unlimited access to the file.
> 3 - You can execute, read, or change the protection code of the file.
> 2 - You have unlimited access to the file, except for renaming it.
> 1, 0 - You have unlimited access.
> * The File Daemon is called on a protection failure on this file (my
> memory is a little fuzzy on this, but I believe it allowed finer grained
> protections).
>
> Protection Codes for Fields 2 and 3
> 7 - The user cannot access the file.
> 6 - The user can only execute the file.
> 5 - The user can execute or read the file.
> 4 - The user can execute, read, or append to the file.
> 3 - The user can execute, read, append to, or update the file.
> 2 - The user can execute, read, append to, update, and write to the file.
> 1 - The user can execute, read, append to, update, write to, and rename
> the file.
> 0 - Unlimited access, including changing the protection code of the file.
>
> The name TOPS-10 was first used in 1970, but the monitor itself dates
> back to 1964. I'm not sure when these protection codes came into being,
> though.
>

Interesting; similar, though not identical to some material I captured back
in the 1990s on TOPS-10 FILDAE in a discussion about Linux filesystem
permission semantics...

It seemed interesting, so I added it to a web page:
linuxfinances.info/info/fs.html

The claim is that there would be a fildae control file like the following:
# anything in a directory named "private" is off limits
*/private/*:*:*:*:
# people in group "foo" get full (create, delete, read, write,
# execute) access to everything in the foo project directory
~/projects/foo/*:*:foo:*:cdrwx
# people playing mygame can update the high score file
~/mygame/score.dat:*:*:
~/mygame/bin/mygame:rw
# some friends have access to the RCS files for mygame
~/mygame/src/RCS/*:dennis,kevin,josh:*:
/usr/bin/ci:rw
~/mygame/src/RCS/*:dennis,kevin,josh:*:
/usr/bin/co:rw
# I'll put stuff I want everyone to read in my ~/public directory
# I'll make the public directory 744, so no one will actually have
# to check .access_list, but I'll still put in this entry for
completeness
~/public/*:*:*:*:r# anything left over gets no access*:*:*:*:
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190731/eb471ca8/attachment.html>

From gtaylor at tnetconsulting.net  Thu Aug  1 04:46:02 2019
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 31 Jul 2019 12:46:02 -0600
Subject: [TUHS] Who's behind the UNIX filesystem permission
 implementation
In-Reply-To: <e28d95ae-5696-7479-d967-1b754aaa56b0@telegraphics.com.au>
References: <CAJV3Z_-JVU2Nn1nhrXOKHWQOni3ZWhRsPiAn_mQ7oH5hMnWumA@mail.gmail.com>
 <e28d95ae-5696-7479-d967-1b754aaa56b0@telegraphics.com.au>
Message-ID: <b08a5508-0fc7-3a02-772c-405717c152f1@spamtrap.tnetconsulting.net>

On 7/31/19 11:00 AM, Toby Thain wrote:
> It may not address "all aspects" since it has been necessary for some 
> purposes to extend the permission model substantially over time, such 
> as ACLs, SELinux, etc.

I thought that ACLs acted as additional gates / restriction points 
beyond what standard Unix file system permissions allowed.  Meaning that
ACLs couldn't /add/ permission, but they could /remove/ permission.

I think SELinux behaves similarly.  It blocks (removes) existing 
permissions.  Beyond that, I think SELinux is filtering (removing) 
permissions when comparing what (who) is running combined with what is 
being run further combined with what it is being run against.  So again, 
removing existing permissions.

The only thing that I'm aware of that actually /adds/ permissions is the 
capability subsystem.  It can give an unprivileged user the ability to 
run a binary that can bind to a port below 1024.



-- 
Grant. . . .
unix || die

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

From clemc at ccc.com  Thu Aug  1 05:01:30 2019
From: clemc at ccc.com (Clem Cole)
Date: Wed, 31 Jul 2019 15:01:30 -0400
Subject: [TUHS] Who's behind the UNIX filesystem permission
 implementation
In-Reply-To: <b08a5508-0fc7-3a02-772c-405717c152f1@spamtrap.tnetconsulting.net>
References: <CAJV3Z_-JVU2Nn1nhrXOKHWQOni3ZWhRsPiAn_mQ7oH5hMnWumA@mail.gmail.com>
 <e28d95ae-5696-7479-d967-1b754aaa56b0@telegraphics.com.au>
 <b08a5508-0fc7-3a02-772c-405717c152f1@spamtrap.tnetconsulting.net>
Message-ID: <CAC20D2PCQDrMWPAA8pRsFOEpH_L_yCE9Kd=4q7pFTBh+eN84+g@mail.gmail.com>

On Wed, Jul 31, 2019 at 2:46 PM Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
wrote:

> I thought that ACLs acted as additional gates / restriction points
> beyond what standard Unix file system permissions allowed.
>
It's really how strict you want to be in the definition of an ACL.   UNIX
uses the same basic/simple model but traditional UNIX style ACLs of 3
options of 3 modes are implemented are just more coarsely defined than say
VMS or later NT or SELinux, uses for their file systems.   It's arguable
that the extra granularity of the others actually adds a great deal in
actual day to day use cases.

At one time, I will admit that I had thought VMS style ACLs might be more
helpful to UNIX and we added them to one of our file systems, but when I
look back on 40 years of using anything beyond UNIX style ACLs its been
pretty rare when I actually needed much more (*i.e.* theory vs. practice).

The problem is the programming interface tends to get more difficult when
you add some of the extra features.   To me the brilliance to UNIX has
always been getting down to a very simple interface that was "good enough"
to get the *job done* and not so full of *extra stuff *that it gets in the
way (which tends to be a complaint by way with Linux -- which does have a
lot of new/rich features, but so full of some many different features
theses days you have to wonder is/was it worth it).

To me, it's arguable that ACL's beyond R/W/E and U/G/E is really needed in
practice.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190731/8adfb843/attachment.html>

From ben at cogs.com  Thu Aug  1 05:34:44 2019
From: ben at cogs.com (Ben Greenfield)
Date: Wed, 31 Jul 2019 15:34:44 -0400
Subject: [TUHS] Who's behind the UNIX filesystem permission
 implementation
In-Reply-To: <b08a5508-0fc7-3a02-772c-405717c152f1@spamtrap.tnetconsulting.net>
References: <CAJV3Z_-JVU2Nn1nhrXOKHWQOni3ZWhRsPiAn_mQ7oH5hMnWumA@mail.gmail.com>
 <e28d95ae-5696-7479-d967-1b754aaa56b0@telegraphics.com.au>
 <b08a5508-0fc7-3a02-772c-405717c152f1@spamtrap.tnetconsulting.net>
Message-ID: <22C0158A-6731-4CA4-BC5A-3CDD3F76F4F9@cogs.com>

In the Sun System Administration class you got to bring a system up from nothing which included mucking with inodes. I believe I was taught that Sun implemented ACLS by assigning to inodes to a file. The first inode was assigned the unix permissions and the second inode was assigned the acls permissions and there was some backend mechanism that kept both inodes referring to a single file.

It was a week long class and I found it the best unix experience. I all machine and no users:)

Ben


> On Jul 31, 2019, at 2:46 PM, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
> 
> On 7/31/19 11:00 AM, Toby Thain wrote:
>> It may not address "all aspects" since it has been necessary for some purposes to extend the permission model substantially over time, such as ACLs, SELinux, etc.
> 
> I thought that ACLs acted as additional gates / restriction points beyond what standard Unix file system permissions allowed.  Meaning that
> ACLs couldn't /add/ permission, but they could /remove/ permission.
> 
> I think SELinux behaves similarly.  It blocks (removes) existing permissions.  Beyond that, I think SELinux is filtering (removing) permissions when comparing what (who) is running combined with what is being run further combined with what it is being run against.  So again, removing existing permissions.
> 
> The only thing that I'm aware of that actually /adds/ permissions is the capability subsystem.  It can give an unprivileged user the ability to run a binary that can bind to a port below 1024.
> 
> 
> 
> -- 
> Grant. . . .
> unix || die
> 


From krewat at kilonet.net  Thu Aug  1 06:16:25 2019
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 31 Jul 2019 16:16:25 -0400
Subject: [TUHS] Who's behind the UNIX filesystem permission
 implementation
In-Reply-To: <e3bcb400-8405-cc0f-7d2c-eb7019215e08@kilonet.net>
References: <CAJV3Z_-JVU2Nn1nhrXOKHWQOni3ZWhRsPiAn_mQ7oH5hMnWumA@mail.gmail.com>
 <CA+cCjXrWok5DR61hA0xKEodMfVyCUgNmsksTCjS6u6Aikf-0pw@mail.gmail.com>
 <e3bcb400-8405-cc0f-7d2c-eb7019215e08@kilonet.net>
Message-ID: <6d2955e3-c77b-fbd0-6e9e-bcdf3a58d45e@kilonet.net>

Sorry to reply to myself, but I wanted to add one note to this, and 
didn't, which pertains to the "rename" versus "update" part of file 
protections in TOPS-10, and perhaps was a bug that was never fixed, or 
it was, and I didn't know it.

In TOPS-10, you use the monitor call ENTER to update (write to) an 
existing file. It uses a common argument list with LOOKUP and I think a 
few other calls, that include the file name and extension. If a file had 
a 4 protection code for you, you could LOOKUP the file, then ENTER it 
with a different filename, and the filename would change, effectively 
renaming the file which you would think required a 1 protection code. 
You could also, if I recall correctly, specify a different protection.

The significance of this? Many installations put files in SYS: ([1,4]) 
that had a 4 protection code so they could be written to by various 
applications users ran, or it was an oversight by a system 
administrator. Using DDT, one could easily whip up a short piece of code 
to rename any file in SYS: that had a 4 protection code, rename it to a 
.SAV or .SHR (if it needed a highseg) and basically "hide" behind 
another program, such as LOGIN.EXE (When EXE was introduced, I think in 
version 6, TOPS-10 still supported .SAV, .SHR, and .HGH but would 
attempt to run the .EXE first if you didn't specify an extension).

Certain programs in SYS: like LOGIN had JACCT privileges - full rights 
to everything, including device I/O. So, find a writable file in SYS:, 
rename it to LOGIN.SAV, copy PIP over it, or something you cobbled up 
yourself, and take over the system without causing any other issues 
except that missing writable file.

JACCT priv was much like "setuid" in UNIX - except it was a hardcoded 
list of filenames in the monitor (I think mostly or exclusively in SYS:) 
that would get carte blanche access to everything. I believe by version 
7, some programs had been deprecated out of SYS, but they still existed 
in the JACCT list in the monitor.

And boy, there were a lot of systems out there on Telenet or the ARPANET 
that had files in SYS: protected with a 4. Side note: Telenet was BBN's 
attempt to create a private sector ARPANET. 
https://en.wikipedia.org/wiki/Telenet - A late night dumpster dive at 
Radio Shack in the very early 80's got me a local dialin number.

Sorry for the lengthy dissertation :)

On 7/31/2019 1:29 PM, Arthur Krewat wrote:
> TOPS-10 had a 3 octal digit file protection code:
>
> <xxx> - <Owner, Project, Everyone else> - Logins are PPNs - [Project, 
> Programmer] - So if I was [76,5], another user with [76,10] was in the 
> same project. Much like UNIX groups.
>
> Owner Protection Codes
> 7*, 6* - You can execute, read, or change the protection code of the 
> file.
> 5* - You have unlimited access to the file, except for renaming it.
> 4* - You have unlimited access to the file.
> 3 - You can execute, read, or change the protection code of the file.
> 2 - You have unlimited access to the file, except for renaming it.
> 1, 0 - You have unlimited access.
> * The File Daemon is called on a protection failure on this file (my 
> memory is a little fuzzy on this, but I believe it allowed finer 
> grained protections).
>
> Protection Codes for Fields 2 and 3
> 7 - The user cannot access the file.
> 6 - The user can only execute the file.
> 5 - The user can execute or read the file.
> 4 - The user can execute, read, or append to the file.
> 3 - The user can execute, read, append to, or update the file.
> 2 - The user can execute, read, append to, update, and write to the file.
> 1 - The user can execute, read, append to, update, write to, and 
> rename the file.
> 0 - Unlimited access, including changing the protection code of the file.
>
> The name TOPS-10 was first used in 1970, but the monitor itself dates 
> back to 1964. I'm not sure when these protection codes came into 
> being, though.
>


From wlc at jctaylor.com  Thu Aug  1 08:24:11 2019
From: wlc at jctaylor.com (William Corcoran)
Date: Wed, 31 Jul 2019 22:24:11 +0000
Subject: [TUHS] Who's behind the UNIX filesystem permission
 implementation
In-Reply-To: <CANCZdfoF08SaZX4-693cOXHT0JK=48iza-YPcHHPF-tU_pfR1A@mail.gmail.com>
References: <CAJV3Z_-JVU2Nn1nhrXOKHWQOni3ZWhRsPiAn_mQ7oH5hMnWumA@mail.gmail.com>
 <e28d95ae-5696-7479-d967-1b754aaa56b0@telegraphics.com.au>,
 <CANCZdfoF08SaZX4-693cOXHT0JK=48iza-YPcHHPF-tU_pfR1A@mail.gmail.com>
Message-ID: <91450743-C517-4F04-9E0A-DA3CDA2234D0@jctaylor.com>

No filesystem permission discussion would be complete without mentioning United States Patent US 4135240.

Set user ID!
setuid
setgid

(Hmmmm, I believe there is an Et al. missing after the inventors name, Dennis Ritchie, on the face of this patent, right?)

Bill Corcoran



On Jul 31, 2019, at 1:18 PM, Warner Losh <imp at bsdimp.com<mailto:imp at bsdimp.com>> wrote:



On Wed, Jul 31, 2019, 12:09 PM Toby Thain <toby at telegraphics.com.au<mailto:toby at telegraphics.com.au>> wrote:
On 2019-07-31 5:59 a.m., Stephan Han. wrote:
> Hello Unix enthusiasts.
>
> I'd like to know who or the group of people behind implementing this
> filesystem permission system.
> Since we are using this system for nearly 40 years and it addresses all
> the aspects of the permission matter without any hustle.

It may not address "all aspects" since it has been necessary for some
purposes to extend the permission model substantially over time, such as
ACLs, SELinux, etc.

He did say they solved the problem without hassle. All those other things introduced hassle.  :) There is also all the various capacity frameworks to self limit what you are allowed to do as any easy to administer exploits...

Warner

--Toby


> I'm inspired to know who/how came up with this theory?
> Also if it derived from somewhere else or If there's an origin story
> about this, it would be worth to share.
>
> Cheers.
> Stephan
>
> --
> No When

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

From ggm at algebras.org  Thu Aug  1 08:49:09 2019
From: ggm at algebras.org (George Michaelson)
Date: Thu, 1 Aug 2019 08:49:09 +1000
Subject: [TUHS] Who's behind the UNIX filesystem permission
 implementation
In-Reply-To: <91450743-C517-4F04-9E0A-DA3CDA2234D0@jctaylor.com>
References: <CAJV3Z_-JVU2Nn1nhrXOKHWQOni3ZWhRsPiAn_mQ7oH5hMnWumA@mail.gmail.com>
 <e28d95ae-5696-7479-d967-1b754aaa56b0@telegraphics.com.au>
 <CANCZdfoF08SaZX4-693cOXHT0JK=48iza-YPcHHPF-tU_pfR1A@mail.gmail.com>
 <91450743-C517-4F04-9E0A-DA3CDA2234D0@jctaylor.com>
Message-ID: <CAKr6gn19=thho5OU6+tRZfFWdiBPAHNEA5LdD+X7ZpKBd2GErA@mail.gmail.com>

The "useful layer of indirection" story carries the seeds of its own
problem, if you consider xattr on files. They always prove harder to
deal with, lie in cat -v extended options, cannot be invoked without
bigger wetware cache memory than I hold, which requires a retreat to
the man page, and crop up at the worst possible times, such as when
you are doing buildworld installworld sequences, they blow up, and you
have xattr locked files with setuid bit littering the FS tree. chmod
can't do them with octal bit settings or they lie in octal spaces I
don't understand further up from 777

Necessary but evil.

What I like about user/group/other is that the group memberships list
is independent, but maps into the tested space in the flags for chmod.
If I want to grant somebody permission in group sense, I make sure we
share a group and I arrange for the group to be set. If I cannot make
the dir be group the same, I use --x permissions on other to give them
transitive rights down into the file.

It would be possible to argue creat(e) was a distinct permission from
write. I think I heard Dennis say he regretted some aspects of the
model around "is write the same as create" at an AUUG once, (I mean
more than just his joke about calling it creat() not create() -he
actually said there were arguments both sides to breaking out more
modes of behaviour on things, and modifying the contents of a created
named entity is not the same as naming it) And Microslop and xattr and
I think VMS do indeed go to the "I can make things as well as change
things" place. So yes, write permissions on the directory are the
"proper" place to say "you can make things" but then you're in an
indirection: the dir block is not the file, the file name is in the
dir block, oh dear, so maybe we mean we want Apples resource fork and
the data fork, a model I could never understand? No please.. but..
then again.. Oh dear. Its just a projection into a UNIX FS to make
this a file and a .attr file, thats not how Apple "Ideated" it, but
still.

All designs come with costs. I guess if you like apple pie, you can
dream about peaches, but peaches aren't apples.

On Thu, Aug 1, 2019 at 8:36 AM William Corcoran <wlc at jctaylor.com> wrote:
>
> No filesystem permission discussion would be complete without mentioning United States Patent US 4135240.
>
> Set user ID!
> setuid
> setgid
>
> (Hmmmm, I believe there is an Et al. missing after the inventors name, Dennis Ritchie, on the face of this patent, right?)
>
> Bill Corcoran
>
>
>
> On Jul 31, 2019, at 1:18 PM, Warner Losh <imp at bsdimp.com> wrote:
>
>
>
> On Wed, Jul 31, 2019, 12:09 PM Toby Thain <toby at telegraphics.com.au> wrote:
>>
>> On 2019-07-31 5:59 a.m., Stephan Han. wrote:
>> > Hello Unix enthusiasts.
>> >
>> > I'd like to know who or the group of people behind implementing this
>> > filesystem permission system.
>> > Since we are using this system for nearly 40 years and it addresses all
>> > the aspects of the permission matter without any hustle.
>>
>> It may not address "all aspects" since it has been necessary for some
>> purposes to extend the permission model substantially over time, such as
>> ACLs, SELinux, etc.
>
>
> He did say they solved the problem without hassle. All those other things introduced hassle.  :) There is also all the various capacity frameworks to self limit what you are allowed to do as any easy to administer exploits...
>
> Warner
>
>> --Toby
>>
>>
>> > I'm inspired to know who/how came up with this theory?
>> > Also if it derived from somewhere else or If there's an origin story
>> > about this, it would be worth to share.
>> >
>> > Cheers.
>> > Stephan
>> >
>> > --
>> > No When
>>

From doug at cs.dartmouth.edu  Thu Aug  1 22:35:25 2019
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Thu, 01 Aug 2019 08:35:25 -0400
Subject: [TUHS] Who's behind the UNIX filesystem permission
Message-ID: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU>

Read and write permission were common ideas--even part of
the Atlas paging hardware that was described before 1960.
The original concept of time-sharing was to give a virtual
computer to each user. When it became clear that sharing
was an equally important aspect, owner/other permissions
arose. I believe that was the case with Multics.

Owner/other permissions were in PDP-11 Unix from the start.
Group permissions arose from the ferment of daily talk in
the Unix lab. How might the usual protections be extended
to collaborative projects? Ken and Dennis deserve credit
for the final implementation. Yet clean as the idea of groups
was, it has been used only sporadically (in my experience).

Execute permission (much overloaded in Unix) also dates
back to the dawn of paging. One Unix innovation, due to
Dennis, was the suid bit--the only patented feature in
the Research system. It was instantly adopted for 
maintaining the Moo (a game now sold under the name
"Master Mind") league standings table.

One trouble with full-blown ACLs as required by NSA's
Orange Book, is obscurity. It is hard (possibly NP-
complete) to analyze the actual security of an ACL
configuration.

A common failing of Unix administration was a proliferation
of suid-root programs, e.g. mail(1). I recall one system
that had a hundred such programs. Sudo provided a way
station between suid and ACLs.

Doug

From jpl.jpl at gmail.com  Fri Aug  2 02:22:35 2019
From: jpl.jpl at gmail.com (John P. Linderman)
Date: Thu, 1 Aug 2019 12:22:35 -0400
Subject: [TUHS] Who's behind the UNIX filesystem permission
In-Reply-To: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU>
References: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU>
Message-ID: <CAC0cEp8oZ6kYXZGrwSVKM64MdkKCEMnkwu_62k9z+bne9x-Gaw@mail.gmail.com>

*Yet clean as the idea of groups was, it has been used only sporadically
(in my experience).*


As I recall it, the original "basic groups" were essentially "us" and
"them". "Us" was everyone in the "in crowd", "them" was everyone else.
Since the basic groups were rather extensive, it was prudent to turn group
write permission off in your default umask. But that made groups rather
clunky. You were in only one group at a time, so you had to "chgrp" to a
select group, and then remember to set your umask to allow group write
permission so others in the group could modify files. This changed when you
could be in multiple groups at the same time (a BSD invention?), and your
primary group automatically changed to the group owning your current
working directory (iff you belonged to that group). This made it
unnecessary to do an explicit chgrp in most cases. Having group write
permission off in your default umask was now a nuisance. We fixed that by
giving everyone an unshared primary group id, typically the same as the
uid. It then became safe to make group write permission on by default. This
made groups much more useful. Anyone in a group (but only those members)
could create a directory owned by that group, and group members working in
that directory defaulted to creating files (and subdirectories) group-owned
by and writable by all the members of the group. It just worked.

On Thu, Aug 1, 2019 at 8:36 AM Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> Read and write permission were common ideas--even part of
> the Atlas paging hardware that was described before 1960.
> The original concept of time-sharing was to give a virtual
> computer to each user. When it became clear that sharing
> was an equally important aspect, owner/other permissions
> arose. I believe that was the case with Multics.
>
> Owner/other permissions were in PDP-11 Unix from the start.
> Group permissions arose from the ferment of daily talk in
> the Unix lab. How might the usual protections be extended
> to collaborative projects? Ken and Dennis deserve credit
> for the final implementation. Yet clean as the idea of groups
> was, it has been used only sporadically (in my experience).
>
> Execute permission (much overloaded in Unix) also dates
> back to the dawn of paging. One Unix innovation, due to
> Dennis, was the suid bit--the only patented feature in
> the Research system. It was instantly adopted for
> maintaining the Moo (a game now sold under the name
> "Master Mind") league standings table.
>
> One trouble with full-blown ACLs as required by NSA's
> Orange Book, is obscurity. It is hard (possibly NP-
> complete) to analyze the actual security of an ACL
> configuration.
>
> A common failing of Unix administration was a proliferation
> of suid-root programs, e.g. mail(1). I recall one system
> that had a hundred such programs. Sudo provided a way
> station between suid and ACLs.
>
> Doug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190801/8906c76e/attachment.html>

From krewat at kilonet.net  Fri Aug  2 02:35:29 2019
From: krewat at kilonet.net (Arthur Krewat)
Date: Thu, 1 Aug 2019 12:35:29 -0400
Subject: [TUHS] Who's behind the UNIX filesystem permission
In-Reply-To: <CAC0cEp8oZ6kYXZGrwSVKM64MdkKCEMnkwu_62k9z+bne9x-Gaw@mail.gmail.com>
References: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU>
 <CAC0cEp8oZ6kYXZGrwSVKM64MdkKCEMnkwu_62k9z+bne9x-Gaw@mail.gmail.com>
Message-ID: <6bdbf145-7bd3-971b-0ced-3ad1cae8b33d@kilonet.net>

There's also the setgid bit on directories, that when files are created, 
they will be in the group that the parent directory has on it.

Also, I don't think it's been mentioned, but there's the setuid bit on 
directories - otherwise known as the sticky bit. When set, even if you 
have rights to "write" the directory (meaning, delete files), you can't 
delete those owned by other users. Useful for /tmp

I have no idea what the timeline is for either of these features :)


On 8/1/2019 12:22 PM, John P. Linderman wrote:
>
>     *Yet clean as the idea of groups was, it has been used only
>     sporadically (in my experience).*
>
>
> As I recall it, the original "basic groups" were essentially "us" and 
> "them". "Us" was everyone in the "in crowd", "them" was everyone else. 
> Since the basic groups were rather extensive, it was prudent to turn 
> group write permission off in your default umask. But that made groups 
> rather clunky. You were in only one group at a time, so you had to 
> "chgrp" to a select group, and then remember to set your umask to 
> allow group write permission so others in the group could modify 
> files. This changed when you could be in multiple groups at the same 
> time (a BSD invention?), and your primary group automatically changed 
> to the group owning your current working directory (iff you belonged 
> to that group). This made it unnecessary to do an explicit chgrp in 
> most cases. Having group write permission off in your default umask 
> was now a nuisance. We fixed that by giving everyone an unshared 
> primary group id, typically the same as the uid. It then became safe 
> to make group write permission on by default. This made groups much 
> more useful. Anyone in a group (but only those members) could create a 
> directory owned by that group, and group members working in that 
> directory defaulted to creating files (and subdirectories) group-owned 
> by and writable by all the members of the group. It just worked.
>

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

From cym224 at gmail.com  Fri Aug  2 03:01:46 2019
From: cym224 at gmail.com (Nemo Nusquam)
Date: Thu, 1 Aug 2019 13:01:46 -0400
Subject: [TUHS] Who's behind the UNIX filesystem permission
In-Reply-To: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU>
References: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU>
Message-ID: <fa72de67-9eb6-81b5-f8c1-d337e40d8854@gmail.com>

On 08/01/19 08:35, Doug McIlroy wrote (in part):
> Yet clean as the idea of groups
> was, it has been used only sporadically (in my experience).
Interesting... we used groups extensively (qa, staging, dev, research, 
release, ...) but never ACLs.

N.

From krewat at kilonet.net  Fri Aug  2 04:26:37 2019
From: krewat at kilonet.net (Arthur Krewat)
Date: Thu, 1 Aug 2019 14:26:37 -0400
Subject: [TUHS] Who's behind the UNIX filesystem permission
In-Reply-To: <fa72de67-9eb6-81b5-f8c1-d337e40d8854@gmail.com>
References: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU>
 <fa72de67-9eb6-81b5-f8c1-d337e40d8854@gmail.com>
Message-ID: <f90648ac-4781-5631-4955-f44575594f87@kilonet.net>

On 8/1/2019 1:01 PM, Nemo Nusquam wrote:
> On 08/01/19 08:35, Doug McIlroy wrote (in part):
>> Yet clean as the idea of groups
>> was, it has been used only sporadically (in my experience).
> Interesting... we used groups extensively (qa, staging, dev, research, 
> release, ...) but never ACLs.

I've had occasion to use groups extensively in various places I've 
consulted. Defense Contractors, educational institutions, etc. That, and 
quotas.

I've used Solaris ZFS ACLs, and Linux ACLs to solve many problems. 
There's always an exception to the UNIX rule when it comes to 
owner/group/world, and trying to corral users into that paradigm is not 
always fruitful.

Although, in one case, a common storage area with both the setgid and 
setuid bit on the parent, and various Engineering departments writing 
files and directories to it, was a really cool solution to a problem 
although it used secondary groups as well.

art k.


From lyndon at orthanc.ca  Fri Aug  2 06:14:07 2019
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Thu, 01 Aug 2019 13:14:07 -0700
Subject: [TUHS] Who's behind the UNIX filesystem permission
In-Reply-To: <f90648ac-4781-5631-4955-f44575594f87@kilonet.net>
References: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU>
 <fa72de67-9eb6-81b5-f8c1-d337e40d8854@gmail.com>
 <f90648ac-4781-5631-4955-f44575594f87@kilonet.net>
Message-ID: <40c91f7f89cb3ea5@orthanc.ca>

Two things killed off the adoption of groups as a widely-deployed
ACL mechanism:

1) NFS, specifically its limits on the number of supplimentary groups
   the protocol supported,

2) Kernel limits on the number of supplimentary groups associated with
   a process (e.g. NGROUPS_MAX)

--lyndon

From dave at horsfall.org  Fri Aug  2 07:23:25 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 2 Aug 2019 07:23:25 +1000 (EST)
Subject: [TUHS] Who's behind the UNIX filesystem permission
In-Reply-To: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU>
References: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU>
Message-ID: <alpine.BSF.2.21.9999.1908020714480.38830@aneurin.horsfall.org>

On Thu, 1 Aug 2019, Doug McIlroy wrote:

> A common failing of Unix administration was a proliferation of suid-root 
> programs, e.g. mail(1). I recall one system that had a hundred such 
> programs. Sudo provided a way station between suid and ACLs.

I've always maintained that if you think you need setuid root (which is a 
gaping chest wound), you can invariably get away with setgid instead.

ObTrivia: Back in the 80s, some third-party software needed to be 
installed under "root".  I was suspicious, but I had little choice but to 
allow it (manager's orders; that company went under shortly after I left 
them).  Eventually I discovered why, when I had to clean up the mess: it 
actually *unlinked* directories; yes, you read that right...

-- Dave

From jnc at mercury.lcs.mit.edu  Fri Aug  2 09:43:51 2019
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu,  1 Aug 2019 19:43:51 -0400 (EDT)
Subject: [TUHS] Who's behind the UNIX filesystem permission
Message-ID: <20190801234351.04A9118C0A1@mercury.lcs.mit.edu>

    > From: Dave Horsfall

    > it actually *unlinked* directories

Maybe the application was written by a LISP programmer? :-)

(Not really, of course; it was probably just someone who didn't know much
about Unix. They had a list of system calls, and 'unlink' probably said ' only
works on directories when the caller is root', so...)

Speaking of LISP and GC, it's impressive how GC is not really a big issue any
more. At one point people were even building special CPUs that had hardware
support for GC; now it seems to be a 'solved problem' on ordinary CPUs.

	Noel

From davida at pobox.com  Fri Aug  2 11:03:34 2019
From: davida at pobox.com (David Arnold)
Date: Fri, 2 Aug 2019 11:03:34 +1000
Subject: [TUHS] Who's behind the UNIX filesystem permission
In-Reply-To: <20190801234351.04A9118C0A1@mercury.lcs.mit.edu>
References: <20190801234351.04A9118C0A1@mercury.lcs.mit.edu>
Message-ID: <A7F61221-47D0-4A21-82FC-F0201F085990@pobox.com>

On 2 Aug 2019, at 09:43, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:

> Speaking of LISP and GC, it's impressive how GC is not really a big issue any
> more. At one point people were even building special CPUs that had hardware
> support for GC; now it seems to be a 'solved problem' on ordinary CPUs.

I think it’s mostly a side effect of modern hardware speeds. For applications that care about latency (and especially latency jitter) it’s still an issue. 

For example, writing low latency trading software in Java requires some fairly silly hoop-jumping to avoid triggering a collection pass.

These apps genuinely care about nanoseconds, but the tooling ecosystem and development time advantages of Java seem to entice a decent number of people to embark on the work-arounds. 

In most areas though you’re absolutely right — it’s a non-issue now. 



d

From robpike at gmail.com  Fri Aug  2 14:36:47 2019
From: robpike at gmail.com (Rob Pike)
Date: Fri, 2 Aug 2019 14:36:47 +1000
Subject: [TUHS] Who's behind the UNIX filesystem permission
In-Reply-To: <A7F61221-47D0-4A21-82FC-F0201F085990@pobox.com>
References: <20190801234351.04A9118C0A1@mercury.lcs.mit.edu>
 <A7F61221-47D0-4A21-82FC-F0201F085990@pobox.com>
Message-ID: <CAKzdPgxNjCEdEOu4b06AKLfzLB0GLphu71M8g=XFRpjRSz7yhw@mail.gmail.com>

In Go we "just" dedicate a core to GC, problem solved. The arrival of
universal multi-CPU hardware made than option. Some tremendous technical
work required (for which I take zero credit; see
https://blog.golang.org/ismmkeynote) but yeah.

-rob


On Fri, Aug 2, 2019 at 11:11 AM David Arnold <davida at pobox.com> wrote:

> On 2 Aug 2019, at 09:43, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>
> > Speaking of LISP and GC, it's impressive how GC is not really a big
> issue any
> > more. At one point people were even building special CPUs that had
> hardware
> > support for GC; now it seems to be a 'solved problem' on ordinary CPUs.
>
> I think it’s mostly a side effect of modern hardware speeds. For
> applications that care about latency (and especially latency jitter) it’s
> still an issue.
>
> For example, writing low latency trading software in Java requires some
> fairly silly hoop-jumping to avoid triggering a collection pass.
>
> These apps genuinely care about nanoseconds, but the tooling ecosystem and
> development time advantages of Java seem to entice a decent number of
> people to embark on the work-arounds.
>
> In most areas though you’re absolutely right — it’s a non-issue now.
>
>
>
> d
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190802/4b123ed4/attachment.html>

From arnold at skeeve.com  Fri Aug  2 18:35:30 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Fri, 02 Aug 2019 02:35:30 -0600
Subject: [TUHS] Additional groups and additional directory permissions
In-Reply-To: <CAC0cEp8oZ6kYXZGrwSVKM64MdkKCEMnkwu_62k9z+bne9x-Gaw@mail.gmail.com>
References: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU>
 <CAC0cEp8oZ6kYXZGrwSVKM64MdkKCEMnkwu_62k9z+bne9x-Gaw@mail.gmail.com>
Message-ID: <201908020835.x728ZUal026532@freefriends.org>

[Subject line changed]

Hi.

Doug McIlroy:
> Yet clean as the idea of groups was, it has been used only sporadically
> (in my experience).

I suspect this was true mainly at Research, where the whole place was
not large. Other people, as pointed out, found groups to be very useful.

"John P. Linderman" <jpl.jpl at gmail.com> wrote:
> This changed when you
> could be in multiple groups at the same time (a BSD invention?),

Yes, at 4.2 BSD. The so-called group set.

> and your
> primary group automatically changed to the group owning your current
> working directory (iff you belonged to that group).

No. Your process simply carried around a bunch of groups with it, and if
the group of the directory matched the primary group or a member of the
group set, you got group permission.

Arthur Krewat <krewat at kilonet.net>:
> There's also the setgid bit on directories, that when files are created, 
> they will be in the group that the parent directory has on it.

IIRC this was a Sun invention. It was in SunOS 4.x, and may even have
been in SunOS 3.x.

> Also, I don't think it's been mentioned, but there's the setuid bit on 
> directories - otherwise known as the sticky bit. When set, even if you 
> have rights to "write" the directory (meaning, delete files), you can't 
> delete those owned by other users. Useful for /tmp

Also a SunOS invention, IIRC.

> I have no idea what the timeline is for either of these features :)

Timeline is late 80s, SunOS 4.0, I believe. (Larry? :-)

These ideas later propogated into SVR4 / Solaris, Linux and most (if not all)
the other proprietary Unixes.

HTH,

Arnold

From dot at dotat.at  Fri Aug  2 21:18:30 2019
From: dot at dotat.at (Tony Finch)
Date: Fri, 2 Aug 2019 12:18:30 +0100
Subject: [TUHS] Additional groups and additional directory permissions
In-Reply-To: <201908020835.x728ZUal026532@freefriends.org>
References: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU>
 <CAC0cEp8oZ6kYXZGrwSVKM64MdkKCEMnkwu_62k9z+bne9x-Gaw@mail.gmail.com>
 <201908020835.x728ZUal026532@freefriends.org>
Message-ID: <alpine.DEB.2.20.1908021139530.11612@grey.csi.cam.ac.uk>

arnold at skeeve.com <arnold at skeeve.com> wrote:
> Arthur Krewat <krewat at kilonet.net>:
> > There's also the setgid bit on directories, that when files are created,
> > they will be in the group that the parent directory has on it.
>
> IIRC this was a Sun invention. It was in SunOS 4.x, and may even have
> been in SunOS 3.x.

When Bill Joy added the "multi-group stuff" to BSD all directories became
implicitly set-gid:

https://svnweb.freebsd.org/csrg/sys/ufs/ffs/ffs_inode.c?r1=4818&r2=5855

This is in SCCS revision 4.8 so I think it appeared in 4.2BSD

As I understand it, when group support was improved in System V they did
not change creat() to match BSD but instead used the directory set-gid bit
to provide opt-in BSD semantics. I don't know if this was in Solaris or
earlier?

> > Also, I don't think it's been mentioned, but there's the setuid bit on
> > directories - otherwise known as the sticky bit. When set, even if you
> > have rights to "write" the directory (meaning, delete files), you can't
> > delete those owned by other users. Useful for /tmp
>
> Also a SunOS invention, IIRC.

BSD again :-) SCCS revision 6.6 so I think it appeared in 4.3BSD

https://svnweb.freebsd.org/csrg/sys/ufs/ffs/ufs_lookup.c?r1=15809&r2=16046

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Mull of Galloway to Mull of Kintyre including the Firth of Clyde and North
Channel: Variable 1 to 3, becoming easterly or southeasterly 2 to 4 later.
Smooth, occasionally slight at first in North Channel. Showers for a time near
shore. Good.

From krewat at kilonet.net  Fri Aug  2 22:45:51 2019
From: krewat at kilonet.net (Arthur Krewat)
Date: Fri, 2 Aug 2019 08:45:51 -0400
Subject: [TUHS] Additional groups and additional directory permissions
In-Reply-To: <201908020835.x728ZUal026532@freefriends.org>
References: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU>
 <CAC0cEp8oZ6kYXZGrwSVKM64MdkKCEMnkwu_62k9z+bne9x-Gaw@mail.gmail.com>
 <201908020835.x728ZUal026532@freefriends.org>
Message-ID: <290b6d92-2e4a-248f-63b0-ab663f49ea65@kilonet.net>



On 8/2/2019 4:35 AM, arnold at skeeve.com wrote:
> [Subject line changed]
>
> Hi.
>
> Arthur Krewat <krewat at kilonet.net>:
>> There's also the setgid bit on directories, that when files are created,
>> they will be in the group that the parent directory has on it.
> IIRC this was a Sun invention. It was in SunOS 4.x, and may even have
> been in SunOS 3.x.
>
>> Also, I don't think it's been mentioned, but there's the setuid bit on
>> directories - otherwise known as the sticky bit. When set, even if you
>> have rights to "write" the directory (meaning, delete files), you can't
>> delete those owned by other users. Useful for /tmp
> Also a SunOS invention, IIRC.
>
>> I have no idea what the timeline is for either of these features :)
> Timeline is late 80s, SunOS 4.0, I believe. (Larry? :-)
>
> These ideas later propogated into SVR4 / Solaris, Linux and most (if not all)
> the other proprietary Unixes.
>

Makes a lot of sense. I just fired up my Consensys SVR4.2 VirtualBox 
guest, and sure enough, neither the sticky bit, nor setgid work on 
directories.

My first commercial experience with UNIX as a consultant was SunOS. I 
had worked on Version 6 earlier, but that was purely personal and never 
more than messing around with a uVAX a friend had brought home from work.

thanks for the info!
art k.


From clemc at ccc.com  Fri Aug  2 23:06:57 2019
From: clemc at ccc.com (Clem Cole)
Date: Fri, 2 Aug 2019 09:06:57 -0400
Subject: [TUHS] Additional groups and additional directory permissions
In-Reply-To: <201908020835.x728ZUal026532@freefriends.org>
References: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU>
 <CAC0cEp8oZ6kYXZGrwSVKM64MdkKCEMnkwu_62k9z+bne9x-Gaw@mail.gmail.com>
 <201908020835.x728ZUal026532@freefriends.org>
Message-ID: <CAC20D2OxTyJPj=yfhpjJRBVtnvEDthO=iB-C-K7ZkU-OndRUPg@mail.gmail.com>

On Fri, Aug 2, 2019 at 4:36 AM <arnold at skeeve.com> wrote:

> Arthur Krewat <krewat at kilonet.net>:
> > Also, I don't think it's been mentioned, but there's the setuid bit on
> > directories - otherwise known as the sticky bit. When set, even if you
> > have rights to "write" the directory (meaning, delete files), you can't
> > delete those owned by other users. Useful for /tmp
>
> Also a SunOS invention, IIRC.
>
Nope, much older.  It was a BSDism -- Cory Hall 11/70 actually (V6
originally) - wnj probably, but it may have been somebody like Asa
Romberger or Bob Kriddle who were the admins.  VAXen distributions picked
it up and Sun got it from there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190802/7440ab82/attachment.html>

From clemc at ccc.com  Fri Aug  2 23:28:18 2019
From: clemc at ccc.com (Clem Cole)
Date: Fri, 2 Aug 2019 09:28:18 -0400
Subject: [TUHS] Additional groups and additional directory permissions
In-Reply-To: <201908020835.x728ZUal026532@freefriends.org>
References: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU>
 <CAC0cEp8oZ6kYXZGrwSVKM64MdkKCEMnkwu_62k9z+bne9x-Gaw@mail.gmail.com>
 <201908020835.x728ZUal026532@freefriends.org>
Message-ID: <CAC20D2PwOxA4LGo+YFt7dLy1kmaQq_cnptYuy8Ajd6ajBqFcPg@mail.gmail.com>

The best I can tell/remember is that groups went through 4 phases:
1.) No groups (earliest  UNIX) [ I personally never used this except in the
V0 retrocomputing]
2.) First group implementation (Thompson) [My first UNIX introduction was
with this implementation]
3.) PWB 1.0 (Mashey version) [then saw this post PWB]
4.) BSD 4.2 (wnj version) [and lived this transistion]

Each was a little different in semantics.

As Doug mentioned, many sites (like Research) really did not need much and
groups were really not used that widely.   Thompson added something like
the Project number of TOPS and some earlier systems.  Truth is, it did not
help much IMO.   It was useful for grouping things like the binaries and
keeping some more privileged programs from having to be setuid root.

Mashey added features in PWB, primarily because of the RJE/Front end to the
Mainframes and the need to have better protections/collections of certain
items.   But they still were much more like the DEC PPN, were you were
running as a single group (i.e. the tuple UID/GID).  This lasted a pretty
long time, as it worked reasonably well for larger academic systems, where
you had a user and were assigned a group, say for a course or class, you
might be talking.  If you looked at big 4.1 BSN Vaxen like at Purdue/Penn
State, *etc.*, that how they were admin'd.  But as Doug said, if you were
still a small site, the use of groups was still pretty shallow.

But, as part of the CSRG support for DARPA, there was a push from the
community to have a list of groups that a user could be a part and you
carried that list around in a more general manner.   The big sites, in
particular, were pushing for this because they were using groups as a major
feature.  wnj implemented same and it would go out widely in 4.2, although
>>by memory<< that was in 4.1B or 4.1C first.   It's possible Robert Elz
may have brought that to Bill with his quota changes, but frankly I've
forgotten.   There was a lot of work being done to the FS at that point,
much less Kirk's rewrite.

But as UNIX went back to workstations, the need for a more general group
system dropped away until the advent widely used distributed file systems
like CMU's AFS and Sun's NFS.  Then the concept of a user being in more
than one group became much more de rigeur even on a small machine.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190802/90f76f84/attachment.html>

From jnc at mercury.lcs.mit.edu  Sat Aug  3 00:35:31 2019
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri,  2 Aug 2019 10:35:31 -0400 (EDT)
Subject: [TUHS] Who's behind the UNIX filesystem permission
Message-ID: <20190802143531.96D4218C096@mercury.lcs.mit.edu>

    > From: Arthur Krewat

    > there's the setuid bit on directories - otherwise known as the sticky
    > bit.

Minor nit; in V6 at least (not sure about later), the 'sticky' bit was a
separate bit from SUID and SGID. (When set on a pure/split object file, it
told the OS to retain the text image on the swap device even when no active
process was using it. Hence the name...)

	Noel


From clemc at ccc.com  Sat Aug  3 01:01:22 2019
From: clemc at ccc.com (Clem Cole)
Date: Fri, 2 Aug 2019 11:01:22 -0400
Subject: [TUHS] Who's behind the UNIX filesystem permission
In-Reply-To: <20190802143531.96D4218C096@mercury.lcs.mit.edu>
References: <20190802143531.96D4218C096@mercury.lcs.mit.edu>
Message-ID: <CAC20D2MvuVsCwz2ZCXyxzB1T7bV+1hyg08yVLSo2y2i8W-sZvw@mail.gmail.com>

On Fri, Aug 2, 2019 at 10:58 AM Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     Minor nit; in V6 at least (not sure about later), the 'sticky' bit was
> a
> separate bit from SUID and SGID. (When set on a pure/split object file, it
> told the OS to retain the text image on the swap device even when no active
> process was using it. Hence the name...)
>
Indeed, nice catch, Noel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190802/a3cb5240/attachment.html>

From krewat at kilonet.net  Sat Aug  3 01:17:31 2019
From: krewat at kilonet.net (Arthur Krewat)
Date: Fri, 2 Aug 2019 11:17:31 -0400
Subject: [TUHS] Who's behind the UNIX filesystem permission
In-Reply-To: <20190802143531.96D4218C096@mercury.lcs.mit.edu>
References: <20190802143531.96D4218C096@mercury.lcs.mit.edu>
Message-ID: <c132fb91-c996-1dc9-9d59-60f2cbb6439d@kilonet.net>



On 8/2/2019 10:35 AM, Noel Chiappa wrote:
>      > From: Arthur Krewat
>
>      > there's the setuid bit on directories - otherwise known as the sticky
>      > bit.
>
> Minor nit; in V6 at least (not sure about later), the 'sticky' bit was a
> separate bit from SUID and SGID. (When set on a pure/split object file, it
> told the OS to retain the text image on the swap device even when no active
> process was using it. Hence the name...)
>

Ah yes, I remember that now... sorry.

Sticky bit is the low-order bit on the first octet which is usually left 
off and assumed to be zero. So to set it, it would be 1755. 4755 would 
be setuid. Woops.

art k.


From thomas.paulsen at firemail.de  Sat Aug  3 05:00:12 2019
From: thomas.paulsen at firemail.de (Thomas Paulsen)
Date: Fri, 02 Aug 2019 21:00:12 +0200
Subject: [TUHS] Additional groups and additional directory permissions
In-Reply-To: <CAC20D2PwOxA4LGo+YFt7dLy1kmaQq_cnptYuy8Ajd6ajBqFcPg@mail.gmail.com>
References: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU>
 <CAC0cEp8oZ6kYXZGrwSVKM64MdkKCEMnkwu_62k9z+bne9x-Gaw@mail.gmail.com>
 <201908020835.x728ZUal026532@freefriends.org>
 <CAC20D2PwOxA4LGo+YFt7dLy1kmaQq_cnptYuy8Ajd6ajBqFcPg@mail.gmail.com>
Message-ID: <76a8b8144de199f3ef3234fae998566e@firemail.de>

isn't Kirk McKusic a member of our group? Guess he can contribute a lot on this issue.

--- Ursprüngliche Nachricht ---
Von: Clem Cole <clemc at ccc.com>
Datum: 02.08.2019 15:28:18
An: Aharon Robbins <arnold at skeeve.com>, Doug McIlroy <doug at cs.dartmouth.edu>
Betreff: Re: [TUHS] Additional groups and additional directory permissions

> The best I can tell/remember is that groups went through 4 phases:
> 1.) No groups (earliest  UNIX) [ I personally never used this except in the
>
> V0 retrocomputing]
> 2.) First group implementation (Thompson) [My first UNIX introduction was
>
> with this implementation]
> 3.) PWB 1.0 (Mashey version) [then saw this post PWB]
> 4.) BSD 4.2 (wnj version) [and lived this transistion]
>
> Each was a little different in semantics.
>
> As Doug mentioned, many sites (like Research) really did not need much and
>
> groups were really not used that widely.   Thompson added something like
>
> the Project number of TOPS and some earlier systems.  Truth is, it did not
>
> help much IMO.   It was useful for grouping things like the binaries and
>
> keeping some more privileged programs from having to be setuid root.
>
> Mashey added features in PWB, primarily because of the RJE/Front end to the
>
> Mainframes and the need to have better protections/collections of certain
>
> items.   But they still were much more like the DEC PPN, were you were
> running as a single group (i.e. the tuple UID/GID).  This lasted a pretty
>
> long time, as it worked reasonably well for larger academic systems, where
>
> you had a user and were assigned a group, say for a course or class, you
>
> might be talking.  If you looked at big 4.1 BSN Vaxen like at Purdue/Penn
>
> State, *etc.*, that how they were admin'd.  But as Doug said, if you were
>
> still a small site, the use of groups was still pretty shallow.
>
> But, as part of the CSRG support for DARPA, there was a push from the
> community to have a list of groups that a user could be a part and you
> carried that list around in a more general manner.   The big sites, in
> particular, were pushing for this because they were using groups as a major
>
> feature.  wnj implemented same and it would go out widely in 4.2, although
>
> >>by memory<< that was in 4.1B or 4.1C first.   It's possible
> Robert Elz
> may have brought that to Bill with his quota changes, but frankly I've
> forgotten.   There was a lot of work being done to the FS at that point,
>
> much less Kirk's rewrite.
>
> But as UNIX went back to workstations, the need for a more general group
>
> system dropped away until the advent widely used distributed file systems
>
> like CMU's AFS and Sun's NFS.  Then the concept of a user being in more
> than one group became much more de rigeur even on a small machine.
>
> Clem
>



From norman at oclsc.org  Sat Aug  3 05:44:53 2019
From: norman at oclsc.org (Norman Wilson)
Date: Fri, 02 Aug 2019 15:44:53 -0400
Subject: [TUHS] Additional groups and additional directory permissions
Message-ID: <1564775096.13771.for-standards-violators@oclsc.org>

Thomas Paulsen:

  isn't Kirk McKusic a member of our group?

====

Kirk is a member of many groups, all at the same time.

Norman Wilson
Toronto ON

From wkt at tuhs.org  Sat Aug  3 06:14:48 2019
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 3 Aug 2019 06:14:48 +1000
Subject: [TUHS] Video of PDP-7 with Graphics-2?
Message-ID: <20190802201448.GA5889@minnie.tuhs.org>

Hi all, I'm chasing the Youtube video of the PDP-7 at Bell Labs where
people are using it to draw circuit schematics. This seems to show
the Graphics-2 module that, I believe, was built at the Labs. Can
someone e-mail the URL? I've done some grepping but I haven't found it yet.

Thanks, Warren

From dave at horsfall.org  Sat Aug  3 07:23:12 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 3 Aug 2019 07:23:12 +1000 (EST)
Subject: [TUHS] Who's behind the UNIX filesystem permission
In-Reply-To: <c132fb91-c996-1dc9-9d59-60f2cbb6439d@kilonet.net>
References: <20190802143531.96D4218C096@mercury.lcs.mit.edu>
 <c132fb91-c996-1dc9-9d59-60f2cbb6439d@kilonet.net>
Message-ID: <alpine.BSF.2.21.9999.1908030721400.38830@aneurin.horsfall.org>

On Fri, 2 Aug 2019, Arthur Krewat wrote:

> Sticky bit is the low-order bit on the first octet which is usually left 
> off and assumed to be zero. So to set it, it would be 1755. 4755 would 
> be setuid.

That's why I use the symbolic modes on "chmod" instead of the octal ones :-)

-- Dave

From wkt at tuhs.org  Sat Aug  3 09:03:48 2019
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 3 Aug 2019 09:03:48 +1000
Subject: [TUHS] Video of PDP-7 with Graphics-2?
In-Reply-To: <e00fc7d7-7182-1d0f-261e-6701af92c690@deitygraveyard.com>
References: <20190802201448.GA5889@minnie.tuhs.org>
 <e00fc7d7-7182-1d0f-261e-6701af92c690@deitygraveyard.com>
Message-ID: <20190802230348.GA22981@minnie.tuhs.org>

On Fri, Aug 02, 2019 at 06:49:19PM -0400, Jim Carpenter wrote:
> On 8/2/19 4:14 PM, Warren Toomey wrote:
> > Hi all, I'm chasing the Youtube video of the PDP-7 at Bell Labs where
> > people are using it to draw circuit schematics.
> 
> A Bell Labs video? The only Bell Labs video I remember seeing that had
> someone doing circuit schematics had it being done on a PDP-5. The -7 was
> shown later doing music stuff. (That's the -7 that I thought maybe Unix
> started life on.)

Thanks Jim, Is it this one?
https://www.youtube.com/watch?v=iwVu2BWLZqA

They mention a Graphics-1 device, so maybe I'm getting this confused
with the PDP-7 and the Graphics-2.

Cheers, Warren

From wkt at tuhs.org  Sat Aug  3 10:33:36 2019
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 3 Aug 2019 10:33:36 +1000
Subject: [TUHS] An Excellent Unix YouTube Video
Message-ID: <20190803003336.GA32125@minnie.tuhs.org>

https://www.youtube.com/watch?v=g3jOJfrOknA

National Inventors Hall of Fame - NIHF
Published on Feb 18, 2019
Bell Labs colleagues Ken Thompson and Dennis Ritchie developed UNIX,
a multi-tasking, multi-user operating system alternative to the batch
processing systems then dominating the computer industry.

Not sure why I hadn't seen this before :)

Cheers, Warren

From cym224 at gmail.com  Sat Aug  3 22:51:32 2019
From: cym224 at gmail.com (Nemo)
Date: Sat, 3 Aug 2019 08:51:32 -0400
Subject: [TUHS] Who's behind the UNIX filesystem permission
In-Reply-To: <alpine.BSF.2.21.9999.1908030721400.38830@aneurin.horsfall.org>
References: <20190802143531.96D4218C096@mercury.lcs.mit.edu>
 <c132fb91-c996-1dc9-9d59-60f2cbb6439d@kilonet.net>
 <alpine.BSF.2.21.9999.1908030721400.38830@aneurin.horsfall.org>
Message-ID: <CAJfiPzwR7yFWW9cr2D_xQuBobvHm269eqA0nRnWJPXtGmPv3dA@mail.gmail.com>

On 02/08/2019, Dave Horsfall <dave at horsfall.org> wrote:
> That's why I use the symbolic modes on "chmod" instead of the octal ones

+1

> :-)
>
> -- Dave
>

From clemc at ccc.com  Sun Aug  4 01:28:13 2019
From: clemc at ccc.com (Clem Cole)
Date: Sat, 3 Aug 2019 11:28:13 -0400
Subject: [TUHS] An Excellent Unix YouTube Video
In-Reply-To: <20190803003336.GA32125@minnie.tuhs.org>
References: <20190803003336.GA32125@minnie.tuhs.org>
Message-ID: <CAC20D2N-=T7tB0S-x1JbGSYXfPWQB1=i76tjv6V0fUF6PX4TKA@mail.gmail.com>

Thanks, Warren - that was wonderful to watch.  Clem

On Fri, Aug 2, 2019 at 8:34 PM Warren Toomey <wkt at tuhs.org> wrote:

> https://www.youtube.com/watch?v=g3jOJfrOknA
>
> National Inventors Hall of Fame - NIHF
> Published on Feb 18, 2019
> Bell Labs colleagues Ken Thompson and Dennis Ritchie developed UNIX,
> a multi-tasking, multi-user operating system alternative to the batch
> processing systems then dominating the computer industry.
>
> Not sure why I hadn't seen this before :)
>
> Cheers, Warren
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190803/5014fd49/attachment.html>

From david at kdbarto.org  Sun Aug  4 03:35:56 2019
From: david at kdbarto.org (David)
Date: Sat, 3 Aug 2019 10:35:56 -0700
Subject: [TUHS] An Excellent Unix YouTube Video
In-Reply-To: <CAC20D2N-=T7tB0S-x1JbGSYXfPWQB1=i76tjv6V0fUF6PX4TKA@mail.gmail.com>
References: <20190803003336.GA32125@minnie.tuhs.org>
 <CAC20D2N-=T7tB0S-x1JbGSYXfPWQB1=i76tjv6V0fUF6PX4TKA@mail.gmail.com>
Message-ID: <74D3057C-2F84-4551-B2B0-BBBC27833F20@kdbarto.org>

Short and wonderful as a complement to 2 very good people.

	David

> On Aug 3, 2019, at 8:28 AM, Clem Cole <clemc at ccc.com> wrote:
> 
> Thanks, Warren - that was wonderful to watch.  Clem
> 
> On Fri, Aug 2, 2019 at 8:34 PM Warren Toomey <wkt at tuhs.org <mailto:wkt at tuhs.org>> wrote:
> https://www.youtube.com/watch?v=g3jOJfrOknA <https://www.youtube.com/watch?v=g3jOJfrOknA>
> 
> National Inventors Hall of Fame - NIHF
> Published on Feb 18, 2019
> Bell Labs colleagues Ken Thompson and Dennis Ritchie developed UNIX,
> a multi-tasking, multi-user operating system alternative to the batch
> processing systems then dominating the computer industry.
> 
> Not sure why I hadn't seen this before :)
> 
> Cheers, Warren

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

From lm at mcvoy.com  Sun Aug  4 03:49:17 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 3 Aug 2019 10:49:17 -0700
Subject: [TUHS] An Excellent Unix YouTube Video
In-Reply-To: <74D3057C-2F84-4551-B2B0-BBBC27833F20@kdbarto.org>
References: <20190803003336.GA32125@minnie.tuhs.org>
 <CAC20D2N-=T7tB0S-x1JbGSYXfPWQB1=i76tjv6V0fUF6PX4TKA@mail.gmail.com>
 <74D3057C-2F84-4551-B2B0-BBBC27833F20@kdbarto.org>
Message-ID: <20190803174917.GI27132@mcvoy.com>

Couldn't agree more.  And the description of Dennis was spot on
and matches my own interactions with him.  Hell of a nice guy and
willing to help you if you demonstated cluefullness (and from what
I've heard, even without cluefulness).

Thanks Ken and Dennis, it's been one hell of a ride and it is still
going!

On Sat, Aug 03, 2019 at 10:35:56AM -0700, David wrote:
> Short and wonderful as a complement to 2 very good people.
> 
> 	David
> 
> > On Aug 3, 2019, at 8:28 AM, Clem Cole <clemc at ccc.com> wrote:
> > 
> > Thanks, Warren - that was wonderful to watch.  Clem
> > 
> > On Fri, Aug 2, 2019 at 8:34 PM Warren Toomey <wkt at tuhs.org <mailto:wkt at tuhs.org>> wrote:
> > https://www.youtube.com/watch?v=g3jOJfrOknA <https://www.youtube.com/watch?v=g3jOJfrOknA>
> > 
> > National Inventors Hall of Fame - NIHF
> > Published on Feb 18, 2019
> > Bell Labs colleagues Ken Thompson and Dennis Ritchie developed UNIX,
> > a multi-tasking, multi-user operating system alternative to the batch
> > processing systems then dominating the computer industry.
> > 
> > Not sure why I hadn't seen this before :)
> > 
> > Cheers, Warren
> 

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

From arnold at skeeve.com  Sun Aug  4 16:40:47 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 04 Aug 2019 00:40:47 -0600
Subject: [TUHS] Additional groups and additional directory permissions
In-Reply-To: <alpine.DEB.2.20.1908021139530.11612@grey.csi.cam.ac.uk>
References: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU>
 <CAC0cEp8oZ6kYXZGrwSVKM64MdkKCEMnkwu_62k9z+bne9x-Gaw@mail.gmail.com>
 <201908020835.x728ZUal026532@freefriends.org>
 <alpine.DEB.2.20.1908021139530.11612@grey.csi.cam.ac.uk>
Message-ID: <201908040640.x746elpl029042@freefriends.org>

> arnold at skeeve.com <arnold at skeeve.com> wrote:
> > Arthur Krewat <krewat at kilonet.net>:
> > > There's also the setgid bit on directories, that when files are created,
> > > they will be in the group that the parent directory has on it.
> >
> > IIRC this was a Sun invention. It was in SunOS 4.x, and may even have
> > been in SunOS 3.x.

Tony Finch <dot at dotat.at> wrote:
> When Bill Joy added the "multi-group stuff" to BSD all directories became
> implicitly set-gid:

Yes.  But the commercial world had backwards compatibility to worry about.
Thus the setgid bit on directories. I'm no longer sure who first came
up with it.

> As I understand it, when group support was improved in System V they did
> not change creat() to match BSD but instead used the directory set-gid bit
> to provide opt-in BSD semantics. I don't know if this was in Solaris or
> earlier?

Correct, but not sure when it was first done.

> > > Also, I don't think it's been mentioned, but there's the setuid bit on
> > > directories - otherwise known as the sticky bit. When set, even if you
> > > have rights to "write" the directory (meaning, delete files), you can't
> > > delete those owned by other users. Useful for /tmp
> >
> > Also a SunOS invention, IIRC.
>
> BSD again :-) SCCS revision 6.6 so I think it appeared in 4.3BSD

That sounds right. I stand corrected.

Thanks,

Arnold

From dave at horsfall.org  Sun Aug  4 17:36:44 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 4 Aug 2019 17:36:44 +1000 (EST)
Subject: [TUHS] Set-uid shell scripts
Message-ID: <alpine.BSF.2.21.9999.1908041714460.38830@aneurin.horsfall.org>

Is it just me, or did someone actually implement set-uid scripts?  I've 
proposed some silly things over the decades (my favourite is stty() 
working on things other than terminals, and guess what, we got ioctl() 
etc) but I have a vague recollection of this...

The trouble is, I've worked with dozens of Unix-based vendors over the 
years (some good, some not so much) and so I've lost track of all the 
stupidity that I've seen.

ObAnecdote: Just about every Unix vendor went belly-up shortly after I 
left them (under various circumstances), because the waste-of-space middle 
managers simply did not appreciate the importance of having a Unix guru 
on board if you're in the game of selling Unix boxen.

I'd happily name them, but I think the principals are still alive :-)

-- Dave

From alec.muffett at gmail.com  Sun Aug  4 17:43:24 2019
From: alec.muffett at gmail.com (Alec Muffett)
Date: Sun, 4 Aug 2019 08:43:24 +0100
Subject: [TUHS] Set-uid shell scripts
In-Reply-To: <alpine.BSF.2.21.9999.1908041714460.38830@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.1908041714460.38830@aneurin.horsfall.org>
Message-ID: <CAFWeb9JFaDAAD-6Bruh1eO-MddAJ17nZTWeTP8syXpPqa-CM9w@mail.gmail.com>

On Sun, 4 Aug 2019 at 08:37, Dave Horsfall <dave at horsfall.org> wrote:

> Is it just me, or did someone actually implement set-uid scripts?


Yes, they were a thing for a while, until someone realised that you could
do:

ln -s /bin/scriptname ./-i
"-i" # assuming that "." is already in your path

...and get a root shell.  Source: I did this on (ISTR) 4.1 or 4.2BSD.

    -a

-- 
http://dropsafe.crypticide.com/aboutalecm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190804/7e61d0aa/attachment.html>

From arnold at skeeve.com  Sun Aug  4 17:46:17 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 04 Aug 2019 01:46:17 -0600
Subject: [TUHS] Set-uid shell scripts
In-Reply-To: <alpine.BSF.2.21.9999.1908041714460.38830@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.1908041714460.38830@aneurin.horsfall.org>
Message-ID: <201908040746.x747kHsu004735@freefriends.org>

Dave Horsfall <dave at horsfall.org> wrote:

> Is it just me, or did someone actually implement set-uid scripts?

I think it worked in the early Unixen (V7, 4.1 time frame, more or less
by accident) but after that the implications were recognized and only
compiled binaries could be run setuid.

> The trouble is, I've worked with dozens of Unix-based vendors over the 
> years (some good, some not so much) and so I've lost track of all the 
> stupidity that I've seen.

It's not just Unix vendors. It's software (and hardware) companies
in general.

Arnold

From jnc at mercury.lcs.mit.edu  Mon Aug  5 01:58:54 2019
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun,  4 Aug 2019 11:58:54 -0400 (EDT)
Subject: [TUHS] Set-uid shell scripts
Message-ID: <20190804155854.C22CA18C096@mercury.lcs.mit.edu>

    > From: Alec Muffett

    > until someone realised that you could do:
    >  ln -s /bin/scriptname ./-i
    >  "-i" # assuming that "." is already in your path
    > ...and get a root shell.

I'm clearly not very awake this morning, because I don't understand how this
works. Can you break it down a little? Thanks!

       Noel


From michael at kjorling.se  Mon Aug  5 02:30:00 2019
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Sun, 4 Aug 2019 16:30:00 +0000
Subject: [TUHS] Set-uid shell scripts
In-Reply-To: <20190804155854.C22CA18C096@mercury.lcs.mit.edu>
References: <CAFWeb9JFaDAAD-6Bruh1eO-MddAJ17nZTWeTP8syXpPqa-CM9w@mail.gmail.com>
 <20190804155854.C22CA18C096@mercury.lcs.mit.edu>
Message-ID: <20190804163000.GB19836@h-178-80.A328.priv.bahnhof.se>

On 4 Aug 2019 11:58 -0400, from jnc at mercury.lcs.mit.edu (Noel Chiappa):
>> until someone realised that you could do:
>>  ln -s /bin/scriptname ./-i
>>  "-i" # assuming that "." is already in your path
>> ...and get a root shell.
> 
> I'm clearly not very awake this morning, because I don't understand how this
> works. Can you break it down a little? Thanks!

I'm guessing a little here, but could it be related to poor command
line argument parsing in some shell, where "-i" forces the shell to
start in interactive mode and the shell looks for parameters
_anywhere_ in its argv[] (including argv[0]), not just at argv[1] and
later?

That would match the result described by Alec, and my modern dash's
man page does give that meaning for "-i", but it also feels like a
trivial bug to fix in the shell without prohibiting setuid scripts...

-- 
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 alec.muffett at gmail.com  Mon Aug  5 02:48:44 2019
From: alec.muffett at gmail.com (Alec Muffett)
Date: Sun, 4 Aug 2019 17:48:44 +0100
Subject: [TUHS] Set-uid shell scripts
In-Reply-To: <20190804163000.GB19836@h-178-80.A328.priv.bahnhof.se>
References: <CAFWeb9JFaDAAD-6Bruh1eO-MddAJ17nZTWeTP8syXpPqa-CM9w@mail.gmail.com>
 <20190804155854.C22CA18C096@mercury.lcs.mit.edu>
 <20190804163000.GB19836@h-178-80.A328.priv.bahnhof.se>
Message-ID: <CAFWeb9KTEds5WsAeG1FGk9HXsAVK+BD=gF+Y4kbmuDDWhtry4g@mail.gmail.com>

The cited filename is passed as argv[1]

If the filename is "-i" then the command is "/bin/sh -i"

This forces an interactive shell.

Hence the important of not invoking it as "./-i"

-a
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190804/89f28300/attachment.html>

From rp at servium.ch  Mon Aug  5 02:50:32 2019
From: rp at servium.ch (Rico Pajarola)
Date: Sun, 4 Aug 2019 09:50:32 -0700
Subject: [TUHS] Set-uid shell scripts
In-Reply-To: <20190804155854.C22CA18C096@mercury.lcs.mit.edu>
References: <20190804155854.C22CA18C096@mercury.lcs.mit.edu>
Message-ID: <CACwAiQkMFrjtY5f1iA5ihd3tQiW=FKqvY1UEKy6SM_Q3zoQqMQ@mail.gmail.com>

when running a shell script, what's actually executed is the first line of
the script (after #!) + the name of the script.

If your script is named "-i", and in your path, just enter "-i", and
/bin/sh -i is executed which gives you an interactive shell.

There are probably half a dozen other ways to trick the shell into
executing arbitrary code that is not contained in the script (more if the
script actually does anything non-trivial, like e.g. an installer of some
sort). So instead of trying to fix them all (and most likely missing a
few), everybody just agreed that it was a terrible idea and removed the
feature.


On Sun, Aug 4, 2019 at 9:00 AM Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:

>     > From: Alec Muffett
>
>     > until someone realised that you could do:
>     >  ln -s /bin/scriptname ./-i
>     >  "-i" # assuming that "." is already in your path
>     > ...and get a root shell.
>
> I'm clearly not very awake this morning, because I don't understand how
> this
> works. Can you break it down a little? Thanks!
>
>        Noel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190804/6a379e76/attachment.html>

From michael at kjorling.se  Mon Aug  5 03:48:09 2019
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Sun, 4 Aug 2019 17:48:09 +0000
Subject: [TUHS] Set-uid shell scripts
In-Reply-To: <CAFWeb9KTEds5WsAeG1FGk9HXsAVK+BD=gF+Y4kbmuDDWhtry4g@mail.gmail.com>
References: <CAFWeb9JFaDAAD-6Bruh1eO-MddAJ17nZTWeTP8syXpPqa-CM9w@mail.gmail.com>
 <20190804155854.C22CA18C096@mercury.lcs.mit.edu>
 <20190804163000.GB19836@h-178-80.A328.priv.bahnhof.se>
 <CAFWeb9KTEds5WsAeG1FGk9HXsAVK+BD=gF+Y4kbmuDDWhtry4g@mail.gmail.com>
Message-ID: <20190804174809.GC19836@h-178-80.A328.priv.bahnhof.se>

On 4 Aug 2019 17:48 +0100, from alec.muffett at gmail.com (Alec Muffett):
> The cited filename is passed as argv[1]

Well, that's even more obvious, and a little harder to "just fix"
indeed. I stand corrected.

-- 
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 alec.muffett at gmail.com  Mon Aug  5 05:45:24 2019
From: alec.muffett at gmail.com (Alec Muffett)
Date: Sun, 4 Aug 2019 20:45:24 +0100
Subject: [TUHS] Set-uid shell scripts
In-Reply-To: <20190804174809.GC19836@h-178-80.A328.priv.bahnhof.se>
References: <CAFWeb9JFaDAAD-6Bruh1eO-MddAJ17nZTWeTP8syXpPqa-CM9w@mail.gmail.com>
 <20190804155854.C22CA18C096@mercury.lcs.mit.edu>
 <20190804163000.GB19836@h-178-80.A328.priv.bahnhof.se>
 <CAFWeb9KTEds5WsAeG1FGk9HXsAVK+BD=gF+Y4kbmuDDWhtry4g@mail.gmail.com>
 <20190804174809.GC19836@h-178-80.A328.priv.bahnhof.se>
Message-ID: <CAFWeb9KUFkncNKngm849=Z5eg+GQwph9rKkzT_UuN-PU3vBKXw@mail.gmail.com>

On Sun, 4 Aug 2019 at 18:57, Michael Kjörling <michael at kjorling.se> wrote:

> Well, that's even more obvious


32 years of security, and I can't say one has passed without someone saying
"in retrospect, [the bug] was obvious" about *something* — so you're in
good company. :-)

-- 
http://dropsafe.crypticide.com/aboutalecm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190804/eaac2edd/attachment.html>

From jnc at mercury.lcs.mit.edu  Mon Aug  5 06:18:37 2019
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun,  4 Aug 2019 16:18:37 -0400 (EDT)
Subject: [TUHS] Set-uid shell scripts
Message-ID: <20190804201838.0246918C08C@mercury.lcs.mit.edu>

    > From: Alec Muffett

    >>>  ln -s /bin/scriptname ./-i
    >>>  "-i" # assuming that "." is already in your path

'scriptname' (above) would have to be a shell script which was SETUID root?
That was part of what I was missing, along with the below.

    > The cited filename is passed as argv[1]

I wonder why it passed the link name, instead of the actual filename of the
target (script)? Perhaps to allow one script to have multiple functions,
depending on the name it was called with? But that could have been done with
hard links? (Adding a hard link must require write access, because the link
count in the inode has to be updated? So it would be equally secure as not
having an SUID program with write access.)

Part of the problem is having the kernel involved in starting shell scripts;
convenient in some ways, but V6 etc worked fine without that 'feature'.

       Noel

From clemc at ccc.com  Mon Aug  5 06:29:58 2019
From: clemc at ccc.com (Clem Cole)
Date: Sun, 4 Aug 2019 16:29:58 -0400
Subject: [TUHS] Set-uid shell scripts
In-Reply-To: <20190804201838.0246918C08C@mercury.lcs.mit.edu>
References: <20190804201838.0246918C08C@mercury.lcs.mit.edu>
Message-ID: <CAC20D2MFZ=H9CPU3QMWEffFVU0RsXzJFMgJX78addLZ-sm-cKw@mail.gmail.com>

On Sun, Aug 4, 2019 at 4:18 PM Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:

> Part of the problem is having the kernel involved in starting shell
> scripts; convenient in some ways, but V6 etc worked fine without that
> 'feature'.
>
That's a tough call.  I have mixed opinions about it as a feature.  I kind
of like the user/kernel interface really, really thin and unadorned.

Adding, it certainly made allowing multiple interpreters to be supported
much easier; but as you say it opens a new can of worms.   Given the later
proliferation of what bwk or Jon Bently once referred too as 'little
languages' (awk, perl, tcl, and sigh eventually python), it was probably a
good feature.

But as you said, v6 worked fairly well without it.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190804/90435ac2/attachment.html>

From rich.salz at gmail.com  Mon Aug  5 06:42:34 2019
From: rich.salz at gmail.com (Richard Salz)
Date: Sun, 4 Aug 2019 16:42:34 -0400
Subject: [TUHS] Set-uid shell scripts
In-Reply-To: <CAC20D2MFZ=H9CPU3QMWEffFVU0RsXzJFMgJX78addLZ-sm-cKw@mail.gmail.com>
References: <20190804201838.0246918C08C@mercury.lcs.mit.edu>
 <CAC20D2MFZ=H9CPU3QMWEffFVU0RsXzJFMgJX78addLZ-sm-cKw@mail.gmail.com>
Message-ID: <CAFH29trTYKHnzRZASH1q9yjCTCjxqW0EJUaBHfOtOt5UUbQkhA@mail.gmail.com>

BSD added the #! "magic number" based on a suggestion from Ken I believe.

Didn't the exec (2) manpage warn about argv[-1] being clobbered until that
was added?

On Sun, Aug 4, 2019, 4:31 PM Clem Cole <clemc at ccc.com> wrote:

>
>
> On Sun, Aug 4, 2019 at 4:18 PM Noel Chiappa <jnc at mercury.lcs.mit.edu>
> wrote:
>
>> Part of the problem is having the kernel involved in starting shell
>> scripts; convenient in some ways, but V6 etc worked fine without that
>> 'feature'.
>>
> That's a tough call.  I have mixed opinions about it as a feature.  I
> kind of like the user/kernel interface really, really thin and unadorned.
>
> Adding, it certainly made allowing multiple interpreters to be supported
> much easier; but as you say it opens a new can of worms.   Given the later
> proliferation of what bwk or Jon Bently once referred too as 'little
> languages' (awk, perl, tcl, and sigh eventually python), it was probably a
> good feature.
>
> But as you said, v6 worked fairly well without it.
>
> Clem
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190804/4a51eab4/attachment.html>

From norman at oclsc.org  Mon Aug  5 07:18:45 2019
From: norman at oclsc.org (Norman Wilson)
Date: Sun, 04 Aug 2019 17:18:45 -0400
Subject: [TUHS] Set-uid shell scripts
Message-ID: <1564953528.6352.for-standards-violators@oclsc.org>

Noel Chiappa:

  I wonder why it passed the link name, instead of the actual filename of the
  target (script)? Perhaps to allow one script to have multiple functions,
  depending on the name it was called with?

====

In fact the latter is still used here and there in standard
system distributions.

But from a security viewpoint it doesn't matter.  For

	ln -s /bin/scriptname ./-i

substitute

	execl("/bin/scriptname", "-i", (char *)0);

If you can execute a program, you can fake its arguments,
including argv[0].  There is no defence.

Norman Wilson
Toronto ON

From norman at oclsc.org  Mon Aug  5 07:27:33 2019
From: norman at oclsc.org (Norman Wilson)
Date: Sun, 04 Aug 2019 17:27:33 -0400
Subject: [TUHS] Set-uid shell scripts
Message-ID: <1564954057.6926.for-standards-violators@oclsc.org>

Oops.  Didn't think it through: the problem is argv[1],
passed as the name of the script being executed, not
argv[0].  Disregard my previous execl(...).

A related problem is the inherent race condition:
If you do
	ln -s /bin/setuidscript .
	./setuidscript
./setuidscript is opened twice: once when the kernel
reads it and finds #! as magic number and execs the
interpreter, a second time when the interpreter opens
./setuidscript.  If you meanwhile run something that
swoops in in the background and replaces ./setuidscript
with malicious instructions for the interpreter, you
win.

I remember managing to do this myself at one point in
the latter part of the 1980s.  That was when I fell
out of love with setuid interpreter scripts.

It looks like we didn't disable the danger in the
Research kernel, though.  I don't remember why not.

Norman Wilson
Toronto ON

From dave at horsfall.org  Mon Aug  5 09:58:49 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 5 Aug 2019 09:58:49 +1000 (EST)
Subject: [TUHS] Set-uid shell scripts
In-Reply-To: <20190804201838.0246918C08C@mercury.lcs.mit.edu>
References: <20190804201838.0246918C08C@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.21.9999.1908050957110.38830@aneurin.horsfall.org>

On Sun, 4 Aug 2019, Noel Chiappa wrote:

> 'scriptname' (above) would have to be a shell script which was SETUID root?
> That was part of what I was missing, along with the below.

Well, it's in the Subject: line :-)

-- Dave

From jnc at mercury.lcs.mit.edu  Mon Aug  5 10:13:07 2019
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun,  4 Aug 2019 20:13:07 -0400 (EDT)
Subject: [TUHS] Set-uid shell scripts
Message-ID: <20190805001307.73F6918C08C@mercury.lcs.mit.edu>

    > From: Dave Horsfall

    > Well, it's in the Subject: line :-)

That was my _assumption_, but you know the old line about assumptions.

     Noel

From emu at e-bbes.com  Tue Aug  6 16:49:34 2019
From: emu at e-bbes.com (emanuel stiebler)
Date: Tue, 6 Aug 2019 08:49:34 +0200
Subject: [TUHS] An Excellent Unix YouTube Video
In-Reply-To: <20190803003336.GA32125@minnie.tuhs.org>
References: <20190803003336.GA32125@minnie.tuhs.org>
Message-ID: <f4d425dd-4d19-6281-1210-6b75881e046c@e-bbes.com>

On 2019-08-03 02:33, Warren Toomey wrote:>
https://www.youtube.com/watch?v=g3jOJfrOknA
>
> National Inventors Hall of Fame - NIHF
> Published on Feb 18, 2019
> Bell Labs colleagues Ken Thompson and Dennis Ritchie developed UNIX,
> a multi-tasking, multi-user operating system alternative to the batch
> processing systems then dominating the computer industry.
>
> Not sure why I hadn't seen this before :)

Specially, as there is even a paper shown in the video, by some
"Warren Toomey" ;-)

From jason-tuhs at shalott.net  Tue Aug  6 18:28:43 2019
From: jason-tuhs at shalott.net (jason-tuhs at shalott.net)
Date: Tue, 6 Aug 2019 01:28:43 -0700 (PDT)
Subject: [TUHS] Set-uid shell scripts
In-Reply-To: <1564954057.6926.for-standards-violators@oclsc.org>
References: <1564954057.6926.for-standards-violators@oclsc.org>
Message-ID: <alpine.LRH.2.21.1908060104130.2617@waffle.shalott.net>


> A related problem is the inherent race condition:
> If you do
> 	ln -s /bin/setuidscript .
> 	./setuidscript
> ./setuidscript is opened twice: once when the kernel
> reads it and finds #! as magic number and execs the
> interpreter, a second time when the interpreter opens
> ./setuidscript.  If you meanwhile run something that
> swoops in in the background and replaces ./setuidscript
> with malicious instructions for the interpreter, you
> win.

This was always described to me as the canonical reason why setuid 
interpreted scripts were a security hole, irrespective of any specifics 
in the shell or other interpreter.

However, there's a workaround: use fdescfs.  fdescfs allows the kernel to 
open the script, and then pass the fdescfs path for the (already open) 
descriptor to the interpreter as the command to run.

According to https://www.in-ulm.de/~mascheck/various/shebang/#setuid, this 
is supported by many systems, including Solaris, several BSDs, and OSX 
(with a sysctl).


  -Jason


From arnold at skeeve.com  Tue Aug  6 19:55:45 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 06 Aug 2019 03:55:45 -0600
Subject: [TUHS] Set-uid shell scripts
In-Reply-To: <alpine.LRH.2.21.1908060104130.2617@waffle.shalott.net>
References: <1564954057.6926.for-standards-violators@oclsc.org>
 <alpine.LRH.2.21.1908060104130.2617@waffle.shalott.net>
Message-ID: <201908060955.x769tjAv005804@freefriends.org>

jason-tuhs at shalott.net wrote:

> > A related problem is the inherent race condition:
> > If you do
> > 	ln -s /bin/setuidscript .
> > 	./setuidscript
> > ./setuidscript is opened twice: once when the kernel
> > reads it and finds #! as magic number and execs the
> > interpreter, a second time when the interpreter opens
> > ./setuidscript.  If you meanwhile run something that
> > swoops in in the background and replaces ./setuidscript
> > with malicious instructions for the interpreter, you
> > win.
>
> This was always described to me as the canonical reason why setuid 
> interpreted scripts were a security hole, irrespective of any specifics 
> in the shell or other interpreter.
>
> However, there's a workaround: use fdescfs.  fdescfs allows the kernel to 
> open the script, and then pass the fdescfs path for the (already open) 
> descriptor to the interpreter as the command to run.

I'm guessing by this you files like /dev/fd/42.

> According to https://www.in-ulm.de/~mascheck/various/shebang/#setuid, this 
> is supported by many systems, including Solaris, several BSDs, and OSX 
> (with a sysctl).

There's a historical disconnect here. Setuid scripts were disabled in
the mid- to late 80s.  /dev/fd didn't hit the commercial Unix world
until SVR4 in 1989, and didn't get into the other systems you mention
until even later.

So yes, that might have worked, but the solution came along too late.

Arnold

From dave at horsfall.org  Wed Aug  7 08:48:59 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 7 Aug 2019 08:48:59 +1000 (EST)
Subject: [TUHS] Set-uid shell scripts
In-Reply-To: <alpine.LRH.2.21.1908060104130.2617@waffle.shalott.net>
References: <1564954057.6926.for-standards-violators@oclsc.org>
 <alpine.LRH.2.21.1908060104130.2617@waffle.shalott.net>
Message-ID: <alpine.BSF.2.21.9999.1908070840370.81938@aneurin.horsfall.org>

On Tue, 6 Aug 2019, jason-tuhs at shalott.net wrote:

[ Replacing a temporary set-uid file ]

> This was always described to me as the canonical reason why setuid 
> interpreted scripts were a security hole, irrespective of any specifics 
> in the shell or other interpreter.

It's a problem for any temporary files in a world-writable directory, 
hence the extensions to directory permissions e.g. /tmp and /var/tmp...

Amusingly enough, the Mac works around this by symlinking /tmp to 
private/tmp i.e. you get your own /tmp...

-- Dave

From rminnich at gmail.com  Wed Aug  7 08:56:17 2019
From: rminnich at gmail.com (ron minnich)
Date: Tue, 6 Aug 2019 15:56:17 -0700
Subject: [TUHS] Set-uid shell scripts
In-Reply-To: <alpine.BSF.2.21.9999.1908070840370.81938@aneurin.horsfall.org>
References: <1564954057.6926.for-standards-violators@oclsc.org>
 <alpine.LRH.2.21.1908060104130.2617@waffle.shalott.net>
 <alpine.BSF.2.21.9999.1908070840370.81938@aneurin.horsfall.org>
Message-ID: <CAP6exYJ761dyccRwVs02723D99OCca8MTJPnHZ7kejZFc-i_PA@mail.gmail.com>

This brought to mind this old discussion:
https://www.tuhs.org/Usenet/comp.unix.wizards/1988-November/023460.html

On Tue, Aug 6, 2019 at 3:49 PM Dave Horsfall <dave at horsfall.org> wrote:
>
> On Tue, 6 Aug 2019, jason-tuhs at shalott.net wrote:
>
> [ Replacing a temporary set-uid file ]
>
> > This was always described to me as the canonical reason why setuid
> > interpreted scripts were a security hole, irrespective of any specifics
> > in the shell or other interpreter.
>
> It's a problem for any temporary files in a world-writable directory,
> hence the extensions to directory permissions e.g. /tmp and /var/tmp...
>
> Amusingly enough, the Mac works around this by symlinking /tmp to
> private/tmp i.e. you get your own /tmp...
>
> -- Dave

From gtaylor at tnetconsulting.net  Wed Aug  7 09:46:58 2019
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 6 Aug 2019 17:46:58 -0600
Subject: [TUHS] Pre-init initialization
Message-ID: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net>

Do, or did, anything other than Linux use a concept of an initramfs / 
initrd to create a pre-(main)-init initialization environment to prepare 
the system to execute the (main)-init process?



-- 
Grant. . . .
unix || die

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

From dave at horsfall.org  Wed Aug  7 11:21:17 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 7 Aug 2019 11:21:17 +1000 (EST)
Subject: [TUHS] Set-uid shell scripts
In-Reply-To: <alpine.BSF.2.21.9999.1908070840370.81938@aneurin.horsfall.org>
References: <1564954057.6926.for-standards-violators@oclsc.org>
 <alpine.LRH.2.21.1908060104130.2617@waffle.shalott.net>
 <alpine.BSF.2.21.9999.1908070840370.81938@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.21.9999.1908071111470.81938@aneurin.horsfall.org>

Just to extend this thread a bit more, when did the set[ug]id bit start 
getting turned off if the file was overwritten?  I've used so many *x 
systems over the years that I cannot remember, but I don't think even root 
was exempt i.e. part of any upgrade process was to put it back again.

-- Dave

From andreww591 at gmail.com  Wed Aug  7 11:22:08 2019
From: andreww591 at gmail.com (Andrew Warkentin)
Date: Tue, 6 Aug 2019 19:22:08 -0600
Subject: [TUHS] Pre-init initialization
In-Reply-To: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net>
References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net>
Message-ID: <CAD-qYGq4CZO=B5Un-wT6MV8-=XiMR=08zaqbqW4R0rhhLTaTMA@mail.gmail.com>

On 8/6/19, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
> Do, or did, anything other than Linux use a concept of an initramfs /
> initrd to create a pre-(main)-init initialization environment to prepare
> the system to execute the (main)-init process?
>

Off the top of my head I'm not aware of any other conventional Unix
besides Linux that uses a memory filesystem for early userspace.
Solaris does use a memory filesystem during boot, but it normally
contains only kernel modules and is only read by the kernel module
linker, and IIRC AIX uses a weird vaguely zImage-like format for its
boot image but I can't remember if the image contains just the kernel
and some modules or if there are userspace programs in it.

As far as unconventional Unix-like OSes go, QNX Neutrino (but not QNX
2 and 4) and Plan 9 both use in-memory filesystems during early
userspace boot, although both only load a single image from disk
rather than a separate kernel and ramdisk. In QNX, the image is a
page-oriented XIP filesystem that contains the kernel and early
userspace as regular files, and in Plan 9 the image is the kernel
executable, which contains a minimal embedded filesystem with a few
user-mode programs.

UX/RT, the OS that I'm writing, will also boot from a memory
filesystem containing the kernel and early userspace in a similar
manner to QNX (it's loosely based on QNX and Plan 9 but is not a clone
of either), although currently it isn't running any real userspace
programs.

From dave at horsfall.org  Wed Aug  7 12:35:49 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 7 Aug 2019 12:35:49 +1000 (EST)
Subject: [TUHS] Who's behind the UNIX filesystem permission
In-Reply-To: <20190801234351.04A9118C0A1@mercury.lcs.mit.edu>
References: <20190801234351.04A9118C0A1@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.21.9999.1908071225090.81938@aneurin.horsfall.org>

On Thu, 1 Aug 2019, Noel Chiappa wrote:

> Maybe the application was written by a LISP programmer? :-)
>
> (Not really, of course; it was probably just someone who didn't know much
> about Unix. They had a list of system calls, and 'unlink' probably said ' only
> works on directories when the caller is root', so...)

I dimly recall that there was a little-documented utility /etc/unlink 
which did just that; it was probably not on all systems, but was on our 
CCI Power 6/32.

I only discovered their incompetence at the next reboot, when I had to 
clean up all the orphaned (but temporary) files that were left behind 
because [idn]check went berserk (we didn't have fsck back then).

-- Dave

From benito.buchheim at student.hpi.de  Wed Aug  7 17:51:34 2019
From: benito.buchheim at student.hpi.de (Benito Buchheim)
Date: Wed, 7 Aug 2019 09:51:34 +0200
Subject: [TUHS] Running Research Unix v3 on simh
Message-ID: <9e68c3f4-af37-a70f-2a1a-530dfcf0ae51@student.hpi.de>

Hello everyone,

My name is Benito Buchheim and I am a computer science student at 
Hasso-Plattner-Institute in Germany.
During our Operating Systems Course we came across The Unix Heritage 
Society, more specifically Research Unix Version 3, and took a look into 
the source code of this version.
The idea arose to try to get this running somehow as a sort of voluntary 
task.

So I started digging my way through the available material and quickly 
found the "modified_nsys" version by Warren Toomey, which conveniently 
contained a very detailed readme file on how to compile and run this 
version on a Unix v5 emulator.
Thus, I started cloning the simh Github Repository and built the pdp11 
emulator.
After downloading the v5root disk image and figuring out how to use simh 
to run it, I had a working Unix v5, but struggled a bit to copy more 
than one file onto it using the emulated devices.
In the end, I used a very Hacky way and wrote a short python script 
which just runs the emulator and "copy pastes" the folder structure into 
the image. I now thought to be ready to start working my way through 
Toomey's readme.

Unfortunately already the first command failed quite miserably. I 
changed my working directory and ran the first shell script to compile 
the kernel, but cc spat out loads of error messages which are not very 
detailed. As this is a very early version of c code I am kinda stuck at 
this point and running a bit out of ideas on what may have gone wrong.
As there is this mailing list we thought to have a chat with the 
experts. Maybe there is somebody who could help or give a hint on how to 
get this running on the pdp11 emulator.

I attached my shell script output and the v5 image containing the v3 
source code in the /sys/nsys directory.
It can be downloaded here:
https://www.mission-eins.de/runningv3.zip

Thanks a lot and best wishes from a small suburb near Berlin,
Benito Buchheim


From chet.ramey at case.edu  Wed Aug  7 22:56:10 2019
From: chet.ramey at case.edu (Chet Ramey)
Date: Wed, 7 Aug 2019 08:56:10 -0400
Subject: [TUHS] Set-uid shell scripts
In-Reply-To: <alpine.BSF.2.21.9999.1908070840370.81938@aneurin.horsfall.org>
References: <1564954057.6926.for-standards-violators@oclsc.org>
 <alpine.LRH.2.21.1908060104130.2617@waffle.shalott.net>
 <alpine.BSF.2.21.9999.1908070840370.81938@aneurin.horsfall.org>
Message-ID: <c411365d-184d-ecfc-9e33-150efa8b2187@case.edu>

On 8/6/19 6:48 PM, Dave Horsfall wrote:

> It's a problem for any temporary files in a world-writable directory, hence
> the extensions to directory permissions e.g. /tmp and /var/tmp...
> 
> Amusingly enough, the Mac works around this by symlinking /tmp to
> private/tmp i.e. you get your own /tmp...

/private/tmp is still word-writable with the sticky bit set. What you do
get is a private $TMPDIR, e.g.,

/var/folders/41/pgctqv8s3_301dzlcghzcbs800008y/T/


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://tiswww.cwru.edu/~chet/

From clemc at ccc.com  Wed Aug  7 23:04:36 2019
From: clemc at ccc.com (Clem Cole)
Date: Wed, 7 Aug 2019 09:04:36 -0400
Subject: [TUHS] Pre-init initialization
In-Reply-To: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net>
References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net>
Message-ID: <CAC20D2PjoKqSfEeBu9pJuOOR772hDhwmUh_k0TbYZU-WTnHSNA@mail.gmail.com>

A couple of the commercial systems did this for sure. Linux definitely
picked it up from UNIX practices, although I have no idea/memory of who did
it first.  We used the idea at Stellar (Stellix) and at Masscomp (RTU).
IIRC, a couple of others like Pyramid made have created a RAMFS - but it
was kicking around the UNIX community for a fairly long time - certainly in
the late 1970s - *i.e.* post V7.

FWIW: V7 had /stand which was a funky UNIX-like standalone system that some
applications could be compiled.  The problem was that it was a little
different so you would end up seeing #ifdef STAND in code for things like
fsck, fsdb, even cat.  At Masscomp we ended up with three target
environments for a couple of the system maintenance utilities: the OS,
/stand and the boot ROMS.   This was expensive/a PITA to maintain and keep
straight, and in the case of the boot ROM, space was a huge problem.

The RAMFS idea was created to get rid of at least /stand and IIRC we were
able to drop a number of utilities out of the boot ROM.  I'm not sure how
far they took it.   I left for Stellar and it was always the way Stellix
booted.



On Tue, Aug 6, 2019 at 7:47 PM Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
wrote:

> Do, or did, anything other than Linux use a concept of an initramfs /
> initrd to create a pre-(main)-init initialization environment to prepare
> the system to execute the (main)-init process?
>
>
>
> --
> Grant. . . .
> unix || die
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190807/be3db5da/attachment.html>

From imp at bsdimp.com  Thu Aug  8 02:40:06 2019
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 7 Aug 2019 10:40:06 -0600
Subject: [TUHS] Pre-init initialization
In-Reply-To: <CAC20D2PjoKqSfEeBu9pJuOOR772hDhwmUh_k0TbYZU-WTnHSNA@mail.gmail.com>
References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net>
 <CAC20D2PjoKqSfEeBu9pJuOOR772hDhwmUh_k0TbYZU-WTnHSNA@mail.gmail.com>
Message-ID: <CANCZdfpPbnB+8GGbzT65dRigDEX=i4qQEsy9MKyV3TnxS8-v2w@mail.gmail.com>

The move into RAM disks happened as memories grew. This obviated the need
to copy a filesystem to a new disk's swap space and then use that to really
install the system.

Kernels with bundled RAM disks were a thing in BSD for a long time, though
I'm unsure when that functionality entered the code stream. I know the
early versions of FreeBSD's installer ran out of a RAM disk loaded off
floppies, though that's not the same as initrd since there never was a
pivot to something else: just a reboot to boot the real thing.

FreeBSD, at least, has the functionality to also do a RAM disk to get
things configured enough to pivot to the real disk on boot, but that's a
niche operation there: most everybody just boots off / directly without the
initrd-like thing. It's rarely needed, but it's one of those things that
when it is needed, it's really needed, which is why one can do it.

FreeBSD has an interesting 'tertiary loader' that plays a similar role to
initrd. It orchestrates loading of modules, setting tunable parameters and
launching the kernel. It's grown up to be a mini-kernel stand-alone
program, but as the real kernel is now 28MB, the boot loader leverages off
'boot services' or other well-known interfaces to weigh in at only a few
hundred k. This has proven to be both a blessing and a curse at times,
however.

Warner

On Wed, Aug 7, 2019 at 7:05 AM Clem Cole <clemc at ccc.com> wrote:

> A couple of the commercial systems did this for sure. Linux definitely
> picked it up from UNIX practices, although I have no idea/memory of who did
> it first.  We used the idea at Stellar (Stellix) and at Masscomp (RTU).
> IIRC, a couple of others like Pyramid made have created a RAMFS - but it
> was kicking around the UNIX community for a fairly long time - certainly in
> the late 1970s - *i.e.* post V7.
>
> FWIW: V7 had /stand which was a funky UNIX-like standalone system that
> some applications could be compiled.  The problem was that it was a little
> different so you would end up seeing #ifdef STAND in code for things like
> fsck, fsdb, even cat.  At Masscomp we ended up with three target
> environments for a couple of the system maintenance utilities: the OS,
> /stand and the boot ROMS.   This was expensive/a PITA to maintain and keep
> straight, and in the case of the boot ROM, space was a huge problem.
>
> The RAMFS idea was created to get rid of at least /stand and IIRC we were
> able to drop a number of utilities out of the boot ROM.  I'm not sure how
> far they took it.   I left for Stellar and it was always the way Stellix
> booted.
>
>
>
> On Tue, Aug 6, 2019 at 7:47 PM Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
> wrote:
>
>> Do, or did, anything other than Linux use a concept of an initramfs /
>> initrd to create a pre-(main)-init initialization environment to prepare
>> the system to execute the (main)-init process?
>>
>>
>>
>> --
>> Grant. . . .
>> unix || die
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190807/a9d172be/attachment.html>

From dave at horsfall.org  Thu Aug  8 07:33:47 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 8 Aug 2019 07:33:47 +1000 (EST)
Subject: [TUHS] Set-uid shell scripts
In-Reply-To: <40c92e85142fe7e3@orthanc.ca>
References: <1564954057.6926.for-standards-violators@oclsc.org>
 <alpine.LRH.2.21.1908060104130.2617@waffle.shalott.net>
 <alpine.BSF.2.21.9999.1908070840370.81938@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.1908071111470.81938@aneurin.horsfall.org>
 <40c92e85142fe7e3@orthanc.ca>
Message-ID: <alpine.BSF.2.21.9999.1908080724190.81938@aneurin.horsfall.org>

On Tue, 6 Aug 2019, Lyndon Nerenberg wrote:

>> Just to extend this thread a bit more, when did the set[ug]id bit start 
>> getting turned off if the file was overwritten?
>
> I'm pretty sure that's been the case since the dawn of time.

Hmmm...  I have this vague memory of V5 (which I only used for a couple of 
months before we got V6) not clearing that bit, but after all these years 
my memory is starting to fail me :-(

> It was certainly the case in every System V (release 0 and beyond) I 
> worked with, along with many BSDs derivatives (SunOS 3+, Ultrix, etc). 
> (And Xenix, which had it's own insanity that I now think selinux is 
> trying to inflict on me.)

I've always thought that Xenix was insane to start with...  Then again, my 
first experience with it was on a 286...  Now, when porting Unify, should 
I use large memory model here or small memory model?  Crazy.

> This has been documented in chown(2) for as long as I can remember, so 
> that's a good place to start if you want to dig back through the various 
> source trees.

I don't have access to the sources right now, but I'll take your word for 
it; it was just a passing thought.

-- Dave

From dave at horsfall.org  Thu Aug  8 07:40:52 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 8 Aug 2019 07:40:52 +1000 (EST)
Subject: [TUHS] Set-uid shell scripts
In-Reply-To: <c411365d-184d-ecfc-9e33-150efa8b2187@case.edu>
References: <1564954057.6926.for-standards-violators@oclsc.org>
 <alpine.LRH.2.21.1908060104130.2617@waffle.shalott.net>
 <alpine.BSF.2.21.9999.1908070840370.81938@aneurin.horsfall.org>
 <c411365d-184d-ecfc-9e33-150efa8b2187@case.edu>
Message-ID: <alpine.BSF.2.21.9999.1908080734080.81938@aneurin.horsfall.org>

On Wed, 7 Aug 2019, Chet Ramey wrote:

>> Amusingly enough, the Mac works around this by symlinking /tmp to 
>> private/tmp i.e. you get your own /tmp...
>
> /private/tmp is still word-writable with the sticky bit set. What you do 
> get is a private $TMPDIR, e.g.,
>
> /var/folders/41/pgctqv8s3_301dzlcghzcbs800008y/T/

Aha!  You have just unwittingly solved a mystery for me :-)  I was 
wondering where those files were coming from...

I'm not really a Mac freak; apart from the occasional port, I just use it 
to SSH into my FreeBSD server, with multiple Terminals all over the 
screen..

Thanks!

-- Dave

From athornton at gmail.com  Thu Aug  8 15:16:51 2019
From: athornton at gmail.com (Adam Thornton)
Date: Wed, 7 Aug 2019 22:16:51 -0700
Subject: [TUHS] Set-uid shell scripts
In-Reply-To: <alpine.BSF.2.21.9999.1908080734080.81938@aneurin.horsfall.org>
References: <1564954057.6926.for-standards-violators@oclsc.org>
 <alpine.LRH.2.21.1908060104130.2617@waffle.shalott.net>
 <alpine.BSF.2.21.9999.1908070840370.81938@aneurin.horsfall.org>
 <c411365d-184d-ecfc-9e33-150efa8b2187@case.edu>
 <alpine.BSF.2.21.9999.1908080734080.81938@aneurin.horsfall.org>
Message-ID: <B96F5844-B97C-4BC7-904D-E23FB0A020C7@gmail.com>



> On Aug 7, 2019, at 2:40 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> I'm not really a Mac freak; apart from the occasional port, I just use it to SSH into my FreeBSD server, with multiple Terminals all over the screen..


iTerm2 is really rather nice.

Folks here may be interested in a new toy of mine:

https://mvsevm.fsf.net

Currently, the TOPS-10 guest account (42,42) and the Unix v7 account dmr have no passwords.

Please treat the dmr account respectfully.

I will get to account requests…eventually, probably.  TImeliness is not guaranteed.  All systems are hosted on Raspberry Pis (the 36-bit ones on a Pi 3B+ and the 16-bit and 32-bit ones on a Pi 2B+) on Debian Buster.  Absolutely no guarantee of availability or usability is made.

Adam



From peter at rulingia.com  Thu Aug  8 16:39:03 2019
From: peter at rulingia.com (Peter Jeremy)
Date: Thu, 8 Aug 2019 16:39:03 +1000
Subject: [TUHS] Set-uid shell scripts
In-Reply-To: <alpine.BSF.2.21.9999.1908080724190.81938@aneurin.horsfall.org>
References: <1564954057.6926.for-standards-violators@oclsc.org>
 <alpine.LRH.2.21.1908060104130.2617@waffle.shalott.net>
 <alpine.BSF.2.21.9999.1908070840370.81938@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.1908071111470.81938@aneurin.horsfall.org>
 <40c92e85142fe7e3@orthanc.ca>
 <alpine.BSF.2.21.9999.1908080724190.81938@aneurin.horsfall.org>
Message-ID: <20190808063903.GB84848@server.rulingia.com>

On 2019-Aug-08 07:33:47 +1000, Dave Horsfall <dave at horsfall.org> wrote:
>I've always thought that Xenix was insane to start with...  Then again, my 
>first experience with it was on a 286...  Now, when porting Unify, should 
>I use large memory model here or small memory model?  Crazy.

Ah, yes.  I remember it well.  The large, small and various mixed modes
were a consequence of the braindeadedness of the 286 - reloading segment
registers (pretty much every memory reference in large mode) was abysmally
slow.  I recall hacking mg (a cut-down emacs clone) so that buffers were
in "far" memory and everything else was "near".

Some of the Xenix features I recall were:
* occasionally fork() would return -1 in both the parent and child (or
  something like that - it would both succeed and report failure)
* The contents of comments would affect the Pascal compiler's ability
  to compile the program (this was "using uninitialised variables"
  behaviour, rather than magic lint-style comments).  It made software
  development "interesting" because checking a program into SCCS might
  stop it compiling.
* fork()ing a large process could panic the system.
* The C compiler barfed on parts of starchart (from comp.sources.???)

-- 
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/20190808/430130c2/attachment.sig>

From tytso at mit.edu  Thu Aug  8 23:31:24 2019
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Thu, 8 Aug 2019 09:31:24 -0400
Subject: [TUHS] Pre-init initialization
In-Reply-To: <CANCZdfpPbnB+8GGbzT65dRigDEX=i4qQEsy9MKyV3TnxS8-v2w@mail.gmail.com>
References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net>
 <CAC20D2PjoKqSfEeBu9pJuOOR772hDhwmUh_k0TbYZU-WTnHSNA@mail.gmail.com>
 <CANCZdfpPbnB+8GGbzT65dRigDEX=i4qQEsy9MKyV3TnxS8-v2w@mail.gmail.com>
Message-ID: <20190808133124.GA3340@mit.edu>

On Wed, Aug 07, 2019 at 10:40:06AM -0600, Warner Losh wrote:
> The move into RAM disks happened as memories grew. This obviated the need
> to copy a filesystem to a new disk's swap space and then use that to really
> install the system.
> 
> Kernels with bundled RAM disks were a thing in BSD for a long time, though
> I'm unsure when that functionality entered the code stream. I know the
> early versions of FreeBSD's installer ran out of a RAM disk loaded off
> floppies, though that's not the same as initrd since there never was a
> pivot to something else: just a reboot to boot the real thing.

I implemented loading the root file system as a ramdisk from a floppy
in 1991 for Linux.  This predates the publication of 386BSD, and I
wasn't aware of how commercial Unix systems did their initial
installation and setup.  So as far as I know I came up on it on my
own, but none of this was especially earthshaking or subtle.

Linux's ramdisk was implemented because most PC's of the day (I was
using a 40 MHz 386 with only a megabyte of memory) only had a single
floppy drive (and if they had a second it was a 5.25" drive).  So the
very first implementation which I did assumed the kernel would be no
larger than 512k, and looked for Minix file system signature at 512k.
If it existed, it would load it into the ramdisk and use that as the
boot region.

Before that, the kernel was loaded from the first floppy, and then
kernel would prompt the user to eject the boot disk and insert the
root disk, and hit any key to continue, and then it would mount the
root disk.  But then the only floppy drive would be tied up with the
root file system, so that meant there needed to be a second kernel on
the root floppy, and everything else needed to set up the root image
would have to be copied to the hard disk, and then you'd have to
reboot to release the floppy drive so you could install other programs
that couldn't fit on that initial 1.44MB root floppy.

For people who are interested in the history of initrd used as part of
the boot process in Linux, please refer to Werner Almesberger's 2000
paper, "Booting Linux: The History and the Future"[1], presented at the
Ottawa Linux Symposium.

[1] http://www.almesberger.net/cv/papers/ols2k-9.ps.gz

Cheers,

					- Ted

From clemc at ccc.com  Thu Aug  8 23:43:15 2019
From: clemc at ccc.com (Clem Cole)
Date: Thu, 8 Aug 2019 09:43:15 -0400
Subject: [TUHS] Pre-init initialization
In-Reply-To: <CANCZdfpPbnB+8GGbzT65dRigDEX=i4qQEsy9MKyV3TnxS8-v2w@mail.gmail.com>
References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net>
 <CAC20D2PjoKqSfEeBu9pJuOOR772hDhwmUh_k0TbYZU-WTnHSNA@mail.gmail.com>
 <CANCZdfpPbnB+8GGbzT65dRigDEX=i4qQEsy9MKyV3TnxS8-v2w@mail.gmail.com>
Message-ID: <CAC20D2Pu0Jwfs=qFc2gVAzDpyuR4gvPepo8RVuC-=YsPM4keoQ@mail.gmail.com>

On Wed, Aug 7, 2019 at 12:40 PM Warner Losh <imp at bsdimp.com> wrote:

> This obviated the need to copy a filesystem to a new disk's swap space and
> then use that to really install the system.
>

Thanks for the reminder.   I don't remember if V7 on the PDP-11 used the
swap space (but I don't think so). That said, I fairly sure that by BSD 4.1
the boot loader did, which I think is when that trick was first added to
boot phase.

Again, it was all about trying to get rid of the special /stand version of
things.   Funny, history would move on and we come back to that idea with
busybox 🤔
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190808/206f7495/attachment.html>

From imp at bsdimp.com  Fri Aug  9 04:59:23 2019
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 8 Aug 2019 12:59:23 -0600
Subject: [TUHS] Pre-init initialization
In-Reply-To: <CAC20D2Pu0Jwfs=qFc2gVAzDpyuR4gvPepo8RVuC-=YsPM4keoQ@mail.gmail.com>
References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net>
 <CAC20D2PjoKqSfEeBu9pJuOOR772hDhwmUh_k0TbYZU-WTnHSNA@mail.gmail.com>
 <CANCZdfpPbnB+8GGbzT65dRigDEX=i4qQEsy9MKyV3TnxS8-v2w@mail.gmail.com>
 <CAC20D2Pu0Jwfs=qFc2gVAzDpyuR4gvPepo8RVuC-=YsPM4keoQ@mail.gmail.com>
Message-ID: <CANCZdfqksWFQ-vMZtZjaQO0agCrdrDL0HeMEwjD1mLnBC9+CVA@mail.gmail.com>

On Thu, Aug 8, 2019 at 7:43 AM Clem Cole <clemc at ccc.com> wrote:

>
>
> On Wed, Aug 7, 2019 at 12:40 PM Warner Losh <imp at bsdimp.com> wrote:
>
>> This obviated the need to copy a filesystem to a new disk's swap space
>> and then use that to really install the system.
>>
>
> Thanks for the reminder.   I don't remember if V7 on the PDP-11 used the
> swap space (but I don't think so). That said, I fairly sure that by BSD 4.1
> the boot loader did, which I think is when that trick was first added to
> boot phase.
>

Just checked the archives. V7 had a stand alone program to restore a
filesystem image form the tape to the disk that you ran after running the
stand alone program to partition and newfs the disk... I think you are
right on your timeline. I installed a dozen Sun3 boxes from tape and hated
mistyping the file number and having to start over...


> Again, it was all about trying to get rid of the special /stand version of
> things.   Funny, history would move on and we come back to that idea with
> busybox 🤔
>

Well, busybox is special in many ways, so there's that in common with
/stand, but it runs under a full otherwise standard kernel, not as some
special mini-exec that provides just enough of the unix APIs to keep the
standalone programs happy.

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

From gtaylor at tnetconsulting.net  Fri Aug  9 11:46:22 2019
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Thu, 8 Aug 2019 19:46:22 -0600
Subject: [TUHS] Pre-init initialization
In-Reply-To: <CAC20D2PjoKqSfEeBu9pJuOOR772hDhwmUh_k0TbYZU-WTnHSNA@mail.gmail.com>
References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net>
 <CAC20D2PjoKqSfEeBu9pJuOOR772hDhwmUh_k0TbYZU-WTnHSNA@mail.gmail.com>
Message-ID: <94138535-c502-109d-752d-5ef7a6d53b23@spamtrap.tnetconsulting.net>

On 8/7/19 7:04 AM, Clem Cole wrote:
> FWIW: V7 had /stand which was a funky UNIX-like standalone system that 
> some applications could be compiled.

I've seen /stand on a few systems (I think SCO OpenServer and / or 
UnixWare) but never really knew what it was for.  I think I had naively 
assumed it was associated with the kernel and / or booting.

Now I'm somewhat more curious what it was.  Was it a simplified version 
of the OS with minimal utilities with fewer dependencies so that the 
system could boot and load more features.

I thought that Linux's initramfs / initrd had the usual suspect files / 
utilities copied from /.  So the idea that a utility in /stand would be 
different from the same utility in / seems strange to me.

> The problem was that it was a little different so you would end up 
> seeing #ifdef STAND in code for things like fsck, fsdb, even cat. 
> At Masscomp we ended up with three target environments for a couple of 
> the system maintenance utilities: the OS, /stand and the boot ROMS. 
> This was expensive/a PITA to maintain and keep straight, and in the 
> case of the boot ROM, space was a huge problem.

Ya.  I can see how that would be a PITA to maintain.

> The RAMFS idea was created to get rid of at least /stand and IIRC we 
> were able to drop a number of utilities out of the boot ROM.  I'm not 
> sure how far they took it.   I left for Stellar and it was always the 
> way Stellix booted.

ACK



-- 
Grant. . . .
unix || die

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

From gtaylor at tnetconsulting.net  Fri Aug  9 11:52:04 2019
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Thu, 8 Aug 2019 19:52:04 -0600
Subject: [TUHS] Pre-init initialization
In-Reply-To: <20190808133124.GA3340@mit.edu>
References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net>
 <CAC20D2PjoKqSfEeBu9pJuOOR772hDhwmUh_k0TbYZU-WTnHSNA@mail.gmail.com>
 <CANCZdfpPbnB+8GGbzT65dRigDEX=i4qQEsy9MKyV3TnxS8-v2w@mail.gmail.com>
 <20190808133124.GA3340@mit.edu>
Message-ID: <ccdd93f2-2cc9-d3f4-757a-24fc0efd3da6@spamtrap.tnetconsulting.net>

On 8/8/19 7:31 AM, Theodore Y. Ts'o wrote:
> I implemented loading the root file system as a ramdisk from a 
> floppy in 1991 for Linux.

Impressive.

> This predates the publication of 386BSD, and I wasn't aware of how 
> commercial Unix systems did their initial installation and setup. 
> So as far as I know I came up on it on my own, but none of this was 
> especially earthshaking or subtle.

That logic makes sense to me.

> Linux's ramdisk was implemented because most PC's of the day (I was 
> using a 40 MHz 386 with only a megabyte of memory) only had a single 
> floppy drive (and if they had a second it was a 5.25" drive).  So the 
> very first implementation which I did assumed the kernel would be no 
> larger than 512k, and looked for Minix file system signature at 512k. 
> If it existed, it would load it into the ramdisk and use that as the 
> boot region.

That's before my time.  If I remember correctly, by the time I was 
creating boot+root disks it was the kernel plus something—I don't 
remember if it was an initramfs or an initrd—concatenated together.  I 
also remember having to use a utility to update the kernel to tell it 
where the something started.  Which was really based on how big the 
kernel was as padding before the something started.  That was probably 
2.<something> on Slackware in '99.

> Before that, the kernel was loaded from the first floppy, and then 
> kernel would prompt the user to eject the boot disk and insert the 
> root disk, and hit any key to continue, and then it would mount the 
> root disk.

I remember doing that.  But perhaps it was for a different reason.

> But then the only floppy drive would be tied up with the root file 
> system, so that meant there needed to be a second kernel on the root 
> floppy, and everything else needed to set up the root image would 
> have to be copied to the hard disk, and then you'd have to reboot 
> to release the floppy drive so you could install other programs that 
> couldn't fit on that initial 1.44MB root floppy.
> 
> For people who are interested in the history of initrd used as part 
> of the boot process in Linux, please refer to Werner Almesberger's 
> 2000 paper, "Booting Linux: The History and the Future"[1], presented 
> at the Ottawa Linux Symposium.
> 
> [1] http://www.almesberger.net/cv/papers/ols2k-9.ps.gz

I will definitely check that out.  Thank you for the link.

> Cheers,

:-)



-- 
Grant. . . .
unix || die

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

From imp at bsdimp.com  Fri Aug  9 12:15:34 2019
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 8 Aug 2019 20:15:34 -0600
Subject: [TUHS] Pre-init initialization
In-Reply-To: <94138535-c502-109d-752d-5ef7a6d53b23@spamtrap.tnetconsulting.net>
References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net>
 <CAC20D2PjoKqSfEeBu9pJuOOR772hDhwmUh_k0TbYZU-WTnHSNA@mail.gmail.com>
 <94138535-c502-109d-752d-5ef7a6d53b23@spamtrap.tnetconsulting.net>
Message-ID: <CANCZdfpZgYTBWjMpKkEF8sseAo-62h50ERJsTQSvF2Fn_G1Gjg@mail.gmail.com>

On Thu, Aug 8, 2019, 7:47 PM Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
wrote:

> On 8/7/19 7:04 AM, Clem Cole wrote:
> > FWIW: V7 had /stand which was a funky UNIX-like standalone system that
> > some applications could be compiled.
>
> I've seen /stand on a few systems (I think SCO OpenServer and / or
> UnixWare) but never really knew what it was for.  I think I had naively
> assumed it was associated with the kernel and / or booting.
>
> Now I'm somewhat more curious what it was.  Was it a simplified version
> of the OS with minimal utilities with fewer dependencies so that the
> system could boot and load more features.
>

Yes. There was a library that implemented much of the unix API in a
simplified way that ran on bare metal.

I thought that Linux's initramfs / initrd had the usual suspect files /
> utilities copied from /.  So the idea that a utility in /stand would be
> different from the same utility in / seems strange to me.
>

They are because there was no kernel for them to run under. They were
similar, but if you go look at the sources, they are different.

> The problem was that it was a little different so you would end up
> > seeing #ifdef STAND in code for things like fsck, fsdb, even cat.
> > At Masscomp we ended up with three target environments for a couple of
> > the system maintenance utilities: the OS, /stand and the boot ROMS.
> > This was expensive/a PITA to maintain and keep straight, and in the
> > case of the boot ROM, space was a huge problem.
>
> Ya.  I can see how that would be a PITA to maintain.
>

FreeBSD, NetBSD and OpenBSD all implement some version of this. FreeBSD has
it in src/stand in honor of V7 stand. I did that when I integrate / rewrote
the GSoC project to bring Lua scripting to the boot loader. The other BSDs
have it split between sys/boot and lib/libs. FreeBSD uses it to implement
the rich boot loader which knows how to load off a lot of different file
systems and BIOS interfaces. Net/OpenBSD use it more modestly in their boot
loaders, but have a few standalone programs for things like bootstrapping
VAXen.

Warner

> The RAMFS idea was created to get rid of at least /stand and IIRC we
> > were able to drop a number of utilities out of the boot ROM.  I'm not
> > sure how far they took it.   I left for Stellar and it was always the
> > way Stellix booted.
>
> ACK
>
>
>
> --
> Grant. . . .
> unix || die
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190808/28a5b369/attachment.html>

From kevin.bowling at kev009.com  Fri Aug  9 16:43:09 2019
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Thu, 8 Aug 2019 23:43:09 -0700
Subject: [TUHS] Pre-init initialization
In-Reply-To: <CANCZdfpZgYTBWjMpKkEF8sseAo-62h50ERJsTQSvF2Fn_G1Gjg@mail.gmail.com>
References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net>
 <CAC20D2PjoKqSfEeBu9pJuOOR772hDhwmUh_k0TbYZU-WTnHSNA@mail.gmail.com>
 <94138535-c502-109d-752d-5ef7a6d53b23@spamtrap.tnetconsulting.net>
 <CANCZdfpZgYTBWjMpKkEF8sseAo-62h50ERJsTQSvF2Fn_G1Gjg@mail.gmail.com>
Message-ID: <CAK7dMtAWK+SahB+KQ8qHQcN+0krRtMtvCVM-=560hC_-tEJWsw@mail.gmail.com>

On Thu, Aug 8, 2019 at 7:16 PM Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Thu, Aug 8, 2019, 7:47 PM Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
> wrote:
>
>> On 8/7/19 7:04 AM, Clem Cole wrote:
>> > FWIW: V7 had /stand which was a funky UNIX-like standalone system that
>> > some applications could be compiled.
>>
>> I've seen /stand on a few systems (I think SCO OpenServer and / or
>> UnixWare) but never really knew what it was for.  I think I had naively
>> assumed it was associated with the kernel and / or booting.
>>
>> Now I'm somewhat more curious what it was.  Was it a simplified version
>> of the OS with minimal utilities with fewer dependencies so that the
>> system could boot and load more features.
>>
>
> Yes. There was a library that implemented much of the unix API in a
> simplified way that ran on bare metal.
>
> I thought that Linux's initramfs / initrd had the usual suspect files /
>> utilities copied from /.  So the idea that a utility in /stand would be
>> different from the same utility in / seems strange to me.
>>
>
> They are because there was no kernel for them to run under. They were
> similar, but if you go look at the sources, they are different.
>
> > The problem was that it was a little different so you would end up
>> > seeing #ifdef STAND in code for things like fsck, fsdb, even cat.
>> > At Masscomp we ended up with three target environments for a couple of
>> > the system maintenance utilities: the OS, /stand and the boot ROMS.
>> > This was expensive/a PITA to maintain and keep straight, and in the
>> > case of the boot ROM, space was a huge problem.
>>
>> Ya.  I can see how that would be a PITA to maintain.
>>
>
> FreeBSD, NetBSD and OpenBSD all implement some version of this. FreeBSD
> has it in src/stand in honor of V7 stand. I did that when I integrate /
> rewrote the GSoC project to bring Lua scripting to the boot loader. The
> other BSDs have it split between sys/boot and lib/libs. FreeBSD uses it to
> implement the rich boot loader which knows how to load off a lot of
> different file systems and BIOS interfaces. Net/OpenBSD use it more
> modestly in their boot loaders, but have a few standalone programs for
> things like bootstrapping VAXen.
>

Yeah NetBSD has little gadgets in the ports stand directory for booting odd
hardware.  It would be preferable to have something like FreeBSD’s loader
everywhere, but that would be hard to cover to the swath of ports NetBSD
has, and would still require chain loading gadgets for many platforms.

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

From imp at bsdimp.com  Sat Aug 10 01:10:01 2019
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 9 Aug 2019 09:10:01 -0600
Subject: [TUHS] MERT aka UNIX/RT
Message-ID: <CANCZdfoL_Mxd5zr-RY9tA2kc09fN+hpyP13ztiAt_J0GLZ9H7g@mail.gmail.com>

Greetings,

I was wondering if there were any early versions of MERT available?

Reading different sources, it appears that MERT was a real time kernel that
used EMT traps to implement unix system calls (from around V4 or V5 given
the timelines) on top of a real time executive (though some sources seem to
imply it was a derivative of V4, most disagree).

I see this in our archives
https://wiki.tuhs.org/doku.php?id=misc:snippets:mert1 which is quite handy
for discover its (and other early) unix lineages for a talk I'm doing in
about a month. Now that we have sources, I go back and double check the
recollections of things like this to see if version numbers were right,
etc. But I can't do that with MERT at all. I can find the Bell Systems
Technical Journal for Unix that has a brief article on it, but no sources
to double check.

So I thought I'd ask here if we have any MERT artifacts I can look at that
have escaped my casual browsing of the archive. So far I've just found an
email from Kevin Bowling on the topic from last month with no replies. And
a similar thread from 2002, plus pleading from time to time (I can't tell
if Warren or Noel wants it more :).

I guess the same could be said for CB-UNIX and UNIX/TS, though I see a
USDL/CB_Unix directory in the archive I could look at :).

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

From tytso at mit.edu  Sat Aug 10 10:23:08 2019
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Fri, 9 Aug 2019 20:23:08 -0400
Subject: [TUHS] Pre-init initialization
In-Reply-To: <ccdd93f2-2cc9-d3f4-757a-24fc0efd3da6@spamtrap.tnetconsulting.net>
References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net>
 <CAC20D2PjoKqSfEeBu9pJuOOR772hDhwmUh_k0TbYZU-WTnHSNA@mail.gmail.com>
 <CANCZdfpPbnB+8GGbzT65dRigDEX=i4qQEsy9MKyV3TnxS8-v2w@mail.gmail.com>
 <20190808133124.GA3340@mit.edu>
 <ccdd93f2-2cc9-d3f4-757a-24fc0efd3da6@spamtrap.tnetconsulting.net>
Message-ID: <20190810002308.GB8368@mit.edu>

On Thu, Aug 08, 2019 at 07:52:04PM -0600, Grant Taylor via TUHS wrote:
> That's before my time.  If I remember correctly, by the time I was creating
> boot+root disks it was the kernel plus something—I don't remember if it was
> an initramfs or an initrd—concatenated together.  I also remember having to
> use a utility to update the kernel to tell it where the something started.
> Which was really based on how big the kernel was as padding before the
> something started.  That was probably 2.<something> on Slackware in '99.

In 1993 Fred van Kempen (who did the original Linux TCP stack before I
got rewritten by Alan Cox's Net-2 stack) added a patch to the ramdisk
code which so the root file system would be loaded from a second
floppy into the ramdisk.  That was because he wanted to fit more into
stuff into the root file system, and by using a second floppy, the
full 1.44MB could be used for the root file system in the ramdisk.  As
I recall the kernel was also getting bigger than 512k, too.

In '95, Slackware started releasing on CD-ROM's, and while there may
have been boot/root floppies, I suspect more and more they were used
as rescue media, since installing from a CD-ROM was *way* more
convenient.

I'm guesing what you were doing was creating a kernel plus initramfs
which was sufficient to mount a root file system elsewhere as an
emergency "boot this failsafe kernel off the floppy", perhaps?  I
don't think a kernel+initramfs on a single 1.44MB floppy would have
been sufficient for use as an install medium by '99.  Or were you
making an emergency USB thumb-drive as a rescue device, maybe?

Cheers,

				- Ted

From cmhanson at eschatologist.net  Sat Aug 10 11:45:41 2019
From: cmhanson at eschatologist.net (Chris Hanson)
Date: Fri, 9 Aug 2019 18:45:41 -0700
Subject: [TUHS] Pre-init initialization
In-Reply-To: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net>
References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net>
Message-ID: <88A08A53-33F2-4630-B39D-30316AD10D10@eschatologist.net>

On Aug 6, 2019, at 4:46 PM, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
> 
> Do, or did, anything other than Linux use a concept of an initramfs / initrd to create a pre-(main)-init initialization environment to prepare the system to execute the (main)-init process?

Mach-based UNIX systems (can) have a Mach init that’s separate from UNIX pid 1 init.

When using a non-colocated UNIX subsystem (like the BSD Single Server) I think I recall that’s how the UNIX subsystem is started, along with other Mach tasks like the port name server.

  -- Chris



From gtaylor at tnetconsulting.net  Sat Aug 10 12:28:55 2019
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Fri, 9 Aug 2019 20:28:55 -0600
Subject: [TUHS] Pre-init initialization
In-Reply-To: <20190810002308.GB8368@mit.edu>
References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net>
 <CAC20D2PjoKqSfEeBu9pJuOOR772hDhwmUh_k0TbYZU-WTnHSNA@mail.gmail.com>
 <CANCZdfpPbnB+8GGbzT65dRigDEX=i4qQEsy9MKyV3TnxS8-v2w@mail.gmail.com>
 <20190808133124.GA3340@mit.edu>
 <ccdd93f2-2cc9-d3f4-757a-24fc0efd3da6@spamtrap.tnetconsulting.net>
 <20190810002308.GB8368@mit.edu>
Message-ID: <cbbcb9ef-99f3-3370-125b-03534a76b0bc@spamtrap.tnetconsulting.net>

On 8/9/19 6:23 PM, Theodore Y. Ts'o wrote:
> In '95, Slackware started releasing on CD-ROM's, and while there may 
> have been boot/root floppies, I suspect more and more they were used as 
> rescue media, since installing from a CD-ROM was *way* more convenient.

The boot & root floppies were how you booted Slackware for a long time. 
The CD-ROM was unbootable for quite a while.  You booted off of floppy 
and the installation scripts would ask you which drive had the CD-ROM in 
it to mount and install from.

> I'm guesing what you were doing was creating a kernel plus initramfs 
> which was sufficient to mount a root file system elsewhere as an 
> emergency "boot this failsafe kernel off the floppy", perhaps? 
> I don't think a kernel+initramfs on a single 1.44MB floppy would 
> have been sufficient for use as an install medium by '99.  Or were 
> you making an emergency USB thumb-drive as a rescue device, maybe?

It was a re-roll of the above boot & root disk set.  It was not rescue 
media per-say.  Though the standard boot & root disk set did get used 
for rescue purposes in addition to installation.



-- 
Grant. . . .
unix || die

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

From mckusick at mckusick.com  Sat Aug 10 14:02:51 2019
From: mckusick at mckusick.com (Kirk McKusick)
Date: Fri, 09 Aug 2019 21:02:51 -0700
Subject: [TUHS] Additional groups and additional directory permissions
Message-ID: <201908100402.x7A42p7C008714@chez.mckusick.com>

> Date: Fri, 2 Aug 2019 09:28:18 -0400
> From: Clem Cole <clemc at ccc.com>
> To: Aharon Robbins <arnold at skeeve.com>, Doug McIlroy <doug at cs.dartmouth.edu>
> Cc: The Eunuchs Hysterical Society <tuhs at tuhs.org>
> Subject: Re: [TUHS] Additional groups and additional directory permissions
> 
> The best I can tell/remember is that groups went through 4 phases:
> 1.) No groups (earliest  UNIX) [ I personally never used this except in the
> V0 retrocomputing]
> 2.) First group implementation (Thompson) [My first UNIX introduction was
> with this implementation]
> 3.) PWB 1.0 (Mashey version) [then saw this post PWB]
> 4.) BSD 4.2 (wnj version) [and lived this transistion]
> 
> Each was a little different in semantics.
> 
> As Doug mentioned, many sites (like Research) really did not need much and
> groups were really not used that widely.   Thompson added something like
> the Project number of TOPS and some earlier systems.  Truth is, it did not
> help much IMO.   It was useful for grouping things like the binaries and
> keeping some more privileged programs from having to be setuid root.
> 
> Mashey added features in PWB, primarily because of the RJE/Front end to the
> Mainframes and the need to have better protections/collections of certain
> items.   But they still were much more like the DEC PPN, were you were
> running as a single group (i.e. the tuple UID/GID).  This lasted a pretty
> long time, as it worked reasonably well for larger academic systems, where
> you had a user and were assigned a group, say for a course or class, you
> might be talking.  If you looked at big 4.1 BSN Vaxen like at Purdue/Penn
> State, *etc.*, that how they were admin'd.  But as Doug said, if you were
> still a small site, the use of groups was still pretty shallow.
> 
> But, as part of the CSRG support for DARPA, there was a push from the
> community to have a list of groups that a user could be a part and you
> carried that list around in a more general manner.   The big sites, in
> particular, were pushing for this because they were using groups as a major
> feature.  wnj implemented same and it would go out widely in 4.2, although
> >>by memory<< that was in 4.1B or 4.1C first.   It's possible Robert Elz
> may have brought that to Bill with his quota changes, but frankly I've
> forgotten.   There was a lot of work being done to the FS at that point,
> much less Kirk's rewrite.
> 
> But as UNIX went back to workstations, the need for a more general group
> system dropped away until the advent widely used distributed file systems
> like CMU's AFS and Sun's NFS.  Then the concept of a user being in more
> than one group became much more de rigeur even on a small machine.
> 
> Clem

Late to answer...

As far as I remember, Clem's description is correct. The filesystem
itself stores only one owner and one group ID. When checking access
to the file, the file owner is checked to see if the user ID matches.
If so, then the owner permissions are applied. If not then the group
array associated with the user is used to decide if the group of the
file matches one of the groups of which the user is a member and if
so the group permissions apply. Otherwise the other permissions are
used.

In BSD, the group assigned to the file is assigned from the group of
the directory in which it is created. The setgid flag can be set only
if that group is a member of the user's group array. The user can only
change the group ID to one that appears in their group array.

Until multiple group sets were added to System V, the group of the
file was taken from the gid assigned to the user at login.

	Kirk McKusick

From kevin.bowling at kev009.com  Sat Aug 10 14:21:30 2019
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Fri, 9 Aug 2019 21:21:30 -0700
Subject: [TUHS] Pre-init initialization
In-Reply-To: <cbbcb9ef-99f3-3370-125b-03534a76b0bc@spamtrap.tnetconsulting.net>
References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net>
 <CAC20D2PjoKqSfEeBu9pJuOOR772hDhwmUh_k0TbYZU-WTnHSNA@mail.gmail.com>
 <CANCZdfpPbnB+8GGbzT65dRigDEX=i4qQEsy9MKyV3TnxS8-v2w@mail.gmail.com>
 <20190808133124.GA3340@mit.edu>
 <ccdd93f2-2cc9-d3f4-757a-24fc0efd3da6@spamtrap.tnetconsulting.net>
 <20190810002308.GB8368@mit.edu>
 <cbbcb9ef-99f3-3370-125b-03534a76b0bc@spamtrap.tnetconsulting.net>
Message-ID: <CAK7dMtA6fe3MAtRaLMOrt_Vk1=4xJCiJNV0o2mYm+YKq_f=jqQ@mail.gmail.com>

Yup I remember doing a boot/root floppies with Slackware as late as the
early 2000s on an IBM PS/2 Model 95.

On Fri, Aug 9, 2019 at 7:29 PM Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
wrote:

> On 8/9/19 6:23 PM, Theodore Y. Ts'o wrote:
> > In '95, Slackware started releasing on CD-ROM's, and while there may
> > have been boot/root floppies, I suspect more and more they were used as
> > rescue media, since installing from a CD-ROM was *way* more convenient.
>
> The boot & root floppies were how you booted Slackware for a long time.
> The CD-ROM was unbootable for quite a while.  You booted off of floppy
> and the installation scripts would ask you which drive had the CD-ROM in
> it to mount and install from.
>
> > I'm guesing what you were doing was creating a kernel plus initramfs
> > which was sufficient to mount a root file system elsewhere as an
> > emergency "boot this failsafe kernel off the floppy", perhaps?
> > I don't think a kernel+initramfs on a single 1.44MB floppy would
> > have been sufficient for use as an install medium by '99.  Or were
> > you making an emergency USB thumb-drive as a rescue device, maybe?
>
> It was a re-roll of the above boot & root disk set.  It was not rescue
> media per-say.  Though the standard boot & root disk set did get used
> for rescue purposes in addition to installation.
>
>
>
> --
> Grant. . . .
> unix || die
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190809/358ce646/attachment.html>

From gtaylor at tnetconsulting.net  Sat Aug 10 14:50:32 2019
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Fri, 9 Aug 2019 22:50:32 -0600
Subject: [TUHS] Pre-init initialization
In-Reply-To: <CAK7dMtA6fe3MAtRaLMOrt_Vk1=4xJCiJNV0o2mYm+YKq_f=jqQ@mail.gmail.com>
References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net>
 <CAC20D2PjoKqSfEeBu9pJuOOR772hDhwmUh_k0TbYZU-WTnHSNA@mail.gmail.com>
 <CANCZdfpPbnB+8GGbzT65dRigDEX=i4qQEsy9MKyV3TnxS8-v2w@mail.gmail.com>
 <20190808133124.GA3340@mit.edu>
 <ccdd93f2-2cc9-d3f4-757a-24fc0efd3da6@spamtrap.tnetconsulting.net>
 <20190810002308.GB8368@mit.edu>
 <cbbcb9ef-99f3-3370-125b-03534a76b0bc@spamtrap.tnetconsulting.net>
 <CAK7dMtA6fe3MAtRaLMOrt_Vk1=4xJCiJNV0o2mYm+YKq_f=jqQ@mail.gmail.com>
Message-ID: <ea597c8b-5366-f0a2-c9cb-b05c5b1f5fb5@spamtrap.tnetconsulting.net>

On 8/9/19 10:21 PM, Kevin Bowling wrote:
> Yup I remember doing a boot/root floppies with Slackware as late as the 
> early 2000s on an IBM PS/2 Model 95.

That timing seems correct.

I didn't think the IBM PS/2 Model 95, or any PS/2 for that matter, 
supported booting from CD-ROM.  At least stock firmware.  (I have no 
idea if a 3rd party / hacked firmware exists.)



-- 
Grant. . . .
unix || die

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

From athornton at gmail.com  Sat Aug 10 14:52:47 2019
From: athornton at gmail.com (Adam Thornton)
Date: Fri, 9 Aug 2019 21:52:47 -0700
Subject: [TUHS] Pre-init initialization
In-Reply-To: <CAK7dMtA6fe3MAtRaLMOrt_Vk1=4xJCiJNV0o2mYm+YKq_f=jqQ@mail.gmail.com>
References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net>
 <CAC20D2PjoKqSfEeBu9pJuOOR772hDhwmUh_k0TbYZU-WTnHSNA@mail.gmail.com>
 <CANCZdfpPbnB+8GGbzT65dRigDEX=i4qQEsy9MKyV3TnxS8-v2w@mail.gmail.com>
 <20190808133124.GA3340@mit.edu>
 <ccdd93f2-2cc9-d3f4-757a-24fc0efd3da6@spamtrap.tnetconsulting.net>
 <20190810002308.GB8368@mit.edu>
 <cbbcb9ef-99f3-3370-125b-03534a76b0bc@spamtrap.tnetconsulting.net>
 <CAK7dMtA6fe3MAtRaLMOrt_Vk1=4xJCiJNV0o2mYm+YKq_f=jqQ@mail.gmail.com>
Message-ID: <CAP2nic2Tv5is8_V7k6QpJSGXv0bMEz8TiaZHf-hp1wvOtkZtAQ@mail.gmail.com>

MCA support came pretty late, so that's not terribly surprising.

As did booting-from CD-ROM, for that matter.  I think I remember a fairly
long period where the CD-ROM hung off the SoundBlaster, not the IDE bus.

Adam

On Fri, Aug 9, 2019 at 9:22 PM Kevin Bowling <kevin.bowling at kev009.com>
wrote:

> Yup I remember doing a boot/root floppies with Slackware as late as the
> early 2000s on an IBM PS/2 Model 95.
>
> On Fri, Aug 9, 2019 at 7:29 PM Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
> wrote:
>
>> On 8/9/19 6:23 PM, Theodore Y. Ts'o wrote:
>> > In '95, Slackware started releasing on CD-ROM's, and while there may
>> > have been boot/root floppies, I suspect more and more they were used as
>> > rescue media, since installing from a CD-ROM was *way* more convenient.
>>
>> The boot & root floppies were how you booted Slackware for a long time.
>> The CD-ROM was unbootable for quite a while.  You booted off of floppy
>> and the installation scripts would ask you which drive had the CD-ROM in
>> it to mount and install from.
>>
>> > I'm guesing what you were doing was creating a kernel plus initramfs
>> > which was sufficient to mount a root file system elsewhere as an
>> > emergency "boot this failsafe kernel off the floppy", perhaps?
>> > I don't think a kernel+initramfs on a single 1.44MB floppy would
>> > have been sufficient for use as an install medium by '99.  Or were
>> > you making an emergency USB thumb-drive as a rescue device, maybe?
>>
>> It was a re-roll of the above boot & root disk set.  It was not rescue
>> media per-say.  Though the standard boot & root disk set did get used
>> for rescue purposes in addition to installation.
>>
>>
>>
>> --
>> Grant. . . .
>> unix || die
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190809/beed8a1e/attachment.html>

From thomas.paulsen at firemail.de  Sat Aug 10 16:02:03 2019
From: thomas.paulsen at firemail.de (Thomas Paulsen)
Date: Sat, 10 Aug 2019 08:02:03 +0200
Subject: [TUHS] Additional groups and additional directory permissions
In-Reply-To: <201908100402.x7A42p7C008714@chez.mckusick.com>
References: <201908100402.x7A42p7C008714@chez.mckusick.com>
Message-ID: <51fd4ffbdeb80edffe8f837f04edf1aa@firemail.de>

thanks a lot!

--- Ursprüngliche Nachricht ---
Von: Kirk McKusick <mckusick at mckusick.com>
Datum: 10.08.2019 06:02:51
An: Clem Cole <clemc at ccc.com>
Betreff: Re: [TUHS] Additional groups and additional directory permissions

>
> Late to answer...
>
> As far as I remember, Clem's description is correct. The filesystem
> itself stores only one owner and one group ID. When checking access
> to the file, the file owner is checked to see if the user ID matches.
> If so, then the owner permissions are applied. If not then the group
> array associated with the user is used to decide if the group of the
> file matches one of the groups of which the user is a member and if
> so the group permissions apply. Otherwise the other permissions are
> used.
>
> In BSD, the group assigned to the file is assigned from the group of
> the directory in which it is created. The setgid flag can be set only
> if that group is a member of the user's group array. The user can only
> change the group ID to one that appears in their group array.
>
> Until multiple group sets were added to System V, the group of the
> file was taken from the gid assigned to the user at login.
>
> 	Kirk McKusick
>



From efton.collins at gmail.com  Wed Aug 14 15:41:50 2019
From: efton.collins at gmail.com (Efton Collins)
Date: Wed, 14 Aug 2019 00:41:50 -0500
Subject: [TUHS] Set-uid shell scripts
In-Reply-To: <B96F5844-B97C-4BC7-904D-E23FB0A020C7@gmail.com>
References: <1564954057.6926.for-standards-violators@oclsc.org>
 <alpine.LRH.2.21.1908060104130.2617@waffle.shalott.net>
 <alpine.BSF.2.21.9999.1908070840370.81938@aneurin.horsfall.org>
 <c411365d-184d-ecfc-9e33-150efa8b2187@case.edu>
 <alpine.BSF.2.21.9999.1908080734080.81938@aneurin.horsfall.org>
 <B96F5844-B97C-4BC7-904D-E23FB0A020C7@gmail.com>
Message-ID: <CAGkfwV+8+Dv0HrCvyTsV+Fii6utfxURR6j8rkSj5eosy1Za2NA@mail.gmail.com>

On 8/8/19, Adam Thornton <athornton at gmail.com> wrote:
>
>
>> On Aug 7, 2019, at 2:40 PM, Dave Horsfall <dave at horsfall.org> wrote:
>>
>> I'm not really a Mac freak; apart from the occasional port, I just use it
>> to SSH into my FreeBSD server, with multiple Terminals all over the
>> screen..
>
>
> iTerm2 is really rather nice.
>
> Folks here may be interested in a new toy of mine:
>
> https://mvsevm.fsf.net

I like this. CTSS would make a good addition to the collection. I've
always loved the CTSS - Multics - Unix progression, with Multics
having so much ambition, and Unix coming out of that with simplicity
and taste and no expectations.

>
> Currently, the TOPS-10 guest account (42,42) and the Unix v7 account dmr
> have no passwords.
>
> Please treat the dmr account respectfully.
>
> I will get to account requests…eventually, probably.  TImeliness is not
> guaranteed.  All systems are hosted on Raspberry Pis (the 36-bit ones on a
> Pi 3B+ and the 16-bit and 32-bit ones on a Pi 2B+) on Debian Buster.
> Absolutely no guarantee of availability or usability is made.
>
> Adam
>
>
>

From imp at bsdimp.com  Fri Aug 16 08:08:43 2019
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 15 Aug 2019 16:08:43 -0600
Subject: [TUHS] Video of PDP-7 with Graphics-2?
In-Reply-To: <20190802230348.GA22981@minnie.tuhs.org>
References: <20190802201448.GA5889@minnie.tuhs.org>
 <e00fc7d7-7182-1d0f-261e-6701af92c690@deitygraveyard.com>
 <20190802230348.GA22981@minnie.tuhs.org>
Message-ID: <CANCZdfoP7GQtU3mOx9E3GDw+f+dFBRYOHm2pi+K+yWre3qDo=A@mail.gmail.com>

On Fri, Aug 2, 2019 at 5:04 PM Warren Toomey <wkt at tuhs.org> wrote:

> On Fri, Aug 02, 2019 at 06:49:19PM -0400, Jim Carpenter wrote:
> > On 8/2/19 4:14 PM, Warren Toomey wrote:
> > > Hi all, I'm chasing the Youtube video of the PDP-7 at Bell Labs where
> > > people are using it to draw circuit schematics.
> >
> > A Bell Labs video? The only Bell Labs video I remember seeing that had
> > someone doing circuit schematics had it being done on a PDP-5. The -7 was
> > shown later doing music stuff. (That's the -7 that I thought maybe Unix
> > started life on.)
>
> Thanks Jim, Is it this one?
> https://www.youtube.com/watch?v=iwVu2BWLZqA
>
> They mention a Graphics-1 device, so maybe I'm getting this confused
> with the PDP-7 and the Graphics-2.
>

The early one for the circuit simulator is definitely on a PDP-5 and I
presume the Graphics-1 display. You can see the PDP 5 letters on one of the
cabinets. How do you know that the music was composed on the PDP-7 that
appears from 9:20-10:30? Cool paper tape feeding sequence, though, you
gotta admit :) (well, unless you waited for far too many of those to run
back in the day).

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

From imp at bsdimp.com  Fri Aug 16 08:46:21 2019
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 15 Aug 2019 16:46:21 -0600
Subject: [TUHS] Video of PDP-7 with Graphics-2?
In-Reply-To: <CANCZdfoP7GQtU3mOx9E3GDw+f+dFBRYOHm2pi+K+yWre3qDo=A@mail.gmail.com>
References: <20190802201448.GA5889@minnie.tuhs.org>
 <e00fc7d7-7182-1d0f-261e-6701af92c690@deitygraveyard.com>
 <20190802230348.GA22981@minnie.tuhs.org>
 <CANCZdfoP7GQtU3mOx9E3GDw+f+dFBRYOHm2pi+K+yWre3qDo=A@mail.gmail.com>
Message-ID: <CANCZdfpPXzWXpS4abphwADbvSatSOUG0jTOB_zF3m0fZo7LRZw@mail.gmail.com>

On Thu, Aug 15, 2019 at 4:08 PM Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Fri, Aug 2, 2019 at 5:04 PM Warren Toomey <wkt at tuhs.org> wrote:
>
>> On Fri, Aug 02, 2019 at 06:49:19PM -0400, Jim Carpenter wrote:
>> > On 8/2/19 4:14 PM, Warren Toomey wrote:
>> > > Hi all, I'm chasing the Youtube video of the PDP-7 at Bell Labs where
>> > > people are using it to draw circuit schematics.
>> >
>> > A Bell Labs video? The only Bell Labs video I remember seeing that had
>> > someone doing circuit schematics had it being done on a PDP-5. The -7
>> was
>> > shown later doing music stuff. (That's the -7 that I thought maybe Unix
>> > started life on.)
>>
>> Thanks Jim, Is it this one?
>> https://www.youtube.com/watch?v=iwVu2BWLZqA
>>
>> They mention a Graphics-1 device, so maybe I'm getting this confused
>> with the PDP-7 and the Graphics-2.
>>
>
> The early one for the circuit simulator is definitely on a PDP-5 and I
> presume the Graphics-1 display. You can see the PDP 5 letters on one of the
> cabinets. How do you know that the music was composed on the PDP-7 that
> appears from 9:20-10:30? Cool paper tape feeding sequence, though, you
> gotta admit :) (well, unless you waited for far too many of those to run
> back in the day).
>

Oh! I've found the right set of photos to make a good case this is a
PDP-7...

https://docs.google.com/presentation/d/1lNmjaJhuqKSbpDU96sc3Kia3d-Ag0DVylMzW6APdWEY/edit?usp=sharing

has an early version of a slide I'll be using in my talk next month.

Comments?

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

From athornton at gmail.com  Wed Aug 21 07:10:55 2019
From: athornton at gmail.com (Adam Thornton)
Date: Tue, 20 Aug 2019 14:10:55 -0700
Subject: [TUHS] Shell builtin exec
Message-ID: <CAP2nic1SEFg=e4htyw_23KAL_pUC98JL4XDoWLKwU365BMWXxg@mail.gmail.com>

This is probably the place to ask:

I understand why the shell builtin "exec" is the same as the syscall exec()
in the sense of "replace this process with that one."  But why is it also
the way to redirect filehandles in the current shell?  (That is, why isn't
the redirection named something else?)

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

From wkt at tuhs.org  Wed Aug 21 08:00:33 2019
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 21 Aug 2019 08:00:33 +1000
Subject: [TUHS] Shell builtin exec
In-Reply-To: <CAP2nic1SEFg=e4htyw_23KAL_pUC98JL4XDoWLKwU365BMWXxg@mail.gmail.com>
References: <CAP2nic1SEFg=e4htyw_23KAL_pUC98JL4XDoWLKwU365BMWXxg@mail.gmail.com>
Message-ID: <20190820220033.GA18256@minnie.tuhs.org>

On Tue, Aug 20, 2019 at 02:10:55PM -0700, Adam Thornton wrote:
>    This is probably the place to ask:
>    I understand why the shell builtin "exec" is the same as the syscall
>    exec() in the sense of "replace this process with that one."  But why
>    is it also the way to redirect filehandles in the current shell?  (That
>    is, why isn't the redirection named something else?)

exec() doesn't do anything with file handles; it simply replaces the
executable code in the current process. Here's the pseudo-code for a
shell where redirection is done.

  int pid;                      /* Holds the process-id of the child */

  switch (pid = fork())         /* Call fork, and test what it returns */
  {
    case -1: printf("The fork failed\n"); return (-1);

    case 0:              /* The child is given a value of 0 from fork() */
                           /* Do special things like closing files etc. */

    if (redirection required) {
      close my standard output;
      open the named output file as my standard output;
    }

                                /* Replace ourselves with the real child */
                                /* Call execvp */
      execlp(command, arg1, arg2, ..., NULL);
      exit(1);                  /* Exec failed, indicate error */

    default:          /* The parent receives the new process-id from fork() */
      wait();                   /* Wait for child to exit */
}

So the child shell itself does the redirection after the fork(), but before
it replaces itself with the new executable code.

Cheers, Warren



From chet.ramey at case.edu  Wed Aug 21 10:38:08 2019
From: chet.ramey at case.edu (Chet Ramey)
Date: Tue, 20 Aug 2019 20:38:08 -0400
Subject: [TUHS] Shell builtin exec
In-Reply-To: <CAP2nic1SEFg=e4htyw_23KAL_pUC98JL4XDoWLKwU365BMWXxg@mail.gmail.com>
References: <CAP2nic1SEFg=e4htyw_23KAL_pUC98JL4XDoWLKwU365BMWXxg@mail.gmail.com>
Message-ID: <83aa800b-76e8-7d72-8f1b-2148e36eec05@case.edu>

On 8/20/19 5:10 PM, Adam Thornton wrote:
> This is probably the place to ask:
> 
> I understand why the shell builtin "exec" is the same as the syscall exec()
> in the sense of "replace this process with that one."  But why is it also
> the way to redirect filehandles in the current shell?  (That is, why isn't
> the redirection named something else?)

It was probably a side effect that turned out to be useful. The `exec'
builtin performs redirections without a way to undo them, because why
bother, and executes its arguments as a command with arguments, as if it
were in a child process.

The original Bourne shell just performed the redirections and returned
if there weren't any arguments, leaving the non-undoable redirections
in place.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://tiswww.cwru.edu/~chet/

From krewat at kilonet.net  Tue Aug 27 09:13:25 2019
From: krewat at kilonet.net (Arthur Krewat)
Date: Mon, 26 Aug 2019 19:13:25 -0400
Subject: [TUHS] If not Linux, then what?
Message-ID: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>

https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel

Leaving licensing and copyright issues out of this mental exercise, what 
would we have now if it wasn't for Linux? Not what you'd WANT it to be, 
although that can add to the discussion, but what WOULD it be?

I'm not asking as a proponent of Linux. If anything, I was dragged 
kicking and screaming into the current day and have begrudgingly ceded 
my server space to Linux.

But if not for Linux, would it be BSD? A System V variant? Or (the 
horror) Windows NT?

I do understand that this has been discussed on the list before. I 
think, however, it would make a good late-summer exercise. Or late 
winter depending on where you are :)

art k.



From imp at bsdimp.com  Tue Aug 27 09:27:14 2019
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 26 Aug 2019 17:27:14 -0600
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
Message-ID: <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>

On Mon, Aug 26, 2019, 5:14 PM Arthur Krewat <krewat at kilonet.net> wrote:

>
> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel
>
> Leaving licensing and copyright issues out of this mental exercise, what
> would we have now if it wasn't for Linux? Not what you'd WANT it to be,
> although that can add to the discussion, but what WOULD it be?
>
> I'm not asking as a proponent of Linux. If anything, I was dragged
> kicking and screaming into the current day and have begrudgingly ceded
> my server space to Linux.
>
> But if not for Linux, would it be BSD? A System V variant? Or (the
> horror) Windows NT?
>

BSD was in decent enough shape at the time to run on PCs. Though it
fragmented early through no fault of Linux. And the AT&T lawsuit created a
lot of FUD in the area without actually protecting System V. It's unclear
if another thing would have popped up to fill the void... Linux flourished
in the confusion, but without it, it's hard to know if something else would
have been developed before the AT&T lawsuit settled.

Warner


I do understand that this has been discussed on the list before. I
> think, however, it would make a good late-summer exercise. Or late
> winter depending on where you are :)
>
> art k.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190826/5303852a/attachment.html>

From jon at fourwinds.com  Tue Aug 27 09:18:52 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Mon, 26 Aug 2019 16:18:52 -0700
Subject: [TUHS] /dev/null
Message-ID: <201908262318.x7QNIqaY012455@darkstar.fourwinds.com>

Just curious - am doing a cross-country road trip with my kid and saw a
Wisconsin dev null license plate.  Didn't get a look at the driver.
Does it belong to anyone on this list?

Jon

From lm at mcvoy.com  Tue Aug 27 09:37:04 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 26 Aug 2019 16:37:04 -0700
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
Message-ID: <20190826233704.GR13570@mcvoy.com>

On Mon, Aug 26, 2019 at 05:27:14PM -0600, Warner Losh wrote:
> On Mon, Aug 26, 2019, 5:14 PM Arthur Krewat <krewat at kilonet.net> wrote:
> 
> >
> > https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel
> >
> > Leaving licensing and copyright issues out of this mental exercise, what
> > would we have now if it wasn't for Linux? Not what you'd WANT it to be,
> > although that can add to the discussion, but what WOULD it be?
> >
> > I'm not asking as a proponent of Linux. If anything, I was dragged
> > kicking and screaming into the current day and have begrudgingly ceded
> > my server space to Linux.
> >
> > But if not for Linux, would it be BSD? A System V variant? Or (the
> > horror) Windows NT?
> 
> BSD was in decent enough shape at the time to run on PCs. Though it
> fragmented early through no fault of Linux. And the AT&T lawsuit created a
> lot of FUD in the area without actually protecting System V. It's unclear
> if another thing would have popped up to fill the void... Linux flourished
> in the confusion, but without it, it's hard to know if something else would
> have been developed before the AT&T lawsuit settled.

I've always wondered what would have happened if Sun had open sourced
SunOS, I think it stood a pretty good chance of winning.  Shoulda,
woulda, coulda.

From pechter at gmail.com  Tue Aug 27 09:56:41 2019
From: pechter at gmail.com (William Pechter)
Date: Mon, 26 Aug 2019 19:56:41 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
Message-ID: <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com>

On 8/26/2019 7:27 PM, Warner Losh wrote:
>
>
> On Mon, Aug 26, 2019, 5:14 PM Arthur Krewat <krewat at kilonet.net 
> <mailto:krewat at kilonet.net>> wrote:
>
>     https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel
>
>     Leaving licensing and copyright issues out of this mental
>     exercise, what
>     would we have now if it wasn't for Linux? Not what you'd WANT it
>     to be,
>     although that can add to the discussion, but what WOULD it be?
>
>     I'm not asking as a proponent of Linux. If anything, I was dragged
>     kicking and screaming into the current day and have begrudgingly
>     ceded
>     my server space to Linux.
>
>     But if not for Linux, would it be BSD? A System V variant? Or (the
>     horror) Windows NT?
>
>
> BSD was in decent enough shape at the time to run on PCs. Though it 
> fragmented early through no fault of Linux. And the AT&T lawsuit 
> created a lot of FUD in the area without actually protecting System V. 
> It's unclear if another thing would have popped up to fill the void... 
> Linux flourished in the confusion, but without it, it's hard to know 
> if something else would have been developed before the AT&T lawsuit 
> settled.
>
> Warner
>
>
>     I do understand that this has been discussed on the list before. I
>     think, however, it would make a good late-summer exercise. Or late
>     winter depending on where you are :)
>
>     art k.
>
>
I ran both FreeBSD (up through at least 4.11 (and have the Tshirt) and 
NetBSD back in the 0.8 0.9 time frame.  My final -- (I used to move 
between them based on stability and driver support) -- move to Linux was 
caused by a lack of drivers for the Lenovo Workstation that used the 
Marvell 88SE63XX which with 5 SAS/SATA drives on it and 3 available on 
the Intel SATA controller would've been a great in-house server.

I really preferred the FreeBSD stability and docs back in the early 
1990's -- but by 2000 my jobs were all going Linux (Red Hat Sysadmin 
mostly) and I figured the work was moving to supported RHEL.  One of the 
things that often made me migrate was the support (in the early days) of 
all the weird interfaced cdrom drives like the Panasonic and other 
pre-ATAPI stuff.

I'm going to revisit the ZFS on Linux stuff when Ubuntu puts it in their 
installer.  That will finally get me what I want on the D20.

Bill

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

From krewat at kilonet.net  Tue Aug 27 10:19:45 2019
From: krewat at kilonet.net (Arthur Krewat)
Date: Mon, 26 Aug 2019 20:19:45 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
 <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com>
Message-ID: <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>

On 8/26/2019 7:56 PM, William Pechter wrote:
> ZFS

Here, here!

From lm at mcvoy.com  Tue Aug 27 10:30:13 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 26 Aug 2019 17:30:13 -0700
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
 <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com>
 <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
Message-ID: <20190827003013.GS13570@mcvoy.com>

On Mon, Aug 26, 2019 at 08:19:45PM -0400, Arthur Krewat wrote:
> On 8/26/2019 7:56 PM, William Pechter wrote:
> >ZFS
> 
> Here, here!

I really don't understand the love for ZFS.  I hired Bonwick and I
hired Moore, I had high expectations but they were all dashed when I
realized ZFS doesn't use the page cache.  That's so crazy busted I lost
all interest in ZFS.  ZFS took us back to HP-UX mmap semantics.

From clemc at ccc.com  Tue Aug 27 10:48:48 2019
From: clemc at ccc.com (Clem Cole)
Date: Mon, 26 Aug 2019 20:48:48 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
Message-ID: <CAC20D2MhuPOS1dR6ihFysngYbFDYrKvKCJ0xVd33wJ5rynQ1hQ@mail.gmail.com>

On Mon, Aug 26, 2019 at 7:28 PM Warner Losh <imp at bsdimp.com> wrote:

>
> BSD was in decent enough shape at the time to run on PCs. Though it
> fragmented early through no fault of Linux. And the AT&T lawsuit created a
> lot of FUD in the area without actually protecting System V. It's unclear
> if another thing would have popped up to fill the void... Linux flourished
> in the confusion, but without it, it's hard to know if something else would
> have been developed before the AT&T lawsuit settled.
>


But what really allowed Linux to take off the AT&T vs. UCB/BSDi lawsuit.
At the time Linux, didn't have networking much less a window manager
etc...   so lot of people, mysef included (incorrectly thinking is was a
copyright case) thought we were going to lose a UNIX for our inexpensice
(i.e. 'cheap' 386 based systems) so we all started started to hack on Linux
0.99xxx [my first real serious taste was an early Slackware version on a
billion floppies fairly soon after Linus made it available and Patrick
pulled together his first distribution].

But ... (and as I have point out elsewhere - see
http://technique-societe.cnam.fr/la-recherche-sur-les-systemes-des-pivots-dans-l-histoire-de-l-informatique-ii-ii-988170.kjsp?RH=cdhte
],
.... *if AT&T had won the case, all the other UNIX flavors* (Linux included
would have had to have been pulled from the market).
So in many ways, this question is not really a fair one.

AT&T lost the case, and Linux got the ball and ran for it.

That said, I'll drop into the hypotheical, if AT&T had lost and Linux had
not been there ..... then... I do think some flavor of BSD would have been
the winner.    The two wild cards are from Sun and OSF/CMU.   As Larry says
is what about SunOS and Solaris, although the legals of Sun doing that I
wonder.   The other question is Mach/OSF (I know Larry does not like the
codebase).

But one of the *BSD, Mach or an FOSS Sun code base would have had the most
legs.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190826/1e075f98/attachment.html>

From robpike at gmail.com  Tue Aug 27 10:58:54 2019
From: robpike at gmail.com (Rob Pike)
Date: Tue, 27 Aug 2019 10:58:54 +1000
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <20190827003013.GS13570@mcvoy.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
 <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com>
 <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
 <20190827003013.GS13570@mcvoy.com>
Message-ID: <CAKzdPgxvb1MSA1yN3h0wY2aySzkd0aDjFSYH6pa==7MEw_zR8w@mail.gmail.com>

I always thought Research 10th Edition was fantastic. Even the 8th edition
was an improvement on most of its successors. But things flowed another
way, with muddy streams mixing in.

-rob


On Tue, Aug 27, 2019 at 10:30 AM Larry McVoy <lm at mcvoy.com> wrote:

> On Mon, Aug 26, 2019 at 08:19:45PM -0400, Arthur Krewat wrote:
> > On 8/26/2019 7:56 PM, William Pechter wrote:
> > >ZFS
> >
> > Here, here!
>
> I really don't understand the love for ZFS.  I hired Bonwick and I
> hired Moore, I had high expectations but they were all dashed when I
> realized ZFS doesn't use the page cache.  That's so crazy busted I lost
> all interest in ZFS.  ZFS took us back to HP-UX mmap semantics.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190827/15f106a0/attachment.html>

From krewat at kilonet.net  Tue Aug 27 10:59:02 2019
From: krewat at kilonet.net (Arthur Krewat)
Date: Mon, 26 Aug 2019 20:59:02 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <20190827003013.GS13570@mcvoy.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
 <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com>
 <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
 <20190827003013.GS13570@mcvoy.com>
Message-ID: <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net>

On 8/26/2019 8:30 PM, Larry McVoy wrote:
>
> I really don't understand the love for ZFS.  I hired Bonwick and I
> hired Moore, I had high expectations but they were all dashed when I
> realized ZFS doesn't use the page cache.  That's so crazy busted I lost
> all interest in ZFS.  ZFS took us back to HP-UX mmap semantics.
>

At the risk of going off-topic:

 From a system-administration standpoint, and data-integrity standpoint, 
ZFS was a huge step forward. In my humble opinion ;)

Besides the obvious (to me) benefits of adding mount points, adjusting 
volume sizes, and all the other things that ZFS does, I have yet to find 
any mainstream filesystem (if you can call ZFS "just" a filesystem) that 
guarantees data integrity. I have an office server, that contains a lot 
of source code and archived data that I depend on religiously. I do 
copious backups to LTO tapes as well as an off-site Amazon EC2 instance.

Within the recent past few years, I had an issue with a Dell MD Raid 
array where ZFS was complaining about checksum errors on a certain disk. 
Data was being corrupted on the fly. It seems that the writes were being 
corrupted, not reads. Thankfully, it was on a RAIDZ2 volume, where it 
could correct the corruption. The corruption in question was on files 
that are dated back to the early 90's.

Stopping bit-rot in it's tracks, ZFS has done me well.

As for what mmap() doesn't do right, I started using memory mapped files 
back in the early 80s on VMS on a VAX-11/780 when I and a colleague were 
converting a database from TOPS-10 to VMS. Perhaps I am misunderstanding 
your dislike for mmap() but please, enlighten me. It was my 
understanding at the time that it was akin to swapping/virtual-memory 
using an MMU. The difference was that instead of using the main paging 
area, the kernel would use an actual file.  Why would mmap() be a bad 
thing, when it's hooked into the kernel, and possibly hardware, at such 
a low point?

art k.




From clemc at ccc.com  Tue Aug 27 11:06:46 2019
From: clemc at ccc.com (Clem Cole)
Date: Mon, 26 Aug 2019 21:06:46 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CAKzdPgxvb1MSA1yN3h0wY2aySzkd0aDjFSYH6pa==7MEw_zR8w@mail.gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
 <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com>
 <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
 <20190827003013.GS13570@mcvoy.com>
 <CAKzdPgxvb1MSA1yN3h0wY2aySzkd0aDjFSYH6pa==7MEw_zR8w@mail.gmail.com>
Message-ID: <CAC20D2Mah0DQ8=MB6AU1Z3zqgCiYfZUgnRAJxYOnfPmVSHWHHw@mail.gmail.com>

On Mon, Aug 26, 2019 at 8:59 PM Rob Pike <robpike at gmail.com> wrote:

> I always thought Research 10th Edition was fantastic. Even the 8th edition
> was an improvement on most of its successors. But things flowed another
> way, with muddy streams mixing in.
>
> -rob
>

Rob - Fair enough/excellent point/I agree from a pure technology stand
point, but the problem was anything from Research after Seventh Edition was
the limited availability so few people out side really used it (and I'll
have include Plan 9 in that family also - although you guys did get it out
more widely than 8th or 10th UNIX -- funny by that point, I had read about
it and seen the manuals in a book store in the UK, but I did not get the
mess with the actual 10th edition code until  a few years after I had a
Plan 9 boot floppy that Dave gave me running in a laptop).

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

From crossd at gmail.com  Tue Aug 27 11:17:38 2019
From: crossd at gmail.com (Dan Cross)
Date: Mon, 26 Aug 2019 21:17:38 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
Message-ID: <CAEoi9W5xRsb1Fc4=4kBTcgaGOrk1RLa+B97cU_dhTGv-rA9cog@mail.gmail.com>

On Mon, Aug 26, 2019, 7:14 PM Arthur Krewat <krewat at kilonet.net> wrote:

>
> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel
>
> Leaving licensing and copyright issues out of this mental exercise, what
> would we have now if it wasn't for Linux? Not what you'd WANT it to be,
> although that can add to the discussion, but what WOULD it be?
>
> I'm not asking as a proponent of Linux. If anything, I was dragged
> kicking and screaming into the current day and have begrudgingly ceded
> my server space to Linux.
>
> But if not for Linux, would it be BSD? A System V variant? Or (the
> horror) Windows NT?
>
> I do understand that this has been discussed on the list before. I
> think, however, it would make a good late-summer exercise. Or late
> winter depending on where you are :)
>

This is an interesting question, though of course impossible to actually
answer in a meaningful way, as hypotheticals always are. But assuming one
could hold all else constant and just erase Linux from the picture, it
seems pretty obvious that some kind of BSD variant would have been "it."

I think a more interesting question, however, might be: had Linux not
happened, would that have opened the space for serious consideration of
alternative system architectures, either along Unix derivative lines, or
completely different? For example, perhaps something like plan 9 would have
had greater penetration into the market.

I saw a talk a couple of months ago that attributed the diversity of
systems in the 60s and 70s to the idea that people were trying so many
different things because no one knew _how_ to build systems. That may be at
least partially true, but I was wondering thinking about that very thing
this morning and realized that we're certainly swirling around the toilet
bowl converging on some central set of things we think work pretty well
(files! processes! threads!). But as time marches on and we see the
environment changing around us, we don't often go back and revisit these
sorts of fundamental assumptions. More's the shame, I'm afraid.

One wonders what's next. People now talk about Linux with the sort of
reverent tones they once discussed Windows and before that the mainframe.
Too big to fail, the Last System, etc. But there are cracks there: Fuchsia
is a different architecture, because that Unix model isn't going to
accommodate all contemporary use cases: the security model seems to be a
big driver here. Will they succeed? It'll be at least interesting to watch
and see.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190826/9ad30b0a/attachment.html>

From gregg.drwho8 at gmail.com  Tue Aug 27 11:25:51 2019
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Mon, 26 Aug 2019 21:25:51 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CAC20D2MhuPOS1dR6ihFysngYbFDYrKvKCJ0xVd33wJ5rynQ1hQ@mail.gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
 <CAC20D2MhuPOS1dR6ihFysngYbFDYrKvKCJ0xVd33wJ5rynQ1hQ@mail.gmail.com>
Message-ID: <CAC5iaNHkwGMVs6cFcR3qoE0+rQ5ZhfKqdBJ2WLFmeGRWv9M9OQ@mail.gmail.com>

Hello!
having run both FreeBSD and NetBSD and several different examples of
Linux, I found that FreeBSD was a bit flaky at the time. NetBSD was
good, but for my efforts, I ended up with Slackware, I started with
his three something examples, and now I have 11 running.

I have tried under SIMH most of the examples that live on the FTP site
which will boot. But I still have strong support for practically
everything SUN wrote.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."

On Mon, Aug 26, 2019 at 8:49 PM Clem Cole <clemc at ccc.com> wrote:
>
>
>
> On Mon, Aug 26, 2019 at 7:28 PM Warner Losh <imp at bsdimp.com> wrote:
>>
>>
>> BSD was in decent enough shape at the time to run on PCs. Though it fragmented early through no fault of Linux. And the AT&T lawsuit created a lot of FUD in the area without actually protecting System V. It's unclear if another thing would have popped up to fill the void... Linux flourished in the confusion, but without it, it's hard to know if something else would have been developed before the AT&T lawsuit settled.
>
>
>
> But what really allowed Linux to take off the AT&T vs. UCB/BSDi lawsuit.  At the time Linux, didn't have networking much less a window manager etc...   so lot of people, mysef included (incorrectly thinking is was a copyright case) thought we were going to lose a UNIX for our inexpensice (i.e. 'cheap' 386 based systems) so we all started started to hack on Linux 0.99xxx [my first real serious taste was an early Slackware version on a billion floppies fairly soon after Linus made it available and Patrick pulled together his first distribution].
>
> But ... (and as I have point out elsewhere - see
> http://technique-societe.cnam.fr/la-recherche-sur-les-systemes-des-pivots-dans-l-histoire-de-l-informatique-ii-ii-988170.kjsp?RH=cdhte],
> .... if AT&T had won the case, all the other UNIX flavors (Linux included would have had to have been pulled from the market).
> So in many ways, this question is not really a fair one.
>
> AT&T lost the case, and Linux got the ball and ran for it.
>
> That said, I'll drop into the hypotheical, if AT&T had lost and Linux had not been there ..... then... I do think some flavor of BSD would have been the winner.    The two wild cards are from Sun and OSF/CMU.   As Larry says is what about SunOS and Solaris, although the legals of Sun doing that I wonder.   The other question is Mach/OSF (I know Larry does not like the codebase).
>
> But one of the *BSD, Mach or an FOSS Sun code base would have had the most legs.
>
> Clem
>

From crossd at gmail.com  Tue Aug 27 11:26:27 2019
From: crossd at gmail.com (Dan Cross)
Date: Mon, 26 Aug 2019 21:26:27 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
 <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com>
 <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
 <20190827003013.GS13570@mcvoy.com>
 <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net>
Message-ID: <CAEoi9W6upO4LdvV0AVLy8f1je6oSZeuz4bbP4yuux-Xe6UUEBA@mail.gmail.com>

On Mon, Aug 26, 2019, 9:00 PM Arthur Krewat wrote:
>[snip]

>
> As for what mmap() doesn't do right, I started using memory mapped files
> back in the early 80s on VMS on a VAX-11/780 when I and a colleague were
> converting a database from TOPS-10 to VMS. Perhaps I am misunderstanding
> your dislike for mmap() but please, enlighten me. It was my
> understanding at the time that it was akin to swapping/virtual-memory
> using an MMU. The difference was that instead of using the main paging
> area, the kernel would use an actual file.  Why would mmap() be a bad
> thing, when it's hooked into the kernel, and possibly hardware, at such
> a low point?


I don't mean to put words in Larry's mouth, but I think he meant that ZFS
bypasses the OS page cache, so that file IO and mmap use a different
buffering scheme that is not mutually consistent. So a process could mmap()
a file, write to it via a pointer indirection, and then invoke read() at a
relevant offset and (perhaps) not see the earlier write reflected; or vice
versa. It's not that mmap is a priori bad, but rather that ZFS has this
unfortunate corner case related to mmap.

         - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190826/5def982d/attachment.html>

From tytso at mit.edu  Tue Aug 27 12:16:58 2019
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Mon, 26 Aug 2019 22:16:58 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
Message-ID: <20190827021658.GF28066@mit.edu>

On Mon, Aug 26, 2019 at 05:27:14PM -0600, Warner Losh wrote:
> 
> BSD was in decent enough shape at the time to run on PCs. Though it
> fragmented early through no fault of Linux. And the AT&T lawsuit created a
> lot of FUD in the area without actually protecting System V. It's unclear
> if another thing would have popped up to fill the void... Linux flourished
> in the confusion, but without it, it's hard to know if something else would
> have been developed before the AT&T lawsuit settled.

It's really hard to answer these what-if questions.  The *BSD's
suffered from some really toxic politics which resulted in the
fragmentation, but it also no doubt turned away some developers.  I
had friends at MIT who were urging me to quit the "toy" Linux and
switch to the more "Real" Unix efforts.  But I got to meet at least
one very toxic personality in person which immediately turned me away
from that offer --- and I got my start on BSD 4.3 with Project Athena.
(For all that people used to like to complain about Linus's e-mail
persona, I *much* preferred to work with Linus than with some of the
personalities in the *BSD/HURD communities.)

People are very fond of blaming the *BSD's failure to become popular
on the AT&T lawsuit, and that no doubt didn't help.  But it's not at
all clear to me that was the only, or even the primary, reason.

    	     	     	     	      	   - Ted

From lm at mcvoy.com  Tue Aug 27 12:39:13 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 26 Aug 2019 19:39:13 -0700
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <20190827021658.GF28066@mit.edu>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
 <20190827021658.GF28066@mit.edu>
Message-ID: <20190827023913.GT13570@mcvoy.com>

On Mon, Aug 26, 2019 at 10:16:58PM -0400, Theodore Y. Ts'o wrote:
> On Mon, Aug 26, 2019 at 05:27:14PM -0600, Warner Losh wrote:
> > 
> > BSD was in decent enough shape at the time to run on PCs. Though it
> > fragmented early through no fault of Linux. And the AT&T lawsuit created a
> > lot of FUD in the area without actually protecting System V. It's unclear
> > if another thing would have popped up to fill the void... Linux flourished
> > in the confusion, but without it, it's hard to know if something else would
> > have been developed before the AT&T lawsuit settled.
> 
> It's really hard to answer these what-if questions.  The *BSD's
> suffered from some really toxic politics which resulted in the
> fragmentation, but it also no doubt turned away some developers.  I
> had friends at MIT who were urging me to quit the "toy" Linux and
> switch to the more "Real" Unix efforts.  But I got to meet at least
> one very toxic personality in person which immediately turned me away
> from that offer --- and I got my start on BSD 4.3 with Project Athena.
> (For all that people used to like to complain about Linus's e-mail
> persona, I *much* preferred to work with Linus than with some of the
> personalities in the *BSD/HURD communities.)
> 
> People are very fond of blaming the *BSD's failure to become popular
> on the AT&T lawsuit, and that no doubt didn't help.  But it's not at
> all clear to me that was the only, or even the primary, reason.

I agree with Ted and I'm seeing it to this day, I hang with some BSD
folks and they spend way too much time complaining about people.  Sorry,
but that's my take.  Maybe the world is as shitty as they say it is but
my world wasn't that great, you just roll up your sleeves and make a 
difference.  I dunno, it does seem different, maybe it was easy for
me and it is hard for them but I don't like the complaining.

Linus, in my opinion, is a great programmer (all you have to do is read
his rants about obscure stuff and it is clear he knows the details of a
ton of stuff), a great architect (I could be pushed back a little on 
this one but he is good), and a great manager.  He inspires other people
to do well, he pushes for a good code base, he hates shitty code.  He
is a leader, you can argue about his faults but he leads.  And I have
*never* seen all those skill sets in one person.  I've said that at 
least 20 years ago and it is true today.

The BSD crowd lacked that sort of leader.  So
{386,Net,Open,Free,DragonFly}BSD all have their own crowd but they are
tiny crowds.

I say this with dismay, I'm a SunOS 4.x guy, that's the bugfixed BSD.
I loved BSD Unix, it was the best and it had the chance to be the 
future but for whatever reason the "leaders" in BSD didn't have an
actual leader.  Not one of them.  Not 1/100th of the leader that 
Linus is.

So Linux won.  I'm not that happy about it, I could imagine a world
where BSD won and I think I'd be happier in that world but it didn't
happen.

From lm at mcvoy.com  Tue Aug 27 12:45:11 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 26 Aug 2019 19:45:11 -0700
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CAEoi9W6upO4LdvV0AVLy8f1je6oSZeuz4bbP4yuux-Xe6UUEBA@mail.gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
 <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com>
 <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
 <20190827003013.GS13570@mcvoy.com>
 <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net>
 <CAEoi9W6upO4LdvV0AVLy8f1je6oSZeuz4bbP4yuux-Xe6UUEBA@mail.gmail.com>
Message-ID: <20190827024511.GU13570@mcvoy.com>

On Mon, Aug 26, 2019 at 09:26:27PM -0400, Dan Cross wrote:
> On Mon, Aug 26, 2019, 9:00 PM Arthur Krewat wrote:
> >[snip]
> 
> >
> > As for what mmap() doesn't do right, I started using memory mapped files
> > back in the early 80s on VMS on a VAX-11/780 when I and a colleague were
> > converting a database from TOPS-10 to VMS. Perhaps I am misunderstanding
> > your dislike for mmap() but please, enlighten me. It was my
> > understanding at the time that it was akin to swapping/virtual-memory
> > using an MMU. The difference was that instead of using the main paging
> > area, the kernel would use an actual file.  Why would mmap() be a bad
> > thing, when it's hooked into the kernel, and possibly hardware, at such
> > a low point?
> 
> 
> I don't mean to put words in Larry's mouth, but I think he meant that ZFS
> bypasses the OS page cache, so that file IO and mmap use a different
> buffering scheme that is not mutually consistent. 

Dan is right.  At Sun, when Joe Moran did the 4.x VM system, he put into
place the vision that Bill Joy had.  Which was that the page cache is 
*the* cache.  There is nothing else.  We spent a bunch of time killing
the buffer cache because you couldn't mmap the buffer cache, you could
mmap the page cache.

It's hard to describe how right that was but it was right.  You could
have as many processes as you wanted mmap-ing the same data and there
was a single version of the data.

What ZFS did was manage the data on their own.  So if you mmap-ed a ZFS
file it had to bcopy the data into the page cache and now it is right
back to two copies of the data and you have to manage consistency.

I would have been fine if all page sized blocks were in the page cache
and ZFS managed the less than page sized blocks.  But they punted on
the page cache entirely.

My mind is blown that that was allowed to ship.  The Sun I worked at,
if I had proposed that design, I would have been kicked out of the
kernel group.

From lm at mcvoy.com  Tue Aug 27 12:53:10 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 26 Aug 2019 19:53:10 -0700
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CAKzdPgxvb1MSA1yN3h0wY2aySzkd0aDjFSYH6pa==7MEw_zR8w@mail.gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
 <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com>
 <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
 <20190827003013.GS13570@mcvoy.com>
 <CAKzdPgxvb1MSA1yN3h0wY2aySzkd0aDjFSYH6pa==7MEw_zR8w@mail.gmail.com>
Message-ID: <20190827025310.GW13570@mcvoy.com>

Hey Rob,

I followed Bell Labs through the papers, the Lions doc, but I didn't get
any insight into Research after v7 or so.

Can you tell us what you liked about the later versions?

I don't want to be a total suck up but I've been a fan of your insight
ever since you said something like "if you think you need threads your
processes are too fat".  I've had long discussions with Linus about how
to make that statement 100% true (partial page table sharing across
processes, how do you make that work in general).  We didn't come to
an answer but we both agreed that processes should be as cheap as 
threads and mmap is the way to share data.

On Tue, Aug 27, 2019 at 10:58:54AM +1000, Rob Pike wrote:
> I always thought Research 10th Edition was fantastic. Even the 8th edition
> was an improvement on most of its successors. But things flowed another
> way, with muddy streams mixing in.
> 
> -rob
> 
> 
> On Tue, Aug 27, 2019 at 10:30 AM Larry McVoy <lm at mcvoy.com> wrote:
> 
> > On Mon, Aug 26, 2019 at 08:19:45PM -0400, Arthur Krewat wrote:
> > > On 8/26/2019 7:56 PM, William Pechter wrote:
> > > >ZFS
> > >
> > > Here, here!
> >
> > I really don't understand the love for ZFS.  I hired Bonwick and I
> > hired Moore, I had high expectations but they were all dashed when I
> > realized ZFS doesn't use the page cache.  That's so crazy busted I lost
> > all interest in ZFS.  ZFS took us back to HP-UX mmap semantics.
> >

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

From krewat at kilonet.net  Tue Aug 27 13:14:45 2019
From: krewat at kilonet.net (Arthur Krewat)
Date: Mon, 26 Aug 2019 23:14:45 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <20190827024511.GU13570@mcvoy.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
 <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com>
 <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
 <20190827003013.GS13570@mcvoy.com>
 <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net>
 <CAEoi9W6upO4LdvV0AVLy8f1je6oSZeuz4bbP4yuux-Xe6UUEBA@mail.gmail.com>
 <20190827024511.GU13570@mcvoy.com>
Message-ID: <faaebe25-e5e5-0f6e-6eda-fc2fc6a0dc95@kilonet.net>



On 8/26/2019 10:45 PM, Larry McVoy wrote:
>   Which was that the page cache is
> *the*  cache.  There is nothing else.
Yeah, I re-read what you wrote a few times after I replied, and realized 
what you meant ... eventually ;)



From athornton at gmail.com  Tue Aug 27 15:54:31 2019
From: athornton at gmail.com (Adam Thornton)
Date: Mon, 26 Aug 2019 22:54:31 -0700
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <20190827023913.GT13570@mcvoy.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
 <20190827021658.GF28066@mit.edu> <20190827023913.GT13570@mcvoy.com>
Message-ID: <7DB50A42-BBA3-4F70-BCCA-31FBAB2F1E1C@gmail.com>



> On Aug 26, 2019, at 7:39 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> On Mon, Aug 26, 2019 at 10:16:58PM -0400, Theodore Y. Ts'o wrote:
>> But I got to meet at least
>> one very toxic personality in person which immediately turned me away
>> from that offer --- and I got my start on BSD 4.3 with Project Athena.
>> (For all that people used to like to complain about Linus's e-mail
>> persona, I *much* preferred to work with Linus than with some of the
>> personalities in the *BSD/HURD communities.)
>> 
> 
> I agree with Ted and I'm seeing it to this day, I hang with some BSD
> folks and they spend way too much time complaining about people. 

Yeah, this.  I don’t know about these days, but….

End of the 90s, early 2000s, I was deeply involved in the Linux port to System/390 and then zSeries.  Sometime, probably ’99, maybe ’00, I went to a Linux conference in Atlanta; I talked a little about Linux on S/390 and the things we were looking for help with.

And I went to the NetBSD booth.  I mean, even then, NetBSD’s thing was that it ran on all sorts of architectures.  So I introduced myself, to say, “hey, if you guys want a development environment to hammer out a S/390 port, I can probably hook you up.”  What I got was a btiter rant about Linux’s “so-called portability” and I was basically told to FOAD.

That was…quite a surprise, having been working in a mostly-supportive community, albeit one in which the manufacturer was pretty dubious about the port.

Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190826/327dd2bd/attachment.html>

From gregg.drwho8 at gmail.com  Tue Aug 27 16:05:00 2019
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Tue, 27 Aug 2019 02:05:00 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <7DB50A42-BBA3-4F70-BCCA-31FBAB2F1E1C@gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
 <20190827021658.GF28066@mit.edu> <20190827023913.GT13570@mcvoy.com>
 <7DB50A42-BBA3-4F70-BCCA-31FBAB2F1E1C@gmail.com>
Message-ID: <CAC5iaNHbx5cnYMOm_ng8NpM9EkTg-ekfgK3vS7vm6KFNxLiXpw@mail.gmail.com>

Hello!
Oh dear.
At the very first Linux conference in NYC, I caught up with the NetBSD
group there, and suggested something-of-a-sort. Let's just say that
the person there is probably still active on their lists, and
sometimes comes across as someone even Larry wouldn't like very much.
I tried again after he stopped behaving like someone from a movie we
all know, and I asked again. His response was similar. I put it down
to extreme jet lag.

Adam if your interested please ask off list.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."

On Tue, Aug 27, 2019 at 1:55 AM Adam Thornton <athornton at gmail.com> wrote:
>
>
>
> On Aug 26, 2019, at 7:39 PM, Larry McVoy <lm at mcvoy.com> wrote:
>
> On Mon, Aug 26, 2019 at 10:16:58PM -0400, Theodore Y. Ts'o wrote:
>
> But I got to meet at least
> one very toxic personality in person which immediately turned me away
> from that offer --- and I got my start on BSD 4.3 with Project Athena.
> (For all that people used to like to complain about Linus's e-mail
> persona, I *much* preferred to work with Linus than with some of the
> personalities in the *BSD/HURD communities.)
>
>
> I agree with Ted and I'm seeing it to this day, I hang with some BSD
> folks and they spend way too much time complaining about people.
>
>
> Yeah, this.  I don’t know about these days, but….
>
> End of the 90s, early 2000s, I was deeply involved in the Linux port to System/390 and then zSeries.  Sometime, probably ’99, maybe ’00, I went to a Linux conference in Atlanta; I talked a little about Linux on S/390 and the things we were looking for help with.
>
> And I went to the NetBSD booth.  I mean, even then, NetBSD’s thing was that it ran on all sorts of architectures.  So I introduced myself, to say, “hey, if you guys want a development environment to hammer out a S/390 port, I can probably hook you up.”  What I got was a btiter rant about Linux’s “so-called portability” and I was basically told to FOAD.
>
> That was…quite a surprise, having been working in a mostly-supportive community, albeit one in which the manufacturer was pretty dubious about the port.
>
> Adam

From emu at e-bbes.com  Tue Aug 27 16:37:26 2019
From: emu at e-bbes.com (emanuel stiebler)
Date: Tue, 27 Aug 2019 02:37:26 -0400
Subject: [TUHS] /dev/null
In-Reply-To: <201908262318.x7QNIqaY012455@darkstar.fourwinds.com>
References: <201908262318.x7QNIqaY012455@darkstar.fourwinds.com>
Message-ID: <e69e933b-4e0e-0c2e-700a-10c522fe3ad9@e-bbes.com>

On 2019-08-26 19:18, Jon Steinhart wrote:
> Just curious - am doing a cross-country road trip with my kid and saw a
> Wisconsin dev null license plate.  Didn't get a look at the driver.
> Does it belong to anyone on this list?

Hopefully he has more fun with it, than this guy:

https://www.wired.com/story/null-license-plate-landed-one-hacker-ticket-hell/



From arnold at skeeve.com  Tue Aug 27 17:47:07 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 27 Aug 2019 01:47:07 -0600
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CAKzdPgxvb1MSA1yN3h0wY2aySzkd0aDjFSYH6pa==7MEw_zR8w@mail.gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
 <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com>
 <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
 <20190827003013.GS13570@mcvoy.com>
 <CAKzdPgxvb1MSA1yN3h0wY2aySzkd0aDjFSYH6pa==7MEw_zR8w@mail.gmail.com>
Message-ID: <201908270747.x7R7l73N024373@freefriends.org>

I'd have liked to see Plan 9 take over the world. I think we'd all be
in a nicer place if it had.

My $.02,

Arnold

Rob Pike <robpike at gmail.com> wrote:

> I always thought Research 10th Edition was fantastic. Even the 8th edition
> was an improvement on most of its successors. But things flowed another
> way, with muddy streams mixing in.
>
> -rob
>
>
> On Tue, Aug 27, 2019 at 10:30 AM Larry McVoy <lm at mcvoy.com> wrote:
>
> > On Mon, Aug 26, 2019 at 08:19:45PM -0400, Arthur Krewat wrote:
> > > On 8/26/2019 7:56 PM, William Pechter wrote:
> > > >ZFS
> > >
> > > Here, here!
> >
> > I really don't understand the love for ZFS.  I hired Bonwick and I
> > hired Moore, I had high expectations but they were all dashed when I
> > realized ZFS doesn't use the page cache.  That's so crazy busted I lost
> > all interest in ZFS.  ZFS took us back to HP-UX mmap semantics.
> >

From robpike at gmail.com  Tue Aug 27 19:47:58 2019
From: robpike at gmail.com (Rob Pike)
Date: Tue, 27 Aug 2019 19:47:58 +1000
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <20190827025310.GW13570@mcvoy.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
 <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com>
 <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
 <20190827003013.GS13570@mcvoy.com>
 <CAKzdPgxvb1MSA1yN3h0wY2aySzkd0aDjFSYH6pa==7MEw_zR8w@mail.gmail.com>
 <20190827025310.GW13570@mcvoy.com>
Message-ID: <CAKzdPgzJ044_68_yaMhu0qzU=XvtuYvQq0UxX82D=Q9wF2DKRQ@mail.gmail.com>

V8 was the first of a series of refinements that unified things nicely,
allowing programs to interact more smoothly. Nothing too dramatic, really:
things like a shell that could export its environment, including functions;
tweaks to how $PATH worked so we could have binaries with names like n/m1
n/m2 etc. to connect to machines m1 and m2; a push for output from programs
that worked as input to the same programs (a huge deal for the shell); and
so on. Lots of cleanups (db really worked, and worked well; stuff like
that). Not to mention clean networking and graphics APIs that showed how
easy it was to incorporate them into Unix.

What is a socket for, anyway? Why do you need them when you have file
descriptors? (Rhetorical question, because the answer is, you don't. But
the earliest sockets didn't even implement read and write!)

And so on.

But we did Plan 9 after v10, so it's clear we didn't think it was perfect,
yet.

-rob


On Tue, Aug 27, 2019 at 12:53 PM Larry McVoy <lm at mcvoy.com> wrote:

> Hey Rob,
>
> I followed Bell Labs through the papers, the Lions doc, but I didn't get
> any insight into Research after v7 or so.
>
> Can you tell us what you liked about the later versions?
>
> I don't want to be a total suck up but I've been a fan of your insight
> ever since you said something like "if you think you need threads your
> processes are too fat".  I've had long discussions with Linus about how
> to make that statement 100% true (partial page table sharing across
> processes, how do you make that work in general).  We didn't come to
> an answer but we both agreed that processes should be as cheap as
> threads and mmap is the way to share data.
>
> On Tue, Aug 27, 2019 at 10:58:54AM +1000, Rob Pike wrote:
> > I always thought Research 10th Edition was fantastic. Even the 8th
> edition
> > was an improvement on most of its successors. But things flowed another
> > way, with muddy streams mixing in.
> >
> > -rob
> >
> >
> > On Tue, Aug 27, 2019 at 10:30 AM Larry McVoy <lm at mcvoy.com> wrote:
> >
> > > On Mon, Aug 26, 2019 at 08:19:45PM -0400, Arthur Krewat wrote:
> > > > On 8/26/2019 7:56 PM, William Pechter wrote:
> > > > >ZFS
> > > >
> > > > Here, here!
> > >
> > > I really don't understand the love for ZFS.  I hired Bonwick and I
> > > hired Moore, I had high expectations but they were all dashed when I
> > > realized ZFS doesn't use the page cache.  That's so crazy busted I lost
> > > all interest in ZFS.  ZFS took us back to HP-UX mmap semantics.
> > >
>
> --
> ---
> Larry McVoy                  lm at mcvoy.com
> http://www.mcvoy.com/lm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190827/8a021aaf/attachment.html>

From norman at oclsc.org  Tue Aug 27 20:41:43 2019
From: norman at oclsc.org (Norman Wilson)
Date: Tue, 27 Aug 2019 06:41:43 -0400
Subject: [TUHS] /dev/null
Message-ID: <1566902508.8190.for-standards-violators@oclsc.org>

John Steinhart:

  Just curious - am doing a cross-country road trip with my kid and saw a
  Wisconsin dev null license plate.  Didn't get a look at the driver.

=====

It's in ken/mem.c in Fourth Edition, dmr/mem.c in Fifth and Sixth.

Norman (no sheds) Wilson
Toronto ON

From lm at mcvoy.com  Wed Aug 28 00:55:56 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 27 Aug 2019 07:55:56 -0700
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <faaebe25-e5e5-0f6e-6eda-fc2fc6a0dc95@kilonet.net>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
 <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com>
 <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
 <20190827003013.GS13570@mcvoy.com>
 <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net>
 <CAEoi9W6upO4LdvV0AVLy8f1je6oSZeuz4bbP4yuux-Xe6UUEBA@mail.gmail.com>
 <20190827024511.GU13570@mcvoy.com>
 <faaebe25-e5e5-0f6e-6eda-fc2fc6a0dc95@kilonet.net>
Message-ID: <20190827145556.GD13570@mcvoy.com>

On Mon, Aug 26, 2019 at 11:14:45PM -0400, Arthur Krewat wrote:
> On 8/26/2019 10:45 PM, Larry McVoy wrote:
> >  Which was that the page cache is
> >*the*  cache.  There is nothing else.
> Yeah, I re-read what you wrote a few times after I replied, and realized
> what you meant ... eventually ;)

I might be making too big of a deal about it.  mmap semantics mattered
a lot when SMPs first showed up and main memory was small.  It meant
that you could have multiple CPUs seeing and working on the same chunk
of data at the same time.

It's very similar to way that IOMMUs are exposed to user space these
days, enabling virtual machines direct access to the I/O devices.

ZFS breaks that model, the data is all in the ARC and if you mmap
it they have to bcopy the data out of the ARC, into the page cache
and now they have a consistency problem, you could modify stuff 
via mmap or write and they have to manage that.

That consistency problem is the main reason that Sun almost completely
killed the buffer cache (it still was used for inodes and directories
but that was it).  That consistency problem is a pain in the rear,
all sorts of race conditions and it tended to bit rot.

Jeff and Bill are smart people so I suspect they got it right but I'm
still stunned that they took such an architecturally bad approach.
And even more stunned that the oversight people approved it.  There
is zero chance that the Sun I worked at would have allowed that.

--lm

From aap at papnet.eu  Wed Aug 28 02:05:59 2019
From: aap at papnet.eu (Angelo Papenhoff)
Date: Tue, 27 Aug 2019 18:05:59 +0200
Subject: [TUHS] Running v10
In-Reply-To: <CAKzdPgxvb1MSA1yN3h0wY2aySzkd0aDjFSYH6pa==7MEw_zR8w@mail.gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
 <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com>
 <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
 <20190827003013.GS13570@mcvoy.com>
 <CAKzdPgxvb1MSA1yN3h0wY2aySzkd0aDjFSYH6pa==7MEw_zR8w@mail.gmail.com>
Message-ID: <20190827160559.GA92491@indra.papnet.eu>

Did anyone try to get v10 running in simh yet? It's been public for a
while now and while we have two blit emulators already I haven't seen
v10 alive yet. I have to admit I haven't tried to get it running myself either.

aap

On 27/08/19, Rob Pike wrote:
> I always thought Research 10th Edition was fantastic. Even the 8th edition
> was an improvement on most of its successors. But things flowed another
> way, with muddy streams mixing in.

From henry.r.bent at gmail.com  Wed Aug 28 02:27:23 2019
From: henry.r.bent at gmail.com (Henry Bent)
Date: Tue, 27 Aug 2019 12:27:23 -0400
Subject: [TUHS] Running v10
In-Reply-To: <20190827160559.GA92491@indra.papnet.eu>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
 <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com>
 <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
 <20190827003013.GS13570@mcvoy.com>
 <CAKzdPgxvb1MSA1yN3h0wY2aySzkd0aDjFSYH6pa==7MEw_zR8w@mail.gmail.com>
 <20190827160559.GA92491@indra.papnet.eu>
Message-ID: <CAEdTPBddQangO-vGMT6nM=BeJFCywz9DX1yngwiq7YaYapvHCA@mail.gmail.com>

On Tue, 27 Aug 2019 at 12:12, Angelo Papenhoff <aap at papnet.eu> wrote:

> Did anyone try to get v10 running in simh yet? It's been public for a
> while now and while we have two blit emulators already I haven't seen
> v10 alive yet. I have to admit I haven't tried to get it running myself
> either.
>

After a brief look at the boot and config sources it appears as though
there is support for the MicroVAX II which SIMH supports and I have used.
Is there an environment which is preferred for building the V10 source
tree?  4.3BSD?  V8?  Something else?

-Henry

On 27/08/19, Rob Pike wrote:
> > I always thought Research 10th Edition was fantastic. Even the 8th
> edition
> > was an improvement on most of its successors. But things flowed another
> > way, with muddy streams mixing in.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190827/5b431988/attachment.html>

From ggm at algebras.org  Wed Aug 28 08:30:01 2019
From: ggm at algebras.org (George Michaelson)
Date: Wed, 28 Aug 2019 08:30:01 +1000
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <20190827145556.GD13570@mcvoy.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
 <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com>
 <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
 <20190827003013.GS13570@mcvoy.com>
 <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net>
 <CAEoi9W6upO4LdvV0AVLy8f1je6oSZeuz4bbP4yuux-Xe6UUEBA@mail.gmail.com>
 <20190827024511.GU13570@mcvoy.com>
 <faaebe25-e5e5-0f6e-6eda-fc2fc6a0dc95@kilonet.net>
 <20190827145556.GD13570@mcvoy.com>
Message-ID: <CAKr6gn2V_T_EnYaz3OYassHSpLecoKTkqZe+By8A9kQQ=7jnMA@mail.gmail.com>

BSD, but with the original STREAMS semantics, not sockets.

DARPA did us no favours accepting sockets in place of simple file I/O
semantics for networks.

Newcastle connection put the namespace into
/.../remote-part/path/to/thing which I felt was also good.

So for me, 7 -> BSD -> got worse for some values of worse

On Wed, Aug 28, 2019 at 12:56 AM Larry McVoy <lm at mcvoy.com> wrote:
>
> On Mon, Aug 26, 2019 at 11:14:45PM -0400, Arthur Krewat wrote:
> > On 8/26/2019 10:45 PM, Larry McVoy wrote:
> > >  Which was that the page cache is
> > >*the*  cache.  There is nothing else.
> > Yeah, I re-read what you wrote a few times after I replied, and realized
> > what you meant ... eventually ;)
>
> I might be making too big of a deal about it.  mmap semantics mattered
> a lot when SMPs first showed up and main memory was small.  It meant
> that you could have multiple CPUs seeing and working on the same chunk
> of data at the same time.
>
> It's very similar to way that IOMMUs are exposed to user space these
> days, enabling virtual machines direct access to the I/O devices.
>
> ZFS breaks that model, the data is all in the ARC and if you mmap
> it they have to bcopy the data out of the ARC, into the page cache
> and now they have a consistency problem, you could modify stuff
> via mmap or write and they have to manage that.
>
> That consistency problem is the main reason that Sun almost completely
> killed the buffer cache (it still was used for inodes and directories
> but that was it).  That consistency problem is a pain in the rear,
> all sorts of race conditions and it tended to bit rot.
>
> Jeff and Bill are smart people so I suspect they got it right but I'm
> still stunned that they took such an architecturally bad approach.
> And even more stunned that the oversight people approved it.  There
> is zero chance that the Sun I worked at would have allowed that.
>
> --lm

From lm at mcvoy.com  Wed Aug 28 08:40:02 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 27 Aug 2019 15:40:02 -0700
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CAKr6gn2V_T_EnYaz3OYassHSpLecoKTkqZe+By8A9kQQ=7jnMA@mail.gmail.com>
References: <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
 <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com>
 <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
 <20190827003013.GS13570@mcvoy.com>
 <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net>
 <CAEoi9W6upO4LdvV0AVLy8f1je6oSZeuz4bbP4yuux-Xe6UUEBA@mail.gmail.com>
 <20190827024511.GU13570@mcvoy.com>
 <faaebe25-e5e5-0f6e-6eda-fc2fc6a0dc95@kilonet.net>
 <20190827145556.GD13570@mcvoy.com>
 <CAKr6gn2V_T_EnYaz3OYassHSpLecoKTkqZe+By8A9kQQ=7jnMA@mail.gmail.com>
Message-ID: <20190827224002.GB15511@mcvoy.com>

Wait, are you arguing for STREAMS over sockets?  Dear god, please no.
Have you ever used STREAMS (not Ritchies streams, those were OK)?
I have.  I ported Lachman's STREAMS based TCP/IP stack twice, once
to a long since defunct super computer called the ETA-10 and then 
to SCO Unix.  I've got way more STREAMS experience than most people
and I can tell you that sockets are WAY WAY better.  I get the "it
should have just been file I/O" except that I don't.  I tried to 
write a library that let you open up /net/tcp/$host:$port and do
I/O like it was a file descriptor.  That works for a lot of stuff
but I ran into problems quickly.  A networking connection is not
a file handle.  You can make some stuff work but I couldn't figure
out how to do all of it.   You end up having to do ioctls to handle
the stuff that doesn't fit well into the file system name space.
I think plan 9 did this sort of thing, maybe Rob can prove me wrong
or remember where it didn't match.

I do know that STREAMS came back to Solaris, some VP inked a shitty
deal with Lachman and bought the rights to the stack.  It was slow
as molasses in the winter and customers absolutely hated it.  Sun 
got Mentat to redo it for perf but customers still hated it, they
understood sockets, everyone else had sockets, they wanted sockets
and they got them.  Sun put them back and nobody ever asked about
STREAMS again.

On Wed, Aug 28, 2019 at 08:30:01AM +1000, George Michaelson wrote:
> BSD, but with the original STREAMS semantics, not sockets.
> 
> DARPA did us no favours accepting sockets in place of simple file I/O
> semantics for networks.
> 
> Newcastle connection put the namespace into
> /.../remote-part/path/to/thing which I felt was also good.
> 
> So for me, 7 -> BSD -> got worse for some values of worse
> 
> On Wed, Aug 28, 2019 at 12:56 AM Larry McVoy <lm at mcvoy.com> wrote:
> >
> > On Mon, Aug 26, 2019 at 11:14:45PM -0400, Arthur Krewat wrote:
> > > On 8/26/2019 10:45 PM, Larry McVoy wrote:
> > > >  Which was that the page cache is
> > > >*the*  cache.  There is nothing else.
> > > Yeah, I re-read what you wrote a few times after I replied, and realized
> > > what you meant ... eventually ;)
> >
> > I might be making too big of a deal about it.  mmap semantics mattered
> > a lot when SMPs first showed up and main memory was small.  It meant
> > that you could have multiple CPUs seeing and working on the same chunk
> > of data at the same time.
> >
> > It's very similar to way that IOMMUs are exposed to user space these
> > days, enabling virtual machines direct access to the I/O devices.
> >
> > ZFS breaks that model, the data is all in the ARC and if you mmap
> > it they have to bcopy the data out of the ARC, into the page cache
> > and now they have a consistency problem, you could modify stuff
> > via mmap or write and they have to manage that.
> >
> > That consistency problem is the main reason that Sun almost completely
> > killed the buffer cache (it still was used for inodes and directories
> > but that was it).  That consistency problem is a pain in the rear,
> > all sorts of race conditions and it tended to bit rot.
> >
> > Jeff and Bill are smart people so I suspect they got it right but I'm
> > still stunned that they took such an architecturally bad approach.
> > And even more stunned that the oversight people approved it.  There
> > is zero chance that the Sun I worked at would have allowed that.
> >
> > --lm

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

From ggm at algebras.org  Wed Aug 28 08:46:35 2019
From: ggm at algebras.org (George Michaelson)
Date: Wed, 28 Aug 2019 08:46:35 +1000
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <20190827224002.GB15511@mcvoy.com>
References: <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
 <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com>
 <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
 <20190827003013.GS13570@mcvoy.com>
 <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net>
 <CAEoi9W6upO4LdvV0AVLy8f1je6oSZeuz4bbP4yuux-Xe6UUEBA@mail.gmail.com>
 <20190827024511.GU13570@mcvoy.com>
 <faaebe25-e5e5-0f6e-6eda-fc2fc6a0dc95@kilonet.net>
 <20190827145556.GD13570@mcvoy.com>
 <CAKr6gn2V_T_EnYaz3OYassHSpLecoKTkqZe+By8A9kQQ=7jnMA@mail.gmail.com>
 <20190827224002.GB15511@mcvoy.com>
Message-ID: <CAKr6gn2EwxJH+5R75QuxgHBtF7BFFdc7Qfx=3HPvHi71i2fLdA@mail.gmail.com>

oh maybe I meant "streams" not "STREAMS" I always got confused if the
original ritchie spec was upper or lower case. Charles Forsyth coded
it into the York Uni Vaxen, worked fine. I left shortly after to do
stuff at UCL, it only came back into my life when at UQ in Australia
we got an ICL "certified" SYSV host and along side dead technology
like RFS up it popped (I think ICL had coded an OSI stack we were
testing)

-G

On Wed, Aug 28, 2019 at 8:40 AM Larry McVoy <lm at mcvoy.com> wrote:
>
> Wait, are you arguing for STREAMS over sockets?  Dear god, please no.
> Have you ever used STREAMS (not Ritchies streams, those were OK)?
> I have.  I ported Lachman's STREAMS based TCP/IP stack twice, once
> to a long since defunct super computer called the ETA-10 and then
> to SCO Unix.  I've got way more STREAMS experience than most people
> and I can tell you that sockets are WAY WAY better.  I get the "it
> should have just been file I/O" except that I don't.  I tried to
> write a library that let you open up /net/tcp/$host:$port and do
> I/O like it was a file descriptor.  That works for a lot of stuff
> but I ran into problems quickly.  A networking connection is not
> a file handle.  You can make some stuff work but I couldn't figure
> out how to do all of it.   You end up having to do ioctls to handle
> the stuff that doesn't fit well into the file system name space.
> I think plan 9 did this sort of thing, maybe Rob can prove me wrong
> or remember where it didn't match.
>
> I do know that STREAMS came back to Solaris, some VP inked a shitty
> deal with Lachman and bought the rights to the stack.  It was slow
> as molasses in the winter and customers absolutely hated it.  Sun
> got Mentat to redo it for perf but customers still hated it, they
> understood sockets, everyone else had sockets, they wanted sockets
> and they got them.  Sun put them back and nobody ever asked about
> STREAMS again.
>
> On Wed, Aug 28, 2019 at 08:30:01AM +1000, George Michaelson wrote:
> > BSD, but with the original STREAMS semantics, not sockets.
> >
> > DARPA did us no favours accepting sockets in place of simple file I/O
> > semantics for networks.
> >
> > Newcastle connection put the namespace into
> > /.../remote-part/path/to/thing which I felt was also good.
> >
> > So for me, 7 -> BSD -> got worse for some values of worse
> >
> > On Wed, Aug 28, 2019 at 12:56 AM Larry McVoy <lm at mcvoy.com> wrote:
> > >
> > > On Mon, Aug 26, 2019 at 11:14:45PM -0400, Arthur Krewat wrote:
> > > > On 8/26/2019 10:45 PM, Larry McVoy wrote:
> > > > >  Which was that the page cache is
> > > > >*the*  cache.  There is nothing else.
> > > > Yeah, I re-read what you wrote a few times after I replied, and realized
> > > > what you meant ... eventually ;)
> > >
> > > I might be making too big of a deal about it.  mmap semantics mattered
> > > a lot when SMPs first showed up and main memory was small.  It meant
> > > that you could have multiple CPUs seeing and working on the same chunk
> > > of data at the same time.
> > >
> > > It's very similar to way that IOMMUs are exposed to user space these
> > > days, enabling virtual machines direct access to the I/O devices.
> > >
> > > ZFS breaks that model, the data is all in the ARC and if you mmap
> > > it they have to bcopy the data out of the ARC, into the page cache
> > > and now they have a consistency problem, you could modify stuff
> > > via mmap or write and they have to manage that.
> > >
> > > That consistency problem is the main reason that Sun almost completely
> > > killed the buffer cache (it still was used for inodes and directories
> > > but that was it).  That consistency problem is a pain in the rear,
> > > all sorts of race conditions and it tended to bit rot.
> > >
> > > Jeff and Bill are smart people so I suspect they got it right but I'm
> > > still stunned that they took such an architecturally bad approach.
> > > And even more stunned that the oversight people approved it.  There
> > > is zero chance that the Sun I worked at would have allowed that.
> > >
> > > --lm
>
> --
> ---
> Larry McVoy                  lm at mcvoy.com             http://www.mcvoy.com/lm

From lm at mcvoy.com  Wed Aug 28 08:59:55 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 27 Aug 2019 15:59:55 -0700
Subject: [TUHS] [SPAM] Re:  If not Linux, then what?
In-Reply-To: <CAKr6gn2EwxJH+5R75QuxgHBtF7BFFdc7Qfx=3HPvHi71i2fLdA@mail.gmail.com>
References: <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
 <20190827003013.GS13570@mcvoy.com>
 <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net>
 <CAEoi9W6upO4LdvV0AVLy8f1je6oSZeuz4bbP4yuux-Xe6UUEBA@mail.gmail.com>
 <20190827024511.GU13570@mcvoy.com>
 <faaebe25-e5e5-0f6e-6eda-fc2fc6a0dc95@kilonet.net>
 <20190827145556.GD13570@mcvoy.com>
 <CAKr6gn2V_T_EnYaz3OYassHSpLecoKTkqZe+By8A9kQQ=7jnMA@mail.gmail.com>
 <20190827224002.GB15511@mcvoy.com>
 <CAKr6gn2EwxJH+5R75QuxgHBtF7BFFdc7Qfx=3HPvHi71i2fLdA@mail.gmail.com>
Message-ID: <20190827225955.GC15511@mcvoy.com>

streams were OK but Dennis himself told me he didn't intend them for 
networking.  They were a simple mechanism for pushing line disciplines
onto tty drivers.

I can't remember exactly what he said, this was back in ~1988 or so
and I was talking to him about the STREAMS stuff.  He wasn't very
happy with it and I'm pretty sure he said something like streams
weren't design to mux multiple sources or network connections.
I think he sort of grudgingly gave credit that they made it work
but he seemed to think that it was twisting streams more than they
should be twisted.

On Wed, Aug 28, 2019 at 08:46:35AM +1000, George Michaelson wrote:
> oh maybe I meant "streams" not "STREAMS" I always got confused if the
> original ritchie spec was upper or lower case. Charles Forsyth coded
> it into the York Uni Vaxen, worked fine. I left shortly after to do
> stuff at UCL, it only came back into my life when at UQ in Australia
> we got an ICL "certified" SYSV host and along side dead technology
> like RFS up it popped (I think ICL had coded an OSI stack we were
> testing)
> 
> -G
> 
> On Wed, Aug 28, 2019 at 8:40 AM Larry McVoy <lm at mcvoy.com> wrote:
> >
> > Wait, are you arguing for STREAMS over sockets?  Dear god, please no.
> > Have you ever used STREAMS (not Ritchies streams, those were OK)?
> > I have.  I ported Lachman's STREAMS based TCP/IP stack twice, once
> > to a long since defunct super computer called the ETA-10 and then
> > to SCO Unix.  I've got way more STREAMS experience than most people
> > and I can tell you that sockets are WAY WAY better.  I get the "it
> > should have just been file I/O" except that I don't.  I tried to
> > write a library that let you open up /net/tcp/$host:$port and do
> > I/O like it was a file descriptor.  That works for a lot of stuff
> > but I ran into problems quickly.  A networking connection is not
> > a file handle.  You can make some stuff work but I couldn't figure
> > out how to do all of it.   You end up having to do ioctls to handle
> > the stuff that doesn't fit well into the file system name space.
> > I think plan 9 did this sort of thing, maybe Rob can prove me wrong
> > or remember where it didn't match.
> >
> > I do know that STREAMS came back to Solaris, some VP inked a shitty
> > deal with Lachman and bought the rights to the stack.  It was slow
> > as molasses in the winter and customers absolutely hated it.  Sun
> > got Mentat to redo it for perf but customers still hated it, they
> > understood sockets, everyone else had sockets, they wanted sockets
> > and they got them.  Sun put them back and nobody ever asked about
> > STREAMS again.
> >
> > On Wed, Aug 28, 2019 at 08:30:01AM +1000, George Michaelson wrote:
> > > BSD, but with the original STREAMS semantics, not sockets.
> > >
> > > DARPA did us no favours accepting sockets in place of simple file I/O
> > > semantics for networks.
> > >
> > > Newcastle connection put the namespace into
> > > /.../remote-part/path/to/thing which I felt was also good.
> > >
> > > So for me, 7 -> BSD -> got worse for some values of worse
> > >
> > > On Wed, Aug 28, 2019 at 12:56 AM Larry McVoy <lm at mcvoy.com> wrote:
> > > >
> > > > On Mon, Aug 26, 2019 at 11:14:45PM -0400, Arthur Krewat wrote:
> > > > > On 8/26/2019 10:45 PM, Larry McVoy wrote:
> > > > > >  Which was that the page cache is
> > > > > >*the*  cache.  There is nothing else.
> > > > > Yeah, I re-read what you wrote a few times after I replied, and realized
> > > > > what you meant ... eventually ;)
> > > >
> > > > I might be making too big of a deal about it.  mmap semantics mattered
> > > > a lot when SMPs first showed up and main memory was small.  It meant
> > > > that you could have multiple CPUs seeing and working on the same chunk
> > > > of data at the same time.
> > > >
> > > > It's very similar to way that IOMMUs are exposed to user space these
> > > > days, enabling virtual machines direct access to the I/O devices.
> > > >
> > > > ZFS breaks that model, the data is all in the ARC and if you mmap
> > > > it they have to bcopy the data out of the ARC, into the page cache
> > > > and now they have a consistency problem, you could modify stuff
> > > > via mmap or write and they have to manage that.
> > > >
> > > > That consistency problem is the main reason that Sun almost completely
> > > > killed the buffer cache (it still was used for inodes and directories
> > > > but that was it).  That consistency problem is a pain in the rear,
> > > > all sorts of race conditions and it tended to bit rot.
> > > >
> > > > Jeff and Bill are smart people so I suspect they got it right but I'm
> > > > still stunned that they took such an architecturally bad approach.
> > > > And even more stunned that the oversight people approved it.  There
> > > > is zero chance that the Sun I worked at would have allowed that.
> > > >
> > > > --lm
> >
> > --
> > ---
> > Larry McVoy                  lm at mcvoy.com             http://www.mcvoy.com/lm

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

From clemc at ccc.com  Wed Aug 28 09:10:03 2019
From: clemc at ccc.com (Clem Cole)
Date: Tue, 27 Aug 2019 19:10:03 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <20190827225955.GC15511@mcvoy.com>
References: <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
 <20190827003013.GS13570@mcvoy.com>
 <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net>
 <CAEoi9W6upO4LdvV0AVLy8f1je6oSZeuz4bbP4yuux-Xe6UUEBA@mail.gmail.com>
 <20190827024511.GU13570@mcvoy.com>
 <faaebe25-e5e5-0f6e-6eda-fc2fc6a0dc95@kilonet.net>
 <20190827145556.GD13570@mcvoy.com>
 <CAKr6gn2V_T_EnYaz3OYassHSpLecoKTkqZe+By8A9kQQ=7jnMA@mail.gmail.com>
 <20190827224002.GB15511@mcvoy.com>
 <CAKr6gn2EwxJH+5R75QuxgHBtF7BFFdc7Qfx=3HPvHi71i2fLdA@mail.gmail.com>
 <20190827225955.GC15511@mcvoy.com>
Message-ID: <CAC20D2OWrKk0hxfth3r9HyruoNf8_A-Sa07YrC-rPUPTrYbWZg@mail.gmail.com>

I had a similar conversation btw.  I liked what Dennis did to clean up the
tty handler but I agree as a networking interface it was wretched which is
what system v did.    At stellar we put in the bbn (walsh2) stack and
spliced back in sockets so the bsd code still worked.
That said the idea of trying to keep the everything is a file semantic was
good and streams were closer. The problem sockets is they really were not
quite The same.

What I liked about plan 9 was breaking the control interface out so the
file stuff stayed sane.   But that was a bridge to far for a traditional
Unix.


On Tue, Aug 27, 2019 at 7:00 PM Larry McVoy <lm at mcvoy.com> wrote:

> streams were OK but Dennis himself told me he didn't intend them for
> networking.  They were a simple mechanism for pushing line disciplines
> onto tty drivers.
>
> I can't remember exactly what he said, this was back in ~1988 or so
> and I was talking to him about the STREAMS stuff.  He wasn't very
> happy with it and I'm pretty sure he said something like streams
> weren't design to mux multiple sources or network connections.
> I think he sort of grudgingly gave credit that they made it work
> but he seemed to think that it was twisting streams more than they
> should be twisted.
>
> On Wed, Aug 28, 2019 at 08:46:35AM +1000, George Michaelson wrote:
> > oh maybe I meant "streams" not "STREAMS" I always got confused if the
> > original ritchie spec was upper or lower case. Charles Forsyth coded
> > it into the York Uni Vaxen, worked fine. I left shortly after to do
> > stuff at UCL, it only came back into my life when at UQ in Australia
> > we got an ICL "certified" SYSV host and along side dead technology
> > like RFS up it popped (I think ICL had coded an OSI stack we were
> > testing)
> >
> > -G
> >
> > On Wed, Aug 28, 2019 at 8:40 AM Larry McVoy <lm at mcvoy.com> wrote:
> > >
> > > Wait, are you arguing for STREAMS over sockets?  Dear god, please no.
> > > Have you ever used STREAMS (not Ritchies streams, those were OK)?
> > > I have.  I ported Lachman's STREAMS based TCP/IP stack twice, once
> > > to a long since defunct super computer called the ETA-10 and then
> > > to SCO Unix.  I've got way more STREAMS experience than most people
> > > and I can tell you that sockets are WAY WAY better.  I get the "it
> > > should have just been file I/O" except that I don't.  I tried to
> > > write a library that let you open up /net/tcp/$host:$port and do
> > > I/O like it was a file descriptor.  That works for a lot of stuff
> > > but I ran into problems quickly.  A networking connection is not
> > > a file handle.  You can make some stuff work but I couldn't figure
> > > out how to do all of it.   You end up having to do ioctls to handle
> > > the stuff that doesn't fit well into the file system name space.
> > > I think plan 9 did this sort of thing, maybe Rob can prove me wrong
> > > or remember where it didn't match.
> > >
> > > I do know that STREAMS came back to Solaris, some VP inked a shitty
> > > deal with Lachman and bought the rights to the stack.  It was slow
> > > as molasses in the winter and customers absolutely hated it.  Sun
> > > got Mentat to redo it for perf but customers still hated it, they
> > > understood sockets, everyone else had sockets, they wanted sockets
> > > and they got them.  Sun put them back and nobody ever asked about
> > > STREAMS again.
> > >
> > > On Wed, Aug 28, 2019 at 08:30:01AM +1000, George Michaelson wrote:
> > > > BSD, but with the original STREAMS semantics, not sockets.
> > > >
> > > > DARPA did us no favours accepting sockets in place of simple file I/O
> > > > semantics for networks.
> > > >
> > > > Newcastle connection put the namespace into
> > > > /.../remote-part/path/to/thing which I felt was also good.
> > > >
> > > > So for me, 7 -> BSD -> got worse for some values of worse
> > > >
> > > > On Wed, Aug 28, 2019 at 12:56 AM Larry McVoy <lm at mcvoy.com> wrote:
> > > > >
> > > > > On Mon, Aug 26, 2019 at 11:14:45PM -0400, Arthur Krewat wrote:
> > > > > > On 8/26/2019 10:45 PM, Larry McVoy wrote:
> > > > > > >  Which was that the page cache is
> > > > > > >*the*  cache.  There is nothing else.
> > > > > > Yeah, I re-read what you wrote a few times after I replied, and
> realized
> > > > > > what you meant ... eventually ;)
> > > > >
> > > > > I might be making too big of a deal about it.  mmap semantics
> mattered
> > > > > a lot when SMPs first showed up and main memory was small.  It
> meant
> > > > > that you could have multiple CPUs seeing and working on the same
> chunk
> > > > > of data at the same time.
> > > > >
> > > > > It's very similar to way that IOMMUs are exposed to user space
> these
> > > > > days, enabling virtual machines direct access to the I/O devices.
> > > > >
> > > > > ZFS breaks that model, the data is all in the ARC and if you mmap
> > > > > it they have to bcopy the data out of the ARC, into the page cache
> > > > > and now they have a consistency problem, you could modify stuff
> > > > > via mmap or write and they have to manage that.
> > > > >
> > > > > That consistency problem is the main reason that Sun almost
> completely
> > > > > killed the buffer cache (it still was used for inodes and
> directories
> > > > > but that was it).  That consistency problem is a pain in the rear,
> > > > > all sorts of race conditions and it tended to bit rot.
> > > > >
> > > > > Jeff and Bill are smart people so I suspect they got it right but
> I'm
> > > > > still stunned that they took such an architecturally bad approach.
> > > > > And even more stunned that the oversight people approved it.  There
> > > > > is zero chance that the Sun I worked at would have allowed that.
> > > > >
> > > > > --lm
> > >
> > > --
> > > ---
> > > Larry McVoy                  lm at mcvoy.com
> http://www.mcvoy.com/lm
>
> --
> ---
> Larry McVoy                  lm at mcvoy.com
> http://www.mcvoy.com/lm
>
-- 
Sent from a handheld expect more typos than usual
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190827/3250212d/attachment-0001.html>

From bakul at bitblocks.com  Wed Aug 28 09:16:18 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Tue, 27 Aug 2019 16:16:18 -0700
Subject: [TUHS] If not Linux, then what?
In-Reply-To: Your message of "Tue, 27 Aug 2019 15:40:02 -0700."
 <20190827224002.GB15511@mcvoy.com>
References: <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
 <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com>
 <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
 <20190827003013.GS13570@mcvoy.com>
 <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net>
 <CAEoi9W6upO4LdvV0AVLy8f1je6oSZeuz4bbP4yuux-Xe6UUEBA@mail.gmail.com>
 <20190827024511.GU13570@mcvoy.com>
 <faaebe25-e5e5-0f6e-6eda-fc2fc6a0dc95@kilonet.net>
 <20190827145556.GD13570@mcvoy.com>
 <CAKr6gn2V_T_EnYaz3OYassHSpLecoKTkqZe+By8A9kQQ=7jnMA@mail.gmail.com>
 <20190827224002.GB15511@mcvoy.com>
Message-ID: <20190827231625.55E991570CEA@mail.bitblocks.com>

On Tue, 27 Aug 2019 15:40:02 -0700 Larry McVoy <lm at mcvoy.com> wrote:
Larry McVoy writes:
> and I can tell you that sockets are WAY WAY better.  I get the "it
> should have just been file I/O" except that I don't.  I tried to 
> write a library that let you open up /net/tcp/$host:$port and do
> I/O like it was a file descriptor.  That works for a lot of stuff
> but I ran into problems quickly.  A networking connection is not
> a file handle.  You can make some stuff work but I couldn't figure
> out how to do all of it.   You end up having to do ioctls to handle
> the stuff that doesn't fit well into the file system name space.
> I think plan 9 did this sort of thing, maybe Rob can prove me wrong
> or remember where it didn't match.

Plan9 does a decent enough job.

cpu% ls /net/tcp
/net/tcp/0
/net/tcp/1
/net/tcp/2
/net/tcp/clone
/net/tcp/stats

cpu% ls /net/tcp/1
/net/tcp/1/ctl
/net/tcp/1/data
/net/tcp/1/err
/net/tcp/1/listen
/net/tcp/1/local
/net/tcp/1/remote
/net/tcp/1/status

cpu% cd /net/tcp/1
cpu% cat local remote
192.168.1.103!17010
192.168.1.11!52027

See http://doc.cat-v.org/plan_9/4th_edition/papers/net/

Replacing ioctls with writing ascii commands to ctl files was
a significant improvement. For one thing you can do all this
from a shell script. 

plan9 would've been a big improvement over *BSD or Linux. But
I think a conceptual merge was needed between some sane
version of Unix and plan9 so as to not throw out all the dusty
decks.

From lm at mcvoy.com  Wed Aug 28 09:33:38 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 27 Aug 2019 16:33:38 -0700
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <20190827231625.55E991570CEA@mail.bitblocks.com>
References: <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
 <20190827003013.GS13570@mcvoy.com>
 <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net>
 <CAEoi9W6upO4LdvV0AVLy8f1je6oSZeuz4bbP4yuux-Xe6UUEBA@mail.gmail.com>
 <20190827024511.GU13570@mcvoy.com>
 <faaebe25-e5e5-0f6e-6eda-fc2fc6a0dc95@kilonet.net>
 <20190827145556.GD13570@mcvoy.com>
 <CAKr6gn2V_T_EnYaz3OYassHSpLecoKTkqZe+By8A9kQQ=7jnMA@mail.gmail.com>
 <20190827224002.GB15511@mcvoy.com>
 <20190827231625.55E991570CEA@mail.bitblocks.com>
Message-ID: <20190827233338.GM13570@mcvoy.com>

On Tue, Aug 27, 2019 at 04:16:18PM -0700, Bakul Shah wrote:
> On Tue, 27 Aug 2019 15:40:02 -0700 Larry McVoy <lm at mcvoy.com> wrote:
> Larry McVoy writes:
> > and I can tell you that sockets are WAY WAY better.  I get the "it
> > should have just been file I/O" except that I don't.  I tried to 
> > write a library that let you open up /net/tcp/$host:$port and do
> > I/O like it was a file descriptor.  That works for a lot of stuff
> > but I ran into problems quickly.  A networking connection is not
> > a file handle.  You can make some stuff work but I couldn't figure
> > out how to do all of it.   You end up having to do ioctls to handle
> > the stuff that doesn't fit well into the file system name space.
> > I think plan 9 did this sort of thing, maybe Rob can prove me wrong
> > or remember where it didn't match.
> 
> Plan9 does a decent enough job.
> 
> cpu% ls /net/tcp
> /net/tcp/0
> /net/tcp/1
> /net/tcp/2
> /net/tcp/clone
> /net/tcp/stats
> 
> cpu% ls /net/tcp/1
> /net/tcp/1/ctl
> /net/tcp/1/data
> /net/tcp/1/err
> /net/tcp/1/listen
> /net/tcp/1/local
> /net/tcp/1/remote
> /net/tcp/1/status

I dunno.  I can't look at that and know what it means.  So it means I have
to toss (by the time this came out) a decade or more worth of knowing how
to use sockets and learn this new model that may or may not go anywhere.

> plan9 would've been a big improvement over *BSD or Linux. But
> I think a conceptual merge was needed between some sane
> version of Unix and plan9 so as to not throw out all the dusty
> decks.

That would have made a huge difference.  The problem with Unix is it
is largely good enough.  All sorts of warts appeared over the years
but you can get your job done.  Plan 9 was such a big departure that
it never gained traction.  Having it conform to Posix or pick the
most popular Unix (SunOS?  BSD?) and conform to that.  I'm biased but
even if I wasn't I'd have picked SunOS, virtually all open source back
in the day compiled out of the tarball on SunOS.  Everyone else had 
to tinker or run configure or whatever.

From ggm at algebras.org  Wed Aug 28 10:07:30 2019
From: ggm at algebras.org (George Michaelson)
Date: Wed, 28 Aug 2019 10:07:30 +1000
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CAC20D2OWrKk0hxfth3r9HyruoNf8_A-Sa07YrC-rPUPTrYbWZg@mail.gmail.com>
References: <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
 <20190827003013.GS13570@mcvoy.com>
 <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net>
 <CAEoi9W6upO4LdvV0AVLy8f1je6oSZeuz4bbP4yuux-Xe6UUEBA@mail.gmail.com>
 <20190827024511.GU13570@mcvoy.com>
 <faaebe25-e5e5-0f6e-6eda-fc2fc6a0dc95@kilonet.net>
 <20190827145556.GD13570@mcvoy.com>
 <CAKr6gn2V_T_EnYaz3OYassHSpLecoKTkqZe+By8A9kQQ=7jnMA@mail.gmail.com>
 <20190827224002.GB15511@mcvoy.com>
 <CAKr6gn2EwxJH+5R75QuxgHBtF7BFFdc7Qfx=3HPvHi71i2fLdA@mail.gmail.com>
 <20190827225955.GC15511@mcvoy.com>
 <CAC20D2OWrKk0hxfth3r9HyruoNf8_A-Sa07YrC-rPUPTrYbWZg@mail.gmail.com>
Message-ID: <CAKr6gn3dtdzUPJJxCqi2iieG3+XxEV+atahJaR=yOsab8wpnuA@mail.gmail.com>

At the time we are talking, almost all people were using serial line
protocols, of some form, for point-to-point links. Ethernet was "new"
and I think at one level, being a good (binary) tty/serial discipline
was workable. Stacking things was possible was it not? And, the way I
understand it, The code avoided data copying so was very very
efficient across protocol stacks.

I think it was capable of being improved. Sockets is now defined by
standards. Its impossible to make it do things without huge cost.
We're comparing now, with then.. always dangerous.

-G

On Wed, Aug 28, 2019 at 9:10 AM Clem Cole <clemc at ccc.com> wrote:
>
> I had a similar conversation btw.  I liked what Dennis did to clean up the tty handler but I agree as a networking interface it was wretched which is what system v did.    At stellar we put in the bbn (walsh2) stack and spliced back in sockets so the bsd code still worked.
> That said the idea of trying to keep the everything is a file semantic was good and streams were closer. The problem sockets is they really were not quite The same.
>
> What I liked about plan 9 was breaking the control interface out so the file stuff stayed sane.   But that was a bridge to far for a traditional Unix.
>
>
> On Tue, Aug 27, 2019 at 7:00 PM Larry McVoy <lm at mcvoy.com> wrote:
>>
>> streams were OK but Dennis himself told me he didn't intend them for
>> networking.  They were a simple mechanism for pushing line disciplines
>> onto tty drivers.
>>
>> I can't remember exactly what he said, this was back in ~1988 or so
>> and I was talking to him about the STREAMS stuff.  He wasn't very
>> happy with it and I'm pretty sure he said something like streams
>> weren't design to mux multiple sources or network connections.
>> I think he sort of grudgingly gave credit that they made it work
>> but he seemed to think that it was twisting streams more than they
>> should be twisted.
>>
>> On Wed, Aug 28, 2019 at 08:46:35AM +1000, George Michaelson wrote:
>> > oh maybe I meant "streams" not "STREAMS" I always got confused if the
>> > original ritchie spec was upper or lower case. Charles Forsyth coded
>> > it into the York Uni Vaxen, worked fine. I left shortly after to do
>> > stuff at UCL, it only came back into my life when at UQ in Australia
>> > we got an ICL "certified" SYSV host and along side dead technology
>> > like RFS up it popped (I think ICL had coded an OSI stack we were
>> > testing)
>> >
>> > -G
>> >
>> > On Wed, Aug 28, 2019 at 8:40 AM Larry McVoy <lm at mcvoy.com> wrote:
>> > >
>> > > Wait, are you arguing for STREAMS over sockets?  Dear god, please no.
>> > > Have you ever used STREAMS (not Ritchies streams, those were OK)?
>> > > I have.  I ported Lachman's STREAMS based TCP/IP stack twice, once
>> > > to a long since defunct super computer called the ETA-10 and then
>> > > to SCO Unix.  I've got way more STREAMS experience than most people
>> > > and I can tell you that sockets are WAY WAY better.  I get the "it
>> > > should have just been file I/O" except that I don't.  I tried to
>> > > write a library that let you open up /net/tcp/$host:$port and do
>> > > I/O like it was a file descriptor.  That works for a lot of stuff
>> > > but I ran into problems quickly.  A networking connection is not
>> > > a file handle.  You can make some stuff work but I couldn't figure
>> > > out how to do all of it.   You end up having to do ioctls to handle
>> > > the stuff that doesn't fit well into the file system name space.
>> > > I think plan 9 did this sort of thing, maybe Rob can prove me wrong
>> > > or remember where it didn't match.
>> > >
>> > > I do know that STREAMS came back to Solaris, some VP inked a shitty
>> > > deal with Lachman and bought the rights to the stack.  It was slow
>> > > as molasses in the winter and customers absolutely hated it.  Sun
>> > > got Mentat to redo it for perf but customers still hated it, they
>> > > understood sockets, everyone else had sockets, they wanted sockets
>> > > and they got them.  Sun put them back and nobody ever asked about
>> > > STREAMS again.
>> > >
>> > > On Wed, Aug 28, 2019 at 08:30:01AM +1000, George Michaelson wrote:
>> > > > BSD, but with the original STREAMS semantics, not sockets.
>> > > >
>> > > > DARPA did us no favours accepting sockets in place of simple file I/O
>> > > > semantics for networks.
>> > > >
>> > > > Newcastle connection put the namespace into
>> > > > /.../remote-part/path/to/thing which I felt was also good.
>> > > >
>> > > > So for me, 7 -> BSD -> got worse for some values of worse
>> > > >
>> > > > On Wed, Aug 28, 2019 at 12:56 AM Larry McVoy <lm at mcvoy.com> wrote:
>> > > > >
>> > > > > On Mon, Aug 26, 2019 at 11:14:45PM -0400, Arthur Krewat wrote:
>> > > > > > On 8/26/2019 10:45 PM, Larry McVoy wrote:
>> > > > > > >  Which was that the page cache is
>> > > > > > >*the*  cache.  There is nothing else.
>> > > > > > Yeah, I re-read what you wrote a few times after I replied, and realized
>> > > > > > what you meant ... eventually ;)
>> > > > >
>> > > > > I might be making too big of a deal about it.  mmap semantics mattered
>> > > > > a lot when SMPs first showed up and main memory was small.  It meant
>> > > > > that you could have multiple CPUs seeing and working on the same chunk
>> > > > > of data at the same time.
>> > > > >
>> > > > > It's very similar to way that IOMMUs are exposed to user space these
>> > > > > days, enabling virtual machines direct access to the I/O devices.
>> > > > >
>> > > > > ZFS breaks that model, the data is all in the ARC and if you mmap
>> > > > > it they have to bcopy the data out of the ARC, into the page cache
>> > > > > and now they have a consistency problem, you could modify stuff
>> > > > > via mmap or write and they have to manage that.
>> > > > >
>> > > > > That consistency problem is the main reason that Sun almost completely
>> > > > > killed the buffer cache (it still was used for inodes and directories
>> > > > > but that was it).  That consistency problem is a pain in the rear,
>> > > > > all sorts of race conditions and it tended to bit rot.
>> > > > >
>> > > > > Jeff and Bill are smart people so I suspect they got it right but I'm
>> > > > > still stunned that they took such an architecturally bad approach.
>> > > > > And even more stunned that the oversight people approved it.  There
>> > > > > is zero chance that the Sun I worked at would have allowed that.
>> > > > >
>> > > > > --lm
>> > >
>> > > --
>> > > ---
>> > > Larry McVoy                  lm at mcvoy.com             http://www.mcvoy.com/lm
>>
>> --
>> ---
>> Larry McVoy                  lm at mcvoy.com             http://www.mcvoy.com/lm
>
> --
> Sent from a handheld expect more typos than usual

From bakul at bitblocks.com  Wed Aug 28 10:21:34 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Tue, 27 Aug 2019 17:21:34 -0700
Subject: [TUHS] If not Linux, then what?
In-Reply-To: Your message of "Tue, 27 Aug 2019 16:33:38 -0700."
 <20190827233338.GM13570@mcvoy.com>
References: <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
 <20190827003013.GS13570@mcvoy.com>
 <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net>
 <CAEoi9W6upO4LdvV0AVLy8f1je6oSZeuz4bbP4yuux-Xe6UUEBA@mail.gmail.com>
 <20190827024511.GU13570@mcvoy.com>
 <faaebe25-e5e5-0f6e-6eda-fc2fc6a0dc95@kilonet.net>
 <20190827145556.GD13570@mcvoy.com>
 <CAKr6gn2V_T_EnYaz3OYassHSpLecoKTkqZe+By8A9kQQ=7jnMA@mail.gmail.com>
 <20190827224002.GB15511@mcvoy.com>
 <20190827231625.55E991570CEA@mail.bitblocks.com>
 <20190827233338.GM13570@mcvoy.com>
Message-ID: <20190828002141.40BE41570CE9@mail.bitblocks.com>

On Tue, 27 Aug 2019 16:33:38 -0700 Larry McVoy <lm at mcvoy.com> wrote:
Larry McVoy writes:
> On Tue, Aug 27, 2019 at 04:16:18PM -0700, Bakul Shah wrote:
> > On Tue, 27 Aug 2019 15:40:02 -0700 Larry McVoy <lm at mcvoy.com> wrote:
> > Larry McVoy writes:
> > > and I can tell you that sockets are WAY WAY better.  I get the "it
> > > should have just been file I/O" except that I don't.  I tried to 
> > > write a library that let you open up /net/tcp/$host:$port and do
> > > I/O like it was a file descriptor.  That works for a lot of stuff
> > > but I ran into problems quickly.  A networking connection is not
> > > a file handle.  You can make some stuff work but I couldn't figure
> > > out how to do all of it.   You end up having to do ioctls to handle
> > > the stuff that doesn't fit well into the file system name space.
> > > I think plan 9 did this sort of thing, maybe Rob can prove me wrong
> > > or remember where it didn't match.
> > 
> > Plan9 does a decent enough job.
> > 
> > cpu% ls /net/tcp
> > /net/tcp/0
> > /net/tcp/1
> > /net/tcp/2
> > /net/tcp/clone
> > /net/tcp/stats
> > 
> > cpu% ls /net/tcp/1
> > /net/tcp/1/ctl
> > /net/tcp/1/data
> > /net/tcp/1/err
> > /net/tcp/1/listen
> > /net/tcp/1/local
> > /net/tcp/1/remote
> > /net/tcp/1/status
>
> I dunno.  I can't look at that and know what it means.  So it means I have

Hence the link to Presotto and Winterbottom's paper.

> to toss (by the time this came out) a decade or more worth of knowing how
> to use sockets and learn this new model that may or may not go anywhere.

It's a simper model. It is no big deal. I was intimately
familiar with sockets and the BSD networking stack (worked in
a router startup from the beginning where we rejiggered the
FreeBSD network stack to support N forwarding tables,
additional protocols, interface types etc.  etc.).

> > plan9 would've been a big improvement over *BSD or Linux. But
> > I think a conceptual merge was needed between some sane
> > version of Unix and plan9 so as to not throw out all the dusty
> > decks.
>
> That would have made a huge difference.  The problem with Unix is it
> is largely good enough.  All sorts of warts appeared over the years
> but you can get your job done.  Plan 9 was such a big departure that
> it never gained traction.  Having it conform to Posix or pick the
> most popular Unix (SunOS?  BSD?) and conform to that.  I'm biased but
> even if I wasn't I'd have picked SunOS, virtually all open source back
> in the day compiled out of the tarball on SunOS.  Everyone else had 
> to tinker or run configure or whatever.

I believe not having to be compatible with Unix meant plan9
could evolve unimpeded. But IMHO it was not so far out that a
merge would have been impossible. plan9 had "ape" (ansi/posix
environment) for compiling posix compatible programs but that
didn't go far enough. The result might've been a worse plan9
but a better Unix.

The last version I used SunOS3.5 on a 4MB Sun 3/50. It was
very nice in its day. Once I got a 386 (or was it 486) with
16MB of memory & BSD, the Sun machine saw less and less use.

From krewat at kilonet.net  Wed Aug 28 11:21:43 2019
From: krewat at kilonet.net (Arthur Krewat)
Date: Tue, 27 Aug 2019 21:21:43 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <20190828002141.40BE41570CE9@mail.bitblocks.com>
References: <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
 <20190827003013.GS13570@mcvoy.com>
 <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net>
 <CAEoi9W6upO4LdvV0AVLy8f1je6oSZeuz4bbP4yuux-Xe6UUEBA@mail.gmail.com>
 <20190827024511.GU13570@mcvoy.com>
 <faaebe25-e5e5-0f6e-6eda-fc2fc6a0dc95@kilonet.net>
 <20190827145556.GD13570@mcvoy.com>
 <CAKr6gn2V_T_EnYaz3OYassHSpLecoKTkqZe+By8A9kQQ=7jnMA@mail.gmail.com>
 <20190827224002.GB15511@mcvoy.com>
 <20190827231625.55E991570CEA@mail.bitblocks.com>
 <20190827233338.GM13570@mcvoy.com>
 <20190828002141.40BE41570CE9@mail.bitblocks.com>
Message-ID: <bf837361-f439-44b9-5a02-cd7c254c9af6@kilonet.net>

In re: the socket() thing...

I remember getting into something (forget what) back in the early 90's, 
writing something (again, I forget what) and realizing what I needed to 
do to open a socket to a remote endpoint.

I remember thinking "wait, I can't just open("hostname:port", O_TCP); ???"

And, horror of all horrors, I need to deal with little/big endian 
things? ntohs(), htons(), et al?

jeez...

:)

art k.



From lm at mcvoy.com  Wed Aug 28 11:46:40 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 27 Aug 2019 18:46:40 -0700
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <bf837361-f439-44b9-5a02-cd7c254c9af6@kilonet.net>
References: <CAEoi9W6upO4LdvV0AVLy8f1je6oSZeuz4bbP4yuux-Xe6UUEBA@mail.gmail.com>
 <20190827024511.GU13570@mcvoy.com>
 <faaebe25-e5e5-0f6e-6eda-fc2fc6a0dc95@kilonet.net>
 <20190827145556.GD13570@mcvoy.com>
 <CAKr6gn2V_T_EnYaz3OYassHSpLecoKTkqZe+By8A9kQQ=7jnMA@mail.gmail.com>
 <20190827224002.GB15511@mcvoy.com>
 <20190827231625.55E991570CEA@mail.bitblocks.com>
 <20190827233338.GM13570@mcvoy.com>
 <20190828002141.40BE41570CE9@mail.bitblocks.com>
 <bf837361-f439-44b9-5a02-cd7c254c9af6@kilonet.net>
Message-ID: <20190828014640.GP13570@mcvoy.com>

On Tue, Aug 27, 2019 at 09:21:43PM -0400, Arthur Krewat wrote:
> In re: the socket() thing...
> 
> I remember getting into something (forget what) back in the early 90's,
> writing something (again, I forget what) and realizing what I needed to do
> to open a socket to a remote endpoint.
> 
> I remember thinking "wait, I can't just open("hostname:port", O_TCP); ???"

So that part is fine.

> And, horror of all horrors, I need to deal with little/big endian things?
> ntohs(), htons(), et al?

That part is reality.  You can send ascii and then pay the price for parsing
that or you can send binary.

These days, we have CPU cycles to burn so the ascii answer seems fine.  It
is, mostly, it's not when it is tons of small messages that need to be 
processed at millions or billions/sec.  In the past, CPU cycles were 
not a given so lots of stuff was designed to not be parsed.

From robpike at gmail.com  Wed Aug 28 13:22:33 2019
From: robpike at gmail.com (Rob Pike)
Date: Wed, 28 Aug 2019 13:22:33 +1000
Subject: [TUHS] [SPAM] Re: If not Linux, then what?
In-Reply-To: <20190827225955.GC15511@mcvoy.com>
References: <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
 <20190827003013.GS13570@mcvoy.com>
 <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net>
 <CAEoi9W6upO4LdvV0AVLy8f1je6oSZeuz4bbP4yuux-Xe6UUEBA@mail.gmail.com>
 <20190827024511.GU13570@mcvoy.com>
 <faaebe25-e5e5-0f6e-6eda-fc2fc6a0dc95@kilonet.net>
 <20190827145556.GD13570@mcvoy.com>
 <CAKr6gn2V_T_EnYaz3OYassHSpLecoKTkqZe+By8A9kQQ=7jnMA@mail.gmail.com>
 <20190827224002.GB15511@mcvoy.com>
 <CAKr6gn2EwxJH+5R75QuxgHBtF7BFFdc7Qfx=3HPvHi71i2fLdA@mail.gmail.com>
 <20190827225955.GC15511@mcvoy.com>
Message-ID: <CAKzdPgwWOGQbFEGSS0W-DC5A3muGSHc83V48OX3YJodxJV2wOQ@mail.gmail.com>

I find it hard to believe what you remember Dennis saying. The point of
dmr's streams was to support networking research in the lab and avoid the
myriad bugs of the mpx interface by stepping around them completely.

Perhaps it's out of context.

-rob


On Wed, Aug 28, 2019 at 9:00 AM Larry McVoy <lm at mcvoy.com> wrote:

> streams were OK but Dennis himself told me he didn't intend them for
> networking.  They were a simple mechanism for pushing line disciplines
> onto tty drivers.
>
> I can't remember exactly what he said, this was back in ~1988 or so
> and I was talking to him about the STREAMS stuff.  He wasn't very
> happy with it and I'm pretty sure he said something like streams
> weren't design to mux multiple sources or network connections.
> I think he sort of grudgingly gave credit that they made it work
> but he seemed to think that it was twisting streams more than they
> should be twisted.
>
> On Wed, Aug 28, 2019 at 08:46:35AM +1000, George Michaelson wrote:
> > oh maybe I meant "streams" not "STREAMS" I always got confused if the
> > original ritchie spec was upper or lower case. Charles Forsyth coded
> > it into the York Uni Vaxen, worked fine. I left shortly after to do
> > stuff at UCL, it only came back into my life when at UQ in Australia
> > we got an ICL "certified" SYSV host and along side dead technology
> > like RFS up it popped (I think ICL had coded an OSI stack we were
> > testing)
> >
> > -G
> >
> > On Wed, Aug 28, 2019 at 8:40 AM Larry McVoy <lm at mcvoy.com> wrote:
> > >
> > > Wait, are you arguing for STREAMS over sockets?  Dear god, please no.
> > > Have you ever used STREAMS (not Ritchies streams, those were OK)?
> > > I have.  I ported Lachman's STREAMS based TCP/IP stack twice, once
> > > to a long since defunct super computer called the ETA-10 and then
> > > to SCO Unix.  I've got way more STREAMS experience than most people
> > > and I can tell you that sockets are WAY WAY better.  I get the "it
> > > should have just been file I/O" except that I don't.  I tried to
> > > write a library that let you open up /net/tcp/$host:$port and do
> > > I/O like it was a file descriptor.  That works for a lot of stuff
> > > but I ran into problems quickly.  A networking connection is not
> > > a file handle.  You can make some stuff work but I couldn't figure
> > > out how to do all of it.   You end up having to do ioctls to handle
> > > the stuff that doesn't fit well into the file system name space.
> > > I think plan 9 did this sort of thing, maybe Rob can prove me wrong
> > > or remember where it didn't match.
> > >
> > > I do know that STREAMS came back to Solaris, some VP inked a shitty
> > > deal with Lachman and bought the rights to the stack.  It was slow
> > > as molasses in the winter and customers absolutely hated it.  Sun
> > > got Mentat to redo it for perf but customers still hated it, they
> > > understood sockets, everyone else had sockets, they wanted sockets
> > > and they got them.  Sun put them back and nobody ever asked about
> > > STREAMS again.
> > >
> > > On Wed, Aug 28, 2019 at 08:30:01AM +1000, George Michaelson wrote:
> > > > BSD, but with the original STREAMS semantics, not sockets.
> > > >
> > > > DARPA did us no favours accepting sockets in place of simple file I/O
> > > > semantics for networks.
> > > >
> > > > Newcastle connection put the namespace into
> > > > /.../remote-part/path/to/thing which I felt was also good.
> > > >
> > > > So for me, 7 -> BSD -> got worse for some values of worse
> > > >
> > > > On Wed, Aug 28, 2019 at 12:56 AM Larry McVoy <lm at mcvoy.com> wrote:
> > > > >
> > > > > On Mon, Aug 26, 2019 at 11:14:45PM -0400, Arthur Krewat wrote:
> > > > > > On 8/26/2019 10:45 PM, Larry McVoy wrote:
> > > > > > >  Which was that the page cache is
> > > > > > >*the*  cache.  There is nothing else.
> > > > > > Yeah, I re-read what you wrote a few times after I replied, and
> realized
> > > > > > what you meant ... eventually ;)
> > > > >
> > > > > I might be making too big of a deal about it.  mmap semantics
> mattered
> > > > > a lot when SMPs first showed up and main memory was small.  It
> meant
> > > > > that you could have multiple CPUs seeing and working on the same
> chunk
> > > > > of data at the same time.
> > > > >
> > > > > It's very similar to way that IOMMUs are exposed to user space
> these
> > > > > days, enabling virtual machines direct access to the I/O devices.
> > > > >
> > > > > ZFS breaks that model, the data is all in the ARC and if you mmap
> > > > > it they have to bcopy the data out of the ARC, into the page cache
> > > > > and now they have a consistency problem, you could modify stuff
> > > > > via mmap or write and they have to manage that.
> > > > >
> > > > > That consistency problem is the main reason that Sun almost
> completely
> > > > > killed the buffer cache (it still was used for inodes and
> directories
> > > > > but that was it).  That consistency problem is a pain in the rear,
> > > > > all sorts of race conditions and it tended to bit rot.
> > > > >
> > > > > Jeff and Bill are smart people so I suspect they got it right but
> I'm
> > > > > still stunned that they took such an architecturally bad approach.
> > > > > And even more stunned that the oversight people approved it.  There
> > > > > is zero chance that the Sun I worked at would have allowed that.
> > > > >
> > > > > --lm
> > >
> > > --
> > > ---
> > > Larry McVoy                  lm at mcvoy.com
> http://www.mcvoy.com/lm
>
> --
> ---
> Larry McVoy                  lm at mcvoy.com
> http://www.mcvoy.com/lm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190828/cc86fe8b/attachment.html>

From robpike at gmail.com  Wed Aug 28 13:25:52 2019
From: robpike at gmail.com (Rob Pike)
Date: Wed, 28 Aug 2019 13:25:52 +1000
Subject: [TUHS] [SPAM] Re: If not Linux, then what?
In-Reply-To: <CAKzdPgwWOGQbFEGSS0W-DC5A3muGSHc83V48OX3YJodxJV2wOQ@mail.gmail.com>
References: <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
 <20190827003013.GS13570@mcvoy.com>
 <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net>
 <CAEoi9W6upO4LdvV0AVLy8f1je6oSZeuz4bbP4yuux-Xe6UUEBA@mail.gmail.com>
 <20190827024511.GU13570@mcvoy.com>
 <faaebe25-e5e5-0f6e-6eda-fc2fc6a0dc95@kilonet.net>
 <20190827145556.GD13570@mcvoy.com>
 <CAKr6gn2V_T_EnYaz3OYassHSpLecoKTkqZe+By8A9kQQ=7jnMA@mail.gmail.com>
 <20190827224002.GB15511@mcvoy.com>
 <CAKr6gn2EwxJH+5R75QuxgHBtF7BFFdc7Qfx=3HPvHi71i2fLdA@mail.gmail.com>
 <20190827225955.GC15511@mcvoy.com>
 <CAKzdPgwWOGQbFEGSS0W-DC5A3muGSHc83V48OX3YJodxJV2wOQ@mail.gmail.com>
Message-ID: <CAKzdPgyN2_SpTR=ziRxQrcXjpMcpULFxVAECLMoPCt=5t6t4yQ@mail.gmail.com>

There are many things to dislike about sockets, but one of them -
irrelevant now, perhaps, but hugely troublesome at the time - was the way
they embedded the specific and peculiar behavior of Ethernet, such as
accepting a connection before you know if it's authorized - into the
networking interface. No other networking hardware worked like Ethernet at
either the electrical or the software level, and yet here we are.

I grump, I grump.

-rob

On Wed, Aug 28, 2019 at 1:22 PM Rob Pike <robpike at gmail.com> wrote:

> I find it hard to believe what you remember Dennis saying. The point of
> dmr's streams was to support networking research in the lab and avoid the
> myriad bugs of the mpx interface by stepping around them completely.
>
> Perhaps it's out of context.
>
> -rob
>
>
> On Wed, Aug 28, 2019 at 9:00 AM Larry McVoy <lm at mcvoy.com> wrote:
>
>> streams were OK but Dennis himself told me he didn't intend them for
>> networking.  They were a simple mechanism for pushing line disciplines
>> onto tty drivers.
>>
>> I can't remember exactly what he said, this was back in ~1988 or so
>> and I was talking to him about the STREAMS stuff.  He wasn't very
>> happy with it and I'm pretty sure he said something like streams
>> weren't design to mux multiple sources or network connections.
>> I think he sort of grudgingly gave credit that they made it work
>> but he seemed to think that it was twisting streams more than they
>> should be twisted.
>>
>> On Wed, Aug 28, 2019 at 08:46:35AM +1000, George Michaelson wrote:
>> > oh maybe I meant "streams" not "STREAMS" I always got confused if the
>> > original ritchie spec was upper or lower case. Charles Forsyth coded
>> > it into the York Uni Vaxen, worked fine. I left shortly after to do
>> > stuff at UCL, it only came back into my life when at UQ in Australia
>> > we got an ICL "certified" SYSV host and along side dead technology
>> > like RFS up it popped (I think ICL had coded an OSI stack we were
>> > testing)
>> >
>> > -G
>> >
>> > On Wed, Aug 28, 2019 at 8:40 AM Larry McVoy <lm at mcvoy.com> wrote:
>> > >
>> > > Wait, are you arguing for STREAMS over sockets?  Dear god, please no.
>> > > Have you ever used STREAMS (not Ritchies streams, those were OK)?
>> > > I have.  I ported Lachman's STREAMS based TCP/IP stack twice, once
>> > > to a long since defunct super computer called the ETA-10 and then
>> > > to SCO Unix.  I've got way more STREAMS experience than most people
>> > > and I can tell you that sockets are WAY WAY better.  I get the "it
>> > > should have just been file I/O" except that I don't.  I tried to
>> > > write a library that let you open up /net/tcp/$host:$port and do
>> > > I/O like it was a file descriptor.  That works for a lot of stuff
>> > > but I ran into problems quickly.  A networking connection is not
>> > > a file handle.  You can make some stuff work but I couldn't figure
>> > > out how to do all of it.   You end up having to do ioctls to handle
>> > > the stuff that doesn't fit well into the file system name space.
>> > > I think plan 9 did this sort of thing, maybe Rob can prove me wrong
>> > > or remember where it didn't match.
>> > >
>> > > I do know that STREAMS came back to Solaris, some VP inked a shitty
>> > > deal with Lachman and bought the rights to the stack.  It was slow
>> > > as molasses in the winter and customers absolutely hated it.  Sun
>> > > got Mentat to redo it for perf but customers still hated it, they
>> > > understood sockets, everyone else had sockets, they wanted sockets
>> > > and they got them.  Sun put them back and nobody ever asked about
>> > > STREAMS again.
>> > >
>> > > On Wed, Aug 28, 2019 at 08:30:01AM +1000, George Michaelson wrote:
>> > > > BSD, but with the original STREAMS semantics, not sockets.
>> > > >
>> > > > DARPA did us no favours accepting sockets in place of simple file
>> I/O
>> > > > semantics for networks.
>> > > >
>> > > > Newcastle connection put the namespace into
>> > > > /.../remote-part/path/to/thing which I felt was also good.
>> > > >
>> > > > So for me, 7 -> BSD -> got worse for some values of worse
>> > > >
>> > > > On Wed, Aug 28, 2019 at 12:56 AM Larry McVoy <lm at mcvoy.com> wrote:
>> > > > >
>> > > > > On Mon, Aug 26, 2019 at 11:14:45PM -0400, Arthur Krewat wrote:
>> > > > > > On 8/26/2019 10:45 PM, Larry McVoy wrote:
>> > > > > > >  Which was that the page cache is
>> > > > > > >*the*  cache.  There is nothing else.
>> > > > > > Yeah, I re-read what you wrote a few times after I replied, and
>> realized
>> > > > > > what you meant ... eventually ;)
>> > > > >
>> > > > > I might be making too big of a deal about it.  mmap semantics
>> mattered
>> > > > > a lot when SMPs first showed up and main memory was small.  It
>> meant
>> > > > > that you could have multiple CPUs seeing and working on the same
>> chunk
>> > > > > of data at the same time.
>> > > > >
>> > > > > It's very similar to way that IOMMUs are exposed to user space
>> these
>> > > > > days, enabling virtual machines direct access to the I/O devices.
>> > > > >
>> > > > > ZFS breaks that model, the data is all in the ARC and if you mmap
>> > > > > it they have to bcopy the data out of the ARC, into the page cache
>> > > > > and now they have a consistency problem, you could modify stuff
>> > > > > via mmap or write and they have to manage that.
>> > > > >
>> > > > > That consistency problem is the main reason that Sun almost
>> completely
>> > > > > killed the buffer cache (it still was used for inodes and
>> directories
>> > > > > but that was it).  That consistency problem is a pain in the rear,
>> > > > > all sorts of race conditions and it tended to bit rot.
>> > > > >
>> > > > > Jeff and Bill are smart people so I suspect they got it right but
>> I'm
>> > > > > still stunned that they took such an architecturally bad approach.
>> > > > > And even more stunned that the oversight people approved it.
>> There
>> > > > > is zero chance that the Sun I worked at would have allowed that.
>> > > > >
>> > > > > --lm
>> > >
>> > > --
>> > > ---
>> > > Larry McVoy                  lm at mcvoy.com
>> http://www.mcvoy.com/lm
>>
>> --
>> ---
>> Larry McVoy                  lm at mcvoy.com
>> http://www.mcvoy.com/lm
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190828/1932238d/attachment.html>

From sauer at technologists.com  Wed Aug 28 13:53:26 2019
From: sauer at technologists.com (Charles H. Sauer)
Date: Tue, 27 Aug 2019 22:53:26 -0500
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
Message-ID: <9544A973-31DA-49AF-B192-DE170530A8BD@technologists.com>

I’m a bit taken aback by the trees (streams/sockets/file systems/paging and difficult people) of this discussion. The forest view seems clear: if not for Linux, Microsoft would have been even more dominant. If not for Microsoft mis-steps (Cairo, ME, Vista, …), Windows dominance would have been even stronger. If not for Steve Jobs return, Apple really would have cratered. Who besides Apple and Linux (including Android) have given Microsoft meaningful competition?

The last couple of months or so I’ve been figuring out how to revive and sustain some early 90s PC hardware (not just JAWS but a also a slightly older ISA only i486DX2-50 machine). I’ve been making the machines multi boot a variety of environments: Windows 3.11 (with Mosaic and Netscape), Windows 95, NT 3.51 with the “new shell” (Win 95 Explorer), NEXTSTEP 3.3, Dell SVR4 2.2.1, and Red Had 5.2/6.2/7. For a “Unix person” my perspective may be unusual, but Win95/NT with new shell/Dell SVR4/Linux all seem preferable to my memory of the Unix systems I casually used when I was using those four predominantly. 

I helped lead AIX from 1982 to ’89 and Dell UNIX from ’89 to ’93. In ’93 I stepped away from Unix to work on Windows 95-based videoconferencing. From ’93 to ’96 I did very little with Unix. Starting in 1992, a friend endeavored to interest me in Linux, but I declined. Then in ’96 I joined a startup that was getting funding based on a prototype app based on PERL/mSQL/Apache/Linux. My task was to make the prototype a real product. My Linux advocate friend said to settle on either Slackware or Red Hat, favoring RPM, so I’ve used Red Hat/Fedora since then. But I also use Windows 10 and am composing this in TextEdit on macOS. I’ve tried the various BSD forks, other Linux distributions, OS/2, Palm OS, etc. but none of those have made me want to keep using them.

Charlie

> On Aug 26, 2019, at 6:13 PM, Arthur Krewat <krewat at kilonet.net> wrote:
> 
> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel
> 
> Leaving licensing and copyright issues out of this mental exercise, what would we have now if it wasn't for Linux? Not what you'd WANT it to be, although that can add to the discussion, but what WOULD it be?
> 
> I'm not asking as a proponent of Linux. If anything, I was dragged kicking and screaming into the current day and have begrudgingly ceded my server space to Linux.
> 
> But if not for Linux, would it be BSD? A System V variant? Or (the horror) Windows NT?
> 
> I do understand that this has been discussed on the list before. I think, however, it would make a good late-summer exercise. Or late winter depending on where you are :)
> 
> art k.
> 

--
voice: +1.512.784.7526       e-mail: sauer at technologists.com <mailto:sauer at technologists.com>           
fax: +1.512.346.5240         web: https://technologists.com/sauer/ <http://technologists.com/sauer/>
Facebook/Google/Skype/Twitter: CharlesHSauer

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

From lm at mcvoy.com  Wed Aug 28 14:05:40 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 27 Aug 2019 21:05:40 -0700
Subject: [TUHS] [SPAM] Re: If not Linux, then what?
In-Reply-To: <CAKzdPgwWOGQbFEGSS0W-DC5A3muGSHc83V48OX3YJodxJV2wOQ@mail.gmail.com>
References: <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net>
 <CAEoi9W6upO4LdvV0AVLy8f1je6oSZeuz4bbP4yuux-Xe6UUEBA@mail.gmail.com>
 <20190827024511.GU13570@mcvoy.com>
 <faaebe25-e5e5-0f6e-6eda-fc2fc6a0dc95@kilonet.net>
 <20190827145556.GD13570@mcvoy.com>
 <CAKr6gn2V_T_EnYaz3OYassHSpLecoKTkqZe+By8A9kQQ=7jnMA@mail.gmail.com>
 <20190827224002.GB15511@mcvoy.com>
 <CAKr6gn2EwxJH+5R75QuxgHBtF7BFFdc7Qfx=3HPvHi71i2fLdA@mail.gmail.com>
 <20190827225955.GC15511@mcvoy.com>
 <CAKzdPgwWOGQbFEGSS0W-DC5A3muGSHc83V48OX3YJodxJV2wOQ@mail.gmail.com>
Message-ID: <20190828040540.GT13570@mcvoy.com>

I could be wrong but that's my memory.  What he told me was streams was
for line disciplines for tty drivers.  That's what I know but you were
there, I was not.  I'm pretty confused because what Dennis said to me
was that he did not think streams would work for networking, he thought
they made sense for a stream but not for a networking connection because
that had multiple connections coming up through a stream.

I'm happy to be wrong but can you talk more about what he was thinking?
There is no way that I'm saying you are wrong, you are you, I just want
to learn.  If there is a way that streams made sense for networking I'd
like to see that.  My experience with STREAMS is that they sucked really
hard for networking.  

My guess is I need to go learn about mpx, I don't know that.

On Wed, Aug 28, 2019 at 01:22:33PM +1000, Rob Pike wrote:
> I find it hard to believe what you remember Dennis saying. The point of
> dmr's streams was to support networking research in the lab and avoid the
> myriad bugs of the mpx interface by stepping around them completely.
> 
> Perhaps it's out of context.
> 
> -rob
> 
> 
> On Wed, Aug 28, 2019 at 9:00 AM Larry McVoy <lm at mcvoy.com> wrote:
> 
> > streams were OK but Dennis himself told me he didn't intend them for
> > networking.  They were a simple mechanism for pushing line disciplines
> > onto tty drivers.
> >
> > I can't remember exactly what he said, this was back in ~1988 or so
> > and I was talking to him about the STREAMS stuff.  He wasn't very
> > happy with it and I'm pretty sure he said something like streams
> > weren't design to mux multiple sources or network connections.
> > I think he sort of grudgingly gave credit that they made it work
> > but he seemed to think that it was twisting streams more than they
> > should be twisted.
> >
> > On Wed, Aug 28, 2019 at 08:46:35AM +1000, George Michaelson wrote:
> > > oh maybe I meant "streams" not "STREAMS" I always got confused if the
> > > original ritchie spec was upper or lower case. Charles Forsyth coded
> > > it into the York Uni Vaxen, worked fine. I left shortly after to do
> > > stuff at UCL, it only came back into my life when at UQ in Australia
> > > we got an ICL "certified" SYSV host and along side dead technology
> > > like RFS up it popped (I think ICL had coded an OSI stack we were
> > > testing)
> > >
> > > -G
> > >
> > > On Wed, Aug 28, 2019 at 8:40 AM Larry McVoy <lm at mcvoy.com> wrote:
> > > >
> > > > Wait, are you arguing for STREAMS over sockets?  Dear god, please no.
> > > > Have you ever used STREAMS (not Ritchies streams, those were OK)?
> > > > I have.  I ported Lachman's STREAMS based TCP/IP stack twice, once
> > > > to a long since defunct super computer called the ETA-10 and then
> > > > to SCO Unix.  I've got way more STREAMS experience than most people
> > > > and I can tell you that sockets are WAY WAY better.  I get the "it
> > > > should have just been file I/O" except that I don't.  I tried to
> > > > write a library that let you open up /net/tcp/$host:$port and do
> > > > I/O like it was a file descriptor.  That works for a lot of stuff
> > > > but I ran into problems quickly.  A networking connection is not
> > > > a file handle.  You can make some stuff work but I couldn't figure
> > > > out how to do all of it.   You end up having to do ioctls to handle
> > > > the stuff that doesn't fit well into the file system name space.
> > > > I think plan 9 did this sort of thing, maybe Rob can prove me wrong
> > > > or remember where it didn't match.
> > > >
> > > > I do know that STREAMS came back to Solaris, some VP inked a shitty
> > > > deal with Lachman and bought the rights to the stack.  It was slow
> > > > as molasses in the winter and customers absolutely hated it.  Sun
> > > > got Mentat to redo it for perf but customers still hated it, they
> > > > understood sockets, everyone else had sockets, they wanted sockets
> > > > and they got them.  Sun put them back and nobody ever asked about
> > > > STREAMS again.
> > > >
> > > > On Wed, Aug 28, 2019 at 08:30:01AM +1000, George Michaelson wrote:
> > > > > BSD, but with the original STREAMS semantics, not sockets.
> > > > >
> > > > > DARPA did us no favours accepting sockets in place of simple file I/O
> > > > > semantics for networks.
> > > > >
> > > > > Newcastle connection put the namespace into
> > > > > /.../remote-part/path/to/thing which I felt was also good.
> > > > >
> > > > > So for me, 7 -> BSD -> got worse for some values of worse
> > > > >
> > > > > On Wed, Aug 28, 2019 at 12:56 AM Larry McVoy <lm at mcvoy.com> wrote:
> > > > > >
> > > > > > On Mon, Aug 26, 2019 at 11:14:45PM -0400, Arthur Krewat wrote:
> > > > > > > On 8/26/2019 10:45 PM, Larry McVoy wrote:
> > > > > > > >  Which was that the page cache is
> > > > > > > >*the*  cache.  There is nothing else.
> > > > > > > Yeah, I re-read what you wrote a few times after I replied, and
> > realized
> > > > > > > what you meant ... eventually ;)
> > > > > >
> > > > > > I might be making too big of a deal about it.  mmap semantics
> > mattered
> > > > > > a lot when SMPs first showed up and main memory was small.  It
> > meant
> > > > > > that you could have multiple CPUs seeing and working on the same
> > chunk
> > > > > > of data at the same time.
> > > > > >
> > > > > > It's very similar to way that IOMMUs are exposed to user space
> > these
> > > > > > days, enabling virtual machines direct access to the I/O devices.
> > > > > >
> > > > > > ZFS breaks that model, the data is all in the ARC and if you mmap
> > > > > > it they have to bcopy the data out of the ARC, into the page cache
> > > > > > and now they have a consistency problem, you could modify stuff
> > > > > > via mmap or write and they have to manage that.
> > > > > >
> > > > > > That consistency problem is the main reason that Sun almost
> > completely
> > > > > > killed the buffer cache (it still was used for inodes and
> > directories
> > > > > > but that was it).  That consistency problem is a pain in the rear,
> > > > > > all sorts of race conditions and it tended to bit rot.
> > > > > >
> > > > > > Jeff and Bill are smart people so I suspect they got it right but
> > I'm
> > > > > > still stunned that they took such an architecturally bad approach.
> > > > > > And even more stunned that the oversight people approved it.  There
> > > > > > is zero chance that the Sun I worked at would have allowed that.
> > > > > >
> > > > > > --lm
> > > >
> > > > --
> > > > ---
> > > > Larry McVoy                  lm at mcvoy.com
> > http://www.mcvoy.com/lm
> >
> > --
> > ---
> > Larry McVoy                  lm at mcvoy.com
> > http://www.mcvoy.com/lm
> >

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

From jsteve at superglobalmegacorp.com  Wed Aug 28 14:22:51 2019
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Wed, 28 Aug 2019 12:22:51 +0800
Subject: [TUHS] Running v10
In-Reply-To: <CAEdTPBddQangO-vGMT6nM=BeJFCywz9DX1yngwiq7YaYapvHCA@mail.gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
 <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com>
 <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
 <20190827003013.GS13570@mcvoy.com>
 <CAKzdPgxvb1MSA1yN3h0wY2aySzkd0aDjFSYH6pa==7MEw_zR8w@mail.gmail.com>
 <20190827160559.GA92491@indra.papnet.eu>
 <CAEdTPBddQangO-vGMT6nM=BeJFCywz9DX1yngwiq7YaYapvHCA@mail.gmail.com>
Message-ID: <a90b2927-a5c2-4de3-aa95-aa9467f9bbee@PU1APC01FT025.eop-APC01.prod.protection.outlook.com>

I don’t recall their being detailed installation instructions like v8/v9.  I never noticed the vax boot stuff as it was buried in the tree.  It’s possible that it’s buildable.  Or it could be incomplete like the Mach 2.5 VAX missing system headers….

I guess it’s worth trying on whatever should be the parallel BSD system if it’s like v8/v9 which needed a BSD machine to bootstrap.

From: Henry Bent
Sent: Wednesday, August 28, 2019 12:28 AM
To: Angelo Papenhoff
Cc: TUHS main list
Subject: Re: [TUHS] Running v10

On Tue, 27 Aug 2019 at 12:12, Angelo Papenhoff <aap at papnet.eu> wrote:
Did anyone try to get v10 running in simh yet? It's been public for a
while now and while we have two blit emulators already I haven't seen
v10 alive yet. I have to admit I haven't tried to get it running myself either.

After a brief look at the boot and config sources it appears as though there is support for the MicroVAX II which SIMH supports and I have used.  Is there an environment which is preferred for building the V10 source tree?  4.3BSD?  V8?  Something else?

-Henry

On 27/08/19, Rob Pike wrote:
> I always thought Research 10th Edition was fantastic. Even the 8th edition
> was an improvement on most of its successors. But things flowed another
> way, with muddy streams mixing in.

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

From jsteve at superglobalmegacorp.com  Wed Aug 28 14:30:02 2019
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Wed, 28 Aug 2019 12:30:02 +0800
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
Message-ID: <64d347fc-23cf-45db-8153-fc80e312c0c6@PU1APC01FT003.eop-APC01.prod.protection.outlook.com>

Maybe that plan B of GNU using the 4.4BSD lite kernel would have gained traction and you would have seen a GNU BSD vs NetBSD thing.

I can’t see it though gaining the kind of traction Linux got as it was all so cloistered.  Much like how GNU Mach never caught on or moved despite having a NetBSD port (Lites) to it.  The killer feature should have been SMP which was available early on in Mach, although it seems that the MPS 1.0 stuff didn’t work well enough or by the time 1.1 caught on it just wasn’t good enough.

I think the development model of Linux is what really drove it, just like how EGCS eclipsed GCC. 

The other crazy thing that hits me is that no Linux means no Caldera which means no Caldera 32v license being set free... 


From: Arthur Krewat
Sent: Tuesday, August 27, 2019 7:14 AM
To: TUHS main list
Subject: [TUHS] If not Linux, then what?

https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel

Leaving licensing and copyright issues out of this mental exercise, what 
would we have now if it wasn't for Linux? Not what you'd WANT it to be, 
although that can add to the discussion, but what WOULD it be?

I'm not asking as a proponent of Linux. If anything, I was dragged 
kicking and screaming into the current day and have begrudgingly ceded 
my server space to Linux.

But if not for Linux, would it be BSD? A System V variant? Or (the 
horror) Windows NT?

I do understand that this has been discussed on the list before. I 
think, however, it would make a good late-summer exercise. Or late 
winter depending on where you are :)

art k.


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

From wobblygong at gmail.com  Wed Aug 28 16:19:21 2019
From: wobblygong at gmail.com (Wesley Parish)
Date: Wed, 28 Aug 2019 18:19:21 +1200
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CAKr6gn2EwxJH+5R75QuxgHBtF7BFFdc7Qfx=3HPvHi71i2fLdA@mail.gmail.com>
References: <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
 <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com>
 <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
 <20190827003013.GS13570@mcvoy.com>
 <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net>
 <CAEoi9W6upO4LdvV0AVLy8f1je6oSZeuz4bbP4yuux-Xe6UUEBA@mail.gmail.com>
 <20190827024511.GU13570@mcvoy.com>
 <faaebe25-e5e5-0f6e-6eda-fc2fc6a0dc95@kilonet.net>
 <20190827145556.GD13570@mcvoy.com>
 <CAKr6gn2V_T_EnYaz3OYassHSpLecoKTkqZe+By8A9kQQ=7jnMA@mail.gmail.com>
 <20190827224002.GB15511@mcvoy.com>
 <CAKr6gn2EwxJH+5R75QuxgHBtF7BFFdc7Qfx=3HPvHi71i2fLdA@mail.gmail.com>
Message-ID: <CACNPpeYdTpm+f5mq+oqhT6_uvD7J=PiHYijNM11cVcH4pCMYGg@mail.gmail.com>

Speaking of OSI stacks, I know 4.4BSD Lite came with some fragments of
one. OSI's dead and hardly mourned these days, but did anyone in the
Unix world ever get beyond the 4.4BSD fragmentary implementation?

Wesley Parish


On 8/28/19, George Michaelson <ggm at algebras.org> wrote:
> oh maybe I meant "streams" not "STREAMS" I always got confused if the
> original ritchie spec was upper or lower case. Charles Forsyth coded
> it into the York Uni Vaxen, worked fine. I left shortly after to do
> stuff at UCL, it only came back into my life when at UQ in Australia
> we got an ICL "certified" SYSV host and along side dead technology
> like RFS up it popped (I think ICL had coded an OSI stack we were
> testing)
>
> -G
>
< snip >

From peter at rulingia.com  Wed Aug 28 16:30:45 2019
From: peter at rulingia.com (Peter Jeremy)
Date: Wed, 28 Aug 2019 16:30:45 +1000
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CACNPpeYdTpm+f5mq+oqhT6_uvD7J=PiHYijNM11cVcH4pCMYGg@mail.gmail.com>
References: <20190827003013.GS13570@mcvoy.com>
 <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net>
 <CAEoi9W6upO4LdvV0AVLy8f1je6oSZeuz4bbP4yuux-Xe6UUEBA@mail.gmail.com>
 <20190827024511.GU13570@mcvoy.com>
 <faaebe25-e5e5-0f6e-6eda-fc2fc6a0dc95@kilonet.net>
 <20190827145556.GD13570@mcvoy.com>
 <CAKr6gn2V_T_EnYaz3OYassHSpLecoKTkqZe+By8A9kQQ=7jnMA@mail.gmail.com>
 <20190827224002.GB15511@mcvoy.com>
 <CAKr6gn2EwxJH+5R75QuxgHBtF7BFFdc7Qfx=3HPvHi71i2fLdA@mail.gmail.com>
 <CACNPpeYdTpm+f5mq+oqhT6_uvD7J=PiHYijNM11cVcH4pCMYGg@mail.gmail.com>
Message-ID: <20190828063045.GE75146@server.rulingia.com>

On 2019-Aug-28 18:19:21 +1200, Wesley Parish <wobblygong at gmail.com> wrote:
>Speaking of OSI stacks, I know 4.4BSD Lite came with some fragments of
>one. OSI's dead and hardly mourned these days, but did anyone in the
>Unix world ever get beyond the 4.4BSD fragmentary implementation?

There was ISODE (https://en.wikipedia.org/wiki/ISO_Development_Environment).
I recall experimenting with it but didn't actually use it in anger.

I know that DEC/Compaq/HP Tru64 Unix (nee OSF/1) came with a OSI stack -
we had customers who wanted/used FTAM and I was surprised to find it
came with the OS.

-- 
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/20190828/2c090487/attachment.sig>

From aap at papnet.eu  Wed Aug 28 17:34:00 2019
From: aap at papnet.eu (Angelo Papenhoff)
Date: Wed, 28 Aug 2019 09:34:00 +0200
Subject: [TUHS] Running v10
In-Reply-To: <a90b2927-a5c2-4de3-aa95-aa9467f9bbee@PU1APC01FT025.eop-APC01.prod.protection.outlook.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
 <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com>
 <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
 <20190827003013.GS13570@mcvoy.com>
 <CAKzdPgxvb1MSA1yN3h0wY2aySzkd0aDjFSYH6pa==7MEw_zR8w@mail.gmail.com>
 <20190827160559.GA92491@indra.papnet.eu>
 <CAEdTPBddQangO-vGMT6nM=BeJFCywz9DX1yngwiq7YaYapvHCA@mail.gmail.com>
 <a90b2927-a5c2-4de3-aa95-aa9467f9bbee@PU1APC01FT025.eop-APC01.prod.protection.outlook.com>
Message-ID: <20190828073400.GA30049@indra.papnet.eu>

On 28/08/19, Jason Stevens wrote:
> I don’t recall their being detailed installation instructions like v8/v9.  I never noticed the vax boot stuff as it was buried in the tree.  It’s possible that it’s buildable.  Or it could be incomplete like the Mach 2.5 VAX missing system headers….
> 
> I guess it’s worth trying on whatever should be the parallel BSD system if it’s like v8/v9 which needed a BSD machine to bootstrap.

Check out "Setting Up a Research UNIX System" by Norman Wilson. troff
sources are in v10.


aap

From pnr at planet.nl  Wed Aug 28 19:17:08 2019
From: pnr at planet.nl (Paul Ruizendaal)
Date: Wed, 28 Aug 2019 11:17:08 +0200
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
Message-ID: <5467B5A6-B084-424E-9493-52D7F03E4074@planet.nl>


> I find it hard to believe what you remember Dennis saying. The point of
> dmr's streams was to support networking research in the lab and avoid the
> myriad bugs of the mpx interface by stepping around them completely.
> 
> Perhaps it's out of context.
> 
> -rob

> I could be wrong but that's my memory.  What he told me was streams was
> for line disciplines for tty drivers.  That's what I know but you were
> there, I was not.  I'm pretty confused because what Dennis said to me
> was that he did not think streams would work for networking, he thought
> they made sense for a stream but not for a networking connection because
> that had multiple connections coming up through a stream.


There is some contemporary material that gives a bit of context. The quotes are a bit contradictory and perhaps reflect evolving views.

[1]

The original dmr paper (1984) on streams (http://cm.bell-labs.co/who/dmr/st.html) seems to support the no networking view, focussing on terminal handling in its discussion. Also, near the end it says: "Streams are linear connections; by themselves, they support no notion of multiplexing, fan-in or fan-out. [...] It seems likely that a general multiplexing mechanism could help in both cases, but again, I do not yet know how to design it.” This seems to exclude usage for networking, which is typically multiplexed.

[2]

However, now that the V8 sources are available it is clear that the streams mechanism was used (by dmr?) to implement TCP/IP networking. He explains how that tallies with the above quote on multiplexing in a 1985 usenet post: https://groups.google.com/forum/#!topicsearchin/net.unix-wizards/subject$3Astreams/net.unix-wizards/b7W_j_0qASU
The config files in the surviving TUHS V8 source tree actually match with the setup that dmr described in the penultimate paragraph.

If the post by dmr does not immediately appear, click on the 8-10-85 post by 'd... at dutoit.uucp’ to make it fold out. For ease of reference, I’m including the message text below.

<quote>

Steven J. Langdon claimed that without multiplexing one couldn't
do a proper kernel-resident version of TCP/IP in the V8 stream context.
Here's how it's done.
It is still true in our system that stream multiplexing does not occur,
in the sense that every stream connection has (from the point of view
of the formal data structures) exactly two ends, one at a user process,
and the other at a device or another process.  However, this has, in
practice, not turned out to be a problem.  Say you have a hardware
device that hands you packets with a channel (or socket) number buried
inside in some complicated format.  The general scheme to handle the
situation uses both a line discipline (stream filter module) and
associated code that, to the system, looks like a stream device driver
with several minor devices; these have entries in /dev.

A watchdog process opens the underlying real device, and pushes
the stream module.   Arriving packets from the real device
are passed to this module, where they are analyzed,
and then given to the appropriate associated pseudo-device.
Likewise, messages written on the pseudo-device are shunted over to
the line discipline, where they are encoded appropriately and sent
to the real device.  This is where the multiplexing-demultiplexing
occurs; formally, it is outside of the stream structure, because
the data-passing doesn't follow the forward and backward links
of the stream modules.  However, the interfaces of the combined
larger module obey stream rules.

For example, IP works this way:  The IP line discipline looks at the
type field of data arriving from the device, and determines whether the
packet is TCP or UDP or ARP or whatever, and shunts it off to the
stream associated with /dev/ip6 or /dev/ip17 or whatever the numbers
are.

TCP, of course, is multiplexed as well.  So there is a TCP line
discipline, and a bunch of TCP devices; a watchdog process opens
/dev/ip6, and pushes the TCP line discipline; then the TCP packets it
gets are parcelled out to the appropriate /dev/tcpXX device.  Each TCP
device looks like the end of a stream, and may, of course, have other
modules (e.g.  tty processor) inserted in this stream.

UDP sits on top of IP in the same way.

This example is complicated, because (TCP,UDP)/IP is.  However, it
works well.  In particular, the underlying real device can be either an
ethernet or our own Datakit network; the software doesn't care.  For
example, from my machine, I can type "rlogin purdy" and connect to a
Sequent machine running 4.2; the TCP connection goes over Datakit to
machine "research" where it is gatewayed to a local ethernet that purdy
is connected to.

A further generalization (that we haven't made) is in principle easy:
there can be protocol suites other than IP on an Ethernet cable.  So
there could be another layer to separate IP from XNS from Chaosnet, etc.

        Dennis Ritchie

</quote>

Maybe the subtle notion expressed as "formally, it is outside of the stream structure, because the data-passing doesn't follow the forward and backward links of the stream modules.  However, the interfaces of the combined larger module obey stream rules” explains how dmr could talk about streams as being just suitable for line disciplines without meaning to say that they did not have good use in networking.

Paul
 


From angus at fairhaven.za.net  Wed Aug 28 19:36:54 2019
From: angus at fairhaven.za.net (Angus Robinson)
Date: Wed, 28 Aug 2019 11:36:54 +0200
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
Message-ID: <CAE49LGnEKsH3t-+caazKAYoWtjXszF7TRb_7DXtqNAybtfvunQ@mail.gmail.com>

Interesting question, the alternative OS would have had to have had a good
leader and I am sure maybe RMS would have created a kernel after some time.
Maybe somebody would have taken 386BSD/FreeBSD/NetBSD and made something
completely different.
I think another question would be, if Linux was never invented, what
technologies would never have happened. For instance, a bunch of animation
movies where made with Linux farms, Planes use Linux within their inbuilt
entertainment systems, the list goes on (I think NASA uses linux on their
ISS). How many people would be interested in technology/IT sector, how many
companies would have started (ie: RedHat, Thwat,etc), What features/addons
would not have been added to other operating systems (Windows tcp/ip)?
Would docker even be a thing, hyper-v ?

I know one thing....... All the old technology would be alot more and
schools would have alot more vunerabilites on their PC's.




On Tue, Aug 27, 2019 at 1:13 AM Arthur Krewat <krewat at kilonet.net> wrote:

>
> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel
>
> Leaving licensing and copyright issues out of this mental exercise, what
> would we have now if it wasn't for Linux? Not what you'd WANT it to be,
> although that can add to the discussion, but what WOULD it be?
>
> I'm not asking as a proponent of Linux. If anything, I was dragged
> kicking and screaming into the current day and have begrudgingly ceded
> my server space to Linux.
>
> But if not for Linux, would it be BSD? A System V variant? Or (the
> horror) Windows NT?
>
> I do understand that this has been discussed on the list before. I
> think, however, it would make a good late-summer exercise. Or late
> winter depending on where you are :)
>
> art k.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190828/a2414cdb/attachment.html>

From michael at kjorling.se  Wed Aug 28 19:50:59 2019
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Wed, 28 Aug 2019 09:50:59 +0000
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CAE49LGnEKsH3t-+caazKAYoWtjXszF7TRb_7DXtqNAybtfvunQ@mail.gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAE49LGnEKsH3t-+caazKAYoWtjXszF7TRb_7DXtqNAybtfvunQ@mail.gmail.com>
Message-ID: <20190828095059.GA10799@h-178-80.A328.priv.bahnhof.se>

On 28 Aug 2019 11:36 +0200, from angus at fairhaven.za.net (Angus Robinson):
> I think another question would be, if Linux was never invented, what
> technologies would never have happened.

I think that if there is a need to be filled, then something will fill
that need. In our timeline, in plenty of cases that need ended up
being filled by Linux -- quite possibly not in least part because it's
there, it's cheap, it's reasonably well-supported, and it can be
modified and extended by end users relatively easily. However, absent
Linux, as long as the task still needed to be done, _something else_
would have filled the need at some point.

Plenty of people got interested in the technology/information
technology sector well before Linux. Maybe Linux offered a venue for
some of those people to _express_ their interest, but I have a hard
time seeing why Linux would be a prerequisite.

On another note, and to get back to the original question, I'm a
little surprised that nobody here seems to have mentioned something
like an outgrowth of Minix.

-- 
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 aap at papnet.eu  Wed Aug 28 20:44:59 2019
From: aap at papnet.eu (Angelo Papenhoff)
Date: Wed, 28 Aug 2019 12:44:59 +0200
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <5467B5A6-B084-424E-9493-52D7F03E4074@planet.nl>
References: <5467B5A6-B084-424E-9493-52D7F03E4074@planet.nl>
Message-ID: <20190828104459.GA7483@indra.papnet.eu>

On 28/08/19, Paul Ruizendaal wrote:
> 
> There is some contemporary material that gives a bit of context. The quotes are a bit contradictory and perhaps reflect evolving views.
> 
> [1]
> 
> The original dmr paper (1984) on streams (http://cm.bell-labs.co/who/dmr/st.html) seems to support the no networking view, focussing on terminal handling in its discussion. Also, near the end it says: "Streams are linear connections; by themselves, they support no notion of multiplexing, fan-in or fan-out. [...] It seems likely that a general multiplexing mechanism could help in both cases, but again, I do not yet know how to design it.” This seems to exclude usage for networking, which is typically multiplexed.
> 
> [2]
> 
> However, now that the V8 sources are available it is clear that the streams mechanism was used (by dmr?) to implement TCP/IP networking. He explains how that tallies with the above quote on multiplexing in a 1985 usenet post: https://groups.google.com/forum/#!topicsearchin/net.unix-wizards/subject$3Astreams/net.unix-wizards/b7W_j_0qASU
> The config files in the surviving TUHS V8 source tree actually match with the setup that dmr described in the penultimate paragraph.
> 

Something else I found interesting is in v8's blit/Road.map:

"Next, operating systems.  We run under Berkeley 4.1bsd or Dennis Ritchie's
stacked line-discipline system."

That sounds to me like an early v8. If not, what was it? I'm really
interested in the timeline here. How long was research running on a
PDP-11 and when did they move to a VAX?


aap

From arnold at skeeve.com  Wed Aug 28 20:48:33 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 28 Aug 2019 04:48:33 -0600
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <20190828095059.GA10799@h-178-80.A328.priv.bahnhof.se>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAE49LGnEKsH3t-+caazKAYoWtjXszF7TRb_7DXtqNAybtfvunQ@mail.gmail.com>
 <20190828095059.GA10799@h-178-80.A328.priv.bahnhof.se>
Message-ID: <201908281048.x7SAmXr7009628@freefriends.org>

Michael Kjörling <michael at kjorling.se> wrote:

> On another note, and to get back to the original question, I'm a
> little surprised that nobody here seems to have mentioned something
> like an outgrowth of Minix.

Hoo boy.  You can thank Andy Tannenbaum that we have Linux in the first
place (almost).

Linus used Minix as his development environment and early versions
supported the Minix filesystem.

I can't cite sources, but as I remember it, at the time (AT&T law suit)
a number of people turned to Tannenbaum to get him to open source Minix
and let people make it a "real" OS (VM, 386 support, etc.).

He wasn't interested. He only cared about teaching and he wanted to
maintain control over it.  (Eventually it grew anyway, but only long
after.)

If he'd been more open, things might have indeed gone that way.

This brings up that there were other maybe viable candidates in
the research world: Sprite at UCB and Tannenbaum's Ameoba.  But it seems
that those were mainly vehicles to get papers published and didn't
spread beyond their home universities.

At some point I got a CD with all the Sprite sources. Maybe I can
find that and get it to Warren.

Arnold

From jsteve at superglobalmegacorp.com  Wed Aug 28 21:05:11 2019
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Wed, 28 Aug 2019 19:05:11 +0800
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <20190828063045.GE75146@server.rulingia.com>
References: <20190828063045.GE75146@server.rulingia.com>
Message-ID: <fbc88cc2-b5ff-4da5-9c70-ae101686a09d@PU1APC01FT025.eop-APC01.prod.protection.outlook.com>


I have OSF/1 1.0 running on gxemul … 

Any idea on where/ how to configure OSI?


OSF/1 Release 1 (OSFMIPS) console

login: root
Last login: Thu Aug 29 06:03:07 on console
DEC OSF/1 V1.0 (Rev. 166); Sun Jun 07 19:23:34 CDT 1970
DEC OSF/1 V1.0 Worksystem Software (Rev. 161)

# find / -name 'osi*' -print
#

From: Peter Jeremy
Sent: Wednesday, August 28, 2019 2:47 PM
To: Wesley Parish
Cc: TUHS main list
Subject: Re: [TUHS] If not Linux, then what?

On 2019-Aug-28 18:19:21 +1200, Wesley Parish <wobblygong at gmail.com>
wrote:
>Speaking of OSI stacks, I know 4.4BSD Lite came with some fragments of
>one. OSI's dead and hardly mourned these days, but did anyone in the
>Unix world ever get beyond the 4.4BSD fragmentary implementation?

There was ISODE
(https://en.wikipedia.org/wiki/ISO_Development_Environment).
I recall experimenting with it but didn't actually use it in anger.

I know that DEC/Compaq/HP Tru64 Unix (nee OSF/1) came with a OSI stack -
we had customers who wanted/used FTAM and I was surprised to find it
came with the OS.

-- 
Peter Jeremy

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

From arrigo at alchemistowl.org  Wed Aug 28 21:11:18 2019
From: arrigo at alchemistowl.org (Arrigo Triulzi)
Date: Wed, 28 Aug 2019 13:11:18 +0200
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <fbc88cc2-b5ff-4da5-9c70-ae101686a09d@PU1APC01FT025.eop-APC01.prod.protection.outlook.com>
References: <20190828063045.GE75146@server.rulingia.com>
 <fbc88cc2-b5ff-4da5-9c70-ae101686a09d@PU1APC01FT025.eop-APC01.prod.protection.outlook.com>
Message-ID: <D39978B7-43F5-4EA7-B04B-11F5ABB2E151@alchemistowl.org>

On 28 Aug 2019, at 13:05, Jason Stevens <jsteve at superglobalmegacorp.com> wrote:
> I have OSF/1 1.0 running on gxemul …
>  
> Any idea on where/ how to configure OSI?

I am not entirely sure it was already available on 1.0, it was around on 2.0.

You got OSI via the "DECnet Plus OSI” and I seem to recall needing a PAK for it.

eolo:~/sys/PAKs/PAKs-DECcampus/paks_unix$ ls *osi*
decnet-osi-end	decnet-osi-ext

:)

Arrigo


From imp at bsdimp.com  Wed Aug 28 22:46:41 2019
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 28 Aug 2019 06:46:41 -0600
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CACNPpeYdTpm+f5mq+oqhT6_uvD7J=PiHYijNM11cVcH4pCMYGg@mail.gmail.com>
References: <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
 <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com>
 <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
 <20190827003013.GS13570@mcvoy.com>
 <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net>
 <CAEoi9W6upO4LdvV0AVLy8f1je6oSZeuz4bbP4yuux-Xe6UUEBA@mail.gmail.com>
 <20190827024511.GU13570@mcvoy.com>
 <faaebe25-e5e5-0f6e-6eda-fc2fc6a0dc95@kilonet.net>
 <20190827145556.GD13570@mcvoy.com>
 <CAKr6gn2V_T_EnYaz3OYassHSpLecoKTkqZe+By8A9kQQ=7jnMA@mail.gmail.com>
 <20190827224002.GB15511@mcvoy.com>
 <CAKr6gn2EwxJH+5R75QuxgHBtF7BFFdc7Qfx=3HPvHi71i2fLdA@mail.gmail.com>
 <CACNPpeYdTpm+f5mq+oqhT6_uvD7J=PiHYijNM11cVcH4pCMYGg@mail.gmail.com>
Message-ID: <CANCZdfrw87NeKW3i+AgH9WECTzGjLifDLL_ZOrvWTcLDeS+q2Q@mail.gmail.com>

On Wed, Aug 28, 2019, 12:19 AM Wesley Parish <wobblygong at gmail.com> wrote:

> Speaking of OSI stacks, I know 4.4BSD Lite came with some fragments of
> one. OSI's dead and hardly mourned these days, but did anyone in the
> Unix world ever get beyond the 4.4BSD fragmentary implementation?
>

The Wollongong Group has OSI for various flavors of Sustem V and System III
running on the 3B* family, 386 and a few others. I recall setting them up
for interop in the summer of 1989.

Warner

Wesley Parish
>
>
> On 8/28/19, George Michaelson <ggm at algebras.org> wrote:
> > oh maybe I meant "streams" not "STREAMS" I always got confused if the
> > original ritchie spec was upper or lower case. Charles Forsyth coded
> > it into the York Uni Vaxen, worked fine. I left shortly after to do
> > stuff at UCL, it only came back into my life when at UQ in Australia
> > we got an ICL "certified" SYSV host and along side dead technology
> > like RFS up it popped (I think ICL had coded an OSI stack we were
> > testing)
> >
> > -G
> >
> < snip >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190828/c722193b/attachment.html>

From clemc at ccc.com  Wed Aug 28 23:52:42 2019
From: clemc at ccc.com (Clem Cole)
Date: Wed, 28 Aug 2019 09:52:42 -0400
Subject: [TUHS] [SPAM] Re: If not Linux, then what?
In-Reply-To: <20190828040540.GT13570@mcvoy.com>
References: <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net>
 <CAEoi9W6upO4LdvV0AVLy8f1je6oSZeuz4bbP4yuux-Xe6UUEBA@mail.gmail.com>
 <20190827024511.GU13570@mcvoy.com>
 <faaebe25-e5e5-0f6e-6eda-fc2fc6a0dc95@kilonet.net>
 <20190827145556.GD13570@mcvoy.com>
 <CAKr6gn2V_T_EnYaz3OYassHSpLecoKTkqZe+By8A9kQQ=7jnMA@mail.gmail.com>
 <20190827224002.GB15511@mcvoy.com>
 <CAKr6gn2EwxJH+5R75QuxgHBtF7BFFdc7Qfx=3HPvHi71i2fLdA@mail.gmail.com>
 <20190827225955.GC15511@mcvoy.com>
 <CAKzdPgwWOGQbFEGSS0W-DC5A3muGSHc83V48OX3YJodxJV2wOQ@mail.gmail.com>
 <20190828040540.GT13570@mcvoy.com>
Message-ID: <CAC20D2MoW59PVh5M4udg_k0b_ixD5rY=LKfwXOis9xHzCyA5ew@mail.gmail.com>

On Wed, Aug 28, 2019 at 12:06 AM Larry McVoy <lm at mcvoy.com> wrote:

> I could be wrong but that's my memory.  What he told me was streams was
> for line disciplines for tty drivers.
>

Rob - this syncs with what Dennis I had talked about too *i.e.* Using
streams for the serial interface; as the line disciplines stuff was a mess
by that point.  I cannt say I remember talking to him about using streams
for networking.   But I will say, I did agree that when we looked later at
Stellar; but stuck with using sockets.  This was for no other reason than
to ensure that the BSD code 'just worked' and for a product, which where I
was at the time (and I think Larry also at Sun), ensuring existing code
worked (and worked efficiently), has to be the high order bit.

I do hear you about many of the deficancies of 'pure joy.'  It seems that
it is always difficult as systems implementors to decide when to have an
'ice age' and try to kill off the old code and when to evolve it.  IMHO:
the code running user space that exploited the networking layer was still
new enough, that evolution (*i.e.* hanging on an interface that was seemly
'good enough' - sockets) was more attractive than revolution.  FWIW: we can
now analyize and argue why BSD UNIX and the socket interface were what made
it happen, but the historical fact is that sockets did seed the user space
network code base.

Also, I will observe that your comments about replacing MPX are a solid
memory for me also, IIRC Greg developed MPX for datakit originally.  He had
sent me a copy at CMU in the late 1970s (but before V7 was out the door)
and we had it in our v6++/CMU distr front -end system. I also remember
messing with it in on the Teklabs system. Because I had messed with it at
CMU aqnd was familar with its semantics, we we got the 3COM UNET code base
(which was the first commercial IP/TCP implementation and it ran in user
space unlike the later BBN Gurwitiz code base), and I rewrote some of Greg
Shaw and Bruce Borden's stuff to use MPX.   I'm trying to remember how
their code worked before we hacked it -- (maybe Rand Pipes); but that was
too many beers ago for my brain to still have it.  I'm pretty sure
Greg/Bruce took this back to 3Com when we were done.   Sadly, the UNET
stuff seems to have been lost.

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

From clemc at ccc.com  Wed Aug 28 23:57:24 2019
From: clemc at ccc.com (Clem Cole)
Date: Wed, 28 Aug 2019 09:57:24 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <20190828063045.GE75146@server.rulingia.com>
References: <20190827003013.GS13570@mcvoy.com>
 <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net>
 <CAEoi9W6upO4LdvV0AVLy8f1je6oSZeuz4bbP4yuux-Xe6UUEBA@mail.gmail.com>
 <20190827024511.GU13570@mcvoy.com>
 <faaebe25-e5e5-0f6e-6eda-fc2fc6a0dc95@kilonet.net>
 <20190827145556.GD13570@mcvoy.com>
 <CAKr6gn2V_T_EnYaz3OYassHSpLecoKTkqZe+By8A9kQQ=7jnMA@mail.gmail.com>
 <20190827224002.GB15511@mcvoy.com>
 <CAKr6gn2EwxJH+5R75QuxgHBtF7BFFdc7Qfx=3HPvHi71i2fLdA@mail.gmail.com>
 <CACNPpeYdTpm+f5mq+oqhT6_uvD7J=PiHYijNM11cVcH4pCMYGg@mail.gmail.com>
 <20190828063045.GE75146@server.rulingia.com>
Message-ID: <CAC20D2NWNd-Njqo+jbMYE7CRfRVTS141UH8J3dq-AUUXpv4x8Q@mail.gmail.com>

On Wed, Aug 28, 2019 at 2:46 AM Peter Jeremy <peter at rulingia.com> wrote:

> There was ISODE (https://en.wikipedia.org/wiki/ISO_Development_Environment
> ).
> I recall experimenting with it but didn't actually use it in anger.
>
Ditto.


>
> I know that DEC/Compaq/HP Tru64 Unix (nee OSF/1) came with a OSI stack -
> we had customers who wanted/used FTAM and I was surprised to find it
> came with the OS.
>
Tru64 talked to DECnet Phase X (I don't remember which one, maybe 4 or 5),
which had become an ISO/OSI stack by that point for political reasons
inside of Digital (the OSI vs TCP war reminded me of the Pascal vs C and
VMS vs UNIX wars - all very silly in retrospect, but I guess it was really
about who got which $s for development).

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190828/5e469920/attachment.html>

From clemc at ccc.com  Thu Aug 29 00:04:13 2019
From: clemc at ccc.com (Clem Cole)
Date: Wed, 28 Aug 2019 10:04:13 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <fbc88cc2-b5ff-4da5-9c70-ae101686a09d@PU1APC01FT025.eop-APC01.prod.protection.outlook.com>
References: <20190828063045.GE75146@server.rulingia.com>
 <fbc88cc2-b5ff-4da5-9c70-ae101686a09d@PU1APC01FT025.eop-APC01.prod.protection.outlook.com>
Message-ID: <CAC20D2NNsH_ijW2Bqic=vBW=Dt8xGfRs_gBHkNoXNjsv2KzyVQ@mail.gmail.com>

If that's the MIPs code base, it is likely to not be there.  I could be
forgetting something, but I remember that DECnet was released for the MIPS
products.   It was on Tru64 and Ultrix, but is a 'layered product' so you
needed a license to install it and it needed to be a late enough version
that had switched to exposing a full OSI stack.

That said, I do not remember/know how well it functioned talking to any OSI
stack other than DECs.

On Wed, Aug 28, 2019 at 7:05 AM Jason Stevens <
jsteve at superglobalmegacorp.com> wrote:

>
>
> I have OSF/1 1.0 running on gxemul …
>
>
>
> Any idea on where/ how to configure OSI?
>
>
>
>
>
> OSF/1 Release 1 (OSFMIPS) console
>
>
>
> login: root
>
> Last login: Thu Aug 29 06:03:07 on console
>
> DEC OSF/1 V1.0 (Rev. 166); Sun Jun 07 19:23:34 CDT 1970
>
> DEC OSF/1 V1.0 Worksystem Software (Rev. 161)
>
>
>
> # find / -name 'osi*' -print
>
> #
>
>
>
> *From: *Peter Jeremy <peter at rulingia.com>
> *Sent: *Wednesday, August 28, 2019 2:47 PM
> *To: *Wesley Parish <wobblygong at gmail.com>
> *Cc: *TUHS main list <tuhs at minnie.tuhs.org>
> *Subject: *Re: [TUHS] If not Linux, then what?
>
>
>
> On 2019-Aug-28 18:19:21 +1200, Wesley Parish <wobblygong at gmail.com>
>
> wrote:
>
> >Speaking of OSI stacks, I know 4.4BSD Lite came with some fragments of
>
> >one. OSI's dead and hardly mourned these days, but did anyone in the
>
> >Unix world ever get beyond the 4.4BSD fragmentary implementation?
>
>
>
> There was ISODE
>
> (https://en.wikipedia.org/wiki/ISO_Development_Environment).
>
> I recall experimenting with it but didn't actually use it in anger.
>
>
>
> I know that DEC/Compaq/HP Tru64 Unix (nee OSF/1) came with a OSI stack -
>
> we had customers who wanted/used FTAM and I was surprised to find it
>
> came with the OS.
>
>
>
> --
>
> Peter Jeremy
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190828/9b676c6c/attachment.html>

From earl.baugh at gmail.com  Thu Aug 29 00:10:17 2019
From: earl.baugh at gmail.com (Earl Baugh)
Date: Wed, 28 Aug 2019 10:10:17 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CAE49LGnEKsH3t-+caazKAYoWtjXszF7TRb_7DXtqNAybtfvunQ@mail.gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAE49LGnEKsH3t-+caazKAYoWtjXszF7TRb_7DXtqNAybtfvunQ@mail.gmail.com>
Message-ID: <08473671-7927-48B7-A4DD-5F766C34E2D7@gmail.com>

One point/ direction nobody seems to have mentioned was “what if Linus found out about BSD on PC hw”?  From what I’ve read he wasn’t aware of it, so perhaps a very different outcome could have been — what if Linus did find out about it and then ultimately took it over ( removing the caustic personalities ) or at worst forked it.   I think that would have become a much preferable outcome.  Just my $0.02. 

Earl 

Sent from my iPhone

> On Aug 28, 2019, at 5:36 AM, Angus Robinson <angus at fairhaven.za.net> wrote:
> 
> Interesting question, the alternative OS would have had to have had a good leader and I am sure maybe RMS would have created a kernel after some time. 
> Maybe somebody would have taken 386BSD/FreeBSD/NetBSD and made something completely different. 
> I think another question would be, if Linux was never invented, what technologies would never have happened. For instance, a bunch of animation movies where made with Linux farms, Planes use Linux within their inbuilt entertainment systems, the list goes on (I think NASA uses linux on their ISS). How many people would be interested in technology/IT sector, how many companies would have started (ie: RedHat, Thwat,etc), What features/addons would not have been added to other operating systems (Windows tcp/ip)? Would docker even be a thing, hyper-v ?
> 
> I know one thing....... All the old technology would be alot more and schools would have alot more vunerabilites on their PC's.
> 
>  
> 
> 
>> On Tue, Aug 27, 2019 at 1:13 AM Arthur Krewat <krewat at kilonet.net> wrote:
>> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel
>> 
>> Leaving licensing and copyright issues out of this mental exercise, what 
>> would we have now if it wasn't for Linux? Not what you'd WANT it to be, 
>> although that can add to the discussion, but what WOULD it be?
>> 
>> I'm not asking as a proponent of Linux. If anything, I was dragged 
>> kicking and screaming into the current day and have begrudgingly ceded 
>> my server space to Linux.
>> 
>> But if not for Linux, would it be BSD? A System V variant? Or (the 
>> horror) Windows NT?
>> 
>> I do understand that this has been discussed on the list before. I 
>> think, however, it would make a good late-summer exercise. Or late 
>> winter depending on where you are :)
>> 
>> art k.
>> 
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190828/3b34d452/attachment.html>

From sauer at technologists.com  Thu Aug 29 00:22:34 2019
From: sauer at technologists.com (Charles H Sauer)
Date: Wed, 28 Aug 2019 09:22:34 -0500
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CAE49LGnEKsH3t-+caazKAYoWtjXszF7TRb_7DXtqNAybtfvunQ@mail.gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAE49LGnEKsH3t-+caazKAYoWtjXszF7TRb_7DXtqNAybtfvunQ@mail.gmail.com>
Message-ID: <b4f60c79-59ff-bf7a-9f83-819da722919a@technologists.com>

possible components of answer regarding animation/CGI:
o SGI/MIPS/IRIX would have fared better/longer
o Jobs would have pushed Pixar towards Mach
o P4+NVIDIA would still have been disruptive 
(https://secure2.linuxjournal.com/ljarchive/LJ/099/6011s1.html)
o Gates would have done more

Windows had usable TCP/IP, at least starting with Windows 3, from 
Trumpet, Chameleon and others. I found/find the Microsoft 32 bit 
implementation preferable running Mosaic and Netscape, but had to do 
some work with 16 bit Trumpet a few years ago for a client that needed 
me to make some things work in DOS outside of Win 3.1.

On 8/28/2019 4:36 AM, Angus Robinson wrote:
...
> I think another question would be, if Linux was never invented, what 
> technologies would never have happened. For instance, a bunch of 
> animation movies where made with Linux farms, Planes use Linux within 
> their inbuilt entertainment systems, the list goes on (I think NASA uses 
> linux on their ISS). How many people would be interested in 
> technology/IT sector, how many companies would have started (ie: RedHat, 
> Thwat,etc), What features/addons would not have been added to other 
> operating systems (Windows tcp/ip)? Would docker even be a thing, hyper-v ?
> 
> I know one thing....... All the old technology would be alot more and 
> schools would have alot more vunerabilites on their PC's.
> 
> 
> 
> On Tue, Aug 27, 2019 at 1:13 AM Arthur Krewat <krewat at kilonet.net 
> <mailto:krewat at kilonet.net>> wrote:
> 
>     https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel
> 
>     Leaving licensing and copyright issues out of this mental exercise,
>     what
>     would we have now if it wasn't for Linux? Not what you'd WANT it to be,
>     although that can add to the discussion, but what WOULD it be?
> 
>     I'm not asking as a proponent of Linux. If anything, I was dragged
>     kicking and screaming into the current day and have begrudgingly ceded
>     my server space to Linux.
> 
>     But if not for Linux, would it be BSD? A System V variant? Or (the
>     horror) Windows NT?
> 
>     I do understand that this has been discussed on the list before. I
>     think, however, it would make a good late-summer exercise. Or late
>     winter depending on where you are :)
> 
>     art k.
> 
> 

-- 
voice: +1.512.784.7526       e-mail: sauer at technologists.com
fax: +1.512.346.5240         Web: https://technologists.com/sauer/
Facebook/Google/Skype/Twitter: CharlesHSauer

From lm at mcvoy.com  Thu Aug 29 00:31:40 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 28 Aug 2019 07:31:40 -0700
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CAC20D2MoW59PVh5M4udg_k0b_ixD5rY=LKfwXOis9xHzCyA5ew@mail.gmail.com>
References: <20190827024511.GU13570@mcvoy.com>
 <faaebe25-e5e5-0f6e-6eda-fc2fc6a0dc95@kilonet.net>
 <20190827145556.GD13570@mcvoy.com>
 <CAKr6gn2V_T_EnYaz3OYassHSpLecoKTkqZe+By8A9kQQ=7jnMA@mail.gmail.com>
 <20190827224002.GB15511@mcvoy.com>
 <CAKr6gn2EwxJH+5R75QuxgHBtF7BFFdc7Qfx=3HPvHi71i2fLdA@mail.gmail.com>
 <20190827225955.GC15511@mcvoy.com>
 <CAKzdPgwWOGQbFEGSS0W-DC5A3muGSHc83V48OX3YJodxJV2wOQ@mail.gmail.com>
 <20190828040540.GT13570@mcvoy.com>
 <CAC20D2MoW59PVh5M4udg_k0b_ixD5rY=LKfwXOis9xHzCyA5ew@mail.gmail.com>
Message-ID: <20190828143140.GU13570@mcvoy.com>

On Wed, Aug 28, 2019 at 09:52:42AM -0400, Clem Cole wrote:
> On Wed, Aug 28, 2019 at 12:06 AM Larry McVoy <lm at mcvoy.com> wrote:
> 
> > I could be wrong but that's my memory.  What he told me was streams was
> > for line disciplines for tty drivers.
> >
> 
> Rob - this syncs with what Dennis I had talked about too *i.e.* Using
> streams for the serial interface; as the line disciplines stuff was a mess
> by that point.  I cannt say I remember talking to him about using streams
> for networking.   

If my memory is right, I would have talked to Dennis about it around
1987 or early 1988.  Is it possible that was before they did networking
in streams?  

Maybe I have the dates wrong but my guess is I talked to him about it 
before the networking stuff was done in research Unix.  So his view
may have evolved.

From clemc at ccc.com  Thu Aug 29 00:55:42 2019
From: clemc at ccc.com (Clem Cole)
Date: Wed, 28 Aug 2019 10:55:42 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <08473671-7927-48B7-A4DD-5F766C34E2D7@gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAE49LGnEKsH3t-+caazKAYoWtjXszF7TRb_7DXtqNAybtfvunQ@mail.gmail.com>
 <08473671-7927-48B7-A4DD-5F766C34E2D7@gmail.com>
Message-ID: <CAC20D2M6PyLPnMw3VnShdOXPCQy8AXX88vDwvKx7wsqhabjwuQ@mail.gmail.com>

On Wed, Aug 28, 2019 at 10:10 AM Earl Baugh <earl.baugh at gmail.com> wrote:

> One point/ direction nobody seems to have mentioned was “what if Linus
> found out about BSD on PC hw”?  From what I’ve read he wasn’t aware of it,
> so perhaps a very different outcome could have been
>
A couple of items.  Linus is on record as saying if he had known about the
'magic FTP site' at UCB for 386BSD code download, he would have obtained it
[it is how most of us got it in those days].  The sad part is that his
University was licensed for it from UCB, so *they could have gotten the
code* is they had asked for it.   But as Larry has pointed out, many
Universities in those days took a fairly restrictive view of access to the
Unix sources; so it's still now clear if Linus himself would have gotten a
copy.


— what if Linus did find out about it and then ultimately took it over (
> removing the caustic personalities ) or at worst forked it.
>
Hmmm, I fear, Linus just would have been one more personality, or his
version would have been one more fork in the quickly branching, BSD tree.  The
real problem IMO was the lawsuit which happened shortly after 368BSD went
into the wild.  Let me tell you about my own experience from the time.

As I said, people like myself got scared that UNIX for a PC/386 would not
be available.  We had Minix, but it did not use the paging HW, whereas
Linus' code did and we thought, Linus code was unencumbered (it
wasn't/isn't, while* it is a rewrite*, it is still based on the AT&T IP -
but again that's a different part of story).

I know I had personally had bought Minix myself for whatever it was (??$70
IIRC) in a 'book' of N floppies from Prentiss-Hall.  I was semi-happy
because it was a rewrite of Unix and was better than DOS.  But .... it was
originally floppy only for the 16 bit 8088 (XT not the AT) and very, slow
and had quite limited in functionality (it did have a C compiler and ed but
no vi, and definitely not, sockets).  At the time, at work, I had a copy of
the WD 1003 controller documentation - which was the disk controller IBM
had used for the AT.  A lot of people doing hacking on PC Unix in those
days did not have that document as it turned out.

So one of the first things I did, was to hack together a Minix AT/IDE
driver for my system and sent it back, maybe posted it to net.noise (I've
forgotten).   As I had known him my UCB days, shortly thereafter it went
into the wild, Joilitz contacted me.  He had tried to write his AT disk
driver for his version via "reverse engineering" (the BIOS ROMs I think).
Bill's original code worked to a point but had some issues and he was
looking for some help.  I had a Wyse 32:16, which was one of the first 386
based PCs.   Hence, I got my copy of Bill's work via the secret address to
download.  We updated his driver with missing info I gave him (FWIW:
Bill references
this in the DDJ articles).    Anyway, now I had a 'real UNIX' and it was
BSD even, Minix was not only primarily floppy-based, but it was a V7 clone
so the difference was remarkable.

Then lawyers showed up....

I know I got scared and so did a lot of others.   Linus has recently made
his post, so we all jumped.   The rest is history, although as I point out,
it is likely world today would have been much different it AT&T had won the
lawsuit.   But they did not so that is a moot point.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190828/638a913b/attachment-0001.html>

From clemc at ccc.com  Thu Aug 29 00:57:11 2019
From: clemc at ccc.com (Clem Cole)
Date: Wed, 28 Aug 2019 10:57:11 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <20190828143140.GU13570@mcvoy.com>
References: <20190827024511.GU13570@mcvoy.com>
 <faaebe25-e5e5-0f6e-6eda-fc2fc6a0dc95@kilonet.net>
 <20190827145556.GD13570@mcvoy.com>
 <CAKr6gn2V_T_EnYaz3OYassHSpLecoKTkqZe+By8A9kQQ=7jnMA@mail.gmail.com>
 <20190827224002.GB15511@mcvoy.com>
 <CAKr6gn2EwxJH+5R75QuxgHBtF7BFFdc7Qfx=3HPvHi71i2fLdA@mail.gmail.com>
 <20190827225955.GC15511@mcvoy.com>
 <CAKzdPgwWOGQbFEGSS0W-DC5A3muGSHc83V48OX3YJodxJV2wOQ@mail.gmail.com>
 <20190828040540.GT13570@mcvoy.com>
 <CAC20D2MoW59PVh5M4udg_k0b_ixD5rY=LKfwXOis9xHzCyA5ew@mail.gmail.com>
 <20190828143140.GU13570@mcvoy.com>
Message-ID: <CAC20D2M7hD2Wb8NH9Fa3pe7vC5Xyv5FuVspckmSK9yebP2OhDA@mail.gmail.com>

Could be.   I'm not sure I can date it,

On Wed, Aug 28, 2019 at 10:31 AM Larry McVoy <lm at mcvoy.com> wrote:

> On Wed, Aug 28, 2019 at 09:52:42AM -0400, Clem Cole wrote:
> > On Wed, Aug 28, 2019 at 12:06 AM Larry McVoy <lm at mcvoy.com> wrote:
> >
> > > I could be wrong but that's my memory.  What he told me was streams was
> > > for line disciplines for tty drivers.
> > >
> >
> > Rob - this syncs with what Dennis I had talked about too *i.e.* Using
> > streams for the serial interface; as the line disciplines stuff was a
> mess
> > by that point.  I cannt say I remember talking to him about using streams
> > for networking.
>
> If my memory is right, I would have talked to Dennis about it around
> 1987 or early 1988.  Is it possible that was before they did networking
> in streams?
>
> Maybe I have the dates wrong but my guess is I talked to him about it
> before the networking stuff was done in research Unix.  So his view
> may have evolved.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190828/e9b476bc/attachment.html>

From usotsuki at buric.co  Thu Aug 29 01:00:31 2019
From: usotsuki at buric.co (Steve Nickolas)
Date: Wed, 28 Aug 2019 11:00:31 -0400 (EDT)
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <b4f60c79-59ff-bf7a-9f83-819da722919a@technologists.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAE49LGnEKsH3t-+caazKAYoWtjXszF7TRb_7DXtqNAybtfvunQ@mail.gmail.com>
 <b4f60c79-59ff-bf7a-9f83-819da722919a@technologists.com>
Message-ID: <alpine.BSF.2.02.1908281059510.81978@frieza.hoshinet.org>

On Wed, 28 Aug 2019, Charles H Sauer wrote:

> possible components of answer regarding animation/CGI:
> o SGI/MIPS/IRIX would have fared better/longer
> o Jobs would have pushed Pixar towards Mach
> o P4+NVIDIA would still have been disruptive 
> (https://secure2.linuxjournal.com/ljarchive/LJ/099/6011s1.html)
> o Gates would have done more
>
> Windows had usable TCP/IP, at least starting with Windows 3, from Trumpet, 
> Chameleon and others. I found/find the Microsoft 32 bit implementation 
> preferable running Mosaic and Netscape, but had to do some work with 16 bit 
> Trumpet a few years ago for a client that needed me to make some things work 
> in DOS outside of Win 3.1.

I actually wrote an IRC client for plain DOS a few years ago - I used 
WatTCP.

-uso.

From rich.salz at gmail.com  Thu Aug 29 01:37:51 2019
From: rich.salz at gmail.com (Richard Salz)
Date: Wed, 28 Aug 2019 11:37:51 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <alpine.BSF.2.02.1908281059510.81978@frieza.hoshinet.org>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAE49LGnEKsH3t-+caazKAYoWtjXszF7TRb_7DXtqNAybtfvunQ@mail.gmail.com>
 <b4f60c79-59ff-bf7a-9f83-819da722919a@technologists.com>
 <alpine.BSF.2.02.1908281059510.81978@frieza.hoshinet.org>
Message-ID: <CAFH29tocmaqAo0iP7Yw+mYsjwd4xB3hm4kjjZE1g5ZHc8y6o1A@mail.gmail.com>

I think the biggest difference would have been no git and therefore no
github, etc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190828/4c98a778/attachment.html>

From henry.r.bent at gmail.com  Thu Aug 29 02:34:46 2019
From: henry.r.bent at gmail.com (Henry Bent)
Date: Wed, 28 Aug 2019 12:34:46 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CAC20D2NNsH_ijW2Bqic=vBW=Dt8xGfRs_gBHkNoXNjsv2KzyVQ@mail.gmail.com>
References: <20190828063045.GE75146@server.rulingia.com>
 <fbc88cc2-b5ff-4da5-9c70-ae101686a09d@PU1APC01FT025.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NNsH_ijW2Bqic=vBW=Dt8xGfRs_gBHkNoXNjsv2KzyVQ@mail.gmail.com>
Message-ID: <CAEdTPBckiN+FcTbUJST7vthc-_5AQLka5NDGxKkp8XUZJaxesg@mail.gmail.com>

On Wed, 28 Aug 2019 at 10:05, Clem Cole <clemc at ccc.com> wrote:

> If that's the MIPs code base, it is likely to not be there.  I could be
> forgetting something, but I remember that DECnet was released for the MIPS
> products.   It was on Tru64 and Ultrix, but is a 'layered product' so you
> needed a license to install it and it needed to be a late enough version
> that had switched to exposing a full OSI stack.
>
> That said, I do not remember/know how well it functioned talking to any
> OSI stack other than DECs.
>

OSF/1 for MIPS wasn't actually a beta but it might as well have been.  It
was slow, it was buggy, and DEC dropped support for it fairly quickly after
it was released.  It was never ported to any of the R4k machines.
Customers were not happy.  Anyway, the official release announcement (
https://groups.google.com/forum/?hl=en#!original/bit.listserv.esl-l/BovGe3q9yWE/cqlcCYfxmbAJ
) mentions a few layered products, none of which I have ever seen in the
wild.  No OSI implementation is mentioned.

Looking through a list of layered products for Ultrix from mid-1994, I see
a few OSI-related things:

MIPS:
        DEC OSI Application           1.1    GZSAA
        Developer's Toolkit

        DECnet/OSI for ULTRIX         5.1A   YT9AA

        OSI Application Toolkit       5.1A   OSIAP_RISC

VAX:
        DECnet/OSI for ULTRIX         5.1A   716AA

        OSI Application Toolkit       5.1A   OSIAP_VAX

If you want more documentation on any of these, contact me off-list.

-Henry


> On Wed, Aug 28, 2019 at 7:05 AM Jason Stevens <
> jsteve at superglobalmegacorp.com> wrote:
>
>>
>>
>> I have OSF/1 1.0 running on gxemul …
>>
>>
>>
>> Any idea on where/ how to configure OSI?
>>
>>
>>
>>
>>
>> OSF/1 Release 1 (OSFMIPS) console
>>
>>
>>
>> login: root
>>
>> Last login: Thu Aug 29 06:03:07 on console
>>
>> DEC OSF/1 V1.0 (Rev. 166); Sun Jun 07 19:23:34 CDT 1970
>>
>> DEC OSF/1 V1.0 Worksystem Software (Rev. 161)
>>
>>
>>
>> # find / -name 'osi*' -print
>>
>> #
>>
>>
>>
>> *From: *Peter Jeremy <peter at rulingia.com>
>> *Sent: *Wednesday, August 28, 2019 2:47 PM
>> *To: *Wesley Parish <wobblygong at gmail.com>
>> *Cc: *TUHS main list <tuhs at minnie.tuhs.org>
>> *Subject: *Re: [TUHS] If not Linux, then what?
>>
>>
>>
>> On 2019-Aug-28 18:19:21 +1200, Wesley Parish <wobblygong at gmail.com>
>>
>> wrote:
>>
>> >Speaking of OSI stacks, I know 4.4BSD Lite came with some fragments of
>>
>> >one. OSI's dead and hardly mourned these days, but did anyone in the
>>
>> >Unix world ever get beyond the 4.4BSD fragmentary implementation?
>>
>>
>>
>> There was ISODE
>>
>> (https://en.wikipedia.org/wiki/ISO_Development_Environment).
>>
>> I recall experimenting with it but didn't actually use it in anger.
>>
>>
>>
>> I know that DEC/Compaq/HP Tru64 Unix (nee OSF/1) came with a OSI stack -
>>
>> we had customers who wanted/used FTAM and I was surprised to find it
>>
>> came with the OS.
>>
>>
>>
>> --
>>
>> Peter Jeremy
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190828/3164ebca/attachment.html>

From henry.r.bent at gmail.com  Thu Aug 29 02:46:03 2019
From: henry.r.bent at gmail.com (Henry Bent)
Date: Wed, 28 Aug 2019 12:46:03 -0400
Subject: [TUHS] Running v10
In-Reply-To: <20190828073400.GA30049@indra.papnet.eu>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CANCZdfqEs2RQ3YO_6PxfMtipD5PXm2wdztdkHRFLZfsO2DhaEA@mail.gmail.com>
 <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com>
 <b9f6633e-36f6-d802-c315-1f1528486270@kilonet.net>
 <20190827003013.GS13570@mcvoy.com>
 <CAKzdPgxvb1MSA1yN3h0wY2aySzkd0aDjFSYH6pa==7MEw_zR8w@mail.gmail.com>
 <20190827160559.GA92491@indra.papnet.eu>
 <CAEdTPBddQangO-vGMT6nM=BeJFCywz9DX1yngwiq7YaYapvHCA@mail.gmail.com>
 <a90b2927-a5c2-4de3-aa95-aa9467f9bbee@PU1APC01FT025.eop-APC01.prod.protection.outlook.com>
 <20190828073400.GA30049@indra.papnet.eu>
Message-ID: <CAEdTPBdgY4LRVUS+--hj4Yi_LSp9aBqJgLrVbX_=BFPyjbTJTQ@mail.gmail.com>

On Wed, 28 Aug 2019 at 03:41, Angelo Papenhoff <aap at papnet.eu> wrote:

> On 28/08/19, Jason Stevens wrote:
> > I don’t recall their being detailed installation instructions like
> v8/v9.  I never noticed the vax boot stuff as it was buried in the tree.
> It’s possible that it’s buildable.  Or it could be incomplete like the Mach
> 2.5 VAX missing system headers….
> >
> > I guess it’s worth trying on whatever should be the parallel BSD system
> if it’s like v8/v9 which needed a BSD machine to bootstrap.
>
> Check out "Setting Up a Research UNIX System" by Norman Wilson. troff
> sources are in v10.
>

Thanks, I hadn't found that yet.  Unfortunately it assumes that you have a
tape with at least a root and /usr dump, which we do not have.

I have several ideas about how one might go about building the tree using
existing distributions but any further discussion probably isn't
appropriate for this list.  If anyone would like to collaborate please feel
free to contact me off-list.

-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190828/87288fcc/attachment.html>

From paul.winalski at gmail.com  Thu Aug 29 02:50:36 2019
From: paul.winalski at gmail.com (Paul Winalski)
Date: Wed, 28 Aug 2019 12:50:36 -0400
Subject: [TUHS] ISO, OSI, and DECnet (was Re:  If not Linux, then what?)
Message-ID: <CABH=_VTKJQ-+0h-PwbNta1CAgtO=8quGV9RonWDP64MoteeG9Q@mail.gmail.com>

On 8/28/19, Clem Cole <clemc at ccc.com> wrote:
> On Wed, Aug 28, 2019 at 2:46 AM Peter Jeremy <peter at rulingia.com> wrote:
>
> Tru64 talked to DECnet Phase X (I don't remember which one, maybe 4 or 5),
> which had become an ISO/OSI stack by that point for political reasons
> inside of Digital (the OSI vs TCP war reminded me of the Pascal vs C and
> VMS vs UNIX wars - all very silly in retrospect, but I guess it was really
> about who got which $s for development).

It was DECnet Phase V that was based on the ISO/OSI stack.  IIRC, at
the time the European telcos were pushing OSI, it had become an ISO
standard, etc. etc.  It was also pretty easy to compatibly slide the
legacy proprietary DECnet Phase IV adaptive routing and virtual
circuit layers into the OSI stack.

TCP won the war, of course.  The risk with international standards
fashioned out of whole cloth by a committee (as opposed to being a
regularization of existing practice) is that the marketplace may
choose to ignore the "standard".  OSI and the Ada programming language
are cases in point.

-Paul W.

From lm at mcvoy.com  Thu Aug 29 03:24:51 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 28 Aug 2019 10:24:51 -0700
Subject: [TUHS] ISO, OSI, and DECnet (was Re:  If not Linux, then what?)
In-Reply-To: <CABH=_VTKJQ-+0h-PwbNta1CAgtO=8quGV9RonWDP64MoteeG9Q@mail.gmail.com>
References: <CABH=_VTKJQ-+0h-PwbNta1CAgtO=8quGV9RonWDP64MoteeG9Q@mail.gmail.com>
Message-ID: <20190828172451.GX13570@mcvoy.com>

On Wed, Aug 28, 2019 at 12:50:36PM -0400, Paul Winalski wrote:
> On 8/28/19, Clem Cole <clemc at ccc.com> wrote:
> > On Wed, Aug 28, 2019 at 2:46 AM Peter Jeremy <peter at rulingia.com> wrote:
> >
> > Tru64 talked to DECnet Phase X (I don't remember which one, maybe 4 or 5),
> > which had become an ISO/OSI stack by that point for political reasons
> > inside of Digital (the OSI vs TCP war reminded me of the Pascal vs C and
> > VMS vs UNIX wars - all very silly in retrospect, but I guess it was really
> > about who got which $s for development).
> 
> It was DECnet Phase V that was based on the ISO/OSI stack.  IIRC, at
> the time the European telcos were pushing OSI, it had become an ISO
> standard, etc. etc.  It was also pretty easy to compatibly slide the
> legacy proprietary DECnet Phase IV adaptive routing and virtual
> circuit layers into the OSI stack.
> 
> TCP won the war, of course.  The risk with international standards
> fashioned out of whole cloth by a committee (as opposed to being a
> regularization of existing practice) is that the marketplace may
> choose to ignore the "standard".  OSI and the Ada programming language
> are cases in point.

The great Mike Padlipski said "do you want protocols that look nice or
protocols that work nice?" in his fantastic book Elements of Networking
Style [*].

Maybe it's just that I read that book at the right time, I was porting
Lachman's STREAMS based TCP/IP stack, I had taken a networking class
where we built a stack, so I knew there was a state machine in there,
I had read Masscomp's networking primer and written some clients and
servers.  So I sort of knew a little but did not have the big picture.
I read Mike's book and it snapped everything into focus, which is in
part why I loved it.  The other part was all the less than subtle jabs
at OSI.  Mike couldn't stand the OSI model, another quote from the book
is "If you know what you are doing, 3 layers are enough.  If you don't,
7 layers won't help you".

I liked the book enough that I tracked down a phone number for Mike,
I think he was at UCLA or somewhere in LA but I might be wrong (the
number I have is 310-670-4288 which is a LA area code), and called him
and thanked him for the book.  We ended up becoming friendly with each
other and chatted from time to time about networking stuff.  I miss that
guy, he was great.

[*] The book is available here for $20.  Worth it.

https://www.iuniverse.com/en/bookstore/bookdetails/124830-The-Elements-of-Networking-Style

From lm at mcvoy.com  Thu Aug 29 03:32:28 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 28 Aug 2019 10:32:28 -0700
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CAEdTPBckiN+FcTbUJST7vthc-_5AQLka5NDGxKkp8XUZJaxesg@mail.gmail.com>
References: <20190828063045.GE75146@server.rulingia.com>
 <fbc88cc2-b5ff-4da5-9c70-ae101686a09d@PU1APC01FT025.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NNsH_ijW2Bqic=vBW=Dt8xGfRs_gBHkNoXNjsv2KzyVQ@mail.gmail.com>
 <CAEdTPBckiN+FcTbUJST7vthc-_5AQLka5NDGxKkp8XUZJaxesg@mail.gmail.com>
Message-ID: <20190828173228.GZ13570@mcvoy.com>

On Wed, Aug 28, 2019 at 12:34:46PM -0400, Henry Bent wrote:
> On Wed, 28 Aug 2019 at 10:05, Clem Cole <clemc at ccc.com> wrote:
> 
> > If that's the MIPs code base, it is likely to not be there.  I could be
> > forgetting something, but I remember that DECnet was released for the MIPS
> > products.   It was on Tru64 and Ultrix, but is a 'layered product' so you
> > needed a license to install it and it needed to be a late enough version
> > that had switched to exposing a full OSI stack.
> >
> > That said, I do not remember/know how well it functioned talking to any
> > OSI stack other than DECs.
> >
> 
> OSF/1 for MIPS wasn't actually a beta but it might as well have been.  It
> was slow, it was buggy, and DEC dropped support for it fairly quickly after
> it was released.  It was never ported to any of the R4k machines.

Perhaps Clem can shed some light on why DEC did a MIPS machine?  I had 
sort of stopped paying attention to them, so don't know the reasoning.

From nobozo at gmail.com  Thu Aug 29 03:45:38 2019
From: nobozo at gmail.com (Jon Forrest)
Date: Wed, 28 Aug 2019 10:45:38 -0700
Subject: [TUHS] ISO, OSI, and DECnet (was Re: If not Linux, then what?)
In-Reply-To: <20190828172451.GX13570@mcvoy.com>
References: <CABH=_VTKJQ-+0h-PwbNta1CAgtO=8quGV9RonWDP64MoteeG9Q@mail.gmail.com>
 <20190828172451.GX13570@mcvoy.com>
Message-ID: <59c49df3-66c3-ca86-18e7-fa1f8251883a@gmail.com>



On 8/28/2019 10:24 AM, Larry McVoy wrote:

> The great Mike Padlipski said "do you want protocols that look nice or
> protocols that work nice?" in his fantastic book Elements of Networking
> Style [*].
> I liked the book enough that I tracked down a phone number for Mike,
> I think he was at UCLA or somewhere in LA but I might be wrong (the
> number I have is 310-670-4288 which is a LA area code), and called him
> and thanked him for the book.  We ended up becoming friendly with each
> other and chatted from time to time about networking stuff.  I miss that
> guy, he was great.

I'm an average system person who's has had the great fortune to have
worked with many world-class people. My first real job was at Ford
Aerospace in 1978. They were an early commercial user of Unix (PWB in
their case). John Nagle had the desk next to me. Mike Padlipski was also
in the  group. I never knew exactly what Mike did, given that he seemed
to spend most of his time smoking and reading the N. Y. Times. But,
other great people in the group said that Mike was a networking
protocol expert. I guess he was.

Mike didn't really converse. Instead, he expounded at great length.
He was quite a character.

> [*] The book is available here for $20.  Worth it.

I have a copy I'd like to sell. It's the 1985 printing. I'll
also sell my copy for $20 + shipping (local pickup in the
Berkeley area is welcome). Contact me off list if you're
interested.

Jon


From lm at mcvoy.com  Thu Aug 29 03:50:11 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 28 Aug 2019 10:50:11 -0700
Subject: [TUHS] ISO, OSI, and DECnet (was Re: If not Linux, then what?)
In-Reply-To: <59c49df3-66c3-ca86-18e7-fa1f8251883a@gmail.com>
References: <CABH=_VTKJQ-+0h-PwbNta1CAgtO=8quGV9RonWDP64MoteeG9Q@mail.gmail.com>
 <20190828172451.GX13570@mcvoy.com>
 <59c49df3-66c3-ca86-18e7-fa1f8251883a@gmail.com>
Message-ID: <20190828175011.GD13570@mcvoy.com>

On Wed, Aug 28, 2019 at 10:45:38AM -0700, Jon Forrest wrote:
> >[*] The book is available here for $20.  Worth it.
> 
> I have a copy I'd like to sell. It's the 1985 printing. I'll
> also sell my copy for $20 + shipping (local pickup in the
> Berkeley area is welcome). Contact me off list if you're
> interested.

If there are any young kids on the list for whom this would be 
helpful I'll happily pay for the book to go to you.

From nobozo at gmail.com  Thu Aug 29 03:51:30 2019
From: nobozo at gmail.com (Jon Forrest)
Date: Wed, 28 Aug 2019 10:51:30 -0700
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <20190828173228.GZ13570@mcvoy.com>
References: <20190828063045.GE75146@server.rulingia.com>
 <fbc88cc2-b5ff-4da5-9c70-ae101686a09d@PU1APC01FT025.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NNsH_ijW2Bqic=vBW=Dt8xGfRs_gBHkNoXNjsv2KzyVQ@mail.gmail.com>
 <CAEdTPBckiN+FcTbUJST7vthc-_5AQLka5NDGxKkp8XUZJaxesg@mail.gmail.com>
 <20190828173228.GZ13570@mcvoy.com>
Message-ID: <f396f262-c049-e109-9ec4-d9f358de2bbf@gmail.com>



On 8/28/2019 10:32 AM, Larry McVoy wrote:

> Perhaps Clem can shed some light on why DEC did a MIPS machine?  I had
> sort of stopped paying attention to them, so don't know the reasoning.

I always thought it was because the Vaxes were too slow (and too
expensive) to compete with Sun, and the Alphas wouldn't be ready
soon enough. So, going with MIPS was a relatively quick and easy
solution.

In UC Berkeley CS in the early 90s we had lots of DEC MIP-stations.
In fact, I believe that Ousterhout used them to develop Sprite.
IIRC, there weren't nearly as many Suns, which was odd, considering
that Dave Patterson was in the department. As a result of the Sequoia
2000 project we got great deals on DEC hardware.

Jon


From doug at cs.dartmouth.edu  Thu Aug 29 03:57:09 2019
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Wed, 28 Aug 2019 13:57:09 -0400
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
Message-ID: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU>


> How long was research running on a PDP-11 and when did they move to a VAX?

London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research.

Doug

From athornton at gmail.com  Thu Aug 29 04:05:26 2019
From: athornton at gmail.com (Adam Thornton)
Date: Wed, 28 Aug 2019 11:05:26 -0700
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU>
References: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU>
Message-ID: <CAP2nic3b_nNm31bj+KmcFanbmhaXmspzHtxhtEpTF42=oBF-og@mail.gmail.com>

Interesting.  In my head, v7 is kind of the pinnacle of what you should run
on a PDP-11 (yes, I know 2.11BSD is still maintained), but that once you
add a networking stack, the 16-bit address limitations really start to
hurt, no matter how clever you are with your overlays.  But when I think of
v7, in my mind it's running on an 11/70.

I also find the multilayer switching described in the streams networking
implementation a lot like "inetd, all the way down."  That's kinda nifty.

Adam

On Wed, Aug 28, 2019 at 10:57 AM Doug McIlroy <doug at cs.dartmouth.edu> wrote:

>
> > How long was research running on a PDP-11 and when did they move to a
> VAX?
>
> London and Reiser had ported Unix to the VAX, replete with virtual memory,
> in 1978. By the time v7 was released (1979), Vaxen had become the workhorse
> machines in Research.
>
> Doug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190828/6d8af8e4/attachment.html>

From arnold at skeeve.com  Thu Aug 29 04:08:38 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 28 Aug 2019 12:08:38 -0600
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU>
References: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU>
Message-ID: <201908281808.x7SI8cUg023542@freefriends.org>

Doug McIlroy <doug at cs.dartmouth.edu> wrote:

>
> > How long was research running on a PDP-11 and when did they move to a VAX?
>
> London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research.
>
> Doug

So, what's the story on why the London/Reiser port didn't get adapted
back by Research, and they ended up starting from 4.1 BSD?

Thanks,

Arnold

From khm at sciops.net  Thu Aug 29 04:17:27 2019
From: khm at sciops.net (Kurt H Maier)
Date: Wed, 28 Aug 2019 11:17:27 -0700
Subject: [TUHS] ISO, OSI, and DECnet (was Re:  If not Linux, then what?)
In-Reply-To: <20190828172451.GX13570@mcvoy.com>
References: <CABH=_VTKJQ-+0h-PwbNta1CAgtO=8quGV9RonWDP64MoteeG9Q@mail.gmail.com>
 <20190828172451.GX13570@mcvoy.com>
Message-ID: <20190828181727.GA82704@wopr>

On Wed, Aug 28, 2019 at 10:24:51AM -0700, Larry McVoy wrote:
> 
> The great Mike Padlipski said "do you want protocols that look nice or
> protocols that work nice?" in his fantastic book Elements of Networking
> Style [*].
> 

This book taught me as much about navigating bureaucracy and the warning
signs of impending death-by-committee as it did about networking.  I
keep a copy on my shelf at the office and annoy my staff with it
regularly.  It's also a wonderful time capsule that provides a lot of
context about how we got where we are.

khm

From imp at bsdimp.com  Thu Aug 29 04:27:26 2019
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 28 Aug 2019 12:27:26 -0600
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU>
References: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU>
Message-ID: <CANCZdfpLtYgqj43aiTAoJPg_Obz=E+QhbMMHUvBcSU-yC-U0qQ@mail.gmail.com>

On Wed, Aug 28, 2019, 11:57 AM Doug McIlroy <doug at cs.dartmouth.edu> wrote:

>
> > How long was research running on a PDP-11 and when did they move to a
> VAX?
>
> London and Reiser had ported Unix to the VAX, replete with virtual memory,
> in 1978. By the time v7 was released (1979), Vaxen had become the workhorse
> machines in Research.
>


Is there a paper on this work?

Warner

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

From imp at bsdimp.com  Thu Aug 29 04:34:10 2019
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 28 Aug 2019 12:34:10 -0600
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <CANCZdfpLtYgqj43aiTAoJPg_Obz=E+QhbMMHUvBcSU-yC-U0qQ@mail.gmail.com>
References: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU>
 <CANCZdfpLtYgqj43aiTAoJPg_Obz=E+QhbMMHUvBcSU-yC-U0qQ@mail.gmail.com>
Message-ID: <CANCZdfqVt=Q+1DLmZuED4m1EgT5BC+8RudKtYZ8LKFxEAbooyg@mail.gmail.com>

On Wed, Aug 28, 2019, 12:27 PM Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Wed, Aug 28, 2019, 11:57 AM Doug McIlroy <doug at cs.dartmouth.edu> wrote:
>
>>
>> > How long was research running on a PDP-11 and when did they move to a
>> VAX?
>>
>> London and Reiser had ported Unix to the VAX, replete with virtual
>> memory, in 1978. By the time v7 was released (1979), Vaxen had become the
>> workhorse machines in Research.
>>
>
>
> Is there a paper on this work?
>

Found the 32V paper, but this was still a swapping implementation if I'm
reading correctly. I thought that the virtual memory was added by BSD /
Bill Joy. That would explain why V8 was BSD 4.1 based, since it was the
first usable Vax port with VM.

Warner

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

From doug at cs.dartmouth.edu  Thu Aug 29 04:41:26 2019
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Wed, 28 Aug 2019 14:41:26 -0400
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
Message-ID: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU>

> Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> 
>>
>>> How long was research running on a PDP-11 and when did they move to a VAX?
>>
>> London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research.
>> 
>> Doug
> 
> So, what's the story on why the London/Reiser port didn't get adapted
> back by Research, and they ended up starting from 4.1 BSD?
> 
> Thanks,
> 
> Arnold


Sorry, what I said about London/Reiser is true, but not the whole story. L/R didn't have demand paging; BSD did.

Doug


From arnold at skeeve.com  Thu Aug 29 04:49:30 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 28 Aug 2019 12:49:30 -0600
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU>
References: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU>
Message-ID: <201908281849.x7SInUE1024803@freefriends.org>

Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> > Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> > 
> >>
> >>> How long was research running on a PDP-11 and when did they move to a VAX?
> >>
> >> London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research.
> >> 
> >> Doug
> > 
> > So, what's the story on why the London/Reiser port didn't get adapted
> > back by Research, and they ended up starting from 4.1 BSD?
> > 
> > Thanks,
> > 
> > Arnold
>
> Sorry, what I said about London/Reiser is true, but not the whole
> story. L/R didn't have demand paging; BSD did.

But my question still stands. Why didn't Research keep going from L/R
and add demand paging?  Wouldn't that have been "cleaner" than starting
from BSD?

Thanks,

Arnold

From clemc at ccc.com  Thu Aug 29 04:56:14 2019
From: clemc at ccc.com (Clem Cole)
Date: Wed, 28 Aug 2019 14:56:14 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <20190828173228.GZ13570@mcvoy.com>
References: <20190828063045.GE75146@server.rulingia.com>
 <fbc88cc2-b5ff-4da5-9c70-ae101686a09d@PU1APC01FT025.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NNsH_ijW2Bqic=vBW=Dt8xGfRs_gBHkNoXNjsv2KzyVQ@mail.gmail.com>
 <CAEdTPBckiN+FcTbUJST7vthc-_5AQLka5NDGxKkp8XUZJaxesg@mail.gmail.com>
 <20190828173228.GZ13570@mcvoy.com>
Message-ID: <CAC20D2PXT68vMCZ2eAOqbsakVKSk4t0gJY9+hpB1xma95AamiQ@mail.gmail.com>

On Wed, Aug 28, 2019 at 1:32 PM Larry McVoy <lm at mcvoy.com> wrote:

> Perhaps Clem can shed some light on why DEC did a MIPS machine?
>
I did not work for DEC at the time and obviously, I was not in the room, so
this is what I can say I picked up.  Supnik would be a better person to
ask.  That said, some things I do know about the time/and behinds the scene.

   - Jupiter and Prism had been canceled.
   - Alpha did not yet exist (and would not for another 2 years)
   - Cutler had left for Microsoft etc..
   - Sun was clearly on its game
   - The VAX on a Chip just was not cutting it
   - RISC architectures were the hot item

Here is where I get fuzzy on details.

   - I believe a prototype (i.e. skunk works) MIPS was running at WRL in
   Palo Alto running Ultrix and DEC windows, I think using some sort of
   cheap ??PC?? chassis.
   - But the performance of the prototype was excellent and cost was
   cheaper than the current vax products.
   - Somebody sr, maybe Bob, shows this to Sr management and got the money
   to productize it.  The issue as making an official Ultrix for it was I know
   a big one.  Ultimately, DEC farmed that work out to us at LCC (with us
   eventually taking over all of Ultrix - MIPS and Vax).

So, I think the MIPS product was a holding pattern while DEC got it's
strategy together. Alpha would really show up until later (I would leave
LCC and go to DEC to be apart if that).   Also note Alpha was brought
up/debugged on Ultrix and of course, Prism sort of had Ultrix on it.    But
I think using the MIPS chip keep them in the game, when Vax was dying and
RISC was the word on the street.

FWIW: The issue of OSF/1 was a different one.  The whole switching off
Ultrix, getting to a new OS had been kicking around DEC for a while.  One
of the arguments for Cutler had been his new Mica system was that it could
run both Unix and VMS on top of it - *i.e.* a single OS kernel.  When Prism
was canceled (along with Mica) and Cutler left, that was a huge hole for
DEC's SW strategy.

Oppose Sun Forever (OSF) as it was formed to counter the Sun/AT&T move.
That gave DEC a way out.  But remember, OSF/1 on MIPS was actually not a
full product.   What you got was what OSF had released, which is why it
really more like a beta.    While it started down the path to being a
product; and DEC did specifically made it available (primarily to
Universities/Research types), DEC management was very reluctant to release
it because they did not want to support it.  In fact, LCC was asked to give
a bid on taking it on after we had taken over Ultrix.   DEC management
already saw Ultrix/MIPS as a resource drag once Alpha finally had been
committed. [ FYI: this was the same behavior as IBM on AIX/360 BTW.  Funny,
how big companies sometimes do things like this].

I always said, asking customers (and the ISVs) to switch OS and ISA in one
step was what caused a huge problem for DEC [along with the ISA being
64-bit only and ISV/customer code 32-bit dirty].   I've often wondered if a
32/64 bit OSF/1 MIPS stepping stone using the R4400 had been available,
particularly with the Gem compiler suite (which they had but never released
outside of DEC), it would have allowed the ISVs to move to Alpha quicker.
 Having to do it all in one step, cost them 3 years and more importantly,
by the time the code was 64-bit clean; Sun & PPC had a 64-bit system and
took the ISVs with away.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190828/651ce8fd/attachment-0001.html>

From chet.ramey at case.edu  Thu Aug 29 05:03:34 2019
From: chet.ramey at case.edu (Chet Ramey)
Date: Wed, 28 Aug 2019 15:03:34 -0400
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <201908281849.x7SInUE1024803@freefriends.org>
References: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU>
 <201908281849.x7SInUE1024803@freefriends.org>
Message-ID: <93732314-1521-3118-47c0-5b973b7b926e@case.edu>

On 8/28/19 2:49 PM, arnold at skeeve.com wrote:

>> Sorry, what I said about London/Reiser is true, but not the whole
>> story. L/R didn't have demand paging; BSD did.
> 
> But my question still stands. Why didn't Research keep going from L/R
> and add demand paging?  Wouldn't that have been "cleaner" than starting
> from BSD?

It's my impression that BSD had done other work that Research didn't want
to duplicate, like autoconfiguration, device support, and so on. Joy got
a lot out of the VAX hardware.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://tiswww.cwru.edu/~chet/

From lm at mcvoy.com  Thu Aug 29 05:05:34 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 28 Aug 2019 12:05:34 -0700
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <93732314-1521-3118-47c0-5b973b7b926e@case.edu>
References: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU>
 <201908281849.x7SInUE1024803@freefriends.org>
 <93732314-1521-3118-47c0-5b973b7b926e@case.edu>
Message-ID: <20190828190534.GH13570@mcvoy.com>

On Wed, Aug 28, 2019 at 03:03:34PM -0400, Chet Ramey wrote:
> On 8/28/19 2:49 PM, arnold at skeeve.com wrote:
> 
> >> Sorry, what I said about London/Reiser is true, but not the whole
> >> story. L/R didn't have demand paging; BSD did.
> > 
> > But my question still stands. Why didn't Research keep going from L/R
> > and add demand paging?  Wouldn't that have been "cleaner" than starting
> > from BSD?
> 
> It's my impression that BSD had done other work that Research didn't want
> to duplicate, like autoconfiguration, device support, and so on. Joy got
> a lot out of the VAX hardware.

He was a coding machine back then.  Quite the legacy.

From paul.winalski at gmail.com  Thu Aug 29 05:14:42 2019
From: paul.winalski at gmail.com (Paul Winalski)
Date: Wed, 28 Aug 2019 15:14:42 -0400
Subject: [TUHS] DEC's MIPS product (was  If not Linux, then what?)
Message-ID: <CABH=_VTmj5DOggtpFL4eH1VwVsDZJHFeJnzod_UwR90QAU7jTA@mail.gmail.com>

On 8/28/19, Clem Cole <clemc at ccc.com> wrote:
>
> So, I think the MIPS product was a holding pattern while DEC got it's
> strategy together. Alpha would really show up until later (I would leave
> LCC and go to DEC to be apart if that).   Also note Alpha was brought
> up/debugged on Ultrix and of course, Prism sort of had Ultrix on it.    But
> I think using the MIPS chip keep them in the game, when Vax was dying and
> RISC was the word on the street.

I was in DEC's compiler development team at the time, working on the
new GEM common back end, and this matches my recollection.  The
original plan was for GEM to be the successor to the VAX Code
Generator (VCG, the common back end used by DEC's PL/I, Ada, C/C++ and
a few other compilers on VAX/VMS) and its first target was the VMS
personality module Prism's OS, Mica.  Prism was close to delivering
silicon when it was cancelled in favor of Alpha.  DEC's MIPS-based
products were done as a stopgap until Alpha was ready.  The GEM group
implemented a MIPS code generator.  I don't recall whether we actually
shipped any GEM-based products on the MIPS/Ultrix platform.  GEM
focused on Alpha (on VMS, Unix, and Windows host and target platforms)
shortly thereafter.

-Paul W.

From spedraja at gmail.com  Thu Aug 29 05:29:21 2019
From: spedraja at gmail.com (SPC)
Date: Wed, 28 Aug 2019 21:29:21 +0200
Subject: [TUHS] ISO, OSI, and DECnet (was Re: If not Linux, then what?)
In-Reply-To: <20190828181727.GA82704@wopr>
References: <CABH=_VTKJQ-+0h-PwbNta1CAgtO=8quGV9RonWDP64MoteeG9Q@mail.gmail.com>
 <20190828172451.GX13570@mcvoy.com> <20190828181727.GA82704@wopr>
Message-ID: <CACytpF-E3C+VrFSXat+jKWiCOToyoDB4b5n9Jj723H=qSgxDXg@mail.gmail.com>

It's a bit funny (at least for me) because I was talking about DECNET as
OSI standard and TCP/IP and OSI differences some days ago to the group of
students of a course on network operation that I am teaching.

On the other hand I don't that book about networking. I'd like to get one
copy bit I live in Spain. Shipment is not a problem but perhaps to deal
with shipping procedures abroad is not what you have in mind :-)

Cordiales saludos / Best Regards / Salutations / Freundliche Grüße
-----
Sergio Pedraja

Senior Technician in Computer Science, Systems Administration, and
Information Security. MBA. Qualified occupational trainer.

El mié., 28 ago. 2019 20:24, Kurt H Maier <khm at sciops.net> escribió:

> On Wed, Aug 28, 2019 at 10:24:51AM -0700, Larry McVoy wrote:
> >
> > The great Mike Padlipski said "do you want protocols that look nice or
> > protocols that work nice?" in his fantastic book Elements of Networking
> > Style [*].
> >
>
> This book taught me as much about navigating bureaucracy and the warning
> signs of impending death-by-committee as it did about networking.  I
> keep a copy on my shelf at the office and annoy my staff with it
> regularly.  It's also a wonderful time capsule that provides a lot of
> context about how we got where we are.
>
> khm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190828/4a8c768e/attachment.html>

From clemc at ccc.com  Thu Aug 29 05:39:16 2019
From: clemc at ccc.com (Clem Cole)
Date: Wed, 28 Aug 2019 15:39:16 -0400
Subject: [TUHS] Lions Commentary on Unix
Message-ID: <CAC20D2PVOiaPsHLt75qJ-MqvkQH4sP6HSq8fZL2sAKKDBcpXhg@mail.gmail.com>

Gentlefolk,

Does anyone have an original copy of the Lions text.  All I have is the new
printed version and my nth generation photocopy from 1975.   There is
another 50th event occurring a few weeks that would love to be able to
borrow a copy for an artifact display.   Reply to me off-list if you can
help.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190828/7462756d/attachment.html>

From peter at rulingia.com  Thu Aug 29 05:54:47 2019
From: peter at rulingia.com (Peter Jeremy)
Date: Thu, 29 Aug 2019 05:54:47 +1000
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CAFH29tocmaqAo0iP7Yw+mYsjwd4xB3hm4kjjZE1g5ZHc8y6o1A@mail.gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAE49LGnEKsH3t-+caazKAYoWtjXszF7TRb_7DXtqNAybtfvunQ@mail.gmail.com>
 <b4f60c79-59ff-bf7a-9f83-819da722919a@technologists.com>
 <alpine.BSF.2.02.1908281059510.81978@frieza.hoshinet.org>
 <CAFH29tocmaqAo0iP7Yw+mYsjwd4xB3hm4kjjZE1g5ZHc8y6o1A@mail.gmail.com>
Message-ID: <20190828195447.GF75146@server.rulingia.com>

On 2019-Aug-28 11:37:51 -0400, Richard Salz <rich.salz at gmail.com> wrote:
>I think the biggest difference would have been no git and therefore no
>github, etc.

But there are other open SCM tools and it's likely there would be another
site serving similar functionality.  As an example. Google offered a
code-sharing site for many 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/20190829/f3f44f6c/attachment.sig>

From cbbrowne at gmail.com  Thu Aug 29 06:05:56 2019
From: cbbrowne at gmail.com (Christopher Browne)
Date: Wed, 28 Aug 2019 16:05:56 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <20190828195447.GF75146@server.rulingia.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAE49LGnEKsH3t-+caazKAYoWtjXszF7TRb_7DXtqNAybtfvunQ@mail.gmail.com>
 <b4f60c79-59ff-bf7a-9f83-819da722919a@technologists.com>
 <alpine.BSF.2.02.1908281059510.81978@frieza.hoshinet.org>
 <CAFH29tocmaqAo0iP7Yw+mYsjwd4xB3hm4kjjZE1g5ZHc8y6o1A@mail.gmail.com>
 <20190828195447.GF75146@server.rulingia.com>
Message-ID: <CAFNqd5XFGJ-RWEDBS=RJcGT4Kjpq6HyifxDGpxJPZ8SByB_HKg@mail.gmail.com>

On Wed, 28 Aug 2019 at 15:55, Peter Jeremy <peter at rulingia.com> wrote:

> On 2019-Aug-28 11:37:51 -0400, Richard Salz <rich.salz at gmail.com> wrote:
> >I think the biggest difference would have been no git and therefore no
> >github, etc.
>
> But there are other open SCM tools and it's likely there would be another
> site serving similar functionality.  As an example. Google offered a
> code-sharing site for many years.
>

I was not a particularly early adopter of Git; I was already a couple years
into usage of darcs.

A one-time colleage, Graydon Hoare, was one of the designers of Monotone,
which definitely influenced Git.  (He's more recently known for the Rust
language, and presently works at Apple on their Swift language.)  Arch,
Bazaar (bzr), Mercurial (hg), Codeville were also out there at the time.

It's rather interesting that Git happened to "win" that particular war;
there were various DSCM systems with similar (and dissimilar) capabilities
emerging in around 2003-2005.  Various were reasonably "production worthy."

Indeed, it's quite fair to say that at the time Git emerged, there was a
very active set of competing distributed SCMs out there.
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190828/82845eae/attachment.html>

From cbbrowne at gmail.com  Thu Aug 29 06:07:39 2019
From: cbbrowne at gmail.com (Christopher Browne)
Date: Wed, 28 Aug 2019 16:07:39 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
Message-ID: <CAFNqd5VpUE9OsKqfHDW8-76S46PYtnTJWDWAs0FU6o+73B4ZfQ@mail.gmail.com>

On Mon, 26 Aug 2019 at 19:14, Arthur Krewat <krewat at kilonet.net> wrote:

>
> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel
>
> Leaving licensing and copyright issues out of this mental exercise, what
> would we have now if it wasn't for Linux? Not what you'd WANT it to be,
> although that can add to the discussion, but what WOULD it be?
>
> I'm not asking as a proponent of Linux. If anything, I was dragged
> kicking and screaming into the current day and have begrudgingly ceded
> my server space to Linux.
>
> But if not for Linux, would it be BSD? A System V variant? Or (the
> horror) Windows NT?
>

I can make a firm "dunno" sound :-)

Some facts can come together to point away from a number of possibilities...

- If you look at the number of hobbyist "Unix homages" that emerged at
around that time, it's clear that there was a sizable community of
interested folk willing to build their own thing, and that weren't
interested in Windows NT.  (Nay, one should put that more strongly...  That
had their minds set on something NOT from Microsoft.)  So I think we can
cross Windows NT off the list.

- OS/2 should briefly come on the list.  It was likable in many ways, if
only IBM had actually supported it...  But it suffers from something of the
same problem as Windows NT; there were a lot of folk that were only
slightly less despising of IBM at the time than of Microsoft.

- Hurd was imagined to be the next thing...

To borrow from my cookie file...

"Of course 5  years from now that will be different,  but 5 years from
now  everyone  will  be  running  free  GNU on  their  200  MIPS,  64M
SPARCstation-5."  -- Andrew Tanenbaum, 1992.
%
"You'll be  rid of most of us  when BSD-detox or GNU  comes out, which
should happen in the next few months (yeah, right)." -- Richard Tobin,
1992. [BSD did follow within a year]
%
"I am aware of the benefits  of a micro kernel approach.  However, the
fact remains  that Linux is  here, and GNU  isn't --- and  people have
been working on Hurd for a lot longer than Linus has been working on
Linux." -- Ted T'so, 1992.

Ted has been on this thread, and should be amused (and slightly disturbed!)
that his old statements are being held here and there, ready to trot out
:-).

In the absence of Linux, perhaps hackers would have flocked to Hurd, but
there was enough going on that there was plenty of room for them to have
done so anyways.

I'm not sure what to blame on whatever happened post-1992, though I'd put
some on Microsoft Research having taken the wind out of Mach's sails by
hiring off a bunch of the relevant folk.  In order for Hurd to "make it,"
Mach has to "make it," too, and it looked like they were depending on CMU
to be behind that.  (I'm not sure I'm right about that; happy to hear a
better story.)

Anyway, Hurd *might* have been a "next thing," and I don't think the
popularity of Linux was enough to have completely taken wind out of its
sails, given that there's the dozens of "Unix homages" out there.

- I'd like to imagine Plan 9 being an alternative, but it was "properly
commercial" for a goodly long time (hence not amenable to attaching waves
of hackers to it to add their favorite device drivers), and was never taken
as a serious answer.  Many of us had admired it from afar via the Dr Dobbs
Journal issue (when was that?  mid or late '90s?) but only from afar.

- FreeBSD is the single best answer I can throw up as a possibility, as it
was the one actively targeting 80386 hardware.  And that had the big risk
of the AT&T lawsuit lurking over it, so had that gone in a different
direction, then that is a branch sadly easily trimmed.

If we lop both Linux and FreeBSD off the list of possibilities, I don't
imagine Windows NT or OS/2 bubble to the top, instead, a critical mass
would have stood behind ... something else, I'd think.  I don't know which
to suggest.
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190828/8ccbf5a1/attachment.html>

From arrigo at alchemistowl.org  Thu Aug 29 06:23:40 2019
From: arrigo at alchemistowl.org (Arrigo Triulzi)
Date: Wed, 28 Aug 2019 22:23:40 +0200
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CAC20D2PXT68vMCZ2eAOqbsakVKSk4t0gJY9+hpB1xma95AamiQ@mail.gmail.com>
References: <CAC20D2PXT68vMCZ2eAOqbsakVKSk4t0gJY9+hpB1xma95AamiQ@mail.gmail.com>
Message-ID: <F4D47614-B96B-4AB8-8061-E67E984653AD@alchemistowl.org>

On 28 Aug 2019, at 20:57, Clem Cole <clemc at ccc.com> wrote:
>> On Wed, Aug 28, 2019 at 1:32 PM Larry McVoy <lm at mcvoy.com> wrote:
>> Perhaps Clem can shed some light on why DEC did a MIPS machine? 
> I did not work for DEC at the time and obviously, I was not in the room, so this is what I can say I picked up.  Supnik would be a better person to ask.  That said, some things I do know about the time/and behinds the scene.

As a customer, back in 1992 in the UK: DEC sold us Ultrix DECstations running on the R3000, the R4000 upgrade and then told us the Alpha upgrade would be for peanuts. So we ran this research cluster with one Alpha 3000/600 and two Alpha 3000/400 running OSF/1 T1.0 and the DECstations on Ultrix, compiling everything on Ultrix and "mx"ing into OSF/1 until, with OSF/1 2.0 the "upgrades" showed up and we ended up with a beautiful Alpha cluster which was the envy of the college. They then spread like wildfire when engineering depts tried their code on our cluster…

For us the MIPS DECstations were literally placeholders for the Alphas we'd be getting with the trade-in! One of the DECstations is still with me because it turned out that DEC did not want back the huge stack of DECstations we had piled up for the trade-in!

Arrigo

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

From athornton at gmail.com  Thu Aug 29 06:27:06 2019
From: athornton at gmail.com (Adam Thornton)
Date: Wed, 28 Aug 2019 13:27:06 -0700
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CAFNqd5VpUE9OsKqfHDW8-76S46PYtnTJWDWAs0FU6o+73B4ZfQ@mail.gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAFNqd5VpUE9OsKqfHDW8-76S46PYtnTJWDWAs0FU6o+73B4ZfQ@mail.gmail.com>
Message-ID: <CAP2nic0_5vXCwSr8THcHfTxSEEWVkv2tvU1qheZusC7Qekh6zQ@mail.gmail.com>

I was an ardent OS/2 supporter for a long time.  Sure, IBM's anemic
marketing, and their close-to-outright-hostility to 3rd-party developers
didn't help.  But what killed it, really, was how damn good its 16-bit
support was.  It *was* a better DOS than DOS and a better Windows than
3.11fW.  So no one wrote to the relatively tiny market of 32-bit OS/2.

I fear that had Linux not made the leap, MS might well have won.  It's
largely the AOL-fuelled explosion of popularity of the Internet and Windows
ignoring same until too late that opened the door enough for Linux to jam
its foot in.

Hurd was, by the time of the '386 Unix Wars and early Linux, clearly not
going to be a contender, I guess because it was about cool research
features rather than running user-facing code.  I kept waiting for a usable
kernel to go with what Linux had already shown was a quite decent
userspace, but eventually had better things to do with my life (like chase
BeOS).  It was like waiting for Perl 6--it missed its moment.

Plan 9 and Amoeba were both really nifty.    I never used Sprite.  Neither
one of them had much of a chance in the real world.  Much like Unix itself,
Linux's worse-is-better approach really worked.

I have a hypothesis about Linux's ascendance too, which is a personal
anecdote I am inflating to the status of hypothesis.  As I recall, the
*BSDs for 386 all assumed they owned the hard disk.  Like, the whole
thing.  You couldn't, at least in 1992, create a multiboot system--or at
least it was my strong impression you could not.  I was an undergrad.  I
had one '386 at my disposal, with one hard disk, and, hey, I needed DOS and
Windows to write my papers (I don't know about you, but I wanted to write
in my room, where I could have my references at hand and be reasonably
undisturbed; sure Framemaker was a much better setup than Word For Windows
1.2 but having to use it in the computer lab made it a nonstarter for me).
Papers, and, well, to play games.  Sure, that too.

Linux let me defragment my drive, non-destructively repartition it, and
create a dual-boot system, so that I could both use the computer for school
and screw around on Linux.  I'm probably not the only person for whom this
was a decisive factor.

Adam

On Wed, Aug 28, 2019 at 1:08 PM Christopher Browne <cbbrowne at gmail.com>
wrote:

> On Mon, 26 Aug 2019 at 19:14, Arthur Krewat <krewat at kilonet.net> wrote:
>
>>
>> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel
>>
>> Leaving licensing and copyright issues out of this mental exercise, what
>> would we have now if it wasn't for Linux? Not what you'd WANT it to be,
>> although that can add to the discussion, but what WOULD it be?
>>
>> I'm not asking as a proponent of Linux. If anything, I was dragged
>> kicking and screaming into the current day and have begrudgingly ceded
>> my server space to Linux.
>>
>> But if not for Linux, would it be BSD? A System V variant? Or (the
>> horror) Windows NT?
>>
>
> I can make a firm "dunno" sound :-)
>
> Some facts can come together to point away from a number of
> possibilities...
>
> - If you look at the number of hobbyist "Unix homages" that emerged at
> around that time, it's clear that there was a sizable community of
> interested folk willing to build their own thing, and that weren't
> interested in Windows NT.  (Nay, one should put that more strongly...  That
> had their minds set on something NOT from Microsoft.)  So I think we can
> cross Windows NT off the list.
>
> - OS/2 should briefly come on the list.  It was likable in many ways, if
> only IBM had actually supported it...  But it suffers from something of the
> same problem as Windows NT; there were a lot of folk that were only
> slightly less despising of IBM at the time than of Microsoft.
>
> - Hurd was imagined to be the next thing...
>
> To borrow from my cookie file...
>
> "Of course 5  years from now that will be different,  but 5 years from
> now  everyone  will  be  running  free  GNU on  their  200  MIPS,  64M
> SPARCstation-5."  -- Andrew Tanenbaum, 1992.
> %
> "You'll be  rid of most of us  when BSD-detox or GNU  comes out, which
> should happen in the next few months (yeah, right)." -- Richard Tobin,
> 1992. [BSD did follow within a year]
> %
> "I am aware of the benefits  of a micro kernel approach.  However, the
> fact remains  that Linux is  here, and GNU  isn't --- and  people have
> been working on Hurd for a lot longer than Linus has been working on
> Linux." -- Ted T'so, 1992.
>
> Ted has been on this thread, and should be amused (and slightly
> disturbed!) that his old statements are being held here and there, ready to
> trot out :-).
>
> In the absence of Linux, perhaps hackers would have flocked to Hurd, but
> there was enough going on that there was plenty of room for them to have
> done so anyways.
>
> I'm not sure what to blame on whatever happened post-1992, though I'd put
> some on Microsoft Research having taken the wind out of Mach's sails by
> hiring off a bunch of the relevant folk.  In order for Hurd to "make it,"
> Mach has to "make it," too, and it looked like they were depending on CMU
> to be behind that.  (I'm not sure I'm right about that; happy to hear a
> better story.)
>
> Anyway, Hurd *might* have been a "next thing," and I don't think the
> popularity of Linux was enough to have completely taken wind out of its
> sails, given that there's the dozens of "Unix homages" out there.
>
> - I'd like to imagine Plan 9 being an alternative, but it was "properly
> commercial" for a goodly long time (hence not amenable to attaching waves
> of hackers to it to add their favorite device drivers), and was never taken
> as a serious answer.  Many of us had admired it from afar via the Dr Dobbs
> Journal issue (when was that?  mid or late '90s?) but only from afar.
>
> - FreeBSD is the single best answer I can throw up as a possibility, as it
> was the one actively targeting 80386 hardware.  And that had the big risk
> of the AT&T lawsuit lurking over it, so had that gone in a different
> direction, then that is a branch sadly easily trimmed.
>
> If we lop both Linux and FreeBSD off the list of possibilities, I don't
> imagine Windows NT or OS/2 bubble to the top, instead, a critical mass
> would have stood behind ... something else, I'd think.  I don't know which
> to suggest.
> --
> When confronted by a difficult problem, solve it by reducing it to the
> question, "How would the Lone Ranger handle this?"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190828/2dcbcdd3/attachment.html>

From pechter at gmail.com  Thu Aug 29 06:56:05 2019
From: pechter at gmail.com (William Pechter)
Date: Wed, 28 Aug 2019 16:56:05 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CAP2nic0_5vXCwSr8THcHfTxSEEWVkv2tvU1qheZusC7Qekh6zQ@mail.gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAFNqd5VpUE9OsKqfHDW8-76S46PYtnTJWDWAs0FU6o+73B4ZfQ@mail.gmail.com>
 <CAP2nic0_5vXCwSr8THcHfTxSEEWVkv2tvU1qheZusC7Qekh6zQ@mail.gmail.com>
Message-ID: <03a959f8-e1a3-4765-a135-efa0bea5fbf2.maildroid@localhost>

Actually, IIRC, you could use fdisk to split up drives in FreeBSD...  I think I did that in the 1.02 days... 

The problem is the semantics of slices and partitions.  Also *BSD, I recall, had to boot from a primary partition.  I don't know if lilo cared and grub2 sure doesn't. 


Sent from pechter at gmail.com

-----Original Message-----
From: Adam Thornton <athornton at gmail.com>
To: The Eunuchs Hysterical Society <tuhs at tuhs.org>
Sent: Wed, 28 Aug 2019 16:28
Subject: Re: [TUHS] If not Linux, then what?

I was an ardent OS/2 supporter for a long time.  Sure, IBM's anemic
marketing, and their close-to-outright-hostility to 3rd-party developers
didn't help.  But what killed it, really, was how damn good its 16-bit
support was.  It *was* a better DOS than DOS and a better Windows than
3.11fW.  So no one wrote to the relatively tiny market of 32-bit OS/2.

I fear that had Linux not made the leap, MS might well have won.  It's
largely the AOL-fuelled explosion of popularity of the Internet and Windows
ignoring same until too late that opened the door enough for Linux to jam
its foot in.

Hurd was, by the time of the '386 Unix Wars and early Linux, clearly not
going to be a contender, I guess because it was about cool research
features rather than running user-facing code.  I kept waiting for a usable
kernel to go with what Linux had already shown was a quite decent
userspace, but eventually had better things to do with my life (like chase
BeOS).  It was like waiting for Perl 6--it missed its moment.

Plan 9 and Amoeba were both really nifty.    I never used Sprite.  Neither
one of them had much of a chance in the real world.  Much like Unix itself,
Linux's worse-is-better approach really worked.

I have a hypothesis about Linux's ascendance too, which is a personal
anecdote I am inflating to the status of hypothesis.  As I recall, the
*BSDs for 386 all assumed they owned the hard disk.  Like, the whole
thing.  You couldn't, at least in 1992, create a multiboot system--or at
least it was my strong impression you could not.  I was an undergrad.  I
had one '386 at my disposal, with one hard disk, and, hey, I needed DOS and
Windows to write my papers (I don't know about you, but I wanted to write
in my room, where I could have my references at hand and be reasonably
undisturbed; sure Framemaker was a much better setup than Word For Windows
1.2 but having to use it in the computer lab made it a nonstarter for me).
Papers, and, well, to play games.  Sure, that too.

Linux let me defragment my drive, non-destructively repartition it, and
create a dual-boot system, so that I could both use the computer for school
and screw around on Linux.  I'm probably not the only person for whom this
was a decisive factor.

Adam

On Wed, Aug 28, 2019 at 1:08 PM Christopher Browne <cbbrowne at gmail.com>
wrote:

> On Mon, 26 Aug 2019 at 19:14, Arthur Krewat <krewat at kilonet.net> wrote:
>
>>
>> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel
>>
>> Leaving licensing and copyright issues out of this mental exercise, what
>> would we have now if it wasn't for Linux? Not what you'd WANT it to be,
>> although that can add to the discussion, but what WOULD it be?
>>
>> I'm not asking as a proponent of Linux. If anything, I was dragged
>> kicking and screaming into the current day and have begrudgingly ceded
>> my server space to Linux.
>>
>> But if not for Linux, would it be BSD? A System V variant? Or (the
>> horror) Windows NT?
>>
>
> I can make a firm "dunno" sound :-)
>
> Some facts can come together to point away from a number of
> possibilities...
>
> - If you look at the number of hobbyist "Unix homages" that emerged at
> around that time, it's clear that there was a sizable community of
> interested folk willing to build their own thing, and that weren't
> interested in Windows NT.  (Nay, one should put that more strongly...  That
> had their minds set on something NOT from Microsoft.)  So I think we can
> cross Windows NT off the list.
>
> - OS/2 should briefly come on the list.  It was likable in many ways, if
> only IBM had actually supported it...  But it suffers from something of the
> same problem as Windows NT; there were a lot of folk that were only
> slightly less despising of IBM at the time than of Microsoft.
>
> - Hurd was imagined to be the next thing...
>
> To borrow from my cookie file...
>
> "Of course 5  years from now that will be different,  but 5 years from
> now  everyone  will  be  running  free  GNU on  their  200  MIPS,  64M
> SPARCstation-5."  -- Andrew Tanenbaum, 1992.
> %
> "You'll be  rid of most of us  when BSD-detox or GNU  comes out, which
> should happen in the next few months (yeah, right)." -- Richard Tobin,
> 1992. [BSD did follow within a year]
> %
> "I am aware of the benefits  of a micro kernel approach.  However, the
> fact remains  that Linux is  here, and GNU  isn't --- and  people have
> been working on Hurd for a lot longer than Linus has been working on
> Linux." -- Ted T'so, 1992.
>
> Ted has been on this thread, and should be amused (and slightly
> disturbed!) that his old statements are being held here and there, ready to
> trot out :-).
>
> In the absence of Linux, perhaps hackers would have flocked to Hurd, but
> there was enough going on that there was plenty of room for them to have
> done so anyways.
>
> I'm not sure what to blame on whatever happened post-1992, though I'd put
> some on Microsoft Research having taken the wind out of Mach's sails by
> hiring off a bunch of the relevant folk.  In order for Hurd to "make it,"
> Mach has to "make it," too, and it looked like they were depending on CMU
> to be behind that.  (I'm not sure I'm right about that; happy to hear a
> better story.)
>
> Anyway, Hurd *might* have been a "next thing," and I don't think the
> popularity of Linux was enough to have completely taken wind out of its
> sails, given that there's the dozens of "Unix homages" out there.
>
> - I'd like to imagine Plan 9 being an alternative, but it was "properly
> commercial" for a goodly long time (hence not amenable to attaching waves
> of hackers to it to add their favorite device drivers), and was never taken
> as a serious answer.  Many of us had admired it from afar via the Dr Dobbs
> Journal issue (when was that?  mid or late '90s?) but only from afar.
>
> - FreeBSD is the single best answer I can throw up as a possibility, as it
> was the one actively targeting 80386 hardware.  And that had the big risk
> of the AT&T lawsuit lurking over it, so had that gone in a different
> direction, then that is a branch sadly easily trimmed.
>
> If we lop both Linux and FreeBSD off the list of possibilities, I don't
> imagine Windows NT or OS/2 bubble to the top, instead, a critical mass
> would have stood behind ... something else, I'd think.  I don't know which
> to suggest.
> --
> When confronted by a difficult problem, solve it by reducing it to the
> question, "How would the Lone Ranger handle this?"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190828/fb244bde/attachment.html>

From thomas.paulsen at firemail.de  Thu Aug 29 07:02:17 2019
From: thomas.paulsen at firemail.de (Thomas Paulsen)
Date: Wed, 28 Aug 2019 23:02:17 +0200
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
Message-ID: <b273680e1f30676e2b2bbbbc360711ad@firemail.de>


--- Ursprüngliche Nachricht ---
Von: Arthur Krewat <krewat at kilonet.net>
Datum: 27.08.2019 01:13:25
An: TUHS main list <tuhs at minnie.tuhs.org>
Betreff: [TUHS] If not Linux, then what?


> But if not for Linux, would it be BSD? A System V variant? Or (the
> horror) Windows NT?

mainly variants of Windows,  Unices in some niches.



From robpike at gmail.com  Thu Aug 29 07:54:28 2019
From: robpike at gmail.com (Rob Pike)
Date: Thu, 29 Aug 2019 07:54:28 +1000
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU>
References: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU>
Message-ID: <CAKzdPgwTMN1C-oKO-8D7UutVOOdvzgia=fsZrtGbeMZ13o79mg@mail.gmail.com>

I think it was slightly later. I joined mid-1980 and VAXes to replace the
11/70 were being discussed but had not arrived. We needed to convert a lab
into a VAX machine room and decide between BSD and Reiser, all of which
happened in the second half of 1980.

Reiser Unix got demand paging a little later, and it was spectacularly
fast. I remember being gobsmacked when I saw a demo in early 1981.

Dead ends everywhere.

-rob


On Thu, Aug 29, 2019 at 3:57 AM Doug McIlroy <doug at cs.dartmouth.edu> wrote:

>
> > How long was research running on a PDP-11 and when did they move to a
> VAX?
>
> London and Reiser had ported Unix to the VAX, replete with virtual memory,
> in 1978. By the time v7 was released (1979), Vaxen had become the workhorse
> machines in Research.
>
> Doug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190829/6f390633/attachment.html>

From robpike at gmail.com  Thu Aug 29 07:55:00 2019
From: robpike at gmail.com (Rob Pike)
Date: Thu, 29 Aug 2019 07:55:00 +1000
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU>
References: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU>
Message-ID: <CAKzdPgw_OJO6ehq4g=t_cqUw-Pqz_T6gn48uMDuyfpiQqNvOKw@mail.gmail.com>

Reiser added paging and it was working well by early 1981.

-rob


On Thu, Aug 29, 2019 at 4:41 AM Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> > Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> >
> >>
> >>> How long was research running on a PDP-11 and when did they move to a
> VAX?
> >>
> >> London and Reiser had ported Unix to the VAX, replete with virtual
> memory, in 1978. By the time v7 was released (1979), Vaxen had become the
> workhorse machines in Research.
> >>
> >> Doug
> >
> > So, what's the story on why the London/Reiser port didn't get adapted
> > back by Research, and they ended up starting from 4.1 BSD?
> >
> > Thanks,
> >
> > Arnold
>
>
> Sorry, what I said about London/Reiser is true, but not the whole story.
> L/R didn't have demand paging; BSD did.
>
> Doug
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190829/885accea/attachment.html>

From clemc at ccc.com  Thu Aug 29 08:24:38 2019
From: clemc at ccc.com (Clem cole)
Date: Wed, 28 Aug 2019 18:24:38 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <03a959f8-e1a3-4765-a135-efa0bea5fbf2.maildroid@localhost>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAFNqd5VpUE9OsKqfHDW8-76S46PYtnTJWDWAs0FU6o+73B4ZfQ@mail.gmail.com>
 <CAP2nic0_5vXCwSr8THcHfTxSEEWVkv2tvU1qheZusC7Qekh6zQ@mail.gmail.com>
 <03a959f8-e1a3-4765-a135-efa0bea5fbf2.maildroid@localhost>
Message-ID: <6A55D190-D7D6-4C1D-817C-5ED868A7E747@ccc.com>

Absolutely. Bill Jolitiz wrote the original version of fdisk with a very small assist from me.  I used to keep a 33m dos partition on my system if for no other reason than the diags all ran on dos

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Aug 28, 2019, at 4:56 PM, William Pechter <pechter at gmail.com> wrote:
> 
> Actually, IIRC, you could use fdisk to split up drives in FreeBSD...  I think I did that in the 1.02 days... 
> 
> The problem is the semantics of slices and partitions.  Also *BSD, I recall, had to boot from a primary partition.  I don't know if lilo cared and grub2 sure doesn't. 
> 
> 
> Sent from pechter at gmail.com
> 
> -----Original Message-----
> From: Adam Thornton <athornton at gmail.com>
> To: The Eunuchs Hysterical Society <tuhs at tuhs.org>
> Sent: Wed, 28 Aug 2019 16:28
> Subject: Re: [TUHS] If not Linux, then what?
> 
> I was an ardent OS/2 supporter for a long time.  Sure, IBM's anemic marketing, and their close-to-outright-hostility to 3rd-party developers didn't help.  But what killed it, really, was how damn good its 16-bit support was.  It *was* a better DOS than DOS and a better Windows than 3.11fW.  So no one wrote to the relatively tiny market of 32-bit OS/2.
> 
> I fear that had Linux not made the leap, MS might well have won.  It's largely the AOL-fuelled explosion of popularity of the Internet and Windows ignoring same until too late that opened the door enough for Linux to jam its foot in.
> 
> Hurd was, by the time of the '386 Unix Wars and early Linux, clearly not going to be a contender, I guess because it was about cool research features rather than running user-facing code.  I kept waiting for a usable kernel to go with what Linux had already shown was a quite decent userspace, but eventually had better things to do with my life (like chase BeOS).  It was like waiting for Perl 6--it missed its moment.
> 
> Plan 9 and Amoeba were both really nifty.    I never used Sprite.  Neither one of them had much of a chance in the real world.  Much like Unix itself, Linux's worse-is-better approach really worked.  
> 
> I have a hypothesis about Linux's ascendance too, which is a personal anecdote I am inflating to the status of hypothesis.  As I recall, the *BSDs for 386 all assumed they owned the hard disk.  Like, the whole thing.  You couldn't, at least in 1992, create a multiboot system--or at least it was my strong impression you could not.  I was an undergrad.  I had one '386 at my disposal, with one hard disk, and, hey, I needed DOS and Windows to write my papers (I don't know about you, but I wanted to write in my room, where I could have my references at hand and be reasonably undisturbed; sure Framemaker was a much better setup than Word For Windows 1.2 but having to use it in the computer lab made it a nonstarter for me).  Papers, and, well, to play games.  Sure, that too.
> 
> Linux let me defragment my drive, non-destructively repartition it, and create a dual-boot system, so that I could both use the computer for school and screw around on Linux.  I'm probably not the only person for whom this was a decisive factor.
> 
> Adam
> 
>> On Wed, Aug 28, 2019 at 1:08 PM Christopher Browne <cbbrowne at gmail.com> wrote:
>>> On Mon, 26 Aug 2019 at 19:14, Arthur Krewat <krewat at kilonet.net> wrote:
>> 
>>> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel
>>> 
>>> Leaving licensing and copyright issues out of this mental exercise, what 
>>> would we have now if it wasn't for Linux? Not what you'd WANT it to be, 
>>> although that can add to the discussion, but what WOULD it be?
>>> 
>>> I'm not asking as a proponent of Linux. If anything, I was dragged 
>>> kicking and screaming into the current day and have begrudgingly ceded 
>>> my server space to Linux.
>>> 
>>> But if not for Linux, would it be BSD? A System V variant? Or (the 
>>> horror) Windows NT?
>> 
>> I can make a firm "dunno" sound :-)
>> 
>> Some facts can come together to point away from a number of possibilities...
>> 
>> - If you look at the number of hobbyist "Unix homages" that emerged at around that time, it's clear that there was a sizable community of interested folk willing to build their own thing, and that weren't interested in Windows NT.  (Nay, one should put that more strongly...  That had their minds set on something NOT from Microsoft.)  So I think we can cross Windows NT off the list.
>> 
>> - OS/2 should briefly come on the list.  It was likable in many ways, if only IBM had actually supported it...  But it suffers from something of the same problem as Windows NT; there were a lot of folk that were only slightly less despising of IBM at the time than of Microsoft.
>> 
>> - Hurd was imagined to be the next thing...
>> 
>> To borrow from my cookie file...
>> 
>> "Of course 5  years from now that will be different,  but 5 years from
>> now  everyone  will  be  running  free  GNU on  their  200  MIPS,  64M
>> SPARCstation-5."  -- Andrew Tanenbaum, 1992.
>> %
>> "You'll be  rid of most of us  when BSD-detox or GNU  comes out, which
>> should happen in the next few months (yeah, right)." -- Richard Tobin,
>> 1992. [BSD did follow within a year]
>> %
>> "I am aware of the benefits  of a micro kernel approach.  However, the
>> fact remains  that Linux is  here, and GNU  isn't --- and  people have
>> been working on Hurd for a lot longer than Linus has been working on
>> Linux." -- Ted T'so, 1992.
>> 
>> Ted has been on this thread, and should be amused (and slightly disturbed!) that his old statements are being held here and there, ready to trot out :-).
>> 
>> In the absence of Linux, perhaps hackers would have flocked to Hurd, but there was enough going on that there was plenty of room for them to have done so anyways.
>> 
>> I'm not sure what to blame on whatever happened post-1992, though I'd put some on Microsoft Research having taken the wind out of Mach's sails by hiring off a bunch of the relevant folk.  In order for Hurd to "make it," Mach has to "make it," too, and it looked like they were depending on CMU to be behind that.  (I'm not sure I'm right about that; happy to hear a better story.)
>> 
>> Anyway, Hurd *might* have been a "next thing," and I don't think the popularity of Linux was enough to have completely taken wind out of its sails, given that there's the dozens of "Unix homages" out there.
>> 
>> - I'd like to imagine Plan 9 being an alternative, but it was "properly commercial" for a goodly long time (hence not amenable to attaching waves of hackers to it to add their favorite device drivers), and was never taken as a serious answer.  Many of us had admired it from afar via the Dr Dobbs Journal issue (when was that?  mid or late '90s?) but only from afar.
>> 
>> - FreeBSD is the single best answer I can throw up as a possibility, as it was the one actively targeting 80386 hardware.  And that had the big risk of the AT&T lawsuit lurking over it, so had that gone in a different direction, then that is a branch sadly easily trimmed.
>> 
>> If we lop both Linux and FreeBSD off the list of possibilities, I don't imagine Windows NT or OS/2 bubble to the top, instead, a critical mass would have stood behind ... something else, I'd think.  I don't know which to suggest.
>> -- 
>> When confronted by a difficult problem, solve it by reducing it to the
>> question, "How would the Lone Ranger handle this?"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190828/b666ffc6/attachment.html>

From pechter at gmail.com  Thu Aug 29 08:27:42 2019
From: pechter at gmail.com (William Pechter)
Date: Wed, 28 Aug 2019 18:27:42 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CAP2nic0_5vXCwSr8THcHfTxSEEWVkv2tvU1qheZusC7Qekh6zQ@mail.gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAFNqd5VpUE9OsKqfHDW8-76S46PYtnTJWDWAs0FU6o+73B4ZfQ@mail.gmail.com>
 <CAP2nic0_5vXCwSr8THcHfTxSEEWVkv2tvU1qheZusC7Qekh6zQ@mail.gmail.com>
Message-ID: <283e3cc2-42ec-a554-602f-5fb67eca9e40@gmail.com>

I tried three times to respond by phone but the lack of a decent 
environment for mail killed my first attempts.

Anyway, without top posting:

On 8/28/2019 4:27 PM, Adam Thornton wrote:
> I was an ardent OS/2 supporter for a long time.  Sure, IBM's anemic 
> marketing, and their close-to-outright-hostility to 3rd-party 
> developers didn't help.  But what killed it, really, was how damn good 
> its 16-bit support was.  It *was* a better DOS than DOS and a better 
> Windows than 3.11fW.  So no one wrote to the relatively tiny market of 
> 32-bit OS/2.
>
OS/2 was slick and if they could've kept the W\indows 3.x compatibility 
(the Win32S was a sliding target that Microsoft kept changing.  There 
was a pretty decent Unix work-alike ported to the top of OS/2 that made 
most of the public domain and open source (the term didn't exist yet) 
stuff available.

I could telnet into the box and run a pretty slick Unix work-alike 
shell.  Unfortunately, I left IBM and IBM dumped OS/2 support and future 
releases.

<snip>

>
> I have a hypothesis about Linux's ascendance too, which is a personal 
> anecdote I am inflating to the status of hypothesis.  As I recall, the 
> *BSDs for 386 all assumed they owned the hard disk.  Like, the whole 
> thing.  You couldn't, at least in 1992, create a multiboot system--or 
> at least it was my strong impression you could not.  I was an 
> undergrad.  I had one '386 at my disposal, with one hard disk, and, 
> hey, I needed DOS and Windows to write my papers (I don't know about 
> you, but I wanted to write in my room, where I could have my 
> references at hand and be reasonably undisturbed; sure Framemaker was 
> a much better setup than Word For Windows 1.2 but having to use it in 
> the computer lab made it a nonstarter for me).  Papers, and, well, to 
> play games.  Sure, that too.
>
>
I love Framemaker.  I run a 2nd hand version of Windows Framemaker since 
I no longer have any Unix boxes that would run the Unix version unless I 
pull an old CD and rebuild a SunOS 4 box.  Wonder if the NVRAM battery's 
dead in the Sparc2 or Sparc10?

I did a training Unix Admin for DC/OSx course for Pyramid that could 
print a full doc with instructors guide (on back side of the pages) and 
all the pages and overheads for the class in a single Frame doc.  And 
everyone told me it couldn't be done in Frame 1.2 or 1.3 on Pyramid OSx. 
Sure you can if you force it. Come here and hold  my Xterminal keyboard 
and my beer. 8-)

Anyway, I thought I had a 386 running with Win3.1 and OS/2 and FreeBSD 
on a single drive.  I checked the FreeBSD archives and it COULD install 
in a primary partition (partition type 165) and share the disk with 
other OS types.

The one thing that was a PITA was the docs --- since they used the 
partition term as well as "disk slices" with partitions meaning ONE 
thing to Unix folks and another to DOS/Windows/OS2 types.  So it was 
explained multiple times on the FreeBSD mailing lists.  I never had any 
issue with it and until ZFS which wants it's own drives to control (and 
drives are now cheap and large -- so why not splurge a bit for data 
protection...)

Bill



From clemc at ccc.com  Thu Aug 29 08:28:10 2019
From: clemc at ccc.com (Clem cole)
Date: Wed, 28 Aug 2019 18:28:10 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CAP2nic0_5vXCwSr8THcHfTxSEEWVkv2tvU1qheZusC7Qekh6zQ@mail.gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAFNqd5VpUE9OsKqfHDW8-76S46PYtnTJWDWAs0FU6o+73B4ZfQ@mail.gmail.com>
 <CAP2nic0_5vXCwSr8THcHfTxSEEWVkv2tvU1qheZusC7Qekh6zQ@mail.gmail.com>
Message-ID: <016BFF16-C490-425D-8168-3D59DCCA6A21@ccc.com>

Not true 386BSD used fdisk.  It shared the disk just fine.  In fact I liked the way it sliced the disk much better than Slackware in those days. 

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Aug 28, 2019, at 4:27 PM, Adam Thornton <athornton at gmail.com> wrote:
> 
> I was an ardent OS/2 supporter for a long time.  Sure, IBM's anemic marketing, and their close-to-outright-hostility to 3rd-party developers didn't help.  But what killed it, really, was how damn good its 16-bit support was.  It *was* a better DOS than DOS and a better Windows than 3.11fW.  So no one wrote to the relatively tiny market of 32-bit OS/2.
> 
> I fear that had Linux not made the leap, MS might well have won.  It's largely the AOL-fuelled explosion of popularity of the Internet and Windows ignoring same until too late that opened the door enough for Linux to jam its foot in.
> 
> Hurd was, by the time of the '386 Unix Wars and early Linux, clearly not going to be a contender, I guess because it was about cool research features rather than running user-facing code.  I kept waiting for a usable kernel to go with what Linux had already shown was a quite decent userspace, but eventually had better things to do with my life (like chase BeOS).  It was like waiting for Perl 6--it missed its moment.
> 
> Plan 9 and Amoeba were both really nifty.    I never used Sprite.  Neither one of them had much of a chance in the real world.  Much like Unix itself, Linux's worse-is-better approach really worked.  
> 
> I have a hypothesis about Linux's ascendance too, which is a personal anecdote I am inflating to the status of hypothesis.  As I recall, the *BSDs for 386 all assumed they owned the hard disk.  Like, the whole thing.  You couldn't, at least in 1992, create a multiboot system--or at least it was my strong impression you could not.  I was an undergrad.  I had one '386 at my disposal, with one hard disk, and, hey, I needed DOS and Windows to write my papers (I don't know about you, but I wanted to write in my room, where I could have my references at hand and be reasonably undisturbed; sure Framemaker was a much better setup than Word For Windows 1.2 but having to use it in the computer lab made it a nonstarter for me).  Papers, and, well, to play games.  Sure, that too.
> 
> Linux let me defragment my drive, non-destructively repartition it, and create a dual-boot system, so that I could both use the computer for school and screw around on Linux.  I'm probably not the only person for whom this was a decisive factor.
> 
> Adam
> 
>> On Wed, Aug 28, 2019 at 1:08 PM Christopher Browne <cbbrowne at gmail.com> wrote:
>>> On Mon, 26 Aug 2019 at 19:14, Arthur Krewat <krewat at kilonet.net> wrote:
>> 
>>> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel
>>> 
>>> Leaving licensing and copyright issues out of this mental exercise, what 
>>> would we have now if it wasn't for Linux? Not what you'd WANT it to be, 
>>> although that can add to the discussion, but what WOULD it be?
>>> 
>>> I'm not asking as a proponent of Linux. If anything, I was dragged 
>>> kicking and screaming into the current day and have begrudgingly ceded 
>>> my server space to Linux.
>>> 
>>> But if not for Linux, would it be BSD? A System V variant? Or (the 
>>> horror) Windows NT?
>> 
>> I can make a firm "dunno" sound :-)
>> 
>> Some facts can come together to point away from a number of possibilities...
>> 
>> - If you look at the number of hobbyist "Unix homages" that emerged at around that time, it's clear that there was a sizable community of interested folk willing to build their own thing, and that weren't interested in Windows NT.  (Nay, one should put that more strongly...  That had their minds set on something NOT from Microsoft.)  So I think we can cross Windows NT off the list.
>> 
>> - OS/2 should briefly come on the list.  It was likable in many ways, if only IBM had actually supported it...  But it suffers from something of the same problem as Windows NT; there were a lot of folk that were only slightly less despising of IBM at the time than of Microsoft.
>> 
>> - Hurd was imagined to be the next thing...
>> 
>> To borrow from my cookie file...
>> 
>> "Of course 5  years from now that will be different,  but 5 years from
>> now  everyone  will  be  running  free  GNU on  their  200  MIPS,  64M
>> SPARCstation-5."  -- Andrew Tanenbaum, 1992.
>> %
>> "You'll be  rid of most of us  when BSD-detox or GNU  comes out, which
>> should happen in the next few months (yeah, right)." -- Richard Tobin,
>> 1992. [BSD did follow within a year]
>> %
>> "I am aware of the benefits  of a micro kernel approach.  However, the
>> fact remains  that Linux is  here, and GNU  isn't --- and  people have
>> been working on Hurd for a lot longer than Linus has been working on
>> Linux." -- Ted T'so, 1992.
>> 
>> Ted has been on this thread, and should be amused (and slightly disturbed!) that his old statements are being held here and there, ready to trot out :-).
>> 
>> In the absence of Linux, perhaps hackers would have flocked to Hurd, but there was enough going on that there was plenty of room for them to have done so anyways.
>> 
>> I'm not sure what to blame on whatever happened post-1992, though I'd put some on Microsoft Research having taken the wind out of Mach's sails by hiring off a bunch of the relevant folk.  In order for Hurd to "make it," Mach has to "make it," too, and it looked like they were depending on CMU to be behind that.  (I'm not sure I'm right about that; happy to hear a better story.)
>> 
>> Anyway, Hurd *might* have been a "next thing," and I don't think the popularity of Linux was enough to have completely taken wind out of its sails, given that there's the dozens of "Unix homages" out there.
>> 
>> - I'd like to imagine Plan 9 being an alternative, but it was "properly commercial" for a goodly long time (hence not amenable to attaching waves of hackers to it to add their favorite device drivers), and was never taken as a serious answer.  Many of us had admired it from afar via the Dr Dobbs Journal issue (when was that?  mid or late '90s?) but only from afar.
>> 
>> - FreeBSD is the single best answer I can throw up as a possibility, as it was the one actively targeting 80386 hardware.  And that had the big risk of the AT&T lawsuit lurking over it, so had that gone in a different direction, then that is a branch sadly easily trimmed.
>> 
>> If we lop both Linux and FreeBSD off the list of possibilities, I don't imagine Windows NT or OS/2 bubble to the top, instead, a critical mass would have stood behind ... something else, I'd think.  I don't know which to suggest.
>> -- 
>> When confronted by a difficult problem, solve it by reducing it to the
>> question, "How would the Lone Ranger handle this?"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190828/27aef900/attachment.html>

From ggm at algebras.org  Thu Aug 29 08:29:03 2019
From: ggm at algebras.org (George Michaelson)
Date: Thu, 29 Aug 2019 08:29:03 +1000
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <CAKzdPgw_OJO6ehq4g=t_cqUw-Pqz_T6gn48uMDuyfpiQqNvOKw@mail.gmail.com>
References: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU>
 <CAKzdPgw_OJO6ehq4g=t_cqUw-Pqz_T6gn48uMDuyfpiQqNvOKw@mail.gmail.com>
Message-ID: <CAKr6gn1ZHLerb4sODqYzMo8zi82gRAt6RnB3Wjtany8TdD15qg@mail.gmail.com>

This is an object lesson in not making assumptions about things. I had
always assumed the V in UNIX 32V stood for something which went to
demand paging, from 'Virtual Addressing'. Turns out: I was wrong.

One other note about sockets: The original 4.2 port had to be used by
a lot of people without the ethernet, because we didn't have the DEC
ethernet card it was written to. This made unix domain sockets very
interesting because you could test in them. Except: the very first
test program somebody wrote at Leeds university to create and write to
a unix domain socket in /tmp crashed the vax. ... (this was around
1982/3) -We were warned off using sockets until the first patch tape
came in the post.

The Berkeley lawyers were amazing. I like to think 'shakespear
witches' or 'evil gnomes' -We had changed staff in some functional
role, and when we came to do licence renewal for the upgrade from 4.1
They insisted we find the mouldering body of the ex appointee and get
them to countersign (press the dead flesh in a pot of ink and put on
the paper?) before they'd re-issue. I'd never seen documents (a)
printed on this bizarre page size called 'legal and (b) actually
*embossed* by the university seal.. This was some serious magic going
down. In my nightmares, somebody in mid-western nondescript university
of somewhereville is screaming "I CANT GET THE ORIGINAL SIGNATURE" and
the Berkeley lawyers just shrug and walk away from the deal.

This was also the release which brought T/Roff drivers for xerographic
process printers. They emitted wet, shiny, even slimy pages in some
process I don't want to understand, all of which bore cut marks on the
side (roll feed, before A4 printers existed) marking this US legal
thing. Cut at the mark? Won't fit a ring-binder we own in the entire
University...  Mike Lesk told me the code had 'witticisms' such as an
extra emitted char on \r to ensure the specific printer it was written
for didn't stuff up TBL output.

-G

On Thu, Aug 29, 2019 at 7:55 AM Rob Pike <robpike at gmail.com> wrote:
>
> Reiser added paging and it was working well by early 1981.
>
> -rob
>
>
> On Thu, Aug 29, 2019 at 4:41 AM Doug McIlroy <doug at cs.dartmouth.edu> wrote:
>>
>> > Doug McIlroy <doug at cs.dartmouth.edu> wrote:
>> >
>> >>
>> >>> How long was research running on a PDP-11 and when did they move to a VAX?
>> >>
>> >> London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research.
>> >>
>> >> Doug
>> >
>> > So, what's the story on why the London/Reiser port didn't get adapted
>> > back by Research, and they ended up starting from 4.1 BSD?
>> >
>> > Thanks,
>> >
>> > Arnold
>>
>>
>> Sorry, what I said about London/Reiser is true, but not the whole story. L/R didn't have demand paging; BSD did.
>>
>> Doug
>>

From pechter at gmail.com  Thu Aug 29 08:36:34 2019
From: pechter at gmail.com (William Pechter)
Date: Wed, 28 Aug 2019 18:36:34 -0400
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <CAKr6gn1ZHLerb4sODqYzMo8zi82gRAt6RnB3Wjtany8TdD15qg@mail.gmail.com>
References: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU>
 <CAKzdPgw_OJO6ehq4g=t_cqUw-Pqz_T6gn48uMDuyfpiQqNvOKw@mail.gmail.com>
 <CAKr6gn1ZHLerb4sODqYzMo8zi82gRAt6RnB3Wjtany8TdD15qg@mail.gmail.com>
Message-ID: <c0c10630-2711-0221-04d4-f291842b07a2@gmail.com>

I could've sworn 4.x BSD supported Micom Internan NI1010 or some other early
ethernet like 3com as well as the DEC boards.

Anyone have the 4.1 or 4.2 BSD docs handy.  Mine are boxed away for safe 
keeping.

On 8/28/2019 6:29 PM, George Michaelson wrote:
> This is an object lesson in not making assumptions about things. I had
> always assumed the V in UNIX 32V stood for something which went to
> demand paging, from 'Virtual Addressing'. Turns out: I was wrong.
>
> One other note about sockets: The original 4.2 port had to be used by
> a lot of people without the ethernet, because we didn't have the DEC
> ethernet card it was written to. This made unix domain sockets very
> interesting because you could test in them. Except: the very first
> test program somebody wrote at Leeds university to create and write to
> a unix domain socket in /tmp crashed the vax. ... (this was around
> 1982/3) -We were warned off using sockets until the first patch tape
> came in the post.
>
>


From athornton at gmail.com  Thu Aug 29 08:48:43 2019
From: athornton at gmail.com (Adam Thornton)
Date: Wed, 28 Aug 2019 15:48:43 -0700
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <016BFF16-C490-425D-8168-3D59DCCA6A21@ccc.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAFNqd5VpUE9OsKqfHDW8-76S46PYtnTJWDWAs0FU6o+73B4ZfQ@mail.gmail.com>
 <CAP2nic0_5vXCwSr8THcHfTxSEEWVkv2tvU1qheZusC7Qekh6zQ@mail.gmail.com>
 <016BFF16-C490-425D-8168-3D59DCCA6A21@ccc.com>
Message-ID: <CAP2nic0GxgqRvz5z9vfRWXjo5-UpbNsut8S0F4vduYLw+a6-Sw@mail.gmail.com>

It probably was the partition/slice confusion that, well, confused me,
then.  My experience, such as it was, was from the DOS world.

Although the period I am thinking of was way pre-slackware.  You had a boot
floppy and a root floppy and that was about it, I think.  I think the
kernel had MFM/RLL disk drivers for an ISA bus interface?  I remember that
I could boot the thing on the MCA machines in the lab but not actually
install it (even had I been allowed to), and I think installation was
pretty much fdisk/mkfs, extract the tarball...I don't remember how you
installed the bootloader...which I guess was already LILO at that point?
Probably just dding the bootsector to the first physical sector of the
disk?  Version 0.08 or so, maybe?

It was quite a while ago, and I was drunk for most of college, so....memory
is imprecise at best.

On Wed, Aug 28, 2019 at 3:28 PM Clem cole <clemc at ccc.com> wrote:

> Not true 386BSD used fdisk.  It shared the disk just fine.  In fact I
> liked the way it sliced the disk much better than Slackware in those days.
>
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not
> quite.
>
> On Aug 28, 2019, at 4:27 PM, Adam Thornton <athornton at gmail.com> wrote:
>
> I was an ardent OS/2 supporter for a long time.  Sure, IBM's anemic
> marketing, and their close-to-outright-hostility to 3rd-party developers
> didn't help.  But what killed it, really, was how damn good its 16-bit
> support was.  It *was* a better DOS than DOS and a better Windows than
> 3.11fW.  So no one wrote to the relatively tiny market of 32-bit OS/2.
>
> I fear that had Linux not made the leap, MS might well have won.  It's
> largely the AOL-fuelled explosion of popularity of the Internet and Windows
> ignoring same until too late that opened the door enough for Linux to jam
> its foot in.
>
> Hurd was, by the time of the '386 Unix Wars and early Linux, clearly not
> going to be a contender, I guess because it was about cool research
> features rather than running user-facing code.  I kept waiting for a usable
> kernel to go with what Linux had already shown was a quite decent
> userspace, but eventually had better things to do with my life (like chase
> BeOS).  It was like waiting for Perl 6--it missed its moment.
>
> Plan 9 and Amoeba were both really nifty.    I never used Sprite.  Neither
> one of them had much of a chance in the real world.  Much like Unix itself,
> Linux's worse-is-better approach really worked.
>
> I have a hypothesis about Linux's ascendance too, which is a personal
> anecdote I am inflating to the status of hypothesis.  As I recall, the
> *BSDs for 386 all assumed they owned the hard disk.  Like, the whole
> thing.  You couldn't, at least in 1992, create a multiboot system--or at
> least it was my strong impression you could not.  I was an undergrad.  I
> had one '386 at my disposal, with one hard disk, and, hey, I needed DOS and
> Windows to write my papers (I don't know about you, but I wanted to write
> in my room, where I could have my references at hand and be reasonably
> undisturbed; sure Framemaker was a much better setup than Word For Windows
> 1.2 but having to use it in the computer lab made it a nonstarter for me).
> Papers, and, well, to play games.  Sure, that too.
>
> Linux let me defragment my drive, non-destructively repartition it, and
> create a dual-boot system, so that I could both use the computer for school
> and screw around on Linux.  I'm probably not the only person for whom this
> was a decisive factor.
>
> Adam
>
> On Wed, Aug 28, 2019 at 1:08 PM Christopher Browne <cbbrowne at gmail.com>
> wrote:
>
>> On Mon, 26 Aug 2019 at 19:14, Arthur Krewat <krewat at kilonet.net> wrote:
>>
>>>
>>> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel
>>>
>>> Leaving licensing and copyright issues out of this mental exercise, what
>>> would we have now if it wasn't for Linux? Not what you'd WANT it to be,
>>> although that can add to the discussion, but what WOULD it be?
>>>
>>> I'm not asking as a proponent of Linux. If anything, I was dragged
>>> kicking and screaming into the current day and have begrudgingly ceded
>>> my server space to Linux.
>>>
>>> But if not for Linux, would it be BSD? A System V variant? Or (the
>>> horror) Windows NT?
>>>
>>
>> I can make a firm "dunno" sound :-)
>>
>> Some facts can come together to point away from a number of
>> possibilities...
>>
>> - If you look at the number of hobbyist "Unix homages" that emerged at
>> around that time, it's clear that there was a sizable community of
>> interested folk willing to build their own thing, and that weren't
>> interested in Windows NT.  (Nay, one should put that more strongly...  That
>> had their minds set on something NOT from Microsoft.)  So I think we can
>> cross Windows NT off the list.
>>
>> - OS/2 should briefly come on the list.  It was likable in many ways, if
>> only IBM had actually supported it...  But it suffers from something of the
>> same problem as Windows NT; there were a lot of folk that were only
>> slightly less despising of IBM at the time than of Microsoft.
>>
>> - Hurd was imagined to be the next thing...
>>
>> To borrow from my cookie file...
>>
>> "Of course 5  years from now that will be different,  but 5 years from
>> now  everyone  will  be  running  free  GNU on  their  200  MIPS,  64M
>> SPARCstation-5."  -- Andrew Tanenbaum, 1992.
>> %
>> "You'll be  rid of most of us  when BSD-detox or GNU  comes out, which
>> should happen in the next few months (yeah, right)." -- Richard Tobin,
>> 1992. [BSD did follow within a year]
>> %
>> "I am aware of the benefits  of a micro kernel approach.  However, the
>> fact remains  that Linux is  here, and GNU  isn't --- and  people have
>> been working on Hurd for a lot longer than Linus has been working on
>> Linux." -- Ted T'so, 1992.
>>
>> Ted has been on this thread, and should be amused (and slightly
>> disturbed!) that his old statements are being held here and there, ready to
>> trot out :-).
>>
>> In the absence of Linux, perhaps hackers would have flocked to Hurd, but
>> there was enough going on that there was plenty of room for them to have
>> done so anyways.
>>
>> I'm not sure what to blame on whatever happened post-1992, though I'd put
>> some on Microsoft Research having taken the wind out of Mach's sails by
>> hiring off a bunch of the relevant folk.  In order for Hurd to "make it,"
>> Mach has to "make it," too, and it looked like they were depending on CMU
>> to be behind that.  (I'm not sure I'm right about that; happy to hear a
>> better story.)
>>
>> Anyway, Hurd *might* have been a "next thing," and I don't think the
>> popularity of Linux was enough to have completely taken wind out of its
>> sails, given that there's the dozens of "Unix homages" out there.
>>
>> - I'd like to imagine Plan 9 being an alternative, but it was "properly
>> commercial" for a goodly long time (hence not amenable to attaching waves
>> of hackers to it to add their favorite device drivers), and was never taken
>> as a serious answer.  Many of us had admired it from afar via the Dr Dobbs
>> Journal issue (when was that?  mid or late '90s?) but only from afar.
>>
>> - FreeBSD is the single best answer I can throw up as a possibility, as
>> it was the one actively targeting 80386 hardware.  And that had the big
>> risk of the AT&T lawsuit lurking over it, so had that gone in a different
>> direction, then that is a branch sadly easily trimmed.
>>
>> If we lop both Linux and FreeBSD off the list of possibilities, I don't
>> imagine Windows NT or OS/2 bubble to the top, instead, a critical mass
>> would have stood behind ... something else, I'd think.  I don't know which
>> to suggest.
>> --
>> When confronted by a difficult problem, solve it by reducing it to the
>> question, "How would the Lone Ranger handle this?"
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190828/e4a04cb2/attachment.html>

From krewat at kilonet.net  Thu Aug 29 08:53:42 2019
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 28 Aug 2019 18:53:42 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <283e3cc2-42ec-a554-602f-5fb67eca9e40@gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAFNqd5VpUE9OsKqfHDW8-76S46PYtnTJWDWAs0FU6o+73B4ZfQ@mail.gmail.com>
 <CAP2nic0_5vXCwSr8THcHfTxSEEWVkv2tvU1qheZusC7Qekh6zQ@mail.gmail.com>
 <283e3cc2-42ec-a554-602f-5fb67eca9e40@gmail.com>
Message-ID: <a4e48702-9890-1798-3e70-408784572ed1@kilonet.net>



On 8/28/2019 6:27 PM, William Pechter wrote:
> I checked the FreeBSD archives and it COULD install in a primary 
> partition (partition type 165) and share the disk with other OS types. 

At some point, I had written a boot partition hook to select which 
partition to boot, and set it as Primary on the fly by modifying the 
partition table. The comments below are from a precursor to that. Sadly 
I do not have the source code for the later version where I had added 
the selection menu and actual partition table update to. Note the reason 
I started it ;)

I know I was dual booting FreeBSD or maybe Consensys (SVR4.2) with DOS 
at some point, and based on the dates on this source code, it would have 
been around the second half of 1992.


PART.ASM:

Title PART - Partition table boot-up program.

Comment *

         (C) 1992 Kilowatt Computing - Arthur Krewat

         Started Feb 2, 1992

         Initiated by the Michelangelo Virus of 1/1992 - I figured if I
         have a program using sector 0 of the hard drive and something 
writes
         to it, it SHOULD crash - unless the virus is particularly
         intelligent. And we all know writers of virii are NOT or else 
they'd
         be doing something INTELLIGENT with their time.


*

Later on in the file:

Partb   Db      00H,"Unknown - empty",0 ;System indicators.
         Db      01H,"DOS (12 bit FAT)",0
         Db      02H,"XENIX",0
         Db      04H,"DOS (16 bit FAT)",0
         Db      05H,"DOS - extended partition",0
         Db      06H,"DOS 4.0",0
         Db      51H,"Ontrack extended partition",0
         Db      64H,"Novell",0
         Db      75H,"PCIX",0
         Db      0DBH,"CP/M",0
         Db      0FFH,"BBT",0
         Db      0


From pechter at gmail.com  Thu Aug 29 09:01:28 2019
From: pechter at gmail.com (William Pechter)
Date: Wed, 28 Aug 2019 19:01:28 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CAP2nic0GxgqRvz5z9vfRWXjo5-UpbNsut8S0F4vduYLw+a6-Sw@mail.gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAFNqd5VpUE9OsKqfHDW8-76S46PYtnTJWDWAs0FU6o+73B4ZfQ@mail.gmail.com>
 <CAP2nic0_5vXCwSr8THcHfTxSEEWVkv2tvU1qheZusC7Qekh6zQ@mail.gmail.com>
 <016BFF16-C490-425D-8168-3D59DCCA6A21@ccc.com>
 <CAP2nic0GxgqRvz5z9vfRWXjo5-UpbNsut8S0F4vduYLw+a6-Sw@mail.gmail.com>
Message-ID: <13e8e297-0b27-ac95-8fd4-e2a9b28d0b64@gmail.com>

On 8/28/2019 6:48 PM, Adam Thornton wrote:
> It probably was the partition/slice confusion that, well, confused me, 
> then.  My experience, such as it was, was from the DOS world.

As was mine mostly 8-) I remember it from the PITA it was to translate 
in my head.  Unix folks looked at partitions as /dev/dsk/0s0->0s7 (I 
think 7 was the SVR2 maximum.  The "Unix" partitions fit inside the 
FDISK partition or dos slice... The dos guys looked at it kind of like 
the fdisk space disk0 partition 3 (for example) was the partition and 
then the BSD folks broke that in to /dev/sd0a /dev/sd0b /dev/sd0c etc.

I did a little SunOS and SysV along with Dos and Windows and could make 
them coexist as long as there was an open primary dos partition.


>
> Although the period I am thinking of was way pre-slackware.  You had a 
> boot floppy and a root floppy and that was about it, I think.  I think 
> the kernel had MFM/RLL disk drivers for an ISA bus interface?  I 
> remember that I could boot the thing on the MCA machines in the lab 
> but not actually install it (even had I been allowed to), and I think 
> installation was pretty much fdisk/mkfs, extract the tarball...I don't 
> remember how you installed the bootloader...which I guess was already 
> LILO at that point? Probably just dding the bootsector to the first 
> physical sector of the disk?  Version 0.08 or so, maybe?
>

Sounds like SLS -- Soft Landing System -- which later was pretty much 
replaced with Slackware.  I used the early MCA stuff on PS/2's at IBM 
for a while.  Most of the PS/2 stuff we had was SCSI.  The boot loader 
was lilo.  It could go in the partition space or disk mbr.  
See:https://www.ibm.com/developerworks/library/l-bootload/index.html


> It was quite a while ago, and I was drunk for most of college, 
> so....memory is imprecise at best.
>
> On Wed, Aug 28, 2019 at 3:28 PM Clem cole <clemc at ccc.com 
> <mailto:clemc at ccc.com>> wrote:
>
>     Not true 386BSD used fdisk.  It shared the disk just fine.  In
>     fact I liked the way it sliced the disk much better than Slackware
>     in those days.
>
>     Sent from my PDP-7 Running UNIX V0 expect things to be almost but
>     not quite.
>
>     On Aug 28, 2019, at 4:27 PM, Adam Thornton <athornton at gmail.com
>     <mailto:athornton at gmail.com>> wrote:
>
>>     I was an ardent OS/2 supporter for a long time. Sure, IBM's
>>     anemic marketing, and their close-to-outright-hostility to
>>     3rd-party developers didn't help.  But what killed it, really,
>>     was how damn good its 16-bit support was.  It *was* a better DOS
>>     than DOS and a better Windows than 3.11fW.  So no one wrote to
>>     the relatively tiny market of 32-bit OS/2.
>>
>>     I fear that had Linux not made the leap, MS might well have won. 
>>     It's largely the AOL-fuelled explosion of popularity of the
>>     Internet and Windows ignoring same until too late that opened the
>>     door enough for Linux to jam its foot in.
>>
>>     Hurd was, by the time of the '386 Unix Wars and early Linux,
>>     clearly not going to be a contender, I guess because it was about
>>     cool research features rather than running user-facing code.  I
>>     kept waiting for a usable kernel to go with what Linux had
>>     already shown was a quite decent userspace, but eventually had
>>     better things to do with my life (like chase BeOS).  It was like
>>     waiting for Perl 6--it missed its moment.
>>
>>     Plan 9 and Amoeba were both really nifty.    I never used
>>     Sprite.  Neither one of them had much of a chance in the real
>>     world.  Much like Unix itself, Linux's worse-is-better approach
>>     really worked.
>>
>>     I have a hypothesis about Linux's ascendance too, which is a
>>     personal anecdote I am inflating to the status of hypothesis.  As
>>     I recall, the *BSDs for 386 all assumed they owned the hard
>>     disk.  Like, the whole thing.  You couldn't, at least in 1992,
>>     create a multiboot system--or at least it was my strong
>>     impression you could not.  I was an undergrad.  I had one '386 at
>>     my disposal, with one hard disk, and, hey, I needed DOS and
>>     Windows to write my papers (I don't know about you, but I wanted
>>     to write in my room, where I could have my references at hand and
>>     be reasonably undisturbed; sure Framemaker was a much better
>>     setup than Word For Windows 1.2 but having to use it in the
>>     computer lab made it a nonstarter for me).  Papers, and, well, to
>>     play games.  Sure, that too.
>>
>>     Linux let me defragment my drive, non-destructively repartition
>>     it, and create a dual-boot system, so that I could both use the
>>     computer for school and screw around on Linux.  I'm probably not
>>     the only person for whom this was a decisive factor.
>>
>>     Adam
>>
>>     On Wed, Aug 28, 2019 at 1:08 PM Christopher Browne
>>     <cbbrowne at gmail.com <mailto:cbbrowne at gmail.com>> wrote:
>>
>>         On Mon, 26 Aug 2019 at 19:14, Arthur Krewat
>>         <krewat at kilonet.net <mailto:krewat at kilonet.net>> wrote:
>>
>>             https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel
>>
>>             Leaving licensing and copyright issues out of this mental
>>             exercise, what
>>             would we have now if it wasn't for Linux? Not what you'd
>>             WANT it to be,
>>             although that can add to the discussion, but what WOULD
>>             it be?
>>
>>             I'm not asking as a proponent of Linux. If anything, I
>>             was dragged
>>             kicking and screaming into the current day and have
>>             begrudgingly ceded
>>             my server space to Linux.
>>
>>             But if not for Linux, would it be BSD? A System V
>>             variant? Or (the
>>             horror) Windows NT?
>>
>>
>>         I can make a firm "dunno" sound :-)
>>
>>         Some facts can come together to point away from a number of
>>         possibilities...
>>
>>         - If you look at the number of hobbyist "Unix homages" that
>>         emerged at around that time, it's clear that there was a
>>         sizable community of interested folk willing to build their
>>         own thing, and that weren't interested in Windows NT.  (Nay,
>>         one should put that more strongly...  That had their minds
>>         set on something NOT from Microsoft.)  So I think we can
>>         cross Windows NT off the list.
>>
>>         - OS/2 should briefly come on the list.  It was likable in
>>         many ways, if only IBM had actually supported it...  But it
>>         suffers from something of the same problem as Windows NT;
>>         there were a lot of folk that were only slightly less
>>         despising of IBM at the time than of Microsoft.
>>
>>         - Hurd was imagined to be the next thing...
>>
>>         To borrow from my cookie file...
>>
>>         "Of course 5  years from now that will be different,  but 5
>>         years from
>>         now  everyone  will  be  running  free  GNU on  their  200
>>          MIPS,  64M
>>         SPARCstation-5."  -- Andrew Tanenbaum, 1992.
>>         %
>>         "You'll be  rid of most of us  when BSD-detox or GNU  comes
>>         out, which
>>         should happen in the next few months (yeah, right)." --
>>         Richard Tobin,
>>         1992. [BSD did follow within a year]
>>         %
>>         "I am aware of the benefits  of a micro kernel approach. 
>>         However, the
>>         fact remains  that Linux is  here, and GNU  isn't --- and
>>          people have
>>         been working on Hurd for a lot longer than Linus has been
>>         working on
>>         Linux." -- Ted T'so, 1992.
>>
>>         Ted has been on this thread, and should be amused (and
>>         slightly disturbed!) that his old statements are being held
>>         here and there, ready to trot out :-).
>>
>>         In the absence of Linux, perhaps hackers would have flocked
>>         to Hurd, but there was enough going on that there was plenty
>>         of room for them to have done so anyways.
>>
>>         I'm not sure what to blame on whatever happened post-1992,
>>         though I'd put some on Microsoft Research having taken the
>>         wind out of Mach's sails by hiring off a bunch of the
>>         relevant folk.  In order for Hurd to "make it," Mach has to
>>         "make it," too, and it looked like they were depending on CMU
>>         to be behind that. (I'm not sure I'm right about that; happy
>>         to hear a better story.)
>>
>>         Anyway, Hurd *might* have been a "next thing," and I don't
>>         think the popularity of Linux was enough to have completely
>>         taken wind out of its sails, given that there's the dozens of
>>         "Unix homages" out there.
>>
>>         - I'd like to imagine Plan 9 being an alternative, but it was
>>         "properly commercial" for a goodly long time (hence not
>>         amenable to attaching waves of hackers to it to add their
>>         favorite device drivers), and was never taken as a serious
>>         answer.  Many of us had admired it from afar via the Dr Dobbs
>>         Journal issue (when was that?  mid or late '90s?) but only
>>         from afar.
>>
>>         - FreeBSD is the single best answer I can throw up as a
>>         possibility, as it was the one actively targeting 80386
>>         hardware.  And that had the big risk of the AT&T lawsuit
>>         lurking over it, so had that gone in a different direction,
>>         then that is a branch sadly easily trimmed.
>>
>>         If we lop both Linux and FreeBSD off the list of
>>         possibilities, I don't imagine Windows NT or OS/2 bubble to
>>         the top, instead, a critical mass would have stood behind ...
>>         something else, I'd think.  I don't know which to suggest.
>>         -- 
>>         When confronted by a difficult problem, solve it by reducing
>>         it to the
>>         question, "How would the Lone Ranger handle this?"
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190828/02037a97/attachment-0001.html>

From krewat at kilonet.net  Thu Aug 29 09:02:40 2019
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 28 Aug 2019 19:02:40 -0400
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <c0c10630-2711-0221-04d4-f291842b07a2@gmail.com>
References: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU>
 <CAKzdPgw_OJO6ehq4g=t_cqUw-Pqz_T6gn48uMDuyfpiQqNvOKw@mail.gmail.com>
 <CAKr6gn1ZHLerb4sODqYzMo8zi82gRAt6RnB3Wjtany8TdD15qg@mail.gmail.com>
 <c0c10630-2711-0221-04d4-f291842b07a2@gmail.com>
Message-ID: <0326ec79-b962-e518-9f4e-dfa80a7aca10@kilonet.net>

On 8/28/2019 6:36 PM, William Pechter wrote:
> I could've sworn 4.x BSD supported Micom Internan NI1010 or some other 
> early
> ethernet like 3com as well as the DEC boards. 
I know some VAX-11/750's running BSD 4.2 were running NI1010's - I don't 
know if that was because someone had made/found a driver and installed 
it, or it was native. Maybe backported from 4.3.

I think I might actually have one of those 1010's and I'm pretty sure I 
have the driver development guide for it (tech specs).

Looking at the 4.3 sources I got from the place that had these VAXs, 
there's this.

./src/nfsdist/32_43.FCS/sys/vaxif/if_il.c
/* @(#)if_il.c  1.4 87/07/22 3.2/4.3NFSSRC */
/*
  * Copyright (c) 1982, 1986 Regents of the University of California.
  * All rights reserved.  The Berkeley software License Agreement
  * specifies the terms and conditions for redistribution.
  *
  *      @(#)if_il.c     7.1 (Berkeley) 6/5/86
  */

#include "il.h"
#if NIL > 0

/*
  * Interlan Ethernet Communications Controller interface
  */

<SNIP>


From gregg.drwho8 at gmail.com  Thu Aug 29 09:04:27 2019
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Wed, 28 Aug 2019 19:04:27 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <016BFF16-C490-425D-8168-3D59DCCA6A21@ccc.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAFNqd5VpUE9OsKqfHDW8-76S46PYtnTJWDWAs0FU6o+73B4ZfQ@mail.gmail.com>
 <CAP2nic0_5vXCwSr8THcHfTxSEEWVkv2tvU1qheZusC7Qekh6zQ@mail.gmail.com>
 <016BFF16-C490-425D-8168-3D59DCCA6A21@ccc.com>
Message-ID: <CAC5iaNFt47KVrTkZKxcRu-o8xF14XM-rpbqTPU8tauPL38Br6Q@mail.gmail.com>

Hello!
I can certainly attest to that one. The partition methods Slackware
was using for releases before 3.0 were stranger then a lot of things.
For release 3.0 and later it all started to make sense. I had more
problems thought figuring out why several others really wanted me to
break up the disk into a batch of individual ones......

However while exploring both NetBSD and FreeBSD I did workout why they
wanted the disk broken out into those slices.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."

On Wed, Aug 28, 2019 at 6:29 PM Clem cole <clemc at ccc.com> wrote:
>
> Not true 386BSD used fdisk.  It shared the disk just fine.  In fact I liked the way it sliced the disk much better than Slackware in those days.
>
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
>
> On Aug 28, 2019, at 4:27 PM, Adam Thornton <athornton at gmail.com> wrote:
>
> I was an ardent OS/2 supporter for a long time.  Sure, IBM's anemic marketing, and their close-to-outright-hostility to 3rd-party developers didn't help.  But what killed it, really, was how damn good its 16-bit support was.  It *was* a better DOS than DOS and a better Windows than 3.11fW.  So no one wrote to the relatively tiny market of 32-bit OS/2.
>
> I fear that had Linux not made the leap, MS might well have won.  It's largely the AOL-fuelled explosion of popularity of the Internet and Windows ignoring same until too late that opened the door enough for Linux to jam its foot in.
>
> Hurd was, by the time of the '386 Unix Wars and early Linux, clearly not going to be a contender, I guess because it was about cool research features rather than running user-facing code.  I kept waiting for a usable kernel to go with what Linux had already shown was a quite decent userspace, but eventually had better things to do with my life (like chase BeOS).  It was like waiting for Perl 6--it missed its moment.
>
> Plan 9 and Amoeba were both really nifty.    I never used Sprite.  Neither one of them had much of a chance in the real world.  Much like Unix itself, Linux's worse-is-better approach really worked.
>
> I have a hypothesis about Linux's ascendance too, which is a personal anecdote I am inflating to the status of hypothesis.  As I recall, the *BSDs for 386 all assumed they owned the hard disk.  Like, the whole thing.  You couldn't, at least in 1992, create a multiboot system--or at least it was my strong impression you could not.  I was an undergrad.  I had one '386 at my disposal, with one hard disk, and, hey, I needed DOS and Windows to write my papers (I don't know about you, but I wanted to write in my room, where I could have my references at hand and be reasonably undisturbed; sure Framemaker was a much better setup than Word For Windows 1.2 but having to use it in the computer lab made it a nonstarter for me).  Papers, and, well, to play games.  Sure, that too.
>
> Linux let me defragment my drive, non-destructively repartition it, and create a dual-boot system, so that I could both use the computer for school and screw around on Linux.  I'm probably not the only person for whom this was a decisive factor.
>
> Adam
>
> On Wed, Aug 28, 2019 at 1:08 PM Christopher Browne <cbbrowne at gmail.com> wrote:
>>
>> On Mon, 26 Aug 2019 at 19:14, Arthur Krewat <krewat at kilonet.net> wrote:
>>>
>>> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel
>>>
>>> Leaving licensing and copyright issues out of this mental exercise, what
>>> would we have now if it wasn't for Linux? Not what you'd WANT it to be,
>>> although that can add to the discussion, but what WOULD it be?
>>>
>>> I'm not asking as a proponent of Linux. If anything, I was dragged
>>> kicking and screaming into the current day and have begrudgingly ceded
>>> my server space to Linux.
>>>
>>> But if not for Linux, would it be BSD? A System V variant? Or (the
>>> horror) Windows NT?
>>
>>
>> I can make a firm "dunno" sound :-)
>>
>> Some facts can come together to point away from a number of possibilities...
>>
>> - If you look at the number of hobbyist "Unix homages" that emerged at around that time, it's clear that there was a sizable community of interested folk willing to build their own thing, and that weren't interested in Windows NT.  (Nay, one should put that more strongly...  That had their minds set on something NOT from Microsoft.)  So I think we can cross Windows NT off the list.
>>
>> - OS/2 should briefly come on the list.  It was likable in many ways, if only IBM had actually supported it...  But it suffers from something of the same problem as Windows NT; there were a lot of folk that were only slightly less despising of IBM at the time than of Microsoft.
>>
>> - Hurd was imagined to be the next thing...
>>
>> To borrow from my cookie file...
>>
>> "Of course 5  years from now that will be different,  but 5 years from
>> now  everyone  will  be  running  free  GNU on  their  200  MIPS,  64M
>> SPARCstation-5."  -- Andrew Tanenbaum, 1992.
>> %
>> "You'll be  rid of most of us  when BSD-detox or GNU  comes out, which
>> should happen in the next few months (yeah, right)." -- Richard Tobin,
>> 1992. [BSD did follow within a year]
>> %
>> "I am aware of the benefits  of a micro kernel approach.  However, the
>> fact remains  that Linux is  here, and GNU  isn't --- and  people have
>> been working on Hurd for a lot longer than Linus has been working on
>> Linux." -- Ted T'so, 1992.
>>
>> Ted has been on this thread, and should be amused (and slightly disturbed!) that his old statements are being held here and there, ready to trot out :-).
>>
>> In the absence of Linux, perhaps hackers would have flocked to Hurd, but there was enough going on that there was plenty of room for them to have done so anyways.
>>
>> I'm not sure what to blame on whatever happened post-1992, though I'd put some on Microsoft Research having taken the wind out of Mach's sails by hiring off a bunch of the relevant folk.  In order for Hurd to "make it," Mach has to "make it," too, and it looked like they were depending on CMU to be behind that.  (I'm not sure I'm right about that; happy to hear a better story.)
>>
>> Anyway, Hurd *might* have been a "next thing," and I don't think the popularity of Linux was enough to have completely taken wind out of its sails, given that there's the dozens of "Unix homages" out there.
>>
>> - I'd like to imagine Plan 9 being an alternative, but it was "properly commercial" for a goodly long time (hence not amenable to attaching waves of hackers to it to add their favorite device drivers), and was never taken as a serious answer.  Many of us had admired it from afar via the Dr Dobbs Journal issue (when was that?  mid or late '90s?) but only from afar.
>>
>> - FreeBSD is the single best answer I can throw up as a possibility, as it was the one actively targeting 80386 hardware.  And that had the big risk of the AT&T lawsuit lurking over it, so had that gone in a different direction, then that is a branch sadly easily trimmed.
>>
>> If we lop both Linux and FreeBSD off the list of possibilities, I don't imagine Windows NT or OS/2 bubble to the top, instead, a critical mass would have stood behind ... something else, I'd think.  I don't know which to suggest.
>> --
>> When confronted by a difficult problem, solve it by reducing it to the
>> question, "How would the Lone Ranger handle this?"

From athornton at gmail.com  Thu Aug 29 09:09:24 2019
From: athornton at gmail.com (Adam Thornton)
Date: Wed, 28 Aug 2019 16:09:24 -0700
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <13e8e297-0b27-ac95-8fd4-e2a9b28d0b64@gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAFNqd5VpUE9OsKqfHDW8-76S46PYtnTJWDWAs0FU6o+73B4ZfQ@mail.gmail.com>
 <CAP2nic0_5vXCwSr8THcHfTxSEEWVkv2tvU1qheZusC7Qekh6zQ@mail.gmail.com>
 <016BFF16-C490-425D-8168-3D59DCCA6A21@ccc.com>
 <CAP2nic0GxgqRvz5z9vfRWXjo5-UpbNsut8S0F4vduYLw+a6-Sw@mail.gmail.com>
 <13e8e297-0b27-ac95-8fd4-e2a9b28d0b64@gmail.com>
Message-ID: <CAP2nic0tvnaiNpny9pap=DDr58iR-A+O=6rVBL21XWErS_RrTQ@mail.gmail.com>

This was pre-SLS as well.  I remember vividly how excited I was when it
came out in mid-92 and how much like cheating it was.  A little googling
and I'm sure I used the HJ Lu diskettes.  I don't actually remember
hand-editing the MBR but, well, I probably did.

Adam

On Wed, Aug 28, 2019 at 4:01 PM William Pechter <pechter at gmail.com> wrote:

> On 8/28/2019 6:48 PM, Adam Thornton wrote:
>
> It probably was the partition/slice confusion that, well, confused me,
> then.  My experience, such as it was, was from the DOS world.
>
> As was mine mostly 8-) I remember it from the PITA it was to translate in
> my head.  Unix folks looked at partitions as  /dev/dsk/0s0->0s7 (I think 7
> was the SVR2 maximum.  The "Unix" partitions fit inside the FDISK partition
> or dos slice... The dos guys looked at it kind of like the fdisk space
> disk0 partition 3 (for example) was the partition and then the BSD folks
> broke that in to /dev/sd0a /dev/sd0b /dev/sd0c etc.
>
> I did a little SunOS and SysV along with Dos and Windows and could make
> them coexist as long as there was an open primary dos partition.
>
>
>
> Although the period I am thinking of was way pre-slackware.  You had a
> boot floppy and a root floppy and that was about it, I think.  I think the
> kernel had MFM/RLL disk drivers for an ISA bus interface?  I remember that
> I could boot the thing on the MCA machines in the lab but not actually
> install it (even had I been allowed to), and I think installation was
> pretty much fdisk/mkfs, extract the tarball...I don't remember how you
> installed the bootloader...which I guess was already LILO at that point?
> Probably just dding the bootsector to the first physical sector of the
> disk?  Version 0.08 or so, maybe?
>
>
> Sounds like SLS -- Soft Landing System -- which later was pretty much
> replaced with Slackware.  I used the early MCA stuff on PS/2's at IBM for a
> while.  Most of the PS/2 stuff we had was SCSI.  The boot loader was lilo.
> It could go in the partition space or disk mbr.  See:
> https://www.ibm.com/developerworks/library/l-bootload/index.html
>
>
> It was quite a while ago, and I was drunk for most of college,
> so....memory is imprecise at best.
>
> On Wed, Aug 28, 2019 at 3:28 PM Clem cole <clemc at ccc.com> wrote:
>
>> Not true 386BSD used fdisk.  It shared the disk just fine.  In fact I
>> liked the way it sliced the disk much better than Slackware in those days.
>>
>> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not
>> quite.
>>
>> On Aug 28, 2019, at 4:27 PM, Adam Thornton <athornton at gmail.com> wrote:
>>
>> I was an ardent OS/2 supporter for a long time.  Sure, IBM's anemic
>> marketing, and their close-to-outright-hostility to 3rd-party developers
>> didn't help.  But what killed it, really, was how damn good its 16-bit
>> support was.  It *was* a better DOS than DOS and a better Windows than
>> 3.11fW.  So no one wrote to the relatively tiny market of 32-bit OS/2.
>>
>> I fear that had Linux not made the leap, MS might well have won.  It's
>> largely the AOL-fuelled explosion of popularity of the Internet and Windows
>> ignoring same until too late that opened the door enough for Linux to jam
>> its foot in.
>>
>> Hurd was, by the time of the '386 Unix Wars and early Linux, clearly not
>> going to be a contender, I guess because it was about cool research
>> features rather than running user-facing code.  I kept waiting for a usable
>> kernel to go with what Linux had already shown was a quite decent
>> userspace, but eventually had better things to do with my life (like chase
>> BeOS).  It was like waiting for Perl 6--it missed its moment.
>>
>> Plan 9 and Amoeba were both really nifty.    I never used Sprite.
>> Neither one of them had much of a chance in the real world.  Much like Unix
>> itself, Linux's worse-is-better approach really worked.
>>
>> I have a hypothesis about Linux's ascendance too, which is a personal
>> anecdote I am inflating to the status of hypothesis.  As I recall, the
>> *BSDs for 386 all assumed they owned the hard disk.  Like, the whole
>> thing.  You couldn't, at least in 1992, create a multiboot system--or at
>> least it was my strong impression you could not.  I was an undergrad.  I
>> had one '386 at my disposal, with one hard disk, and, hey, I needed DOS and
>> Windows to write my papers (I don't know about you, but I wanted to write
>> in my room, where I could have my references at hand and be reasonably
>> undisturbed; sure Framemaker was a much better setup than Word For Windows
>> 1.2 but having to use it in the computer lab made it a nonstarter for me).
>> Papers, and, well, to play games.  Sure, that too.
>>
>> Linux let me defragment my drive, non-destructively repartition it, and
>> create a dual-boot system, so that I could both use the computer for school
>> and screw around on Linux.  I'm probably not the only person for whom this
>> was a decisive factor.
>>
>> Adam
>>
>> On Wed, Aug 28, 2019 at 1:08 PM Christopher Browne <cbbrowne at gmail.com>
>> wrote:
>>
>>> On Mon, 26 Aug 2019 at 19:14, Arthur Krewat <krewat at kilonet.net> wrote:
>>>
>>>>
>>>> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel
>>>>
>>>> Leaving licensing and copyright issues out of this mental exercise,
>>>> what
>>>> would we have now if it wasn't for Linux? Not what you'd WANT it to be,
>>>> although that can add to the discussion, but what WOULD it be?
>>>>
>>>> I'm not asking as a proponent of Linux. If anything, I was dragged
>>>> kicking and screaming into the current day and have begrudgingly ceded
>>>> my server space to Linux.
>>>>
>>>> But if not for Linux, would it be BSD? A System V variant? Or (the
>>>> horror) Windows NT?
>>>>
>>>
>>> I can make a firm "dunno" sound :-)
>>>
>>> Some facts can come together to point away from a number of
>>> possibilities...
>>>
>>> - If you look at the number of hobbyist "Unix homages" that emerged at
>>> around that time, it's clear that there was a sizable community of
>>> interested folk willing to build their own thing, and that weren't
>>> interested in Windows NT.  (Nay, one should put that more strongly...  That
>>> had their minds set on something NOT from Microsoft.)  So I think we can
>>> cross Windows NT off the list.
>>>
>>> - OS/2 should briefly come on the list.  It was likable in many ways, if
>>> only IBM had actually supported it...  But it suffers from something of the
>>> same problem as Windows NT; there were a lot of folk that were only
>>> slightly less despising of IBM at the time than of Microsoft.
>>>
>>> - Hurd was imagined to be the next thing...
>>>
>>> To borrow from my cookie file...
>>>
>>> "Of course 5  years from now that will be different,  but 5 years from
>>> now  everyone  will  be  running  free  GNU on  their  200  MIPS,  64M
>>> SPARCstation-5."  -- Andrew Tanenbaum, 1992.
>>> %
>>> "You'll be  rid of most of us  when BSD-detox or GNU  comes out, which
>>> should happen in the next few months (yeah, right)." -- Richard Tobin,
>>> 1992. [BSD did follow within a year]
>>> %
>>> "I am aware of the benefits  of a micro kernel approach.  However, the
>>> fact remains  that Linux is  here, and GNU  isn't --- and  people have
>>> been working on Hurd for a lot longer than Linus has been working on
>>> Linux." -- Ted T'so, 1992.
>>>
>>> Ted has been on this thread, and should be amused (and slightly
>>> disturbed!) that his old statements are being held here and there, ready to
>>> trot out :-).
>>>
>>> In the absence of Linux, perhaps hackers would have flocked to Hurd, but
>>> there was enough going on that there was plenty of room for them to have
>>> done so anyways.
>>>
>>> I'm not sure what to blame on whatever happened post-1992, though I'd
>>> put some on Microsoft Research having taken the wind out of Mach's sails by
>>> hiring off a bunch of the relevant folk.  In order for Hurd to "make it,"
>>> Mach has to "make it," too, and it looked like they were depending on CMU
>>> to be behind that.  (I'm not sure I'm right about that; happy to hear a
>>> better story.)
>>>
>>> Anyway, Hurd *might* have been a "next thing," and I don't think the
>>> popularity of Linux was enough to have completely taken wind out of its
>>> sails, given that there's the dozens of "Unix homages" out there.
>>>
>>> - I'd like to imagine Plan 9 being an alternative, but it was "properly
>>> commercial" for a goodly long time (hence not amenable to attaching waves
>>> of hackers to it to add their favorite device drivers), and was never taken
>>> as a serious answer.  Many of us had admired it from afar via the Dr Dobbs
>>> Journal issue (when was that?  mid or late '90s?) but only from afar.
>>>
>>> - FreeBSD is the single best answer I can throw up as a possibility, as
>>> it was the one actively targeting 80386 hardware.  And that had the big
>>> risk of the AT&T lawsuit lurking over it, so had that gone in a different
>>> direction, then that is a branch sadly easily trimmed.
>>>
>>> If we lop both Linux and FreeBSD off the list of possibilities, I don't
>>> imagine Windows NT or OS/2 bubble to the top, instead, a critical mass
>>> would have stood behind ... something else, I'd think.  I don't know which
>>> to suggest.
>>> --
>>> When confronted by a difficult problem, solve it by reducing it to the
>>> question, "How would the Lone Ranger handle this?"
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190828/ff7386f2/attachment.html>

From tytso at mit.edu  Thu Aug 29 09:19:52 2019
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Wed, 28 Aug 2019 19:19:52 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CAFNqd5VpUE9OsKqfHDW8-76S46PYtnTJWDWAs0FU6o+73B4ZfQ@mail.gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAFNqd5VpUE9OsKqfHDW8-76S46PYtnTJWDWAs0FU6o+73B4ZfQ@mail.gmail.com>
Message-ID: <20190828231952.GA536@mit.edu>

On Wed, Aug 28, 2019 at 04:07:39PM -0400, Christopher Browne wrote:
> 
> - Hurd was imagined to be the next thing...
> 
> To borrow from my cookie file...
> 
> "I am aware of the benefits  of a micro kernel approach.  However, the
> fact remains  that Linux is  here, and GNU  isn't --- and  people have
> been working on Hurd for a lot longer than Linus has been working on
> Linux." -- Ted T'so, 1992.

That's "Ts'o" :-), and that quote wasn't my arguing that Hurd would be
the next thing.  It was people had been working on the Hurd for
*years* (starting 1984) and it still wasn't real.  If it wasn't going
to be real after eight years, another eighty probably wouldn't have
helped.

And a lot of this was because was because RMS was hard to work with,
and he was a purist.  Pretty much very *definition* of the perfect
should always be the enemy of the "good enough".

In fact, at one point Thomas Bushnell, one of the senior Hurd
developers pushed to have the Hurd switch to using BSD 4.4-Lite, and
Stallman refused[1].

   “RMS was a very strong believer, wrongly, I think, in a very greedy
   algorithm approach to code reuse issues,” Thomas Bushnell later
   remembered.

   “My first choice was to take the BSD 4.4-Lite release and make a
   kernel. I knew the code, I knew how to do it. It is now perfectly
   obvious to me that this would have succeeded splendidly and the
   world would be a very different place today. RMS wanted to work
   together with people from Berkeley on such an effort. Some of them
   were interested, but some seem to have been deliberately dragging
   their feet: and the reason now seems to be that they had the goal
   of spinning off BSDI. A GNU based on 4.4-Lite would undercut BSDI.”

   As Bushnell describes it, Stallman came to the conclusion that
   “Mach is a working kernel. 4.4-Lite is only partial. We will go
   with Mach.”

[1] https://web.archive.org/web/20121228225905/http://www.linuxuser.co.uk/features/whatever-happened-to-the-hurd-the-story-of-the-gnu-os


That's probably one of the other things that may have hampered BSD.
The BSD license made it easier (or at least made easier business
models) for monetizing BSD, and some of the most talented people went
off to make a buck off of BSD.  BSDI, Sun, NetApp, Wasabi Systems, etc.

Nothing wrong with that of course, and if people like Bill Joy were
able to make bank based on BSD, more power to them.  But it probably
removed from the leadership pool people who might have had better
leadership, and technical architect skills who might have led one of
the *BSD's to greater success.

The GPL makes it harder to monetize Linux --- although, as we've seen,
certainly not impossible --- and if you take a look at the most of the
senior technical people at Linux, none of us have made off as well as,
say, Bill Joy.  I'm still a working stiff, and don't have enough to
retire.  (That's OK; I'm perfectly happy being part of the 99%.  :-)

> Anyway, Hurd *might* have been a "next thing," and I don't think the
> popularity of Linux was enough to have completely taken wind out of its
> sails, given that there's the dozens of "Unix homages" out there.

Given who called the shots (and it wasn't the key people actually
doing most of the technical work, such as Bushnell) I actually think
it's not very likely Hurd could have succeeded.  RMS actually tried to
recruit me to work on the Hurd as well, and I refused, because of
project leadership concerns.  (Again, feel free to hate on Linus's
management style, but there were far worse ones in the open source OS
world at the time.)

					- Ted

From clemc at ccc.com  Thu Aug 29 10:11:51 2019
From: clemc at ccc.com (Clem cole)
Date: Wed, 28 Aug 2019 20:11:51 -0400
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <c0c10630-2711-0221-04d4-f291842b07a2@gmail.com>
References: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU>
 <CAKzdPgw_OJO6ehq4g=t_cqUw-Pqz_T6gn48uMDuyfpiQqNvOKw@mail.gmail.com>
 <CAKr6gn1ZHLerb4sODqYzMo8zi82gRAt6RnB3Wjtany8TdD15qg@mail.gmail.com>
 <c0c10630-2711-0221-04d4-f291842b07a2@gmail.com>
Message-ID: <D518A64C-3729-4205-9C2F-8F3E537F5E6F@ccc.com>

William That’s right. 4.1a supported at least these plus the original Xerox 3m card and I think a card MIT made for chaos and the protean card. iirc.  We had one of each of the production 10M Ethernet cards in the cad lab at UCB at some point.  The machine dec gave us had a dec card and that was the only dec card on campus so Sam would come over to my lab to test new OSses on that system.  UCB originally bought 3com cards (eventually in the cad group I got some early interlan cards from their ceo to test and I remember we liked them better for some reason I don’t remember). Before we had the 3COM based 10M link, we had couple of 3M Xerox cards on the original link back to Evans hall. 

The Xerox cards were used with the BBN tcp before 4.1a.  Eric cooper brought all that up with Sam and Bob Kriddle Iirc.  

That was all switched to the 3com cards pretty early to get 10M and Early after 4.1a and I do remember sam and I had used all that to debug Routed as we had the CAD Ethernet in Cory Hall, the back link to Evans and another Ethernet in the Evans machine room.  

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Aug 28, 2019, at 6:36 PM, William Pechter <pechter at gmail.com> wrote:
> 
> I could've sworn 4.x BSD supported Micom Internan NI1010 or some other early
> ethernet like 3com as well as the DEC boards.
> 
> Anyone have the 4.1 or 4.2 BSD docs handy.  Mine are boxed away for safe keeping.
> 
>> On 8/28/2019 6:29 PM, George Michaelson wrote:
>> This is an object lesson in not making assumptions about things. I had
>> always assumed the V in UNIX 32V stood for something which went to
>> demand paging, from 'Virtual Addressing'. Turns out: I was wrong.
>> 
>> One other note about sockets: The original 4.2 port had to be used by
>> a lot of people without the ethernet, because we didn't have the DEC
>> ethernet card it was written to. This made unix domain sockets very
>> interesting because you could test in them. Except: the very first
>> test program somebody wrote at Leeds university to create and write to
>> a unix domain socket in /tmp crashed the vax. ... (this was around
>> 1982/3) -We were warned off using sockets until the first patch tape
>> came in the post.
>> 
>> 
> 

From ggm at algebras.org  Thu Aug 29 10:18:36 2019
From: ggm at algebras.org (George Michaelson)
Date: Thu, 29 Aug 2019 10:18:36 +1000
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <D518A64C-3729-4205-9C2F-8F3E537F5E6F@ccc.com>
References: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU>
 <CAKzdPgw_OJO6ehq4g=t_cqUw-Pqz_T6gn48uMDuyfpiQqNvOKw@mail.gmail.com>
 <CAKr6gn1ZHLerb4sODqYzMo8zi82gRAt6RnB3Wjtany8TdD15qg@mail.gmail.com>
 <c0c10630-2711-0221-04d4-f291842b07a2@gmail.com>
 <D518A64C-3729-4205-9C2F-8F3E537F5E6F@ccc.com>
Message-ID: <CAKr6gn2outfbyGNZszOTT46Qve5C2raSfpnibBxzftzn7Uw3qw@mail.gmail.com>

I should add that in the UK the vaxes we run included "systime"
equipment: They got done for photocopying DEC boards and reselling
without licence fee, and for selling kit to the USSR.  They'd started
as a Vt100 seller. nice terminals.

Shame about the bad business practices. The headquarters was a
modernist building used for the BBC tv series "edge of darkness" and
did have the CEO's helicopter parked outside: he flew it when they
could afford the avgas.

-G

On Thu, Aug 29, 2019 at 10:12 AM Clem cole <clemc at ccc.com> wrote:
>
> William That’s right. 4.1a supported at least these plus the original Xerox 3m card and I think a card MIT made for chaos and the protean card. iirc.  We had one of each of the production 10M Ethernet cards in the cad lab at UCB at some point.  The machine dec gave us had a dec card and that was the only dec card on campus so Sam would come over to my lab to test new OSses on that system.  UCB originally bought 3com cards (eventually in the cad group I got some early interlan cards from their ceo to test and I remember we liked them better for some reason I don’t remember). Before we had the 3COM based 10M link, we had couple of 3M Xerox cards on the original link back to Evans hall.
>
> The Xerox cards were used with the BBN tcp before 4.1a.  Eric cooper brought all that up with Sam and Bob Kriddle Iirc.
>
> That was all switched to the 3com cards pretty early to get 10M and Early after 4.1a and I do remember sam and I had used all that to debug Routed as we had the CAD Ethernet in Cory Hall, the back link to Evans and another Ethernet in the Evans machine room.
>
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
>
> > On Aug 28, 2019, at 6:36 PM, William Pechter <pechter at gmail.com> wrote:
> >
> > I could've sworn 4.x BSD supported Micom Internan NI1010 or some other early
> > ethernet like 3com as well as the DEC boards.
> >
> > Anyone have the 4.1 or 4.2 BSD docs handy.  Mine are boxed away for safe keeping.
> >
> >> On 8/28/2019 6:29 PM, George Michaelson wrote:
> >> This is an object lesson in not making assumptions about things. I had
> >> always assumed the V in UNIX 32V stood for something which went to
> >> demand paging, from 'Virtual Addressing'. Turns out: I was wrong.
> >>
> >> One other note about sockets: The original 4.2 port had to be used by
> >> a lot of people without the ethernet, because we didn't have the DEC
> >> ethernet card it was written to. This made unix domain sockets very
> >> interesting because you could test in them. Except: the very first
> >> test program somebody wrote at Leeds university to create and write to
> >> a unix domain socket in /tmp crashed the vax. ... (this was around
> >> 1982/3) -We were warned off using sockets until the first patch tape
> >> came in the post.
> >>
> >>
> >

From ggm at algebras.org  Thu Aug 29 10:29:44 2019
From: ggm at algebras.org (George Michaelson)
Date: Thu, 29 Aug 2019 10:29:44 +1000
Subject: [TUHS] ISO, OSI, and DECnet (was Re: If not Linux, then what?)
In-Reply-To: <CACytpF-E3C+VrFSXat+jKWiCOToyoDB4b5n9Jj723H=qSgxDXg@mail.gmail.com>
References: <CABH=_VTKJQ-+0h-PwbNta1CAgtO=8quGV9RonWDP64MoteeG9Q@mail.gmail.com>
 <20190828172451.GX13570@mcvoy.com> <20190828181727.GA82704@wopr>
 <CACytpF-E3C+VrFSXat+jKWiCOToyoDB4b5n9Jj723H=qSgxDXg@mail.gmail.com>
Message-ID: <CAKr6gn2FQ0AQnZkDi+pyMve-wN6ugpkW-SLpStmJGQYV-dtm7g@mail.gmail.com>

SPDY and QUIC re-capitulate some ideas of the session layer. It is
ironic how many repudiated aspects of the OSI model are re-surfacing
inside IP centric networking.

-G

On Thu, Aug 29, 2019 at 5:29 AM SPC <spedraja at gmail.com> wrote:
>
> It's a bit funny (at least for me) because I was talking about DECNET as OSI standard and TCP/IP and OSI differences some days ago to the group of students of a course on network operation that I am teaching.
>
> On the other hand I don't that book about networking. I'd like to get one copy bit I live in Spain. Shipment is not a problem but perhaps to deal with shipping procedures abroad is not what you have in mind :-)
>
> Cordiales saludos / Best Regards / Salutations / Freundliche Grüße
> -----
> Sergio Pedraja
>
> Senior Technician in Computer Science, Systems Administration, and Information Security. MBA. Qualified occupational trainer.
>
> El mié., 28 ago. 2019 20:24, Kurt H Maier <khm at sciops.net> escribió:
>>
>> On Wed, Aug 28, 2019 at 10:24:51AM -0700, Larry McVoy wrote:
>> >
>> > The great Mike Padlipski said "do you want protocols that look nice or
>> > protocols that work nice?" in his fantastic book Elements of Networking
>> > Style [*].
>> >
>>
>> This book taught me as much about navigating bureaucracy and the warning
>> signs of impending death-by-committee as it did about networking.  I
>> keep a copy on my shelf at the office and annoy my staff with it
>> regularly.  It's also a wonderful time capsule that provides a lot of
>> context about how we got where we are.
>>
>> khm

From stewart at serissa.com  Thu Aug 29 13:24:20 2019
From: stewart at serissa.com (Lawrence Stewart)
Date: Wed, 28 Aug 2019 23:24:20 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CAC20D2PXT68vMCZ2eAOqbsakVKSk4t0gJY9+hpB1xma95AamiQ@mail.gmail.com>
References: <20190828063045.GE75146@server.rulingia.com>
 <fbc88cc2-b5ff-4da5-9c70-ae101686a09d@PU1APC01FT025.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NNsH_ijW2Bqic=vBW=Dt8xGfRs_gBHkNoXNjsv2KzyVQ@mail.gmail.com>
 <CAEdTPBckiN+FcTbUJST7vthc-_5AQLka5NDGxKkp8XUZJaxesg@mail.gmail.com>
 <20190828173228.GZ13570@mcvoy.com>
 <CAC20D2PXT68vMCZ2eAOqbsakVKSk4t0gJY9+hpB1xma95AamiQ@mail.gmail.com>
Message-ID: <E9F80356-73AB-473E-A9DE-8DE63836C393@serissa.com>


> On 2019, Aug 28, at 2:56 PM, Clem Cole <clemc at ccc.com> wrote:
> 
> 
> 
> On Wed, Aug 28, 2019 at 1:32 PM Larry McVoy <lm at mcvoy.com <mailto:lm at mcvoy.com>> wrote:
> Perhaps Clem can shed some light on why DEC did a MIPS machine? 
> I did not work for DEC at the time and obviously, I was not in the room, so this is what I can say I picked up.  Supnik would be a better person to ask.  That said, some things I do know about the time/and behinds the scene.
> Jupiter and Prism had been canceled. 
> Alpha did not yet exist (and would not for another 2 years)
> Cutler had left for Microsoft etc..
> Sun was clearly on its game
> The VAX on a Chip just was not cutting it
> RISC architectures were the hot item
> Here is where I get fuzzy on details.
> I believe a prototype (i.e. skunk works) MIPS was running at WRL in Palo Alto running Ultrix and DEC windows, I think using some sort of cheap ??PC?? chassis.
> But the performance of the prototype was excellent and cost was cheaper than the current vax products.
> Somebody sr, maybe Bob, shows this to Sr management and got the money to productize it.  The issue as making an official Ultrix for it was I know a big one.  Ultimately, DEC farmed that work out to us at LCC (with us eventually taking over all of Ultrix - MIPS and Vax).
I was at the Digital Systems Research Center in Palo Alto between 1984 and 1989.  Also located in Palo Alto were the Western Research Lab (run by Forest Baskett), Workstation Systems Engineering, and the West Coast Systems Lab.  Steve Bourne was at one of these.

All were within a few blocks of each other and easy walking distance to “Louis’” chinese restaurant, whose official name was “The Little Restaurant”.  The rule was that you could not go to Louis' for lunch if you had eaten lunch there the day before.  

At the time, SRC was building multiprocessor research workstations with VAX chips (the Firefly, I did some of the hardware) and WRL was building an ECL RISC machine (the Titan).   WSE was started, I think, to commercialize a multiprocessor VAX workstation something like the Firefly.  WSL was a software group working on window systems and things like multimedia software.

The WSE machines became the VAXStation 3520 and 3540, code named FireFox (showing the ancestry I guess!).
The folks at WSE, I think with egging on from WRL, who were in the same building, then built the R2000 based “PMAX” and then the R3000 based “3MAX”.  These were rather nice machines for 1990 and 1991.  They also invented a flat attaching I/O card format “TurboChannel”.  The impression I has was that the RS6000 and the PA-RISC and the various MIPS machines put a large scare into Digital.

I don’t know how the politics worked for this.  The west coast was a long long way from Maynard.

Larry

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

From stewart at serissa.com  Thu Aug 29 13:29:02 2019
From: stewart at serissa.com (Lawrence Stewart)
Date: Wed, 28 Aug 2019 23:29:02 -0400
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU>
References: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU>
Message-ID: <C8398AA7-8DE9-40AA-A208-000521A4A8C1@serissa.com>



> On 2019, Aug 28, at 1:57 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> 
> 
>> How long was research running on a PDP-11 and when did they move to a VAX?
> 
> London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research.
> 
> Doug

I’ve always been a little curious about how Reiser (John Reiser, not Hans!) came to port Unix.  I had heard of him from his PhD Dissertation which was something like 35 pages long for Knuth (!) on random number generators.  He finished at Stanford in 1977 and in 1978 he was porting Unix?  How did that happen?

-L


From lm at mcvoy.com  Thu Aug 29 14:10:11 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 28 Aug 2019 21:10:11 -0700
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <C8398AA7-8DE9-40AA-A208-000521A4A8C1@serissa.com>
References: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU>
 <C8398AA7-8DE9-40AA-A208-000521A4A8C1@serissa.com>
Message-ID: <20190829041011.GG10796@mcvoy.com>

On Wed, Aug 28, 2019 at 11:29:02PM -0400, Lawrence Stewart wrote:
> > On 2019, Aug 28, at 1:57 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> >> How long was research running on a PDP-11 and when did they move to a VAX?
> > 
> > London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research.
> > 
> > Doug
> 
> I???ve always been a little curious about how Reiser (John Reiser, not Hans!) came to port Unix.  I had heard of him from his PhD Dissertation which was something like 35 pages long for Knuth (!) on random number generators.  He finished at Stanford in 1977 and in 1978 he was porting Unix?  How did that happen?

I'm with Lawrence, I'd love to hear this.  This thread is the first I've
heard about John Reiser and London.  I don't remember anything about them
in the Bell Labs journals.

I can say it is not a stretch to go from school to porting, I did that.

School is amazing at making you feel like you can do anything.  I took
the grad compiler class, you could take one of them or two of them at
a time, my buddy Rob Netzer and I took two together and we wrote a 
big subset of the ADA language in a semester.

You slow down when you have to make a product that works in the face
of people doing silly (aka stupid) things.  Error checking is a thing,
compiler error messages that point to the exact problem are a much,
much bigger thing.  Gcc is very good at that, I've got a lot of respect
for gcc, I know how hard that is.

From wobblygong at gmail.com  Thu Aug 29 16:37:05 2019
From: wobblygong at gmail.com (Wesley Parish)
Date: Thu, 29 Aug 2019 18:37:05 +1200
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <13e8e297-0b27-ac95-8fd4-e2a9b28d0b64@gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAFNqd5VpUE9OsKqfHDW8-76S46PYtnTJWDWAs0FU6o+73B4ZfQ@mail.gmail.com>
 <CAP2nic0_5vXCwSr8THcHfTxSEEWVkv2tvU1qheZusC7Qekh6zQ@mail.gmail.com>
 <016BFF16-C490-425D-8168-3D59DCCA6A21@ccc.com>
 <CAP2nic0GxgqRvz5z9vfRWXjo5-UpbNsut8S0F4vduYLw+a6-Sw@mail.gmail.com>
 <13e8e297-0b27-ac95-8fd4-e2a9b28d0b64@gmail.com>
Message-ID: <CACNPpeZSm765TBpXxVbgY5bmH+BTcEt9gjzbVhkS_qR=CDFbuw@mail.gmail.com>

On 8/29/19, William Pechter <pechter at gmail.com> wrote:
> On 8/28/2019 6:48 PM, Adam Thornton wrote:
<snip>
>
>
>>
>> Although the period I am thinking of was way pre-slackware.  You had a
>> boot floppy and a root floppy and that was about it, I think.  I think
>> the kernel had MFM/RLL disk drivers for an ISA bus interface?  I
>> remember that I could boot the thing on the MCA machines in the lab
>> but not actually install it (even had I been allowed to), and I think
>> installation was pretty much fdisk/mkfs, extract the tarball...I don't
>> remember how you installed the bootloader...which I guess was already
>> LILO at that point? Probably just dding the bootsector to the first
>> physical sector of the disk?  Version 0.08 or so, maybe?
>>
>
> Sounds like SLS -- Soft Landing System -- which later was pretty much
> replaced with Slackware.  I used the early MCA stuff on PS/2's at IBM
> for a while.  Most of the PS/2 stuff we had was SCSI.  The boot loader
> was lilo.  It could go in the partition space or disk mbr.
> See:https://www.ibm.com/developerworks/library/l-bootload/index.html

FWLIW, you can get a copy of my installation of SLS at
https://sourceforge.net/projects/bochs/files/Disk%20Images/SLS%20Linux/

I included the floppy images so any time you can reinstall it or just
work on acquiring the joys of diskswapping as we knew it back then.
(It's one way to go crazy when you're tired, and get the fdisk/mkfs
stage wrong, or pick up the wrong disk or ... :)
>
>
<snip>

From arnold at skeeve.com  Thu Aug 29 16:43:10 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 29 Aug 2019 00:43:10 -0600
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <CAKzdPgwTMN1C-oKO-8D7UutVOOdvzgia=fsZrtGbeMZ13o79mg@mail.gmail.com>
References: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU>
 <CAKzdPgwTMN1C-oKO-8D7UutVOOdvzgia=fsZrtGbeMZ13o79mg@mail.gmail.com>
Message-ID: <201908290643.x7T6hAYc011290@freefriends.org>

Rob Pike <robpike at gmail.com> wrote:

> Reiser Unix got demand paging a little later, and it was spectacularly
> fast. I remember being gobsmacked when I saw a demo in early 1981.

So, once again, *W*H*Y* did Research choose BSD instead of Reiser's
version on the vax?

> Dead ends everywhere.

Explain please?

Thanks,

Arnold

From lars at nocrew.org  Thu Aug 29 16:27:34 2019
From: lars at nocrew.org (Lars Brinkhoff)
Date: Thu, 29 Aug 2019 06:27:34 +0000
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <D518A64C-3729-4205-9C2F-8F3E537F5E6F@ccc.com> (Clem cole's
 message of "Wed, 28 Aug 2019 20:11:51 -0400")
References: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU>
 <CAKzdPgw_OJO6ehq4g=t_cqUw-Pqz_T6gn48uMDuyfpiQqNvOKw@mail.gmail.com>
 <CAKr6gn1ZHLerb4sODqYzMo8zi82gRAt6RnB3Wjtany8TdD15qg@mail.gmail.com>
 <c0c10630-2711-0221-04d4-f291842b07a2@gmail.com>
 <D518A64C-3729-4205-9C2F-8F3E537F5E6F@ccc.com>
Message-ID: <7wa7bs8p0p.fsf@junk.nocrew.org>

Clem cole wrote:
> William That’s right. 4.1a supported at least these plus the original
> Xerox 3m card and I think a card MIT made for chaos

I would love to see 4.1a with Chaosnet support.  I have 4.1 patched with
MIT's Chaosnet software.

From robpike at gmail.com  Thu Aug 29 17:39:40 2019
From: robpike at gmail.com (Rob Pike)
Date: Thu, 29 Aug 2019 17:39:40 +1000
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <201908290643.x7T6hAYc011290@freefriends.org>
References: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU>
 <CAKzdPgwTMN1C-oKO-8D7UutVOOdvzgia=fsZrtGbeMZ13o79mg@mail.gmail.com>
 <201908290643.x7T6hAYc011290@freefriends.org>
Message-ID: <CAKzdPgzJbAmOM65c6QVOA0WvkmQrnuYRD3UdnzUqRnzfJjO2zg@mail.gmail.com>

It had paging already and there was affection by some towards Berkeley.

-rob


On Thu, Aug 29, 2019 at 4:45 PM <arnold at skeeve.com> wrote:

> Rob Pike <robpike at gmail.com> wrote:
>
> > Reiser Unix got demand paging a little later, and it was spectacularly
> > fast. I remember being gobsmacked when I saw a demo in early 1981.
>
> So, once again, *W*H*Y* did Research choose BSD instead of Reiser's
> version on the vax?
>
> > Dead ends everywhere.
>
> Explain please?
>
> Thanks,
>
> Arnold
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190829/da6dfaa1/attachment.html>

From dot at dotat.at  Thu Aug 29 21:12:38 2019
From: dot at dotat.at (Tony Finch)
Date: Thu, 29 Aug 2019 12:12:38 +0100
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CAP2nic0_5vXCwSr8THcHfTxSEEWVkv2tvU1qheZusC7Qekh6zQ@mail.gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAFNqd5VpUE9OsKqfHDW8-76S46PYtnTJWDWAs0FU6o+73B4ZfQ@mail.gmail.com>
 <CAP2nic0_5vXCwSr8THcHfTxSEEWVkv2tvU1qheZusC7Qekh6zQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1908291201580.5352@grey.csi.cam.ac.uk>

Adam Thornton <athornton at gmail.com> wrote:
>
> I fear that had Linux not made the leap, MS might well have won.  It's
> largely the AOL-fuelled explosion of popularity of the Internet and Windows
> ignoring same until too late that opened the door enough for Linux to jam
> its foot in.

I started work at Demon Internet in 1997. Its origins before 1992 were in
SCO / Xenix consultancy, but by the time I joined the ISP systems were
mostly flavours of BSD and Sun. My colleagues didn't think Linux was
sufficiently good at networking, and I got the impression that was a
relatively common opinion in ISP circles around 1995/6. That kind of
suggests to me that Unix would have been helped by the rise of the
Internet even without Linux...

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Shannon: Southwest 5 to 7, occasionally gale 8 for a time. Rough or very
rough. Rain. Good, becoming moderate or poor.

From dot at dotat.at  Thu Aug 29 20:55:11 2019
From: dot at dotat.at (Tony Finch)
Date: Thu, 29 Aug 2019 11:55:11 +0100
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <E9F80356-73AB-473E-A9DE-8DE63836C393@serissa.com>
References: <20190828063045.GE75146@server.rulingia.com>
 <fbc88cc2-b5ff-4da5-9c70-ae101686a09d@PU1APC01FT025.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NNsH_ijW2Bqic=vBW=Dt8xGfRs_gBHkNoXNjsv2KzyVQ@mail.gmail.com>
 <CAEdTPBckiN+FcTbUJST7vthc-_5AQLka5NDGxKkp8XUZJaxesg@mail.gmail.com>
 <20190828173228.GZ13570@mcvoy.com>
 <CAC20D2PXT68vMCZ2eAOqbsakVKSk4t0gJY9+hpB1xma95AamiQ@mail.gmail.com>
 <E9F80356-73AB-473E-A9DE-8DE63836C393@serissa.com>
Message-ID: <alpine.DEB.2.20.1908291151430.5352@grey.csi.cam.ac.uk>

Lawrence Stewart <stewart at serissa.com> wrote:
>
> At the time, SRC was building multiprocessor research workstations with
> VAX chips (the Firefly, I did some of the hardware) and WRL was building
> an ECL RISC machine (the Titan).

I've found a Titan System Manual from 1988
https://www.hpl.hp.com/techreports/Compaq-DEC/WRL-86-1.pdf

It's a curious machine with a number of unusual instruction set features -
an 8 bit CPU process ID hooked into the virtual memory system, register
banks selected using the processor status register - otherwise RISC
flavoured. Did it have any successors?

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
The Minch: Southwest 5 to 7, occasionally gale 8 for a time, decreasing 2 or 3
and becoming cyclonic later. Moderate or rough. Rain or showers. Moderate or
good, occasionally poor.

From a.phillip.garcia at gmail.com  Thu Aug 29 23:31:16 2019
From: a.phillip.garcia at gmail.com (A. P. Garcia)
Date: Thu, 29 Aug 2019 09:31:16 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <20190828231952.GA536@mit.edu>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAFNqd5VpUE9OsKqfHDW8-76S46PYtnTJWDWAs0FU6o+73B4ZfQ@mail.gmail.com>
 <20190828231952.GA536@mit.edu>
Message-ID: <CAFCBnZs5e3XLUtJVwpSDYZ4LApubKhejG71cRpEoSON6OYUD8w@mail.gmail.com>

On Wed, Aug 28, 2019 at 7:20 PM Theodore Y. Ts'o <tytso at mit.edu> wrote:

<snip>

> The GPL makes it harder to monetize Linux --- although, as we've seen,
> certainly not impossible --- and if you take a look at the most of the
> senior technical people at Linux, none of us have made off as well as,
> say, Bill Joy.  I'm still a working stiff, and don't have enough to
> retire.  (That's OK; I'm perfectly happy being part of the 99%.  :-)

<snip>

Case in point: https://jalopnik.com/the-founders-of-sun-microsystems-their-cars-and-their-5562572

I'm not making any judgments, good or bad. It is what it is.

From krewat at kilonet.net  Thu Aug 29 23:55:10 2019
From: krewat at kilonet.net (Arthur Krewat)
Date: Thu, 29 Aug 2019 09:55:10 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <CAFCBnZs5e3XLUtJVwpSDYZ4LApubKhejG71cRpEoSON6OYUD8w@mail.gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAFNqd5VpUE9OsKqfHDW8-76S46PYtnTJWDWAs0FU6o+73B4ZfQ@mail.gmail.com>
 <20190828231952.GA536@mit.edu>
 <CAFCBnZs5e3XLUtJVwpSDYZ4LApubKhejG71cRpEoSON6OYUD8w@mail.gmail.com>
Message-ID: <3173aba3-b6c3-43db-6374-b600f3217f13@kilonet.net>

On 8/29/2019 9:31 AM, A. P. Garcia wrote:
> On Wed, Aug 28, 2019 at 7:20 PM Theodore Y. Ts'o <tytso at mit.edu> wrote:
>
> <snip>
>
>> The GPL makes it harder to monetize Linux --- although, as we've seen,
>> certainly not impossible --- and if you take a look at the most of the
>> senior technical people at Linux, none of us have made off as well as,
>> say, Bill Joy.  I'm still a working stiff, and don't have enough to
>> retire.  (That's OK; I'm perfectly happy being part of the 99%.  :-)
> <snip>
>
> Case in point: https://jalopnik.com/the-founders-of-sun-microsystems-their-cars-and-their-5562572
>
> I'm not making any judgments, good or bad. It is what it is.
>
Except for the Ferrari (which would be around $160K in today's US 
dollars), the other three are pretty much bargain-basement sports cars ;)



From jsteve at superglobalmegacorp.com  Fri Aug 30 00:54:13 2019
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Thu, 29 Aug 2019 22:54:13 +0800
Subject: [TUHS] ISO, OSI, and DECnet (was Re: If not Linux, then what?)
In-Reply-To: <CACytpF-E3C+VrFSXat+jKWiCOToyoDB4b5n9Jj723H=qSgxDXg@mail.gmail.com>
References: <CABH=_VTKJQ-+0h-PwbNta1CAgtO=8quGV9RonWDP64MoteeG9Q@mail.gmail.com>
 <20190828172451.GX13570@mcvoy.com> <20190828181727.GA82704@wopr>
 <CACytpF-E3C+VrFSXat+jKWiCOToyoDB4b5n9Jj723H=qSgxDXg@mail.gmail.com>
Message-ID: <1d3d8c9a-7006-4666-b32e-8fa4fc5e9f7c@PU1APC01FT039.eop-APC01.prod.protection.outlook.com>

Although I never have seen OSI in the wild, it was the one great thing about ‘Winsock’ is that it worked over TCP/IP , IPX/SPX, AppletTalk and Decnet.  It was fun to convert a BBS from being telnet to some ‘telnet over decnet’ monster I built.

Although I’m guessing OSI would have allowed for common ‘network’ applications to use different network topologies?

I really need to get OSF/1 2.0 installed.


From: SPC
Sent: Thursday, August 29, 2019 3:30 AM
To: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] ISO, OSI, and DECnet (was Re: If not Linux, then what?)

It's a bit funny (at least for me) because I was talking about DECNET as OSI standard and TCP/IP and OSI differences some days ago to the group of students of a course on network operation that I am teaching.

On the other hand I don't that book about networking. I'd like to get one copy bit I live in Spain. Shipment is not a problem but perhaps to deal with shipping procedures abroad is not what you have in mind :-)
Cordiales saludos / Best Regards / Salutations / Freundliche Grüße
-----
Sergio Pedraja

Senior Technician in Computer Science, Systems Administration, and Information Security. MBA. Qualified occupational trainer.

El mié., 28 ago. 2019 20:24, Kurt H Maier <khm at sciops.net> escribió:
On Wed, Aug 28, 2019 at 10:24:51AM -0700, Larry McVoy wrote:
> 
> The great Mike Padlipski said "do you want protocols that look nice or
> protocols that work nice?" in his fantastic book Elements of Networking
> Style [*].
> 

This book taught me as much about navigating bureaucracy and the warning
signs of impending death-by-committee as it did about networking.  I
keep a copy on my shelf at the office and annoy my staff with it
regularly.  It's also a wonderful time capsule that provides a lot of
context about how we got where we are.

khm

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

From jsteve at superglobalmegacorp.com  Fri Aug 30 00:58:19 2019
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Thu, 29 Aug 2019 22:58:19 +0800
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <20190828190534.GH13570@mcvoy.com>
References: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU>
 <201908281849.x7SInUE1024803@freefriends.org>
 <93732314-1521-3118-47c0-5b973b7b926e@case.edu>
 <20190828190534.GH13570@mcvoy.com>
Message-ID: <02ae25cb-d3c4-477b-849d-3809070a343d@PU1APC01FT114.eop-APC01.prod.protection.outlook.com>

Yeah sockets, FFS, VM, autoconfiguration.  It almost seems a shame he went to SUN.  Although at the same time it’s no wonder why they grabbed him ASAP.  I guess it’s like Avie working for NeXT.

From: Larry McVoy
Sent: Thursday, August 29, 2019 3:06 AM
To: Chet Ramey
Cc: tuhs at tuhs.org; doug at cs.dartmouth.edu
Subject: Re: [TUHS] dmr streams & networking [was: Re: If not Linux,then what?]

On Wed, Aug 28, 2019 at 03:03:34PM -0400, Chet Ramey wrote:
> On 8/28/19 2:49 PM, arnold at skeeve.com wrote:
> 
> >> Sorry, what I said about London/Reiser is true, but not the whole
> >> story. L/R didn't have demand paging; BSD did.
> > 
> > But my question still stands. Why didn't Research keep going from L/R
> > and add demand paging?  Wouldn't that have been "cleaner" than starting
> > from BSD?
> 
> It's my impression that BSD had done other work that Research didn't want
> to duplicate, like autoconfiguration, device support, and so on. Joy got
> a lot out of the VAX hardware.

He was a coding machine back then.  Quite the legacy.

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

From thomas.paulsen at firemail.de  Fri Aug 30 01:54:48 2019
From: thomas.paulsen at firemail.de (Thomas Paulsen)
Date: Thu, 29 Aug 2019 17:54:48 +0200
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <3173aba3-b6c3-43db-6374-b600f3217f13@kilonet.net>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAFNqd5VpUE9OsKqfHDW8-76S46PYtnTJWDWAs0FU6o+73B4ZfQ@mail.gmail.com>
 <20190828231952.GA536@mit.edu>
 <CAFCBnZs5e3XLUtJVwpSDYZ4LApubKhejG71cRpEoSON6OYUD8w@mail.gmail.com>
 <3173aba3-b6c3-43db-6374-b600f3217f13@kilonet.net>
Message-ID: <004ec49789583b190ca7c302db9fbb31@firemail.de>


>: Arthur Krewat <krewat at kilonet.net>
> > <snip>
> Except for the Ferrari (which would be around $160K in today's US
> dollars), the other three are pretty much bargain-basement sports cars ;)
Today however not in the 80ths. Inn those days all 4 cars were Richie Rich cars.
>
>
>



From arnold at skeeve.com  Fri Aug 30 02:25:25 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 29 Aug 2019 10:25:25 -0600
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <02ae25cb-d3c4-477b-849d-3809070a343d@PU1APC01FT114.eop-APC01.prod.protection.outlook.com>
References: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU>
 <201908281849.x7SInUE1024803@freefriends.org>
 <93732314-1521-3118-47c0-5b973b7b926e@case.edu>
 <20190828190534.GH13570@mcvoy.com>
 <02ae25cb-d3c4-477b-849d-3809070a343d@PU1APC01FT114.eop-APC01.prod.protection.outlook.com>
Message-ID: <201908291625.x7TGPPG8030855@freefriends.org>

Let's get it straight. I think Kirk McKusick did the FFS. VM was done
by Somebody Babaglu (a greek? name - I know I'm not remembering it correctly.)
I guess Joy did sockets, but I don't know. I do know that he did the
csh and ex/vi.  I gather he was also in the kernel, but it wasn't all him.

BSD was not a one man show.

Arnold

Jason Stevens <jsteve at superglobalmegacorp.com> wrote:

> Yeah sockets, FFS, VM, autoconfiguration.  It almost seems a shame he
> went to SUN.  Although at the same time it’s no wonder why they grabbed
> him ASAP.  I guess it’s like Avie working for NeXT.
>
> From: Larry McVoy
> Sent: Thursday, August 29, 2019 3:06 AM
> To: Chet Ramey
> Cc: tuhs at tuhs.org; doug at cs.dartmouth.edu
> Subject: Re: [TUHS] dmr streams & networking [was: Re: If not Linux,then what?]
>
> On Wed, Aug 28, 2019 at 03:03:34PM -0400, Chet Ramey wrote:
> > On 8/28/19 2:49 PM, arnold at skeeve.com wrote:
> > 
> > >> Sorry, what I said about London/Reiser is true, but not the whole
> > >> story. L/R didn't have demand paging; BSD did.
> > > 
> > > But my question still stands. Why didn't Research keep going from L/R
> > > and add demand paging?  Wouldn't that have been "cleaner" than starting
> > > from BSD?
> > 
> > It's my impression that BSD had done other work that Research didn't want
> > to duplicate, like autoconfiguration, device support, and so on. Joy got
> > a lot out of the VAX hardware.
>
> He was a coding machine back then.  Quite the legacy.
>

From arnold at skeeve.com  Fri Aug 30 02:26:51 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 29 Aug 2019 10:26:51 -0600
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <CAKzdPgzJbAmOM65c6QVOA0WvkmQrnuYRD3UdnzUqRnzfJjO2zg@mail.gmail.com>
References: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU>
 <CAKzdPgwTMN1C-oKO-8D7UutVOOdvzgia=fsZrtGbeMZ13o79mg@mail.gmail.com>
 <201908290643.x7T6hAYc011290@freefriends.org>
 <CAKzdPgzJbAmOM65c6QVOA0WvkmQrnuYRD3UdnzUqRnzfJjO2zg@mail.gmail.com>
Message-ID: <201908291626.x7TGQpV4030895@freefriends.org>

Ah, OK.  Expedience + other considerations.

I don't suppose the Reiser 32V+paging survived anywhere?

Much thanks,

Arnold

Rob Pike <robpike at gmail.com> wrote:

> It had paging already and there was affection by some towards Berkeley.
>
> -rob
>
>
> On Thu, Aug 29, 2019 at 4:45 PM <arnold at skeeve.com> wrote:
>
> > Rob Pike <robpike at gmail.com> wrote:
> >
> > > Reiser Unix got demand paging a little later, and it was spectacularly
> > > fast. I remember being gobsmacked when I saw a demo in early 1981.
> >
> > So, once again, *W*H*Y* did Research choose BSD instead of Reiser's
> > version on the vax?
> >
> > > Dead ends everywhere.
> >
> > Explain please?
> >
> > Thanks,
> >
> > Arnold
> >

From ralph at inputplus.co.uk  Fri Aug 30 02:38:59 2019
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Thu, 29 Aug 2019 17:38:59 +0100
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <201908291625.x7TGPPG8030855@freefriends.org>
References: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU>
 <201908281849.x7SInUE1024803@freefriends.org>
 <93732314-1521-3118-47c0-5b973b7b926e@case.edu>
 <20190828190534.GH13570@mcvoy.com>
 <02ae25cb-d3c4-477b-849d-3809070a343d@PU1APC01FT114.eop-APC01.prod.protection.outlook.com>
 <201908291625.x7TGPPG8030855@freefriends.org>
Message-ID: <20190829163859.8ED2221301@orac.inputplus.co.uk>

Hi Arnold,

> VM was done by Somebody Babaglu (a greek? name - I know I'm not
> remembering it correctly.)

Özalp Babaoğlu, a Turkish name.
https://en.wikipedia.org/wiki/%C3%96zalp_Babao%C4%9Flu

-- 
Cheers, Ralph.

From arnold at skeeve.com  Fri Aug 30 03:35:48 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 29 Aug 2019 11:35:48 -0600
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <20190829163859.8ED2221301@orac.inputplus.co.uk>
References: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU>
 <201908281849.x7SInUE1024803@freefriends.org>
 <93732314-1521-3118-47c0-5b973b7b926e@case.edu>
 <20190828190534.GH13570@mcvoy.com>
 <02ae25cb-d3c4-477b-849d-3809070a343d@PU1APC01FT114.eop-APC01.prod.protection.outlook.com>
 <201908291625.x7TGPPG8030855@freefriends.org>
 <20190829163859.8ED2221301@orac.inputplus.co.uk>
Message-ID: <201908291735.x7THZmmt000452@freefriends.org>

Ralph Corderoy <ralph at inputplus.co.uk> wrote:

> Hi Arnold,
>
> > VM was done by Somebody Babaglu (a greek? name - I know I'm not
> > remembering it correctly.)
>
> Özalp Babaoğlu, a Turkish name.
> https://en.wikipedia.org/wiki/%C3%96zalp_Babao%C4%9Flu
>
> -- 
> Cheers, Ralph.

Much thanks. I knew I didn't have it right. :-)

Arnold

From cym224 at gmail.com  Fri Aug 30 04:40:07 2019
From: cym224 at gmail.com (Nemo Nusquam)
Date: Thu, 29 Aug 2019 14:40:07 -0400
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <283e3cc2-42ec-a554-602f-5fb67eca9e40@gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAFNqd5VpUE9OsKqfHDW8-76S46PYtnTJWDWAs0FU6o+73B4ZfQ@mail.gmail.com>
 <CAP2nic0_5vXCwSr8THcHfTxSEEWVkv2tvU1qheZusC7Qekh6zQ@mail.gmail.com>
 <283e3cc2-42ec-a554-602f-5fb67eca9e40@gmail.com>
Message-ID: <8cb953ef-ef6d-fdfa-76a4-1074cf46f598@gmail.com>


On 08/28/19 18:27, William Pechter wrote (in part):
> On 8/28/2019 4:27 PM, Adam Thornton wrote:
>> I was an ardent OS/2 supporter for a long time.  Sure, IBM's anemic 
>> marketing, and their close-to-outright-hostility to 3rd-party 
>> developers didn't help.  But what killed it, really, was how damn 
>> good its 16-bit support was.  It *was* a better DOS than DOS and a 
>> better Windows than 3.11fW.  So no one wrote to the relatively tiny 
>> market of 32-bit OS/2.
>>
> OS/2 was slick and if they could've kept the W\indows 3.x 
> compatibility (the Win32S was a sliding target that Microsoft kept 
> changing.  There was a pretty decent Unix work-alike ported to the top 
> of OS/2 that made most of the public domain and open source (the term 
> didn't exist yet) stuff available.
>
> I could telnet into the box and run a pretty slick Unix work-alike shell.
Indeed -- forgive my nostalgia here... We were developing a DOS-based 
PC-Card (often incorrectly called a PCMCIA card).  With OS/2, you opened 
up a DOS box. If the driver crashed, you just opened up another and went 
on.  Under Windoze, the whole box crashed (and sometimes took the 
file-system with it).  We used a combination of Eberhard Mattes' emx, 
the MKS toolkit, and case-sensitive file-systems to give us a reasonable 
approximation.

N.


From clemc at ccc.com  Fri Aug 30 05:15:24 2019
From: clemc at ccc.com (Clem Cole)
Date: Thu, 29 Aug 2019 15:15:24 -0400
Subject: [TUHS] ARS Technica on UNIX @ 50
Message-ID: <CAC20D2NEu4RAXzBm1F=gasb7gHKTQbyBtwU-8w9vyL4ArD-BVg@mail.gmail.com>

https://arstechnica.com/gadgets/2019/08/unix-at-50-it-starts-with-a-mainframe-a-gator-and-three-dedicated-researchers/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190829/acf77a5b/attachment.html>

From steffen at sdaoden.eu  Fri Aug 30 05:19:43 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Thu, 29 Aug 2019 21:19:43 +0200
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <004ec49789583b190ca7c302db9fbb31@firemail.de>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAFNqd5VpUE9OsKqfHDW8-76S46PYtnTJWDWAs0FU6o+73B4ZfQ@mail.gmail.com>
 <20190828231952.GA536@mit.edu>
 <CAFCBnZs5e3XLUtJVwpSDYZ4LApubKhejG71cRpEoSON6OYUD8w@mail.gmail.com>
 <3173aba3-b6c3-43db-6374-b600f3217f13@kilonet.net>
 <004ec49789583b190ca7c302db9fbb31@firemail.de>
Message-ID: <20190829191943.BfJ86%steffen@sdaoden.eu>

Thomas Paulsen wrote in <004ec49789583b190ca7c302db9fbb31 at firemail.de>:
 |>: Arthur Krewat <krewat at kilonet.net>
 |>> <snip>
 |> Except for the Ferrari (which would be around $160K in today's US
 |> dollars), the other three are pretty much bargain-basement sports cars ;)

 |Today however not in the 80ths. Inn those days all 4 cars were Richie \
 |Rich cars.

And only the Mazda had that wonderful smooth engine which replaces
pounding pistons with nice chuckling triangles.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From steffen at sdaoden.eu  Fri Aug 30 05:18:37 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Thu, 29 Aug 2019 21:18:37 +0200
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <8cb953ef-ef6d-fdfa-76a4-1074cf46f598@gmail.com>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAFNqd5VpUE9OsKqfHDW8-76S46PYtnTJWDWAs0FU6o+73B4ZfQ@mail.gmail.com>
 <CAP2nic0_5vXCwSr8THcHfTxSEEWVkv2tvU1qheZusC7Qekh6zQ@mail.gmail.com>
 <283e3cc2-42ec-a554-602f-5fb67eca9e40@gmail.com>
 <8cb953ef-ef6d-fdfa-76a4-1074cf46f598@gmail.com>
Message-ID: <20190829191837.JB08c%steffen@sdaoden.eu>

Nemo Nusquam wrote in <8cb953ef-ef6d-fdfa-76a4-1074cf46f598 at gmail.com>:
 |On 08/28/19 18:27, William Pechter wrote (in part):
 |> On 8/28/2019 4:27 PM, Adam Thornton wrote:
 |>> I was an ardent OS/2 supporter for a long time.  Sure, IBM's anemic 
 |>> marketing, and their close-to-outright-hostility to 3rd-party 
 |>> developers didn't help.  But what killed it, really, was how damn 
 |>> good its 16-bit support was.  It *was* a better DOS than DOS and a 
 |>> better Windows than 3.11fW.  So no one wrote to the relatively tiny 
 |>> market of 32-bit OS/2.
 |>>
 |> OS/2 was slick and if they could've kept the W\indows 3.x 
 |> compatibility (the Win32S was a sliding target that Microsoft kept 
 |> changing.  There was a pretty decent Unix work-alike ported to the top 
 |> of OS/2 that made most of the public domain and open source (the term 
 |> didn't exist yet) stuff available.
 |>
 |> I could telnet into the box and run a pretty slick Unix work-alike shell.

 |Indeed -- forgive my nostalgia here... We were developing a DOS-based 
 |PC-Card (often incorrectly called a PCMCIA card).  With OS/2, you opened 
 |up a DOS box. If the driver crashed, you just opened up another and went 
 |on.  Under Windoze, the whole box crashed (and sometimes took the 
 |file-system with it).  We used a combination of Eberhard Mattes' emx, 
 |the MKS toolkit, and case-sensitive file-systems to give us a reasonable 
 |approximation.

For a few holiday weeks i once worked in the IBM factory in Mainz
Germany in a hard disk production line clean room.  One of the
gauges were driven by OS/2 which not only catched my attention but
also crashed randomly up to several times per shift, causing
automatic reboots (reliably).  (The factory as such was not worth
it, it has been closed after fifty years, in the new Heiligkreuz
Viertel (holy-cross quarter) there have been build 242 flats and
a supermarket in the meantime.)

I liked 4DOS.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From steve at quintile.net  Fri Aug 30 06:56:21 2019
From: steve at quintile.net (Steve Simon)
Date: Thu, 29 Aug 2019 22:56:21 +0200
Subject: [TUHS] systime
Message-ID: <2C239CD2-B761-45F2-BF19-E66A4FD2B661@quintile.net>

wow, systime.

i went for a student placement there but didnt get it - i guess my long hair (then)  didn't fit as the interview seemed good.

i had a mate who was working late on the day the combined uk police and CIA (it was said) arrived to shut them down, and tell them they ARE being taken over by CDC. the crime was selling systime re-badged vaxes to the ussr at the height of the cold war. seem odd now that they thought they could get away with it.

exciting times.

-Steve



From athornton at gmail.com  Fri Aug 30 11:08:37 2019
From: athornton at gmail.com (Adam Thornton)
Date: Thu, 29 Aug 2019 18:08:37 -0700
Subject: [TUHS] ARS Technica on UNIX @ 50
In-Reply-To: <CAC20D2NEu4RAXzBm1F=gasb7gHKTQbyBtwU-8w9vyL4ArD-BVg@mail.gmail.com>
References: <CAC20D2NEu4RAXzBm1F=gasb7gHKTQbyBtwU-8w9vyL4ArD-BVg@mail.gmail.com>
Message-ID: <2248B8D1-DEA8-453A-88DA-DAE5BC46DBEA@gmail.com>



> On Aug 29, 2019, at 12:15 PM, Clem Cole <clemc at ccc.com> wrote:
> 
> https://arstechnica.com/gadgets/2019/08/unix-at-50-it-starts-with-a-mainframe-a-gator-and-three-dedicated-researchers/ <https://arstechnica.com/gadgets/2019/08/unix-at-50-it-starts-with-a-mainframe-a-gator-and-three-dedicated-researchers/>

I’m really glad they cited the interviews Mike Mahoney, RIP, did with a lot of the principal people in his Oral History Of Unix.  He was my thesis advisor.  I did not finish my thesis, but several times in the last few months (not all about Unix; as LSST construction approaches completion, there’s been some thought about how to make our project documentation useful for future historians of science) I’ve thought “Professor Mahoney would be interested in what I’m doing here.”

I’d recommend raising a glass to his memory.

Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190829/5a5183e3/attachment.html>

From lm at mcvoy.com  Fri Aug 30 11:32:24 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 29 Aug 2019 18:32:24 -0700
Subject: [TUHS] ARS Technica on UNIX @ 50
In-Reply-To: <2248B8D1-DEA8-453A-88DA-DAE5BC46DBEA@gmail.com>
References: <CAC20D2NEu4RAXzBm1F=gasb7gHKTQbyBtwU-8w9vyL4ArD-BVg@mail.gmail.com>
 <2248B8D1-DEA8-453A-88DA-DAE5BC46DBEA@gmail.com>
Message-ID: <20190830013224.GS10796@mcvoy.com>

I'm just watching this now, the MC is a died in the wool nerd, I love
him.  Great dude, gonna send him some stuff.

On Thu, Aug 29, 2019 at 06:08:37PM -0700, Adam Thornton wrote:
> 
> 
> > On Aug 29, 2019, at 12:15 PM, Clem Cole <clemc at ccc.com> wrote:
> > 
> > https://arstechnica.com/gadgets/2019/08/unix-at-50-it-starts-with-a-mainframe-a-gator-and-three-dedicated-researchers/ <https://arstechnica.com/gadgets/2019/08/unix-at-50-it-starts-with-a-mainframe-a-gator-and-three-dedicated-researchers/>
> 
> I???m really glad they cited the interviews Mike Mahoney, RIP, did with a lot of the principal people in his Oral History Of Unix.  He was my thesis advisor.  I did not finish my thesis, but several times in the last few months (not all about Unix; as LSST construction approaches completion, there???s been some thought about how to make our project documentation useful for future historians of science) I???ve thought ???Professor Mahoney would be interested in what I???m doing here.???
> 
> I???d recommend raising a glass to his memory.
> 
> Adam

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

From wobblygong at gmail.com  Fri Aug 30 19:32:21 2019
From: wobblygong at gmail.com (Wesley Parish)
Date: Fri, 30 Aug 2019 21:32:21 +1200
Subject: [TUHS] ISO, OSI, and DECnet (was Re: If not Linux, then what?)
In-Reply-To: <1d3d8c9a-7006-4666-b32e-8fa4fc5e9f7c@PU1APC01FT039.eop-APC01.prod.protection.outlook.com>
References: <CABH=_VTKJQ-+0h-PwbNta1CAgtO=8quGV9RonWDP64MoteeG9Q@mail.gmail.com>
 <20190828172451.GX13570@mcvoy.com> <20190828181727.GA82704@wopr>
 <CACytpF-E3C+VrFSXat+jKWiCOToyoDB4b5n9Jj723H=qSgxDXg@mail.gmail.com>
 <1d3d8c9a-7006-4666-b32e-8fa4fc5e9f7c@PU1APC01FT039.eop-APC01.prod.protection.outlook.com>
Message-ID: <CACNPpea_Vj5dYf3yzTPZT4jYBBgscVd1QD7TELeTD8DskugAzw@mail.gmail.com>

Well, fwiw, the Aeronautical Telecommunications Network (ATN) that was
being discussed in the late nineties and early noughties, was supposed
to be built on the OSI stack. I have no idea what happened with that,
whether it went ahead or got altered.

On 8/30/19, Jason Stevens <jsteve at superglobalmegacorp.com> wrote:
> Although I never have seen OSI in the wild, it was the one great thing about
> ‘Winsock’ is that it worked over TCP/IP , IPX/SPX, AppletTalk and Decnet.
> It was fun to convert a BBS from being telnet to some ‘telnet over decnet’
> monster I built.
>
> Although I’m guessing OSI would have allowed for common ‘network’
> applications to use different network topologies?
>
> I really need to get OSF/1 2.0 installed.
<snip>

From jnc at mercury.lcs.mit.edu  Fri Aug 30 22:57:39 2019
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 30 Aug 2019 08:57:39 -0400 (EDT)
Subject: [TUHS] systime
Message-ID: <20190830125739.9891418C0D3@mercury.lcs.mit.edu>

    > From: Steve Simon

    > i went for a student placement there but didnt get it - i guess my long
    > hair (then) didn't fit as the interview seemed good.

Maybe you seemed too honest! :-)

      Noel

From clemc at ccc.com  Fri Aug 30 23:59:08 2019
From: clemc at ccc.com (Clem Cole)
Date: Fri, 30 Aug 2019 09:59:08 -0400
Subject: [TUHS] ISO, OSI, and DECnet (was Re: If not Linux, then what?)
In-Reply-To: <CACNPpea_Vj5dYf3yzTPZT4jYBBgscVd1QD7TELeTD8DskugAzw@mail.gmail.com>
References: <CABH=_VTKJQ-+0h-PwbNta1CAgtO=8quGV9RonWDP64MoteeG9Q@mail.gmail.com>
 <20190828172451.GX13570@mcvoy.com> <20190828181727.GA82704@wopr>
 <CACytpF-E3C+VrFSXat+jKWiCOToyoDB4b5n9Jj723H=qSgxDXg@mail.gmail.com>
 <1d3d8c9a-7006-4666-b32e-8fa4fc5e9f7c@PU1APC01FT039.eop-APC01.prod.protection.outlook.com>
 <CACNPpea_Vj5dYf3yzTPZT4jYBBgscVd1QD7TELeTD8DskugAzw@mail.gmail.com>
Message-ID: <CAC20D2Mq-EMeK6nHP0BxuEFoGA69Rzes9BtX4=Xk_QJRnmbPtw@mail.gmail.com>

Besides DECnet, IIRC, in the USA the only semi-large (required) use of OSI
was for TOP [Technical Office Protocol] and MAP [manufacturing automation
protocol]  that GM and Boeing tried to ram down the industries virtual
throat.   At Masscomp, we had already built an OSI/X.25 interface for
Europe, but since I ran Datacom and these folks were definitely my target
customers for a real-time system, I had to listen to them.  I spent way too
many hours in GM and Boeing conference rooms dealing with it.   By memory,
the arguments for MAP over ethernet was the later was considered
'unpredictable', they claimed they all had to have fiber on the
manufacturing floor, and were convinced that TCP/IP had 'too much overhead'
for real-time automation.  I never really understood the justification of
why TOP was needed, other than there were a bunch of folks in both places
running DECnet and there was a huge level of NIH.

When I was at Masscomp, I don't think we ever sold many systems into GM.
But our stop-gap for Ford was to use Protean fiber-based boards on the
manufacturing floor and continued to run TCP on top it, and our traditional
Ethernet was just fine by them, "thank you."  Since Ford Aerospace was our
partner for building the new Mission Control at NASA (we ran redundant
ethernet there), they were already pretty familiar with our Ethernet and IP
stack products, so they took over working with the folks inside of Ford.
Shortly thereafter, Masscomp and Apollo won the bid for the Boeing 7J7
program (which became the 777 when it shipped).  The agreed (common)
interface between all three firms was Ethernet and IP.  [**]

I left for Stellar, but I don't think they ever built either the MAP/TOP or
any of the rest of the OSI stuff besides X.25, funny how they stopped
asking for it.  I still have a binder of all the TOP specs in my basement.






[**] An interesting factoid that I thought of while writing this reply.
One thing I learned from working with Boeing during that time is that until
that program, the C5A and the 747-400 were the only two airplanes that
could carry their documentation as a payload.  The paper required for the
FAA weighed that much.  One of the justifications of the 7J7 was they had
gotten approval from the FAA to make all of the documentation delivered
electronically.  It was the first plane they designed 100% using CAD and no
paper or other models.  Masscomp systems on the manufacturing floor, and
Apollo's in the engineering offices.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190830/e9c6c8d0/attachment.html>

From norman at oclsc.org  Sat Aug 31 05:50:14 2019
From: norman at oclsc.org (Norman Wilson)
Date: Fri, 30 Aug 2019 15:50:14 -0400
Subject: [TUHS] Running v10
Message-ID: <1567194618.21207.for-standards-violators@oclsc.org>

  Check out "Setting Up a Research UNIX System" by Norman Wilson. troff
  sources are in v10.

====

But that assumes you're being given a root image to copy
to the disk initially, no?  We never made a general-purpose
distribution tape; we just made one-off snapshots when someone
wanted a copy of the system in the 10/e era.

Is there a binary root image in Warren's archive?  I forget.

Norman Wilson
Toronto ON
(where the weather feels like NJ these days, dammit)

From aap at papnet.eu  Sat Aug 31 06:10:32 2019
From: aap at papnet.eu (Angelo Papenhoff)
Date: Fri, 30 Aug 2019 22:10:32 +0200
Subject: [TUHS] Running v10
In-Reply-To: <1567194618.21207.for-standards-violators@oclsc.org>
References: <1567194618.21207.for-standards-violators@oclsc.org>
Message-ID: <20190830201032.GA67899@indra.papnet.eu>

On 30/08/19, Norman Wilson wrote:
>   Check out "Setting Up a Research UNIX System" by Norman Wilson. troff
>   sources are in v10.
> 
> ====
> 
> But that assumes you're being given a root image to copy
> to the disk initially, no?  We never made a general-purpose
> distribution tape; we just made one-off snapshots when someone
> wanted a copy of the system in the 10/e era.
> 
> Is there a binary root image in Warren's archive?  I forget.

No we don't. Our hope would be to compile things from source and
bootstrap it from v8. I don't know the state of v9, I've seen it
emulated on a sun but if this helps with bootstrapping v10...
We also have sources for Doug's IX in history/ix...maybe that helps too
in some ways.
Or maybe someone who still has v10 running can help out.
I'd really like to see it running, wouldn't it be fitting for the 50th
anniversary?

aap

From norman at oclsc.org  Sat Aug 31 06:21:47 2019
From: norman at oclsc.org (Norman Wilson)
Date: Fri, 30 Aug 2019 16:21:47 -0400
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
Message-ID: <1567196510.21824.for-standards-violators@oclsc.org>

John Reiser did do his own paging system for UNIX 32/V.
I heard about it from friends at Bell Labs ca. 1982-83,
when I was still running systems for physicists at Caltech.
It sounded very interesting, and I would love to have had
my hands on it--page cache unified with buffer cache,
copy-on-write from the start.

The trouble is that Reiser worked in a different group
from the original UNIX crowd, and his management didn't
think his time well spent on that work, so it never got
released.

I remember asking, either during my interview at the Labs
or after I started work there, why the 4.1 kernel had been
chosen instead of Reiser's.  It had to do with maintainability:
there were already people who could come in and hack on the
Berkeley system, as well as more using it and maintaining it,
whereas Reiser's system had become a unicorn.  Nobody in
1127 wanted to maintain a VM system or anything much close
to the VAX hardware.  So the decision was to stick with a
kernel for which someone else would do those things.

Once I'd been there for a year or so and settled in, I found
that I was actually looking after all that stuff, because I
was really interested in it.  (Which seemed to delight a lot
of people.)  Would we have ended up using Reiser's kernel had
I been there a couple of years earlier?  I don't know.

It is in any case a shame that jfr's code never saw the light
of day.  I really hope someone can find it on an old tape
somewhere and we can get it into the archive, if only because
I'd love to look at it.

Norman Wilson
Toronto ON

From lm at mcvoy.com  Sat Aug 31 06:28:14 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 30 Aug 2019 13:28:14 -0700
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <1567196510.21824.for-standards-violators@oclsc.org>
References: <1567196510.21824.for-standards-violators@oclsc.org>
Message-ID: <20190830202814.GF10796@mcvoy.com>

On Fri, Aug 30, 2019 at 04:21:47PM -0400, Norman Wilson wrote:
> John Reiser did do his own paging system for UNIX 32/V.
> I heard about it from friends at Bell Labs ca. 1982-83,
> when I was still running systems for physicists at Caltech.
> It sounded very interesting, and I would love to have had
> my hands on it--page cache unified with buffer cache,
> copy-on-write from the start.

Huh, Moran published his SunOS VM system paper in 1988, my guess is he
was working on the code for a year or two before that.  So Reiser's work
predates that.  Super interesting.  I too would love for someone to find
a copy of that code.

From clemc at ccc.com  Sat Aug 31 06:39:09 2019
From: clemc at ccc.com (Clem Cole)
Date: Fri, 30 Aug 2019 16:39:09 -0400
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <1567196510.21824.for-standards-violators@oclsc.org>
References: <1567196510.21824.for-standards-violators@oclsc.org>
Message-ID: <CAC20D2OJ=uNZ0yMwpL13TPPW_q9tJeY6559gwsDGUYVkUin+TA@mail.gmail.com>

On Fri, Aug 30, 2019 at 4:22 PM Norman Wilson <norman at oclsc.org> wrote:

> It had to do with maintainability:
> there were already people who could come in and hack on the
> Berkeley system, as well as more using it and maintaining it,
> whereas Reiser's system had become a unicorn.  Nobody in
> 1127 wanted to maintain a VM system or anything much close
> to the VAX hardware.  So the decision was to stick with a
> kernel for which someone else would do those things.


Norman, I suspect the folks in 1127 was really not different the CS-Dept at
UCB in fact.  The whole reason CSRG wound down (and that was before wnj
left BTW) is the project stopped being research and started to have a
maintainence flavor which a lot of people found distasteful.

Funny, one of the things that I think made BSD the most useful, and *really
where wnj made his contribution IMO,* was the all the 'completors' between
things like the #ifdef FAST_VAX work and autoconfiguration, all the new
device support, *etc*.  That was a huge amount of work not very sexy work
that made 4.1BSD in particular, 'just work'   I had had the out-of-box
experience with all of V5 in RK05s, V6 and V7 on 9-track tape, earlier.
 4.1BSD was a dream, really not much to do but role the tape and answer
questions.

I can see why people liked that.    I remember a lot of people complaining
about the BSD VM system, but it worked 'good enough.'  I can tell you when
we did the Masscomp system (and the first thing I worked on was the VM
system with tjt), even thought we had started with a System III kernel
(that was our license), we pulled Joy's code in for the VM pretty early.
The first thing Tom and I did is made it 'MP-safe' (big lock scheme to be
honest) but we were interested in debugging the locking code, not the VM
system.  It's true when we did Stellar and had V.3, we used the AT&T VM
base by that point and started over, used a fine grain locking model
etc...., but by we knew how to make a MP UNIX box by then (remember the
MC-500/DP was the first MP Unix >>product<< -- predates our friends in on
the West coast by 2 years).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190830/0f6d83fe/attachment.html>

From lm at mcvoy.com  Sat Aug 31 07:52:02 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 30 Aug 2019 14:52:02 -0700
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <CAC20D2OJ=uNZ0yMwpL13TPPW_q9tJeY6559gwsDGUYVkUin+TA@mail.gmail.com>
References: <1567196510.21824.for-standards-violators@oclsc.org>
 <CAC20D2OJ=uNZ0yMwpL13TPPW_q9tJeY6559gwsDGUYVkUin+TA@mail.gmail.com>
Message-ID: <20190830215202.GA974@mcvoy.com>

On Fri, Aug 30, 2019 at 04:39:09PM -0400, Clem Cole wrote:
> MC-500/DP was the first MP Unix >>product<< -- predates our friends in on
> the West coast by 2 years).

And as I recall you had to do 2 68000's in lockstep to get the VM system
to do page fault restarts.  That was neat, was that a Masscomp invention
or was it a commonly known trick?

--lm

From clemc at ccc.com  Sat Aug 31 10:58:13 2019
From: clemc at ccc.com (Clem Cole)
Date: Fri, 30 Aug 2019 20:58:13 -0400
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <20190830215202.GA974@mcvoy.com>
References: <1567196510.21824.for-standards-violators@oclsc.org>
 <CAC20D2OJ=uNZ0yMwpL13TPPW_q9tJeY6559gwsDGUYVkUin+TA@mail.gmail.com>
 <20190830215202.GA974@mcvoy.com>
Message-ID: <CAC20D2Pp5hpZraaANsXg0Sgc-sU3fJ4=_N17ogQii3=p-H4Oeg@mail.gmail.com>

Actually not in lock step.  They were independent.  One was called the
executor and the other the fixer.  When a fault was detected the executor
was sent wait stated while the fixer handled the fault and refilled the
TLB.   Once the TLB was set to instruction was allowed to complete.    Btw
when the 68010 was released the pals on the board were changed to allow the
executor to actually take the fault and do something else while the fixer
replaced the TLB entry

The idea was proposed by Forest Baskett at an early Asilomar conference but
never built by him - I want to say 1980 or 81.    I have lost that paper
and would love to find a copy again BTW.    To be fair both Apollo and
Masscomp’s hw teams reduced the idea to practice independently but I know
of no other folks that tried it.

On Fri, Aug 30, 2019 at 5:52 PM Larry McVoy <lm at mcvoy.com> wrote:

> On Fri, Aug 30, 2019 at 04:39:09PM -0400, Clem Cole wrote:
> > MC-500/DP was the first MP Unix >>product<< -- predates our friends in on
> > the West coast by 2 years).
>
> And as I recall you had to do 2 68000's in lockstep to get the VM system
> to do page fault restarts.  That was neat, was that a Masscomp invention
> or was it a commonly known trick?
>
> --lm
>
-- 
Sent from a handheld expect more typos than usual
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190830/b6d871d8/attachment.html>

From bakul at bitblocks.com  Sat Aug 31 11:13:52 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Fri, 30 Aug 2019 18:13:52 -0700
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: Your message of "Fri, 30 Aug 2019 20:58:13 -0400."
 <CAC20D2Pp5hpZraaANsXg0Sgc-sU3fJ4=_N17ogQii3=p-H4Oeg@mail.gmail.com>
References: <1567196510.21824.for-standards-violators@oclsc.org>
 <CAC20D2OJ=uNZ0yMwpL13TPPW_q9tJeY6559gwsDGUYVkUin+TA@mail.gmail.com>
 <20190830215202.GA974@mcvoy.com>
 <CAC20D2Pp5hpZraaANsXg0Sgc-sU3fJ4=_N17ogQii3=p-H4Oeg@mail.gmail.com>
Message-ID: <20190831011359.E9F491570CE9@mail.bitblocks.com>

On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc at ccc.com> wrote:
>
> Actually not in lock step.  They were independent.  One was called the
> executor and the other the fixer.  When a fault was detected the executor
> was sent wait stated while the fixer handled the fault and refilled the
> TLB.   Once the TLB was set to instruction was allowed to complete.    Btw
> when the 68010 was released the pals on the board were changed to allow the
> executor to actually take the fault and do something else while the fixer
> replaced the TLB entry

As I remember, the issue with 68000 was that instructions were
not restartable so in case of accessing memory that didn't
exist, you couldn't take a segfault and do anything useful.
This is why you needed a second processor to deal with an
external MMU. There would have been no TLB unless you actually
added an external TLB -- but an external CAM would've been
very expensive. May be a direct map?

What we did at Fortune was to utilize a 4 entry external map:
text, data, extra and stack.  When a new function was invoked
it would do a 'probe'. If the probe caused a segfault, stack
was extended in the handler. The probe didn't have to be
restartable. So we didn't need a second 68k. This logic may
have been in the V7 port we started from.

From dave at horsfall.org  Sat Aug 31 11:35:46 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 31 Aug 2019 11:35:46 +1000 (EST)
Subject: [TUHS] If not Linux, then what?
In-Reply-To: <20190829191943.BfJ86%steffen@sdaoden.eu>
References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net>
 <CAFNqd5VpUE9OsKqfHDW8-76S46PYtnTJWDWAs0FU6o+73B4ZfQ@mail.gmail.com>
 <20190828231952.GA536@mit.edu>
 <CAFCBnZs5e3XLUtJVwpSDYZ4LApubKhejG71cRpEoSON6OYUD8w@mail.gmail.com>
 <3173aba3-b6c3-43db-6374-b600f3217f13@kilonet.net>
 <004ec49789583b190ca7c302db9fbb31@firemail.de>
 <20190829191943.BfJ86%steffen@sdaoden.eu>
Message-ID: <alpine.BSF.2.21.9999.1908311134050.37360@aneurin.horsfall.org>

On Thu, 29 Aug 2019, Steffen Nurpmeso wrote:

> |Today however not in the 80ths. Inn those days all 4 cars were Richie \
> |Rich cars.
>
> And only the Mazda had that wonderful smooth engine which replaces
> pounding pistons with nice chuckling triangles.

[ Getting OT... ]

Too bad about the seals, though...  They had this habit of wearing out.

-- Dave

From clemc at ccc.com  Sat Aug 31 12:46:57 2019
From: clemc at ccc.com (Clem cole)
Date: Fri, 30 Aug 2019 22:46:57 -0400
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <20190831011359.E9F491570CE9@mail.bitblocks.com>
References: <1567196510.21824.for-standards-violators@oclsc.org>
 <CAC20D2OJ=uNZ0yMwpL13TPPW_q9tJeY6559gwsDGUYVkUin+TA@mail.gmail.com>
 <20190830215202.GA974@mcvoy.com>
 <CAC20D2Pp5hpZraaANsXg0Sgc-sU3fJ4=_N17ogQii3=p-H4Oeg@mail.gmail.com>
 <20190831011359.E9F491570CE9@mail.bitblocks.com>
Message-ID: <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com>

There was most definitely a TLB or as Dave called it ‘The TB’ ***
Remember Dave Cane (Masscomp hw lead) was part of the 780, led the 750 and designed the BI before he left dec.  He was a bus and memory specialist 


*** west coast VS east coast training - calling it a TB vs a TLB.  

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Aug 30, 2019, at 9:13 PM, Bakul Shah <bakul at bitblocks.com> wrote:
> 
>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc at ccc.com> wrote:
>> 
>> Actually not in lock step.  They were independent.  One was called the
>> executor and the other the fixer.  When a fault was detected the executor
>> was sent wait stated while the fixer handled the fault and refilled the
>> TLB.   Once the TLB was set to instruction was allowed to complete.    Btw
>> when the 68010 was released the pals on the board were changed to allow the
>> executor to actually take the fault and do something else while the fixer
>> replaced the TLB entry
> 
> As I remember, the issue with 68000 was that instructions were
> not restartable so in case of accessing memory that didn't
> exist, you couldn't take a segfault and do anything useful.
> This is why you needed a second processor to deal with an
> external MMU. There would have been no TLB unless you actually
> added an external TLB -- but an external CAM would've been
> very expensive. May be a direct map?
> 
> What we did at Fortune was to utilize a 4 entry external map:
> text, data, extra and stack.  When a new function was invoked
> it would do a 'probe'. If the probe caused a segfault, stack
> was extended in the handler. The probe didn't have to be
> restartable. So we didn't need a second 68k. This logic may
> have been in the V7 port we started from.

From clemc at ccc.com  Sat Aug 31 12:57:22 2019
From: clemc at ccc.com (Clem cole)
Date: Fri, 30 Aug 2019 22:57:22 -0400
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com>
References: <1567196510.21824.for-standards-violators@oclsc.org>
 <CAC20D2OJ=uNZ0yMwpL13TPPW_q9tJeY6559gwsDGUYVkUin+TA@mail.gmail.com>
 <20190830215202.GA974@mcvoy.com>
 <CAC20D2Pp5hpZraaANsXg0Sgc-sU3fJ4=_N17ogQii3=p-H4Oeg@mail.gmail.com>
 <20190831011359.E9F491570CE9@mail.bitblocks.com>
 <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com>
Message-ID: <E829BD14-88B7-4469-A1A4-7849BC87CB67@ccc.com>

Btw. The issue with the 68k was Nick Tredenick’s original Microcode did not save enough information during some of the faults.  Les Crudele once told me, that it turns out he had tried to fix it but there were a series of errors and some short cuts they used to fit it in the store.  They gave up trying to fix it as the part was purely skunkworks and they could not respin it at the time.  After it succeeded and were a real project, the difference between the original and the 10 was Nick redid the microcode but they had made a larger microstore - otherwise basically the same Si.    

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Aug 30, 2019, at 10:46 PM, Clem cole <clemc at ccc.com> wrote:
> 
> There was most definitely a TLB or as Dave called it ‘The TB’ ***
> Remember Dave Cane (Masscomp hw lead) was part of the 780, led the 750 and designed the BI before he left dec.  He was a bus and memory specialist 
> 
> 
> *** west coast VS east coast training - calling it a TB vs a TLB.  
> 
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
> 
>>> On Aug 30, 2019, at 9:13 PM, Bakul Shah <bakul at bitblocks.com> wrote:
>>> 
>>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc at ccc.com> wrote:
>>> 
>>> Actually not in lock step.  They were independent.  One was called the
>>> executor and the other the fixer.  When a fault was detected the executor
>>> was sent wait stated while the fixer handled the fault and refilled the
>>> TLB.   Once the TLB was set to instruction was allowed to complete.    Btw
>>> when the 68010 was released the pals on the board were changed to allow the
>>> executor to actually take the fault and do something else while the fixer
>>> replaced the TLB entry
>> 
>> As I remember, the issue with 68000 was that instructions were
>> not restartable so in case of accessing memory that didn't
>> exist, you couldn't take a segfault and do anything useful.
>> This is why you needed a second processor to deal with an
>> external MMU. There would have been no TLB unless you actually
>> added an external TLB -- but an external CAM would've been
>> very expensive. May be a direct map?
>> 
>> What we did at Fortune was to utilize a 4 entry external map:
>> text, data, extra and stack.  When a new function was invoked
>> it would do a 'probe'. If the probe caused a segfault, stack
>> was extended in the handler. The probe didn't have to be
>> restartable. So we didn't need a second 68k. This logic may
>> have been in the V7 port we started from.

From gregg.drwho8 at gmail.com  Sat Aug 31 13:14:29 2019
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Fri, 30 Aug 2019 23:14:29 -0400
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <E829BD14-88B7-4469-A1A4-7849BC87CB67@ccc.com>
References: <1567196510.21824.for-standards-violators@oclsc.org>
 <CAC20D2OJ=uNZ0yMwpL13TPPW_q9tJeY6559gwsDGUYVkUin+TA@mail.gmail.com>
 <20190830215202.GA974@mcvoy.com>
 <CAC20D2Pp5hpZraaANsXg0Sgc-sU3fJ4=_N17ogQii3=p-H4Oeg@mail.gmail.com>
 <20190831011359.E9F491570CE9@mail.bitblocks.com>
 <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com>
 <E829BD14-88B7-4469-A1A4-7849BC87CB67@ccc.com>
Message-ID: <CAC5iaNEv2FXeU-w1OqRcH4-u6cKTn99_0T4i9eUAJxBG=w+bYg@mail.gmail.com>

Hello!
That definitely groks with a decidedly thirty year old memory. I
remember going to BUSCON, and getting into an interesting discussion
with the folks behind the M68K just how difficult it could be to run
more modern code (or operating systems). Let's just say it was
peculiar. They wanted to stick with a proprietary OS, and one odd man
there wanted to expand CPM-68K. And still another was looking into
bringing up UNIX on it.

It was fun.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."

On Fri, Aug 30, 2019 at 10:58 PM Clem cole <clemc at ccc.com> wrote:
>
> Btw. The issue with the 68k was Nick Tredenick’s original Microcode did not save enough information during some of the faults.  Les Crudele once told me, that it turns out he had tried to fix it but there were a series of errors and some short cuts they used to fit it in the store.  They gave up trying to fix it as the part was purely skunkworks and they could not respin it at the time.  After it succeeded and were a real project, the difference between the original and the 10 was Nick redid the microcode but they had made a larger microstore - otherwise basically the same Si.
>
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
>
> > On Aug 30, 2019, at 10:46 PM, Clem cole <clemc at ccc.com> wrote:
> >
> > There was most definitely a TLB or as Dave called it ‘The TB’ ***
> > Remember Dave Cane (Masscomp hw lead) was part of the 780, led the 750 and designed the BI before he left dec.  He was a bus and memory specialist
> >
> >
> > *** west coast VS east coast training - calling it a TB vs a TLB.
> >
> > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
> >
> >>> On Aug 30, 2019, at 9:13 PM, Bakul Shah <bakul at bitblocks.com> wrote:
> >>>
> >>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc at ccc.com> wrote:
> >>>
> >>> Actually not in lock step.  They were independent.  One was called the
> >>> executor and the other the fixer.  When a fault was detected the executor
> >>> was sent wait stated while the fixer handled the fault and refilled the
> >>> TLB.   Once the TLB was set to instruction was allowed to complete.    Btw
> >>> when the 68010 was released the pals on the board were changed to allow the
> >>> executor to actually take the fault and do something else while the fixer
> >>> replaced the TLB entry
> >>
> >> As I remember, the issue with 68000 was that instructions were
> >> not restartable so in case of accessing memory that didn't
> >> exist, you couldn't take a segfault and do anything useful.
> >> This is why you needed a second processor to deal with an
> >> external MMU. There would have been no TLB unless you actually
> >> added an external TLB -- but an external CAM would've been
> >> very expensive. May be a direct map?
> >>
> >> What we did at Fortune was to utilize a 4 entry external map:
> >> text, data, extra and stack.  When a new function was invoked
> >> it would do a 'probe'. If the probe caused a segfault, stack
> >> was extended in the handler. The probe didn't have to be
> >> restartable. So we didn't need a second 68k. This logic may
> >> have been in the V7 port we started from.

From bakul at bitblocks.com  Sat Aug 31 13:19:04 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Fri, 30 Aug 2019 20:19:04 -0700
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com>
References: <1567196510.21824.for-standards-violators@oclsc.org>
 <CAC20D2OJ=uNZ0yMwpL13TPPW_q9tJeY6559gwsDGUYVkUin+TA@mail.gmail.com>
 <20190830215202.GA974@mcvoy.com>
 <CAC20D2Pp5hpZraaANsXg0Sgc-sU3fJ4=_N17ogQii3=p-H4Oeg@mail.gmail.com>
 <20190831011359.E9F491570CE9@mail.bitblocks.com>
 <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com>
Message-ID: <8BFD5926-B916-4AA2-A896-4BA9E5AFDB69@bitblocks.com>

It would be interesting to see its MMU details.

> On Aug 30, 2019, at 7:46 PM, Clem cole <clemc at ccc.com> wrote:
> 
> There was most definitely a TLB or as Dave called it ‘The TB’ ***
> Remember Dave Cane (Masscomp hw lead) was part of the 780, led the 750 and designed the BI before he left dec.  He was a bus and memory specialist 
> 
> 
> *** west coast VS east coast training - calling it a TB vs a TLB.  
> 
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
> 
>> On Aug 30, 2019, at 9:13 PM, Bakul Shah <bakul at bitblocks.com> wrote:
>> 
>>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc at ccc.com> wrote:
>>> 
>>> Actually not in lock step.  They were independent.  One was called the
>>> executor and the other the fixer.  When a fault was detected the executor
>>> was sent wait stated while the fixer handled the fault and refilled the
>>> TLB.   Once the TLB was set to instruction was allowed to complete.    Btw
>>> when the 68010 was released the pals on the board were changed to allow the
>>> executor to actually take the fault and do something else while the fixer
>>> replaced the TLB entry
>> 
>> As I remember, the issue with 68000 was that instructions were
>> not restartable so in case of accessing memory that didn't
>> exist, you couldn't take a segfault and do anything useful.
>> This is why you needed a second processor to deal with an
>> external MMU. There would have been no TLB unless you actually
>> added an external TLB -- but an external CAM would've been
>> very expensive. May be a direct map?
>> 
>> What we did at Fortune was to utilize a 4 entry external map:
>> text, data, extra and stack.  When a new function was invoked
>> it would do a 'probe'. If the probe caused a segfault, stack
>> was extended in the handler. The probe didn't have to be
>> restartable. So we didn't need a second 68k. This logic may
>> have been in the V7 port we started from.


From bakul at bitblocks.com  Sat Aug 31 13:38:14 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Fri, 30 Aug 2019 20:38:14 -0700
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <E829BD14-88B7-4469-A1A4-7849BC87CB67@ccc.com>
References: <1567196510.21824.for-standards-violators@oclsc.org>
 <CAC20D2OJ=uNZ0yMwpL13TPPW_q9tJeY6559gwsDGUYVkUin+TA@mail.gmail.com>
 <20190830215202.GA974@mcvoy.com>
 <CAC20D2Pp5hpZraaANsXg0Sgc-sU3fJ4=_N17ogQii3=p-H4Oeg@mail.gmail.com>
 <20190831011359.E9F491570CE9@mail.bitblocks.com>
 <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com>
 <E829BD14-88B7-4469-A1A4-7849BC87CB67@ccc.com>
Message-ID: <C48679EC-7E4D-489E-8EC0-092AA204965B@bitblocks.com>

One thing I can think of is something like this:
IIRC 68k had 24 address bits. So with a 4K page size, you can have one level
pagetable. If the pagetable is in fast SRAM, may be 1 or 2 clock cyles would
be added. If you allow 2^N processes, you need 2^(12+N) entry page table. The
width of the table would depend on the number of 4K pages in the physical
memory. Context switch would be to simply set the 2^N bit process "base"
register. Going beyond 2^N you'd have to swap out a process. Each process can
then grow up to 16MB. I don't think a real translation lookaside buffer would
help much.

It would be interesting to see the actual details.

> On Aug 30, 2019, at 7:57 PM, Clem cole <clemc at ccc.com> wrote:
> 
> Btw. The issue with the 68k was Nick Tredenick’s original Microcode did not save enough information during some of the faults.  Les Crudele once told me, that it turns out he had tried to fix it but there were a series of errors and some short cuts they used to fit it in the store.  They gave up trying to fix it as the part was purely skunkworks and they could not respin it at the time.  After it succeeded and were a real project, the difference between the original and the 10 was Nick redid the microcode but they had made a larger microstore - otherwise basically the same Si.    
> 
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
> 
>> On Aug 30, 2019, at 10:46 PM, Clem cole <clemc at ccc.com> wrote:
>> 
>> There was most definitely a TLB or as Dave called it ‘The TB’ ***
>> Remember Dave Cane (Masscomp hw lead) was part of the 780, led the 750 and designed the BI before he left dec.  He was a bus and memory specialist 
>> 
>> 
>> *** west coast VS east coast training - calling it a TB vs a TLB.  
>> 
>> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
>> 
>>>> On Aug 30, 2019, at 9:13 PM, Bakul Shah <bakul at bitblocks.com> wrote:
>>>> 
>>>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc at ccc.com> wrote:
>>>> 
>>>> Actually not in lock step.  They were independent.  One was called the
>>>> executor and the other the fixer.  When a fault was detected the executor
>>>> was sent wait stated while the fixer handled the fault and refilled the
>>>> TLB.   Once the TLB was set to instruction was allowed to complete.    Btw
>>>> when the 68010 was released the pals on the board were changed to allow the
>>>> executor to actually take the fault and do something else while the fixer
>>>> replaced the TLB entry
>>> 
>>> As I remember, the issue with 68000 was that instructions were
>>> not restartable so in case of accessing memory that didn't
>>> exist, you couldn't take a segfault and do anything useful.
>>> This is why you needed a second processor to deal with an
>>> external MMU. There would have been no TLB unless you actually
>>> added an external TLB -- but an external CAM would've been
>>> very expensive. May be a direct map?
>>> 
>>> What we did at Fortune was to utilize a 4 entry external map:
>>> text, data, extra and stack.  When a new function was invoked
>>> it would do a 'probe'. If the probe caused a segfault, stack
>>> was extended in the handler. The probe didn't have to be
>>> restartable. So we didn't need a second 68k. This logic may
>>> have been in the V7 port we started from.


From clemc at ccc.com  Sat Aug 31 13:47:00 2019
From: clemc at ccc.com (Clem cole)
Date: Fri, 30 Aug 2019 23:47:00 -0400
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <CAC5iaNEv2FXeU-w1OqRcH4-u6cKTn99_0T4i9eUAJxBG=w+bYg@mail.gmail.com>
References: <1567196510.21824.for-standards-violators@oclsc.org>
 <CAC20D2OJ=uNZ0yMwpL13TPPW_q9tJeY6559gwsDGUYVkUin+TA@mail.gmail.com>
 <20190830215202.GA974@mcvoy.com>
 <CAC20D2Pp5hpZraaANsXg0Sgc-sU3fJ4=_N17ogQii3=p-H4Oeg@mail.gmail.com>
 <20190831011359.E9F491570CE9@mail.bitblocks.com>
 <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com>
 <E829BD14-88B7-4469-A1A4-7849BC87CB67@ccc.com>
 <CAC5iaNEv2FXeU-w1OqRcH4-u6cKTn99_0T4i9eUAJxBG=w+bYg@mail.gmail.com>
Message-ID: <8797F327-14CE-42C2-9B8B-8A58AEA1CC82@ccc.com>

Fwiw. the 68k design team used a 11/70 running an ISC based Unix and with Rand Editor running in Perkin Elmer Fox terminals with special microcode in the 6800 in the terminals roms.  Basically Les, Nick and Tom were all Unix folks.  


Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Aug 30, 2019, at 11:14 PM, Gregg Levine <gregg.drwho8 at gmail.com> wrote:
> 
> Hello!
> That definitely groks with a decidedly thirty year old memory. I
> remember going to BUSCON, and getting into an interesting discussion
> with the folks behind the M68K just how difficult it could be to run
> more modern code (or operating systems). Let's just say it was
> peculiar. They wanted to stick with a proprietary OS, and one odd man
> there wanted to expand CPM-68K. And still another was looking into
> bringing up UNIX on it.
> 
> It was fun.
> -----
> Gregg C Levine gregg.drwho8 at gmail.com
> "This signature fought the Time Wars, time and again."
> 
>> On Fri, Aug 30, 2019 at 10:58 PM Clem cole <clemc at ccc.com> wrote:
>> 
>> Btw. The issue with the 68k was Nick Tredenick’s original Microcode did not save enough information during some of the faults.  Les Crudele once told me, that it turns out he had tried to fix it but there were a series of errors and some short cuts they used to fit it in the store.  They gave up trying to fix it as the part was purely skunkworks and they could not respin it at the time.  After it succeeded and were a real project, the difference between the original and the 10 was Nick redid the microcode but they had made a larger microstore - otherwise basically the same Si.
>> 
>> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
>> 
>>> On Aug 30, 2019, at 10:46 PM, Clem cole <clemc at ccc.com> wrote:
>>> 
>>> There was most definitely a TLB or as Dave called it ‘The TB’ ***
>>> Remember Dave Cane (Masscomp hw lead) was part of the 780, led the 750 and designed the BI before he left dec.  He was a bus and memory specialist
>>> 
>>> 
>>> *** west coast VS east coast training - calling it a TB vs a TLB.
>>> 
>>> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
>>> 
>>>>> On Aug 30, 2019, at 9:13 PM, Bakul Shah <bakul at bitblocks.com> wrote:
>>>>> 
>>>>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc at ccc.com> wrote:
>>>>> 
>>>>> Actually not in lock step.  They were independent.  One was called the
>>>>> executor and the other the fixer.  When a fault was detected the executor
>>>>> was sent wait stated while the fixer handled the fault and refilled the
>>>>> TLB.   Once the TLB was set to instruction was allowed to complete.    Btw
>>>>> when the 68010 was released the pals on the board were changed to allow the
>>>>> executor to actually take the fault and do something else while the fixer
>>>>> replaced the TLB entry
>>>> 
>>>> As I remember, the issue with 68000 was that instructions were
>>>> not restartable so in case of accessing memory that didn't
>>>> exist, you couldn't take a segfault and do anything useful.
>>>> This is why you needed a second processor to deal with an
>>>> external MMU. There would have been no TLB unless you actually
>>>> added an external TLB -- but an external CAM would've been
>>>> very expensive. May be a direct map?
>>>> 
>>>> What we did at Fortune was to utilize a 4 entry external map:
>>>> text, data, extra and stack.  When a new function was invoked
>>>> it would do a 'probe'. If the probe caused a segfault, stack
>>>> was extended in the handler. The probe didn't have to be
>>>> restartable. So we didn't need a second 68k. This logic may
>>>> have been in the V7 port we started from.

From dave at horsfall.org  Sat Aug 31 15:37:32 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 31 Aug 2019 15:37:32 +1000 (EST)
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
In-Reply-To: <E829BD14-88B7-4469-A1A4-7849BC87CB67@ccc.com>
References: <1567196510.21824.for-standards-violators@oclsc.org>
 <CAC20D2OJ=uNZ0yMwpL13TPPW_q9tJeY6559gwsDGUYVkUin+TA@mail.gmail.com>
 <20190830215202.GA974@mcvoy.com>
 <CAC20D2Pp5hpZraaANsXg0Sgc-sU3fJ4=_N17ogQii3=p-H4Oeg@mail.gmail.com>
 <20190831011359.E9F491570CE9@mail.bitblocks.com>
 <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com>
 <E829BD14-88B7-4469-A1A4-7849BC87CB67@ccc.com>
Message-ID: <alpine.BSF.2.21.9999.1908311531460.37360@aneurin.horsfall.org>

On Fri, 30 Aug 2019, Clem cole wrote:

> Btw. The issue with the 68k was Nick Tredenick’s original Microcode did 
> not save enough information during some of the faults.  Les Crudele once 
> told me, that it turns out he had tried to fix it but there were a 
> series of errors and some short cuts they used to fit it in the store. 
> They gave up trying to fix it as the part was purely skunkworks and they 
> could not respin it at the time.  After it succeeded and were a real 
> project, the difference between the original and the 10 was Nick redid 
> the microcode but they had made a larger microstore - otherwise 
> basically the same Si.

Yep, that certainly rings a bell.  ISTR that Sun had a board with the two 
CPUs, one keeping an eye on the other.

Ah, those were the days :-)  Now, we just have to put up with Intel, 
although I believe the ARM is much better.

-- Dave

From rudi.j.blom at gmail.com  Sat Aug 31 19:43:47 2019
From: rudi.j.blom at gmail.com (Rudi Blom)
Date: Sat, 31 Aug 2019 16:43:47 +0700
Subject: [TUHS] dmr streams & networking [was: Re: If not Linux,
 then what?]
Message-ID: <CAMYpm86xi5ztkXMpbvtbymn+t4RwtVPzHepgo5+K67VL2U7uNA@mail.gmail.com>

Whenever I hear UNIX, networking and streams I have to think about this scheme.

Still using this, even on HP-UX 11.31 on Itanium rx-servers

Cheers,
uncle rubl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Transport Interface.gif
Type: image/gif
Size: 8969 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190831/b30e3bca/attachment.gif>

From steve at quintile.net  Sat Aug 31 19:44:22 2019
From: steve at quintile.net (Steve Simon)
Date: Sat, 31 Aug 2019 11:44:22 +0200
Subject: [TUHS] early vm systems
Message-ID: <FBE13D27-3C8B-4169-868D-72C06A2C15D4@quintile.net>

hi

the other early vm system not mentioned yet is the one Charles Forsyth wrote at the university of york for sunos. i never used it as i was learning v7 on an interdata 30 miles away at the time but i read his excellent paper on it.

-Steve





From thomas.paulsen at firemail.de  Sat Aug 31 22:04:19 2019
From: thomas.paulsen at firemail.de (Thomas Paulsen)
Date: Sat, 31 Aug 2019 14:04:19 +0200
Subject: [TUHS] early vm systems
In-Reply-To: <FBE13D27-3C8B-4169-868D-72C06A2C15D4@quintile.net>
References: <FBE13D27-3C8B-4169-868D-72C06A2C15D4@quintile.net>
Message-ID: <fb109b53aa00decf12498b41755d9090@firemail.de>


--- Ursprüngliche Nachricht ---
Von: Steve Simon <steve at quintile.net>
Datum: 31.08.2019 11:44:22
An: tuhs at minnie.tuhs.org
Betreff: [TUHS] early vm systems

> hi
>
> the other early vm system not mentioned yet is the one Charles Forsyth wrote
> at the university of york for sunos. i never used it as i was learning v7
> on an interdata 30 miles away at the time but i read his excellent paper
> on it.
did you mean: https://www.researchgate.net/publication/2411547_The_Mether_System_Distributed_Shared_Memory_for_SunOS_40



