From clemc at ccc.com  Sat Sep  1 00:41:21 2018
From: clemc at ccc.com (Clem Cole)
Date: Fri, 31 Aug 2018 10:41:21 -0400
Subject: [TUHS] UNIX System names - since UNIX was a Trademark
In-Reply-To: <alpine.BSF.2.21.9999.1808311023210.41601@aneurin.horsfall.org>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808300825340.41601@aneurin.horsfall.org>
 <20180829233605.GJ8423@mcvoy.com>
 <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com>
 <CAK7dMtDgkkkP1kGbGRt48ON1BrMkN2GSsi8bfe=EeOGT3O8esw@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808311023210.41601@aneurin.horsfall.org>
Message-ID: <CAC20D2OecE9WX8o4A+VgtEi51c3_QiXQQSq7_t1YGwNK_FG8kw@mail.gmail.com>

Dave Horsfall's comment about AIX made me think.     The joker in me has
 always been impressed by how marketing people 'missed' the obvious
pronunciations that would lead to serious

jokes.
Some of the more memorable ones from the UNIX world that I knew: AIX ->
"aches", CRDS -> "cruds", HP-UX -> HP "yucks" and "hockey pucks" and my
favorite: RHEL -> "our hell"

I bet there are more and others I did know/consider ;-)

That said, I did hear a pro-VMS person in ZKO (*i.e.* a DECie) once tried
refered to "DEC Ultrix" as Dirty Tricks, but I never heard that one take
off/be repeated outside of ZKO.

For history we probably should try to collect them, although I fear the
context of the joke in the future may be lost.


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

From ewayte at gmail.com  Sat Sep  1 01:13:53 2018
From: ewayte at gmail.com (Eric Wayte)
Date: Fri, 31 Aug 2018 11:13:53 -0400
Subject: [TUHS] UNIX System names - since UNIX was a Trademark
In-Reply-To: <CAC20D2OecE9WX8o4A+VgtEi51c3_QiXQQSq7_t1YGwNK_FG8kw@mail.gmail.com>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808300825340.41601@aneurin.horsfall.org>
 <20180829233605.GJ8423@mcvoy.com>
 <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com>
 <CAK7dMtDgkkkP1kGbGRt48ON1BrMkN2GSsi8bfe=EeOGT3O8esw@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808311023210.41601@aneurin.horsfall.org>
 <CAC20D2OecE9WX8o4A+VgtEi51c3_QiXQQSq7_t1YGwNK_FG8kw@mail.gmail.com>
Message-ID: <CAJc6K3Xtj6r8jGZcdzdNADt_P5LChhrV=UmHPTJ5EJUtkF4vNg@mail.gmail.com>

I've heard Red Hat referred to as "root hat".

On Fri, Aug 31, 2018 at 10:42 AM Clem Cole <clemc at ccc.com> wrote:

>
> Dave Horsfall's comment about AIX made me think.     The joker in me has
>  always been impressed by how marketing people 'missed' the obvious
> pronunciations that would lead to serious
>
> jokes.
> Some of the more memorable ones from the UNIX world that I knew: AIX ->
> "aches", CRDS -> "cruds", HP-UX -> HP "yucks" and "hockey pucks" and my
> favorite: RHEL -> "our hell"
>
> I bet there are more and others I did know/consider ;-)
>
> That said, I did hear a pro-VMS person in ZKO (*i.e.* a DECie) once tried
> refered to "DEC Ultrix" as Dirty Tricks, but I never heard that one take
> off/be repeated outside of ZKO.
>
> For history we probably should try to collect them, although I fear the
> context of the joke in the future may be lost.
>
>
> Clem
> ᐧ
>


-- 
Eric Wayte
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180831/86d9a516/attachment.html>

From pechter at gmail.com  Sat Sep  1 01:17:54 2018
From: pechter at gmail.com (William Pechter)
Date: Fri, 31 Aug 2018 11:17:54 -0400
Subject: [TUHS] UNIX System names - since UNIX was a Trademark
In-Reply-To: <CAC20D2OecE9WX8o4A+VgtEi51c3_QiXQQSq7_t1YGwNK_FG8kw@mail.gmail.com>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808300825340.41601@aneurin.horsfall.org>
 <20180829233605.GJ8423@mcvoy.com>
 <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com>
 <CAK7dMtDgkkkP1kGbGRt48ON1BrMkN2GSsi8bfe=EeOGT3O8esw@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808311023210.41601@aneurin.horsfall.org>
 <CAC20D2OecE9WX8o4A+VgtEi51c3_QiXQQSq7_t1YGwNK_FG8kw@mail.gmail.com>
Message-ID: <3b0a2895-4a6b-48c4-87da-cc1018d7b665.maildroid@localhost>

UNIX is a trademark of AT&T
AT&T is a modem test command. 

-----Original Message-----
From: Clem Cole <clemc at ccc.com>
To: Dave Horsfall <dave at horsfall.org>
Cc: The Eunuchs Hysterical Society <tuhs at tuhs.org>
Sent: Fri, 31 Aug 2018 10:42
Subject: Re: [TUHS] UNIX System names - since UNIX was a Trademark

Dave Horsfall's comment about AIX made me think.     The joker in me has
 always been impressed by how marketing people 'missed' the obvious
pronunciations that would lead to serious

jokes.
Some of the more memorable ones from the UNIX world that I knew: AIX ->
"aches", CRDS -> "cruds", HP-UX -> HP "yucks" and "hockey pucks" and my
favorite: RHEL -> "our hell"

I bet there are more and others I did know/consider ;-)

That said, I did hear a pro-VMS person in ZKO (*i.e.* a DECie) once tried
refered to "DEC Ultrix" as Dirty Tricks, but I never heard that one take
off/be repeated outside of ZKO.

For history we probably should try to collect them, although I fear the
context of the joke in the future may be lost.


Clem
ᐧ


From clemc at ccc.com  Sat Sep  1 01:25:38 2018
From: clemc at ccc.com (Clem Cole)
Date: Fri, 31 Aug 2018 11:25:38 -0400
Subject: [TUHS] UNIX System names - since UNIX was a Trademark
In-Reply-To: <3b0a2895-4a6b-48c4-87da-cc1018d7b665.maildroid@localhost>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808300825340.41601@aneurin.horsfall.org>
 <20180829233605.GJ8423@mcvoy.com>
 <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com>
 <CAK7dMtDgkkkP1kGbGRt48ON1BrMkN2GSsi8bfe=EeOGT3O8esw@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808311023210.41601@aneurin.horsfall.org>
 <CAC20D2OecE9WX8o4A+VgtEi51c3_QiXQQSq7_t1YGwNK_FG8kw@mail.gmail.com>
 <3b0a2895-4a6b-48c4-87da-cc1018d7b665.maildroid@localhost>
Message-ID: <CAC20D2NeKfmbS7_9_aJ4eTs0tt-TeO6mv-Sm4hC5c6VFTqUx3w@mail.gmail.com>

Fair enough, but was a cute joke that made those "in the know" smile (like
me), but less of a dig at a marketing naming IMO - like RHEL - not seeing
the obvious way to pronounce the name - duh.  I was more thinking terms of
things like that that marketing folks just were clueless.
Clem
ᐧ

On Fri, Aug 31, 2018 at 11:17 AM William Pechter <pechter at gmail.com> wrote:

> UNIX is a trademark of AT&T
> AT&T is a modem test command.
>
> -----Original Message-----
> From: Clem Cole <clemc at ccc.com>
> To: Dave Horsfall <dave at horsfall.org>
> Cc: The Eunuchs Hysterical Society <tuhs at tuhs.org>
> Sent: Fri, 31 Aug 2018 10:42
> Subject: Re: [TUHS] UNIX System names - since UNIX was a Trademark
>
> Dave Horsfall's comment about AIX made me think.     The joker in me has
>  always been impressed by how marketing people 'missed' the obvious
> pronunciations that would lead to serious
>
> jokes.
> Some of the more memorable ones from the UNIX world that I knew: AIX ->
> "aches", CRDS -> "cruds", HP-UX -> HP "yucks" and "hockey pucks" and my
> favorite: RHEL -> "our hell"
>
> I bet there are more and others I did know/consider ;-)
>
> That said, I did hear a pro-VMS person in ZKO (*i.e.* a DECie) once tried
> refered to "DEC Ultrix" as Dirty Tricks, but I never heard that one take
> off/be repeated outside of ZKO.
>
> For history we probably should try to collect them, although I fear the
> context of the joke in the future may be lost.
>
>
> Clem
> ᐧ
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180831/31a1e2b3/attachment.html>

From mcmer-tuhs at tor.at  Sat Sep  1 02:07:14 2018
From: mcmer-tuhs at tor.at (Marcus Merighi)
Date: Fri, 31 Aug 2018 18:07:14 +0200
Subject: [TUHS] gopher://ftp.icm.edu.pl/1/vol/rzm2/
Message-ID: <20180831160714.GY98238@tor.at>

Hello, 

against my plan to stay under my rock and learn from your messages I now
have to speak up, because I stumbled over this:

https://bsd.network/@sehnsucht/100635118831337239

which speaks of

gopher://ftp.icm.edu.pl/1/vol/rzm2/

(after some puzzled searching for a client I found out that lynx still
supports gopher)

This site has the following list in its root directory:

4.4BSD-Lite FreeBSD LSI NetBSD OpenBSD UnixArchive ancient-unix
desktopbsd dragonflybsd ghostbsd kde kde-applicationdata kś linux-alsa
linux-archlinux linux-atm linux-bipv6 linux-blackarch linux-bluehawk
linux-cbq.init linux-cryptoapi linux-documentation linux-dret
linux-e2compr linux-fido linux-gentoo linux-gentoo-portage linux-inner
linux-iproute linux-linos linux-net-tools linux-norlug linux-nvidia
linux-nvidia.old linux-nvidia.old2 linux-openvz linux-packware
linux-pcmcia linux-radvd linux-raspbian linux-reiserfs linux-rtlinux
linux-sgi linux-silo linux-slackware linux-sparc linux-superrescue
linux-tsx-11 linux-uk linux-usagi linux-uw-linux linux-vectorlinux
linuxberg nexenta openindiana opensolaris pcbsd solaris-10
solaris-cd-fsn solaris-cd-pm solaris_i86pc solaris_sparc sun-fixes
sun-patches www.tazenda.demon.co.uk

I descended into the OpenBSD directory, where things look quite
authentic, at a first glance.

Please keep the stories coming, Marcus


From ckeck at texoma.net  Sat Sep  1 02:24:44 2018
From: ckeck at texoma.net (Cornelius Keck)
Date: Fri, 31 Aug 2018 11:24:44 -0500
Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?=
In-Reply-To: <b1c19c91-3237-8900-4be5-6b6214505794@spamtrap.tnetconsulting.net>
References: <f3f250f4-cffd-794c-450a-d1c3829c890e@spamtrap.tnetconsulting.net>
 <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com>
 <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net>
 <1d8c0539-8b43-9954-d8a7-db4dcc22b27d@texoma.net>
 <b1c19c91-3237-8900-4be5-6b6214505794@spamtrap.tnetconsulting.net>
Message-ID: <c9514323-6a58-4286-ef23-09ff8a9e2d06@texoma.net>

Cool, thx for the pointer with the mailing list!

Grant Taylor via TUHS wrote:
> On 08/30/2018 07:15 PM, Cornelius Keck wrote:
>> Do I want to reserve retronet.us? Could host that here, as I have
>> static IPs.
>
> I'm not going to tell you not to do so if you want to.
>
> I will say that I have registered "retrocomp.net", as in "Retro
> Computing Network".
>
> The person that has registered "retronet.com" (TLD is from memory) has
> both expressed interest in participating and offered use of the domain.
>
> So … I think for the moment we are going to continue with retrocomp.net
> because that's what we have started with.
>
> That being said, it is early enough in the process that we can still
> change domain names if we want to.  I would encourage you to subscribe
> to the RetroNet mailing list and start a conversation about which domain
> name to use.
>
> Link - RetroNet mailing list
>  - http://mailman.chivanet.org/listinfo/retronet
>
>> Having static IPs hanging of a FIOS line is cheaper and easier than
>> dealing with a hoster..
>
> *nod*
>
> I run my personal services on a Linode VPS.  They have served me very
> well.  :-)
>
>
>


From ckeck at texoma.net  Sat Sep  1 02:24:24 2018
From: ckeck at texoma.net (Cornelius Keck)
Date: Fri, 31 Aug 2018 11:24:24 -0500
Subject: [TUHS] =?utf-8?q?RetroNet=E2=80=A6_Virtual_is_cheap=2E?=
In-Reply-To: <e0aa9929-d1fc-43fb-8eae-1c2bad859244.maildroid@localhost>
References: <f3f250f4-cffd-794c-450a-d1c3829c890e@spamtrap.tnetconsulting.net>
 <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com>
 <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net>
 <1d8c0539-8b43-9954-d8a7-db4dcc22b27d@texoma.net>
 <e0aa9929-d1fc-43fb-8eae-1c2bad859244.maildroid@localhost>
Message-ID: <ff99cbb7-1069-9a08-2e41-d1781fe91125@texoma.net>

Indeed, that's cheap. When I started out back in ... thinking .... '99 
with my first own domain, there were not that many offerings for hosting 
at the cost for (then) DSL plus static IPs. Had there been offerings 
this low back then I might have opted for that.

But, I liked the way to have physical control over my setup, still do, 
so there was, is no reason to switch at this time. Given different 
circumstances, I might.

William Pechter wrote:
> Actually, my virtual machine @Digital Ocean has been $5.25/month.  Can't get static IP on my Fios for that.  Domain registration and DNS via Google Domains is another buck per month...
>
> I run mail, web and DNS for $6.25/month on FreeBSD or Linux with full root control.
>
>
>
> -----Original Message-----
> From: Cornelius Keck <ckeck at texoma.net>
> To: Grant Taylor <gtaylor at tnetconsulting.net>, tuhs at minnie.tuhs.org
> Sent: Thu, 30 Aug 2018 21:17
> Subject: Re: [TUHS] RetroNet…
>
> Do I want to reserve retronet.us? Could host that here, as I have static
> IPs.
>
> Having static IPs hanging of a FIOS line is cheaper and easier than
> dealing with a hoster..
>
>
> Grant Taylor via TUHS wrote:
>> On 08/29/2018 12:04 PM, Seth Morabito wrote:
>>> Hmm. I hate to bring this up, but I've been using the name RetroNET as
>>> well. I've had the domain retronet.net registered for ages, and was
>>> about to launch a small pilot project with a handful of 3B2 emulators
>>> running SVR3, with the hope for many more interconnected systems.
>>
>> *gulp*
>>
>> So /you're/ the person that had the domain name we originally wanted.  ;-)
>>
>> We actually decided that we liked "Retro Comp(uting) . Net(work)" and
>> have registered that name.  There is a wiki(…) and forum(…), but the
>> main website isn't up yet.
>>
>> We are about a week into the discussions.  Please join us in the
>> #retronet group on the Synchronet network.  (irc.chivanet.org)
>>
>>> That said, maybe we could pool our efforts? I'd be happy to share the
>>> domain name with this effort, since it's precisely in line with what
>>> I'd like to see.
>>
>> ~sigh~of~relief~
>>
>> I think we would love to welcome more members into the RetroNet.
>>
>> As much as anything else, the idea is to build a community of friendly
>> folks that want to play / learn / help each other, likely in direct
>> relation to retro computing.
>>
>>
>>


From gtaylor at tnetconsulting.net  Sat Sep  1 03:31:35 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Fri, 31 Aug 2018 11:31:35 -0600
Subject: [TUHS] =?utf-8?q?RetroNet=E2=80=A6_Virtual_is_cheap=2E?=
In-Reply-To: <ff99cbb7-1069-9a08-2e41-d1781fe91125@texoma.net>
References: <f3f250f4-cffd-794c-450a-d1c3829c890e@spamtrap.tnetconsulting.net>
 <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com>
 <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net>
 <1d8c0539-8b43-9954-d8a7-db4dcc22b27d@texoma.net>
 <e0aa9929-d1fc-43fb-8eae-1c2bad859244.maildroid@localhost>
 <ff99cbb7-1069-9a08-2e41-d1781fe91125@texoma.net>
Message-ID: <a99678e3-c542-2a9f-a4be-9ec89ccf86f6@spamtrap.tnetconsulting.net>

On 08/31/2018 10:24 AM, Cornelius Keck wrote:
> But, I liked the way to have physical control over my setup, still do, 
> so there was, is no reason to switch at this time. Given different 
> circumstances, I might.

I've actually seen / discussed some options to combine the static IP 
that you get with inexpensive VPSs with the only dynamic nature of some 
residential connections.

I'd be happy to talk about details on COFF if people are interested.



-- 
Grant. . . .
unix || die

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

From pechter at gmail.com  Sat Sep  1 03:36:09 2018
From: pechter at gmail.com (William Pechter)
Date: Fri, 31 Aug 2018 13:36:09 -0400
Subject: [TUHS] =?utf-8?q?RetroNet=E2=80=A6_Virtual_is_cheap=2E?=
In-Reply-To: <ff99cbb7-1069-9a08-2e41-d1781fe91125@texoma.net>
References: <f3f250f4-cffd-794c-450a-d1c3829c890e@spamtrap.tnetconsulting.net>
 <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com>
 <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net>
 <1d8c0539-8b43-9954-d8a7-db4dcc22b27d@texoma.net>
 <e0aa9929-d1fc-43fb-8eae-1c2bad859244.maildroid@localhost>
 <ff99cbb7-1069-9a08-2e41-d1781fe91125@texoma.net>
Message-ID: <7b3d9f5f-af86-40ef-aafb-224f6162eb43.maildroid@localhost>

One thought about Digital Ocean is they even have a web browser based graphic console so you get to fix things @ single user yourself as well as run X remotely if needed... 

-----Original Message-----
From: Cornelius Keck <ckeck at texoma.net>
To: William Pechter <pechter at gmail.com>
Cc: ckeck at texoma.net, tuhs at tuhs.org
Sent: Fri, 31 Aug 2018 12:24
Subject: Re: [TUHS] RetroNet… Virtual is cheap. 

Indeed, that's cheap. When I started out back in ... thinking .... '99 
with my first own domain, there were not that many offerings for hosting 
at the cost for (then) DSL plus static IPs. Had there been offerings 
this low back then I might have opted for that.

But, I liked the way to have physical control over my setup, still do, 
so there was, is no reason to switch at this time. Given different 
circumstances, I might.

William Pechter wrote:
> Actually, my virtual machine @Digital Ocean has been $5.25/month.  Can't get static IP on my Fios for that.  Domain registration and DNS via Google Domains is another buck per month...
>
> I run mail, web and DNS for $6.25/month on FreeBSD or Linux with full root control.
>
>
>
> -----Original Message-----
> From: Cornelius Keck <ckeck at texoma.net>
> To: Grant Taylor <gtaylor at tnetconsulting.net>, tuhs at minnie.tuhs.org
> Sent: Thu, 30 Aug 2018 21:17
> Subject: Re: [TUHS] RetroNet…
>
> Do I want to reserve retronet.us? Could host that here, as I have static
> IPs.
>
> Having static IPs hanging of a FIOS line is cheaper and easier than
> dealing with a hoster..
>
>
> Grant Taylor via TUHS wrote:
>> On 08/29/2018 12:04 PM, Seth Morabito wrote:
>>> Hmm. I hate to bring this up, but I've been using the name RetroNET as
>>> well. I've had the domain retronet.net registered for ages, and was
>>> about to launch a small pilot project with a handful of 3B2 emulators
>>> running SVR3, with the hope for many more interconnected systems.
>>
>> *gulp*
>>
>> So /you're/ the person that had the domain name we originally wanted.  ;-)
>>
>> We actually decided that we liked "Retro Comp(uting) . Net(work)" and
>> have registered that name.  There is a wiki(…) and forum(…), but the
>> main website isn't up yet.
>>
>> We are about a week into the discussions.  Please join us in the
>> #retronet group on the Synchronet network.  (irc.chivanet.org)
>>
>>> That said, maybe we could pool our efforts? I'd be happy to share the
>>> domain name with this effort, since it's precisely in line with what
>>> I'd like to see.
>>
>> ~sigh~of~relief~
>>
>> I think we would love to welcome more members into the RetroNet.
>>
>> As much as anything else, the idea is to build a community of friendly
>> folks that want to play / learn / help each other, likely in direct
>> relation to retro computing.
>>
>>
>>


From ca6c at bitmessage.ch  Sat Sep  1 07:34:51 2018
From: ca6c at bitmessage.ch (=?utf-8?B?Q8OhZw==?=)
Date: Fri, 31 Aug 2018 16:34:51 -0500
Subject: [TUHS] SunOS code?
In-Reply-To: <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
Message-ID: <20180831213451.r7LAj%ca6c@bitmessage.ch>

Kevin Bowling wrote:

> Sun releasing OpenSolaris when they finally did and under the CDDL was
> pretty tone deaf to what was going on in the market with Linux, but
> you have to admire the amount of contract review and legal work that
> must have taken.

How is OpenSolaris different from SunOS (Sun/Oracle Solaris) anyway?
Isn't the relationship kinda RHEL-CentOS'ish? I.e. one is community-
-supported, and another is commercially.

--
caóc



From clemc at ccc.com  Sat Sep  1 07:39:31 2018
From: clemc at ccc.com (Clem Cole)
Date: Fri, 31 Aug 2018 17:39:31 -0400
Subject: [TUHS] SunOS code?
In-Reply-To: <20180831213451.r7LAj%ca6c@bitmessage.ch>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch>
Message-ID: <CAC20D2PntMqqDCp4c25N0tNfd0iD8fj-Yo309eLaiKs0zp9a5w@mail.gmail.com>

On Fri, Aug 31, 2018 at 5:36 PM Cág <ca6c at bitmessage.ch> wrote:

> How is OpenSolaris different from SunOS (Sun/Oracle Solaris) anyway?
> Isn't the relationship kinda RHEL-CentOS'ish? I.e. one is
> community--supported, and another is commercially.
>
Yikes -- this is like Rolls Royce cutting a deal with GM and produce a new
car based on the Chevy Sububuran, painting it, adding a few details  and
calling it a Silver Ghost.


SunOS != is not Solaris

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

From krewat at kilonet.net  Sat Sep  1 07:47:38 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Fri, 31 Aug 2018 17:47:38 -0400
Subject: [TUHS] SunOS code?
In-Reply-To: <CAC20D2PntMqqDCp4c25N0tNfd0iD8fj-Yo309eLaiKs0zp9a5w@mail.gmail.com>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch>
 <CAC20D2PntMqqDCp4c25N0tNfd0iD8fj-Yo309eLaiKs0zp9a5w@mail.gmail.com>
Message-ID: <ae8181fe-8320-0704-7e4c-d3fafb6a53c6@kilonet.net>

On 8/31/2018 5:39 PM, Clem Cole wrote:
> SunOS != is not Solaris
>
> ᐧ

Confusion may arise because the last released SunOS 4.1.4 was called 
"Solaris 1.1.2".

Solaris nor SunOS were ever "community supported" although one could 
make the case that SunOS was more generally liked ;)




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

From clemc at ccc.com  Sat Sep  1 07:47:50 2018
From: clemc at ccc.com (Clem Cole)
Date: Fri, 31 Aug 2018 17:47:50 -0400
Subject: [TUHS] Usenix: no official Unix 50th celebration, (yet)
In-Reply-To: <20180826003127.GA18905@minnie.tuhs.org>
References: <20180826003127.GA18905@minnie.tuhs.org>
Message-ID: <CAC20D2OAdEZT2ncwY3s=TmPSGNG_jcs5dJ4qk+X3NKO88OG-3A@mail.gmail.com>

I do not want to say too much yet ---  but I am making progress.  As people
have determined on this list, there are some real financial realities.
Warren asked me a question -- I answered it.  There is nothing (yet)
official.  But some things have occurred in the last few days that are
encouraging.  I will keep you all posted as it progresses.

What you can do it to say to bod at usenix.org you would like to see it
happen, particularly if you are a member of the organization (feel free to
CC me).   They need to hear that it is worthwhile and something they should
spend some effort and money doing.

Clem


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

From ca6c at bitmessage.ch  Sat Sep  1 07:56:36 2018
From: ca6c at bitmessage.ch (=?utf-8?B?Q8OhZw==?=)
Date: Fri, 31 Aug 2018 16:56:36 -0500
Subject: [TUHS] cat -v and other complaints
In-Reply-To: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
Message-ID: <20180831215636.-eCEx%ca6c@bitmessage.ch>

Not completely on-topic, in my opinion one of the reasons Plan9 failed
was the fact that it presented itself overly idealistic, occasionally
sacrificing usability -- maybe it's because of coming from a Unix system
like Berkeley or IRIX, in which case, I think Brian Kernighan said, "if
you'll think of it as Unix, you'll often be frustrated because something
doesn't exist or works differently." On the one hand the `cat -v` and
some other concerns (like columnated ls(1) output) are valid, and very
well understood. On the other -- lack of find(1), shell history, and
vi are not. Well, to me at least. Both acme and sam seem to have found
its fanbase.

Note, when I'm saying failed I mean commercially. As a research
operating system, or, dare I say, esoteric, because in some way it was
and still is esoteric, it succeeded as none of the others, with its
impact going through this day.

--
caóc



From imp at bsdimp.com  Sat Sep  1 07:57:27 2018
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 31 Aug 2018 15:57:27 -0600
Subject: [TUHS] SunOS code?
In-Reply-To: <20180831213451.r7LAj%ca6c@bitmessage.ch>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch>
Message-ID: <CANCZdfqH_Bo9Aot_akyYAHS2Rpz3xGVaMmb_AD+V7BgddPQfXA@mail.gmail.com>

On Fri, Aug 31, 2018 at 3:36 PM Cág <ca6c at bitmessage.ch> wrote:

> Kevin Bowling wrote:
>
> > Sun releasing OpenSolaris when they finally did and under the CDDL was
> > pretty tone deaf to what was going on in the market with Linux, but
> > you have to admire the amount of contract review and legal work that
> > must have taken.
>
> How is OpenSolaris different from SunOS (Sun/Oracle Solaris) anyway?
> Isn't the relationship kinda RHEL-CentOS'ish? I.e. one is community-
> -supported, and another is commercially.
>

No. Not even close.

SunOS is BSD based (first 4.2 then 4.3 then with some small amount of
System V code) with a written from scratch vm.

Solaris is sun's do-over based on System V Release 4. It's great leap
backwards. It was a huge slap in the face of the old SunOS crew by inept
management. The final indignity was SunOS 4.1 being rebranded Solaris 1.0,
which was pure marketing...

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

From lm at mcvoy.com  Sat Sep  1 07:58:54 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 31 Aug 2018 14:58:54 -0700
Subject: [TUHS] SunOS code?
In-Reply-To: <20180831213451.r7LAj%ca6c@bitmessage.ch>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch>
Message-ID: <20180831215854.GB28971@mcvoy.com>

On Fri, Aug 31, 2018 at 04:34:51PM -0500, C??g wrote:
> Kevin Bowling wrote:
> 
> > Sun releasing OpenSolaris when they finally did and under the CDDL was
> > pretty tone deaf to what was going on in the market with Linux, but
> > you have to admire the amount of contract review and legal work that
> > must have taken.
> 
> How is OpenSolaris different from SunOS (Sun/Oracle Solaris) anyway?
> Isn't the relationship kinda RHEL-CentOS'ish? I.e. one is community-
> -supported, and another is commercially.

SunOS was based on the BSD code, the entire system was frequently
described as "a bug fixed BSD".  It was, of course, a lot more than that,
Sun dis shared libs, a new (much, much better) VM system, invented the
vnode interface that virtualized file systems, BSD had none of that.

Lots of Usenix papers describing that work here:

SunOS felt very much like BSD, all the stuff you thought would work,
usually did, the user space was very BSD like.

http://mcvoy.com/lm/papers/

Solaris was Sys Vr4 (which, if I recall correctly, differed from r3
largely due to some stuff being ported over from SunOS).  Both the kernel
and user space went to a Sys V compat system, it no longer felt anything
like BSD.

So why would Sun take something that everyone loved and replace it
with that steaming pile of Sys V garbage?  Only the top execs actually
knew the real reason, I'm 99% sure my boss, Ken Okin (VP of all server
hardware), did not know the real reason.  Which was, Sun was in some
financial trouble, I don't know the details, but AT&T bought $200M of
Sun stock at 35% over market to bail them out.  In return, Sun had to
drop SunOS and go with Sys V.  AT&T was betting that Sun would make Sys
V as popular as SunOS.

Didn't happen.  Not even close.  A lot of people just bailed, trying to
work with Sys V was miserable.  It put us backwards at least 10 years and
I'd argue more than that.  The engineers loved SunOS and tons of work
got done on the system that management never asked for, the engineers
really drove the agenda.  When all that work was yanked away, it took
the heart out of engineering.

A bunch of people stuck around and tried, they really did and I applaud
them for it but the damage was done.  I was gone by the time ZFS came out
so I have no idea how that passed through the formal vetting process that
Sun had in place.  When I was there, if I had proposed a file system that
wouldn't use the page cache, you'd have to copy from the buffer cache
into the page cache to get mmap to work, I would have been kicked out
of the room and probably kicked out of the kernel group.  We had spent
SO FRIGGING MUCH TIME getting rid of the buffer cache, precisely because
trying to maintain coherency between the page cache (mmap) and the buffer
cache (read/write), it was clear that you wanted a unified model.

Yet the wise heads in charge approved ZFS.  It boggles my mind.  Yeah,
I get it, it's got lots of nice features.  But at the expense of breaking
one of the cornerstones of the kernel design.

The only thing I can think of is that the people who could see the whole
kernel architecture had left, I can't imagine Kleiman, Gingell, Rosenthal,
Powell, any of the old school distinguished engineers, tolerating that
for 1 second.  So my guess is they were gone and nobody in the vetting
process saw the whole picture any more.

If anyone is lurking on the list and was there for the ZFS work, I'd
love to hear your take on it.  I'm speculating.  It just blows my mind
that something that was one of the main design points for the previous
10-15 years, was ignored.  We're not talking about some obscure device
driver, we're talking about mmap(), which was one of the reasons Sun ran
circles around the other guys, they all had crappy mmap() implementations
that copied.  ZFS went back to that.  Weird.


From imp at bsdimp.com  Sat Sep  1 08:02:26 2018
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 31 Aug 2018 16:02:26 -0600
Subject: [TUHS] SunOS code?
In-Reply-To: <20180831215854.GB28971@mcvoy.com>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com>
Message-ID: <CANCZdfrharMj3kHLvCZHTrrMS=C71tx9VHgC15_ubLRARqch8g@mail.gmail.com>

On Fri, Aug 31, 2018 at 3:59 PM Larry McVoy <lm at mcvoy.com> wrote:

> A bunch of people stuck around and tried, they really did and I applaud
> them for it but the damage was done.  I was gone by the time ZFS came out
> so I have no idea how that passed through the formal vetting process that
> Sun had in place.  When I was there, if I had proposed a file system that
> wouldn't use the page cache, you'd have to copy from the buffer cache
> into the page cache to get mmap to work, I would have been kicked out
> of the room and probably kicked out of the kernel group.  We had spent
> SO FRIGGING MUCH TIME getting rid of the buffer cache, precisely because
> trying to maintain coherency between the page cache (mmap) and the buffer
> cache (read/write), it was clear that you wanted a unified model.
>

It's reason #1 why Netflix can't use ZFS: the double copy problem...

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

From ca6c at bitmessage.ch  Sat Sep  1 08:19:27 2018
From: ca6c at bitmessage.ch (=?utf-8?B?Q8OhZw==?=)
Date: Fri, 31 Aug 2018 17:19:27 -0500
Subject: [TUHS] SunOS code?
In-Reply-To: <20180831215854.GB28971@mcvoy.com>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com>
Message-ID: <20180831221927.zeKvq%ca6c@bitmessage.ch>

Larry McVoy wrote:

> SunOS was based on the BSD code, the entire system was frequently
> described as "a bug fixed BSD".
> Solaris was Sys Vr4 [...].  Both the kernel and user space went to a
> Sys V compat system, it no longer felt anything like BSD.
 
I find it kinda weird, considering what Bill Joy did for BSD and,
obviously, for Sun. I wonder what he himself thinks about it. Shout out
to Bill if he reads the list.

Also, I'm using the original vi (ex-vi that is from Heirloom), not nvi,
as my development platform. Another weird thing: his original vi never
made it to any BSD distribution.

--
caóc



From ca6c at bitmessage.ch  Sat Sep  1 08:20:17 2018
From: ca6c at bitmessage.ch (=?utf-8?B?Q8OhZw==?=)
Date: Fri, 31 Aug 2018 17:20:17 -0500
Subject: [TUHS] SunOS code?
In-Reply-To: <20180831215854.GB28971@mcvoy.com>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com>
Message-ID: <20180831222017.KYQ86%ca6c@bitmessage.ch>

Forgot to add: thanks for the good read, Larry!

--
caóc



From nobozo at gmail.com  Sat Sep  1 08:23:22 2018
From: nobozo at gmail.com (Jon Forrest)
Date: Fri, 31 Aug 2018 15:23:22 -0700
Subject: [TUHS] SunOS code?
In-Reply-To: <20180831221927.zeKvq%ca6c@bitmessage.ch>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com>
 <20180831221927.zeKvq%ca6c@bitmessage.ch>
Message-ID: <ff2c779d-19fa-423d-5080-18ba2d58fa7b@gmail.com>



On 8/31/2018 3:19 PM, Cág wrote:

> Also, I'm using the original vi (ex-vi that is from Heirloom), not nvi,
> as my development platform. Another weird thing: his original vi never
> made it to any BSD distribution.

Are you quite sure? I remember using BSD on a VAX in about 1978
when vi just came out. I'm pretty sure Bill Joy wrote the man
page and other documentation.

Maybe it depends on what you mean by "his original vi".

Jon



From ca6c at bitmessage.ch  Sat Sep  1 08:30:34 2018
From: ca6c at bitmessage.ch (=?utf-8?B?Q8OhZw==?=)
Date: Fri, 31 Aug 2018 17:30:34 -0500
Subject: [TUHS] SunOS code?
In-Reply-To: <ff2c779d-19fa-423d-5080-18ba2d58fa7b@gmail.com>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com>
 <20180831221927.zeKvq%ca6c@bitmessage.ch>
 <ff2c779d-19fa-423d-5080-18ba2d58fa7b@gmail.com>
Message-ID: <20180831223034.Um9p2%ca6c@bitmessage.ch>

Jon Forrest wrote:

> Are you quite sure? I remember using BSD on a VAX in about 1978
> when vi just came out. I'm pretty sure Bill Joy wrote the man
> page and other documentation.

*Open-source BSD distribution. I think it had some license restrictions
when the Jolitzes made the 386 port, so they had to put an alternative.
Then it was Elvis, nvi was written later on.

--
caóc



From nobozo at gmail.com  Sat Sep  1 08:34:22 2018
From: nobozo at gmail.com (Jon Forrest)
Date: Fri, 31 Aug 2018 15:34:22 -0700
Subject: [TUHS] SunOS code?
In-Reply-To: <20180831223034.Um9p2%ca6c@bitmessage.ch>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com>
 <20180831221927.zeKvq%ca6c@bitmessage.ch>
 <ff2c779d-19fa-423d-5080-18ba2d58fa7b@gmail.com>
 <20180831223034.Um9p2%ca6c@bitmessage.ch>
Message-ID: <83fec4da-b10e-8459-8e93-eebe196f98c4@gmail.com>



On 8/31/2018 3:30 PM, Cág wrote:
> Jon Forrest wrote:
> 
>> Are you quite sure? I remember using BSD on a VAX in about 1978
>> when vi just came out. I'm pretty sure Bill Joy wrote the man
>> page and other documentation.
> 
> *Open-source BSD distribution. I think it had some license restrictions
> when the Jolitzes made the 386 port, so they had to put an alternative.
> Then it was Elvis, nvi was written later on.

Those of us who used pre-open-source BSD probably have a different
recollection of what BSD was like than those who came later.

Jon



From krewat at kilonet.net  Sat Sep  1 09:02:36 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Fri, 31 Aug 2018 19:02:36 -0400
Subject: [TUHS] SunOS code?
In-Reply-To: <20180831215854.GB28971@mcvoy.com>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com>
Message-ID: <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net>

On 8/31/2018 5:58 PM, Larry McVoy wrote:
>
> Solaris was Sys Vr4 (which, if I recall correctly, differed from r3
> largely due to some stuff being ported over from SunOS).  Both the kernel
> and user space went to a Sys V compat system, it no longer felt anything
> like BSD.
>

I would be very interested in anyone's recollections of how Solaris 
eventually turned out performance-wise, say version 9+, compared to 
other operating systems. SunOS, Linux, AIX, etc.

I find it's about equal, and even exceeds Linux in terms of it's NUMA 
support and multi-processor support. I need to move some systems away 
from Solaris and off to Linux, and I find it's NUMA support lacking in 
certain ways.

ak


From dave at horsfall.org  Sat Sep  1 09:25:09 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 1 Sep 2018 09:25:09 +1000 (EST)
Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?=
In-Reply-To: <2e58402b-6366-4f74-757b-b7c8dd1b729c@texoma.net>
References: <f3f250f4-cffd-794c-450a-d1c3829c890e@spamtrap.tnetconsulting.net>
 <1F62F4D0-7AD1-43C2-A9B7-CF9DF239C3D9@berlan.de>
 <f923f2ae-0463-e3e6-c0fb-55124edb92ff@spamtrap.tnetconsulting.net>
 <2e58402b-6366-4f74-757b-b7c8dd1b729c@texoma.net>
Message-ID: <alpine.BSF.2.21.9999.1809010911470.22638@aneurin.horsfall.org>

On Thu, 30 Aug 2018, Cornelius Keck wrote:

> Flat rate local toll and long distance is fairly prevalent in the US. 
> International long distance is a different story. How does that look 
> like elsewhere, who has a metered land-line?

For any Aussie members, I get free local calls on my plan i.e. anywhere in 
the "02" call area.  I even have a server with genuine serial ports, but 
the latter will change if/when I get a Raspberry Pi.

No modem, though, and I need to see if I can get a second "line" on my NBN 
fibre (to the premises) connection to accept dial-in, and whether modems 
will actually work (it's implemented as VoIP in the router).

(I have tried subscribing to the "retro" list, but nothing heard yet.)

-- Dave


From dave at horsfall.org  Sat Sep  1 10:00:01 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 1 Sep 2018 10:00:01 +1000 (EST)
Subject: [TUHS] UNIX System names - since UNIX was a Trademark
In-Reply-To: <CAC20D2OecE9WX8o4A+VgtEi51c3_QiXQQSq7_t1YGwNK_FG8kw@mail.gmail.com>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808300825340.41601@aneurin.horsfall.org>
 <20180829233605.GJ8423@mcvoy.com>
 <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com>
 <CAK7dMtDgkkkP1kGbGRt48ON1BrMkN2GSsi8bfe=EeOGT3O8esw@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808311023210.41601@aneurin.horsfall.org>
 <CAC20D2OecE9WX8o4A+VgtEi51c3_QiXQQSq7_t1YGwNK_FG8kw@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.1809010957310.22638@aneurin.horsfall.org>

On Fri, 31 Aug 2018, Clem Cole wrote:

> Some of the more memorable ones from the UNIX world that I knew: AIX ->
> "aches", CRDS -> "cruds", HP-UX -> HP "yucks" and "hockey pucks" and my
> favorite: RHEL -> "our hell"

Just be glad that Hewlett-Packard was not called Packard-Hewlett...

-- Dave


From jpl.jpl at gmail.com  Sat Sep  1 10:10:59 2018
From: jpl.jpl at gmail.com (John P. Linderman)
Date: Fri, 31 Aug 2018 20:10:59 -0400
Subject: [TUHS] UNIX System names - since UNIX was a Trademark
In-Reply-To: <3b0a2895-4a6b-48c4-87da-cc1018d7b665.maildroid@localhost>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808300825340.41601@aneurin.horsfall.org>
 <20180829233605.GJ8423@mcvoy.com>
 <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com>
 <CAK7dMtDgkkkP1kGbGRt48ON1BrMkN2GSsi8bfe=EeOGT3O8esw@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808311023210.41601@aneurin.horsfall.org>
 <CAC20D2OecE9WX8o4A+VgtEi51c3_QiXQQSq7_t1YGwNK_FG8kw@mail.gmail.com>
 <3b0a2895-4a6b-48c4-87da-cc1018d7b665.maildroid@localhost>
Message-ID: <CAC0cEp_7jwxdywgs8es0qSBJty3D92BM192-coNEz-EuVQi+pg@mail.gmail.com>

We always referred to HP-UX as "H-Pukes".

On Fri, Aug 31, 2018 at 11:17 AM, William Pechter <pechter at gmail.com> wrote:

> UNIX is a trademark of AT&T
> AT&T is a modem test command.
>
> -----Original Message-----
> From: Clem Cole <clemc at ccc.com>
> To: Dave Horsfall <dave at horsfall.org>
> Cc: The Eunuchs Hysterical Society <tuhs at tuhs.org>
> Sent: Fri, 31 Aug 2018 10:42
> Subject: Re: [TUHS] UNIX System names - since UNIX was a Trademark
>
> Dave Horsfall's comment about AIX made me think.     The joker in me has
>  always been impressed by how marketing people 'missed' the obvious
> pronunciations that would lead to serious
>
> jokes.
> Some of the more memorable ones from the UNIX world that I knew: AIX ->
> "aches", CRDS -> "cruds", HP-UX -> HP "yucks" and "hockey pucks" and my
> favorite: RHEL -> "our hell"
>
> I bet there are more and others I did know/consider ;-)
>
> That said, I did hear a pro-VMS person in ZKO (*i.e.* a DECie) once tried
> refered to "DEC Ultrix" as Dirty Tricks, but I never heard that one take
> off/be repeated outside of ZKO.
>
> For history we probably should try to collect them, although I fear the
> context of the joke in the future may be lost.
>
>
> Clem
> ᐧ
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180831/21e47dd1/attachment.html>

From ron at ronnatalie.com  Sat Sep  1 10:18:58 2018
From: ron at ronnatalie.com (ron at ronnatalie.com)
Date: Fri, 31 Aug 2018 20:18:58 -0400
Subject: [TUHS] UNIX System names - since UNIX was a Trademark
In-Reply-To: <CAC0cEp_7jwxdywgs8es0qSBJty3D92BM192-coNEz-EuVQi+pg@mail.gmail.com>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808300825340.41601@aneurin.horsfall.org>
 <20180829233605.GJ8423@mcvoy.com>
 <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com>
 <CAK7dMtDgkkkP1kGbGRt48ON1BrMkN2GSsi8bfe=EeOGT3O8esw@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808311023210.41601@aneurin.horsfall.org>
 <CAC20D2OecE9WX8o4A+VgtEi51c3_QiXQQSq7_t1YGwNK_FG8kw@mail.gmail.com>
 <3b0a2895-4a6b-48c4-87da-cc1018d7b665.maildroid@localhost>
 <CAC0cEp_7jwxdywgs8es0qSBJty3D92BM192-coNEz-EuVQi+pg@mail.gmail.com>
Message-ID: <261201d44189$60c7aa50$2256fef0$@ronnatalie.com>

Always H-PUCKS to us.   Of course, the other HP operating system (MPE) we called Mighty Poor Excuse.

 

 

From: TUHS <tuhs-bounces at minnie.tuhs.org> On Behalf Of John P. Linderman
Sent: Friday, August 31, 2018 8:11 PM
To: William Pechter <pechter at gmail.com>
Cc: The Eunuchs Hysterical Society <tuhs at tuhs.org>
Subject: Re: [TUHS] UNIX System names - since UNIX was a Trademark

 

We always referred to HP-UX as "H-Pukes".

 

On Fri, Aug 31, 2018 at 11:17 AM, William Pechter <pechter at gmail.com <mailto:pechter at gmail.com> > wrote:

UNIX is a trademark of AT&T
AT&T is a modem test command. 

-----Original Message-----
From: Clem Cole <clemc at ccc.com <mailto:clemc at ccc.com> >
To: Dave Horsfall <dave at horsfall.org <mailto:dave at horsfall.org> >
Cc: The Eunuchs Hysterical Society <tuhs at tuhs.org <mailto:tuhs at tuhs.org> >
Sent: Fri, 31 Aug 2018 10:42
Subject: Re: [TUHS] UNIX System names - since UNIX was a Trademark

Dave Horsfall's comment about AIX made me think.     The joker in me has
 always been impressed by how marketing people 'missed' the obvious
pronunciations that would lead to serious

jokes.
Some of the more memorable ones from the UNIX world that I knew: AIX ->
"aches", CRDS -> "cruds", HP-UX -> HP "yucks" and "hockey pucks" and my
favorite: RHEL -> "our hell"

I bet there are more and others I did know/consider ;-)

That said, I did hear a pro-VMS person in ZKO (*i.e.* a DECie) once tried
refered to "DEC Ultrix" as Dirty Tricks, but I never heard that one take
off/be repeated outside of ZKO.

For history we probably should try to collect them, although I fear the
context of the joke in the future may be lost.


Clem
ᐧ

 

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

From dave at horsfall.org  Sat Sep  1 10:40:40 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 1 Sep 2018 10:40:40 +1000 (EST)
Subject: [TUHS] =?utf-8?q?RetroNet=E2=80=A6_Virtual_is_cheap=2E?=
In-Reply-To: <7b3d9f5f-af86-40ef-aafb-224f6162eb43.maildroid@localhost>
References: <f3f250f4-cffd-794c-450a-d1c3829c890e@spamtrap.tnetconsulting.net>
 <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com>
 <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net>
 <1d8c0539-8b43-9954-d8a7-db4dcc22b27d@texoma.net>
 <e0aa9929-d1fc-43fb-8eae-1c2bad859244.maildroid@localhost>
 <ff99cbb7-1069-9a08-2e41-d1781fe91125@texoma.net>
 <7b3d9f5f-af86-40ef-aafb-224f6162eb43.maildroid@localhost>
Message-ID: <alpine.BSF.2.21.9999.1809011031560.22638@aneurin.horsfall.org>

On Fri, 31 Aug 2018, William Pechter wrote:

> One thought about Digital Ocean is they even have a web browser based 
> graphic console so you get to fix things @ single user yourself as well 
> as run X remotely if needed...

I have a Digital Ocean host myself, so that I can probe my firewall from 
the outside (and there is a metric shitload of tools that I can use to 
attack it; after all, everybody else is); another reason was that I could 
smart-host via it, so that I don't have to use the division of Sirius 
Cybernetics known as Telstra.

-- Dave


From cym224 at gmail.com  Sat Sep  1 10:55:04 2018
From: cym224 at gmail.com (Nemo)
Date: Fri, 31 Aug 2018 20:55:04 -0400
Subject: [TUHS] UNIX System names - since UNIX was a Trademark
In-Reply-To: <261201d44189$60c7aa50$2256fef0$@ronnatalie.com>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808300825340.41601@aneurin.horsfall.org>
 <20180829233605.GJ8423@mcvoy.com>
 <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com>
 <CAK7dMtDgkkkP1kGbGRt48ON1BrMkN2GSsi8bfe=EeOGT3O8esw@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808311023210.41601@aneurin.horsfall.org>
 <CAC20D2OecE9WX8o4A+VgtEi51c3_QiXQQSq7_t1YGwNK_FG8kw@mail.gmail.com>
 <3b0a2895-4a6b-48c4-87da-cc1018d7b665.maildroid@localhost>
 <CAC0cEp_7jwxdywgs8es0qSBJty3D92BM192-coNEz-EuVQi+pg@mail.gmail.com>
 <261201d44189$60c7aa50$2256fef0$@ronnatalie.com>
Message-ID: <CAJfiPzwpZofM9CbjbY5z4Wp5nHxsLuSsLK4Wjd9xggy768K7ng@mail.gmail.com>

On 31/08/2018, ron at ronnatalie.com <ron at ronnatalie.com> wrote:
> Always H-PUCKS to us.   Of course, the other HP operating system (MPE) we
> called Mighty Poor Excuse.

H-Pox in my neck of the woods.

(I think everyone said Slowlaris.  Even the guys from Sun who first
demo'd dtrace
and how it was used to speed up their system calls.)

N.


From lm at mcvoy.com  Sat Sep  1 11:57:41 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 31 Aug 2018 18:57:41 -0700
Subject: [TUHS] SunOS code?
In-Reply-To: <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch>
 <20180831215854.GB28971@mcvoy.com>
 <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net>
Message-ID: <20180901015741.GN28971@mcvoy.com>

On Fri, Aug 31, 2018 at 07:02:36PM -0400, Arthur Krewat wrote:
> On 8/31/2018 5:58 PM, Larry McVoy wrote:
> >
> >Solaris was Sys Vr4 (which, if I recall correctly, differed from r3
> >largely due to some stuff being ported over from SunOS).  Both the kernel
> >and user space went to a Sys V compat system, it no longer felt anything
> >like BSD.
> >
> 
> I would be very interested in anyone's recollections of how Solaris
> eventually turned out performance-wise, say version 9+, compared to other
> operating systems. SunOS, Linux, AIX, etc.

I did some updating of lmbench [*] when I was dancing with Netflix.  I
need to check that in and publish that because the bits have rotted
since 1995.  I have no idea if that will measure what you want, it's
a bunch of microbenchmarks that measure bandwidth and latency of 
everything I could think of: network, disks, file systems, caches,
memory, etc.  It's interesting but might not be so to you.

If you want to know if Solaris is at the same place as Linux, I can
pretty much promise it is not in the "getting out of the way of the
application".  Solaris was known as Slowaris for a reason.  Yeah, I
know it sucked harder in the beginning, but those were order of 
magnitude suckages.  Linus always cared about performance, he had
a big hand in lmbench, we both cared.

Linus was about performance like I am about code size.  I ran the
BitKeeper dev team for almost 20 years.  I loved a changeset that removed
more lines than it added.  We got up to about 120K lines of code in the
core and then we stayed there for the next decade, added so much more
stuff but always found a way to delete stuff so we didn't get bloated.

But all that said, you need to be specific about what perf you care 
about.  These days the kernel is far more complicated, NUMA etc, 
and you might care about parallel make (I doubt it) or you might care
about Oracle or something like that.

--lm

[*] http://mcvoy.com/lm/papers/lmbench-usenix.pdf


From andreww591 at gmail.com  Sat Sep  1 13:37:38 2018
From: andreww591 at gmail.com (Andrew Warkentin)
Date: Fri, 31 Aug 2018 21:37:38 -0600
Subject: [TUHS] cat -v and other complaints
In-Reply-To: <20180831215636.-eCEx%ca6c@bitmessage.ch>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <20180831215636.-eCEx%ca6c@bitmessage.ch>
Message-ID: <CAD-qYGqsq=kZKrHcqUws4mpjV9VGnpNFb31ubUOZ67yOfZMWZA@mail.gmail.com>

On 8/31/18, Cág <ca6c at bitmessage.ch> wrote:
> Not completely on-topic, in my opinion one of the reasons Plan9 failed
> was the fact that it presented itself overly idealistic, occasionally
> sacrificing usability -- maybe it's because of coming from a Unix system
> like Berkeley or IRIX, in which case, I think Brian Kernighan said, "if
> you'll think of it as Unix, you'll often be frustrated because something
> doesn't exist or works differently."

I'd definitely agree with the lack of usability-oriented features
being a part of why Plan 9 hasn't been commercially successful. In
general, it seems like Plan 9 focuses on being minimal above
everything else, whereas I'd say an ideal OS should focus on being
sufficiently general and extensible in addition to being minimal (in
other words, do things in the most minimal way that is sufficiently
general and extensible).

> On the one hand the `cat -v` and
> some other concerns (like columnated ls(1) output) are valid, and very
> well understood. On the other -- lack of find(1), shell history, and
> vi are not. Well, to me at least. Both acme and sam seem to have found
> its fanbase.
>

I'd say features like history, completion, and line editing really
don't belong in a shell. They should be handled by a separate listener
process with a simple API that shells and other client processes can
use for controlling them. That's one good example of Plan 9
prioritizing minimalism above everything else.


From tytso at mit.edu  Sat Sep  1 13:23:18 2018
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Fri, 31 Aug 2018 23:23:18 -0400
Subject: [TUHS] SunOS code?
In-Reply-To: <20180901015741.GN28971@mcvoy.com>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch>
 <20180831215854.GB28971@mcvoy.com>
 <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net>
 <20180901015741.GN28971@mcvoy.com>
Message-ID: <20180901032318.GD27277@thunk.org>

On Fri, Aug 31, 2018 at 06:57:41PM -0700, Larry McVoy wrote:
> 
> But all that said, you need to be specific about what perf you care 
> about.  These days the kernel is far more complicated, NUMA etc, 
> and you might care about parallel make (I doubt it) or you might care
> about Oracle or something like that.

It wouldn't surprise me if Solaris was more scalable for gazillion
dollar SMP machines with a huge number of cores.  That was one of the
reason as I recall why Solaris had a reputation of being slow; being
scalable to big (and much more profitable) servers was considered more
important than the smaller systems that were probably more numerous
(but not nearly as profitable).

					- Ted


From dave at horsfall.org  Sat Sep  1 16:52:07 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 1 Sep 2018 16:52:07 +1000 (EST)
Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?=
In-Reply-To: <alpine.BSF.2.21.9999.1809010911470.22638@aneurin.horsfall.org>
References: <f3f250f4-cffd-794c-450a-d1c3829c890e@spamtrap.tnetconsulting.net>
 <1F62F4D0-7AD1-43C2-A9B7-CF9DF239C3D9@berlan.de>
 <f923f2ae-0463-e3e6-c0fb-55124edb92ff@spamtrap.tnetconsulting.net>
 <2e58402b-6366-4f74-757b-b7c8dd1b729c@texoma.net>
 <alpine.BSF.2.21.9999.1809010911470.22638@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.21.9999.1809011646550.22638@aneurin.horsfall.org>

On Sat, 1 Sep 2018, Dave Horsfall wrote:

> (I have tried subscribing to the "retro" list, but nothing heard yet.)

Hmmm...  Looking at my reject log, I see this:

     Date: Aug 31 17:09:49 (w7V79WBG017201)
     from=<retronet-bounces at mailman.chivanet.org>
     relay=[208.45.186.204]
     reject=550 5.7.1 <dave at horsfall.org>... Fix reverse DNS for 208.45.186.204

Would that be it?  I have some vicious spam defences here, and requiring 
rDNS (anything will do) is one of them; I could always whitelist the IP if 
it won't change, or perhaps chivanet.org if that will be the origin.

-- Dave


From dave at horsfall.org  Sat Sep  1 17:37:46 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 1 Sep 2018 17:37:46 +1000 (EST)
Subject: [TUHS] UNIX System names - since UNIX was a Trademark
In-Reply-To: <CAJfiPzwpZofM9CbjbY5z4Wp5nHxsLuSsLK4Wjd9xggy768K7ng@mail.gmail.com>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808300825340.41601@aneurin.horsfall.org>
 <20180829233605.GJ8423@mcvoy.com>
 <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com>
 <CAK7dMtDgkkkP1kGbGRt48ON1BrMkN2GSsi8bfe=EeOGT3O8esw@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808311023210.41601@aneurin.horsfall.org>
 <CAC20D2OecE9WX8o4A+VgtEi51c3_QiXQQSq7_t1YGwNK_FG8kw@mail.gmail.com>
 <3b0a2895-4a6b-48c4-87da-cc1018d7b665.maildroid@localhost>
 <CAC0cEp_7jwxdywgs8es0qSBJty3D92BM192-coNEz-EuVQi+pg@mail.gmail.com>
 <261201d44189$60c7aa50$2256fef0$@ronnatalie.com>
 <CAJfiPzwpZofM9CbjbY5z4Wp5nHxsLuSsLK4Wjd9xggy768K7ng@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.1809011711200.22638@aneurin.horsfall.org>

On Fri, 31 Aug 2018, Nemo wrote:

> (I think everyone said Slowlaris.  Even the guys from Sun who first 
> demo'd dtrace and how it was used to speed up their system calls.)

I've always called it Slowaris, mostly because my stutter stops me from 
pronouncing words starting with "r" or "l" (it comes out as "w").

And yes, I've seen "Life of Brian", and I can relate to it :-)  "Welease 
Woger" etc...

Oddly enough, I can pronounce "r" and "l" if preceded by a hard consonant, 
so I dunno...

For the morbidly curious, I was born left-handed, and, err, "encouraged" 
to use my right hand back in kindergarten, which apparently completely 
fscked up my neural connections.  As a result, I write right-handed, 
bat/bowl/throw left-handed, and am pretty much ambidextrous otherwise.

Oh, and I also trained myself to use a mouse in my left hand (in 
right-hand mode, and in my SunOS days too!) which is apparently quite 
common amongst the righties; after all, why waste a perfectly good hand? 
It's hilarious watching someone letting go of the mouse to write something 
down, then back to the mouse again...

-- Dave


From mutiny.mutiny at india.com  Sat Sep  1 20:46:31 2018
From: mutiny.mutiny at india.com (Donald ODona)
Date: Sat, 1 Sep 2018 10:46:31 +0000 (UTC)
Subject: [TUHS] SunOS code?
In-Reply-To: <20180831223034.Um9p2%ca6c@bitmessage.ch>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch>
 <20180831215854.GB28971@mcvoy.com>
 <20180831221927.zeKvq%ca6c@bitmessage.ch>
 <ff2c779d-19fa-423d-5080-18ba2d58fa7b@gmail.com>,
 <20180831223034.Um9p2%ca6c@bitmessage.ch>
Message-ID: <1029648209.250928.1535798791745.JavaMail.tomcat@india-live-be04>


At 31 Aug 2018 22:32:06 +0000 (+00:00) from "Cág" <ca6c at bitmessage.ch>:
> Then it was Elvis, nvi was written later on.

"It was originally derived from the first incarnation of elvis, written by Steve Kirkendall, as noted in the README file included in nvi's sources. "
https://en.wikipedia.org/wiki/Nvi#Credits_and_distribution


From steve.mynott at gmail.com  Sat Sep  1 21:43:52 2018
From: steve.mynott at gmail.com (Steve Mynott)
Date: Sat, 1 Sep 2018 12:43:52 +0100
Subject: [TUHS] SunOS code?
In-Reply-To: <20180829145300.GP317@mcvoy.com>
References: <f28da67c-b9af-b038-556b-f2e3012ddcff@mhorton.net>
 <CAC20D2PgjftUBz=wq2=ThZ4HU8yP1KuQ1iCWek-T4R0H17iP6Q@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808281017090.41601@aneurin.horsfall.org>
 <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org>
 <alpine.BSF.2.21.9999.1808290821350.41601@aneurin.horsfall.org>
 <c5abd058-2035-d105-2df2-3f94e5d59035@gmail.com>
 <20180829004627.GG317@mcvoy.com>
 <201808290529.w7T5TFKa006049@freefriends.org>
 <CANCZdfrcZ5Gt_+wNKZ7zqzzWaGoSPE1rtCHEDrqh4eozdnHKAQ@mail.gmail.com>
 <20180829145300.GP317@mcvoy.com>
Message-ID: <CANuZA8S33HVVCSNY32aWLXU=BttPodT75BstOy4OyAob4cwudg@mail.gmail.com>

On Wed, 29 Aug 2018 at 15:53, Larry McVoy <lm at mcvoy.com> wrote:

The BSDs have a less than optimal VM system.  Having SunOS opened up
> would at least let people see what they are missing.  Maybe I have
> rose colored glasses on but it was the only kernel that came into
> focus for me and you could see the architecture from the code.
> Everything else seems like a mess to me.
>

That may have been true in the late 80s and even early 90s but I'd have
thought FreeBSD, NetBSD and OpenBSD would have useable VMs by now.

I've vague recollections that these all originally used the VM from Mach
which did have problems at first.

I recall a more knowledgeable friend complaining about FreeBSD VM in 1994
or so.

I think the latter two use UVM and FreeBSD improved their Mach one (which
has a SunOS kvmish API anyway). I've not seen complaints about modern BSD.

S

-- 
Steve Mynott <steve.mynott at gmail.com>
cv25519/ECF8B611205B447E091246AF959E3D6197190DD5
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180901/cb08d693/attachment.html>

From akosela at andykosela.com  Sat Sep  1 23:50:05 2018
From: akosela at andykosela.com (Andy Kosela)
Date: Sat, 1 Sep 2018 15:50:05 +0200
Subject: [TUHS] SunOS code?
In-Reply-To: <CANuZA8S33HVVCSNY32aWLXU=BttPodT75BstOy4OyAob4cwudg@mail.gmail.com>
References: <f28da67c-b9af-b038-556b-f2e3012ddcff@mhorton.net>
 <CAC20D2PgjftUBz=wq2=ThZ4HU8yP1KuQ1iCWek-T4R0H17iP6Q@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808281017090.41601@aneurin.horsfall.org>
 <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org>
 <alpine.BSF.2.21.9999.1808290821350.41601@aneurin.horsfall.org>
 <c5abd058-2035-d105-2df2-3f94e5d59035@gmail.com>
 <20180829004627.GG317@mcvoy.com>
 <201808290529.w7T5TFKa006049@freefriends.org>
 <CANCZdfrcZ5Gt_+wNKZ7zqzzWaGoSPE1rtCHEDrqh4eozdnHKAQ@mail.gmail.com>
 <20180829145300.GP317@mcvoy.com>
 <CANuZA8S33HVVCSNY32aWLXU=BttPodT75BstOy4OyAob4cwudg@mail.gmail.com>
Message-ID: <CALMnNGi0z050w3qWD6Mr=CxBkwAHPa2EohYhj9P5CrGn298J9w@mail.gmail.com>

On Saturday, September 1, 2018, Steve Mynott <steve.mynott at gmail.com> wrote:

>
>
> On Wed, 29 Aug 2018 at 15:53, Larry McVoy <lm at mcvoy.com> wrote:
>
> The BSDs have a less than optimal VM system.  Having SunOS opened up
>> would at least let people see what they are missing.  Maybe I have
>> rose colored glasses on but it was the only kernel that came into
>> focus for me and you could see the architecture from the code.
>> Everything else seems like a mess to me.
>>
>
> That may have been true in the late 80s and even early 90s but I'd have
> thought FreeBSD, NetBSD and OpenBSD would have useable VMs by now.
>
> I've vague recollections that these all originally used the VM from Mach
> which did have problems at first.
>
> I recall a more knowledgeable friend complaining about FreeBSD VM in 1994
> or so.
>
> I think the latter two use UVM and FreeBSD improved their Mach one (which
> has a SunOS kvmish API anyway). I've not seen complaints about modern BSD.
>
>

Wasn't the whole FreeBSD VM rewritten by John Dyson and David Greenman in
the mid-late 90's?  And then further improved by Matthew Dillon.

Unfortunately they are not affiliated with the project anymore.  All three
had exceptional coding skills.

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

From cym224 at gmail.com  Sat Sep  1 23:54:30 2018
From: cym224 at gmail.com (Nemo)
Date: Sat, 1 Sep 2018 09:54:30 -0400
Subject: [TUHS] UNIX System names - since UNIX was a Trademark
In-Reply-To: <alpine.BSF.2.21.9999.1809011711200.22638@aneurin.horsfall.org>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808300825340.41601@aneurin.horsfall.org>
 <20180829233605.GJ8423@mcvoy.com>
 <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com>
 <CAK7dMtDgkkkP1kGbGRt48ON1BrMkN2GSsi8bfe=EeOGT3O8esw@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808311023210.41601@aneurin.horsfall.org>
 <CAC20D2OecE9WX8o4A+VgtEi51c3_QiXQQSq7_t1YGwNK_FG8kw@mail.gmail.com>
 <3b0a2895-4a6b-48c4-87da-cc1018d7b665.maildroid@localhost>
 <CAC0cEp_7jwxdywgs8es0qSBJty3D92BM192-coNEz-EuVQi+pg@mail.gmail.com>
 <261201d44189$60c7aa50$2256fef0$@ronnatalie.com>
 <CAJfiPzwpZofM9CbjbY5z4Wp5nHxsLuSsLK4Wjd9xggy768K7ng@mail.gmail.com>
 <alpine.BSF.2.21.9999.1809011711200.22638@aneurin.horsfall.org>
Message-ID: <CAJfiPzw64SWxeO64NgUH8fEq4APYxpVeexd-PQkpKiL9eWNxKg@mail.gmail.com>

On 01/09/2018, Dave Horsfall <dave at horsfall.org> wrote (in part):
> Oh, and I also trained myself to use a mouse in my left hand (in
> right-hand mode, and in my SunOS days too!) which is apparently quite
> common amongst the righties;

As did I -- I am right-handed -- but mainly because reaching over the
keypad was such a bother.

N.

> It's hilarious watching someone letting go of the mouse to write something
> down, then back to the mouse again...
>
> -- Dave
>


From imp at bsdimp.com  Sun Sep  2 00:32:23 2018
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 1 Sep 2018 08:32:23 -0600
Subject: [TUHS] SunOS code?
In-Reply-To: <CALMnNGi0z050w3qWD6Mr=CxBkwAHPa2EohYhj9P5CrGn298J9w@mail.gmail.com>
References: <f28da67c-b9af-b038-556b-f2e3012ddcff@mhorton.net>
 <CAC20D2PgjftUBz=wq2=ThZ4HU8yP1KuQ1iCWek-T4R0H17iP6Q@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808281017090.41601@aneurin.horsfall.org>
 <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org>
 <alpine.BSF.2.21.9999.1808290821350.41601@aneurin.horsfall.org>
 <c5abd058-2035-d105-2df2-3f94e5d59035@gmail.com>
 <20180829004627.GG317@mcvoy.com>
 <201808290529.w7T5TFKa006049@freefriends.org>
 <CANCZdfrcZ5Gt_+wNKZ7zqzzWaGoSPE1rtCHEDrqh4eozdnHKAQ@mail.gmail.com>
 <20180829145300.GP317@mcvoy.com>
 <CANuZA8S33HVVCSNY32aWLXU=BttPodT75BstOy4OyAob4cwudg@mail.gmail.com>
 <CALMnNGi0z050w3qWD6Mr=CxBkwAHPa2EohYhj9P5CrGn298J9w@mail.gmail.com>
Message-ID: <CANCZdfqsd4YnLZDZD5JBuayJ-dcNJSt3yWmiAjCRgVp5o0tB5w@mail.gmail.com>

On Sat, Sep 1, 2018 at 7:50 AM Andy Kosela <akosela at andykosela.com> wrote:

>
>
> On Saturday, September 1, 2018, Steve Mynott <steve.mynott at gmail.com>
> wrote:
>
>>
>>
>> On Wed, 29 Aug 2018 at 15:53, Larry McVoy <lm at mcvoy.com> wrote:
>>
>> The BSDs have a less than optimal VM system.  Having SunOS opened up
>>> would at least let people see what they are missing.  Maybe I have
>>> rose colored glasses on but it was the only kernel that came into
>>> focus for me and you could see the architecture from the code.
>>> Everything else seems like a mess to me.
>>>
>>
>> That may have been true in the late 80s and even early 90s but I'd have
>> thought FreeBSD, NetBSD and OpenBSD would have useable VMs by now.
>>
>> I've vague recollections that these all originally used the VM from Mach
>> which did have problems at first.
>>
>
Yes. CSRG used Mach VM because it was available, not because it was
awesome. The folks at CSRG approached Sun to have them donate their VM to
BSD, and there were serious talks about doing this until the lawyers got
involved and explained that would require a serious write down on their
quarterly report so that nixed the whole thing.


> I recall a more knowledgeable friend complaining about FreeBSD VM in 1994
>> or so.
>>
>
It used to be downright aweful.


> I think the latter two use UVM and FreeBSD improved their Mach one (which
>> has a SunOS kvmish API anyway). I've not seen complaints about modern BSD.
>>
>
OpenBSD and NetBSD both moved to uvm.


> Wasn't the whole FreeBSD VM rewritten by John Dyson and David Greenman in
> the mid-late 90's?  And then further improved by Matthew Dillon.
>
> Unfortunately they are not affiliated with the project anymore.  All three
> had exceptional coding skills.
>

With the exception of David, it's not unfortunate at all. Although they
were good for the project's code, they weren't good for the project. They
didn't work well with others and caused much more grief than the code they
contributed. There comes a time when there's just too much drama and the
rest of the code gets much much better when you aren't always fighting
drama :(. It was a tough decision to make when I was on the core team to
show Dillon the door. One not made lightly, nor without a lot of effort to
work through the issues. In the end, though, we had to part ways. Dillon
has done well with DragonFly, however.

In the last 10 years or so there's been a number of people that have
stepped up and replaced them, most notably Allan Cox and Mark Johnston who
have mad coding skills and can play well with others. Though I'm sure I'm
slighting several people by not mentioning them.

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

From lm at mcvoy.com  Sun Sep  2 01:01:09 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 1 Sep 2018 08:01:09 -0700
Subject: [TUHS] SunOS code?
In-Reply-To: <CANuZA8S33HVVCSNY32aWLXU=BttPodT75BstOy4OyAob4cwudg@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1808281017090.41601@aneurin.horsfall.org>
 <20180828003057.GA317@mcvoy.com>
 <201808280601.w7S61oLM030628@freefriends.org>
 <alpine.BSF.2.21.9999.1808290821350.41601@aneurin.horsfall.org>
 <c5abd058-2035-d105-2df2-3f94e5d59035@gmail.com>
 <20180829004627.GG317@mcvoy.com>
 <201808290529.w7T5TFKa006049@freefriends.org>
 <CANCZdfrcZ5Gt_+wNKZ7zqzzWaGoSPE1rtCHEDrqh4eozdnHKAQ@mail.gmail.com>
 <20180829145300.GP317@mcvoy.com>
 <CANuZA8S33HVVCSNY32aWLXU=BttPodT75BstOy4OyAob4cwudg@mail.gmail.com>
Message-ID: <20180901150109.GT28971@mcvoy.com>

On Sat, Sep 01, 2018 at 12:43:52PM +0100, Steve Mynott wrote:
> On Wed, 29 Aug 2018 at 15:53, Larry McVoy <lm at mcvoy.com> wrote:
> The BSDs have a less than optimal VM system.  Having SunOS opened up
> > would at least let people see what they are missing.  Maybe I have
> > rose colored glasses on but it was the only kernel that came into
> > focus for me and you could see the architecture from the code.
> > Everything else seems like a mess to me.
> >
> 
> That may have been true in the late 80s and even early 90s but I'd have
> thought FreeBSD, NetBSD and OpenBSD would have useable VMs by now.

I wandered through the FreeBSD VM recently.  Perhaps I'm just old and
tired but it looked pretty messy to me.  Still Mach based and the
Mach VM system, which came about at about the same time as the SunOS
VM system, doesn't remotely compare.  Sun had some exceptional
talent at the time, there was a reason I fought hard to join that
group, I wanted to work with people who were better than me.


From imp at bsdimp.com  Sun Sep  2 01:20:49 2018
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 1 Sep 2018 09:20:49 -0600
Subject: [TUHS] SunOS code?
In-Reply-To: <20180901150109.GT28971@mcvoy.com>
References: <alpine.BSF.2.21.9999.1808281017090.41601@aneurin.horsfall.org>
 <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org>
 <alpine.BSF.2.21.9999.1808290821350.41601@aneurin.horsfall.org>
 <c5abd058-2035-d105-2df2-3f94e5d59035@gmail.com>
 <20180829004627.GG317@mcvoy.com>
 <201808290529.w7T5TFKa006049@freefriends.org>
 <CANCZdfrcZ5Gt_+wNKZ7zqzzWaGoSPE1rtCHEDrqh4eozdnHKAQ@mail.gmail.com>
 <20180829145300.GP317@mcvoy.com>
 <CANuZA8S33HVVCSNY32aWLXU=BttPodT75BstOy4OyAob4cwudg@mail.gmail.com>
 <20180901150109.GT28971@mcvoy.com>
Message-ID: <CANCZdfptkUFVC27aWeLUY1Wh3=XgwHmUXznO5CB8P6OGixP2Qw@mail.gmail.com>

On Sat, Sep 1, 2018 at 9:01 AM Larry McVoy <lm at mcvoy.com> wrote:

> On Sat, Sep 01, 2018 at 12:43:52PM +0100, Steve Mynott wrote:
> > On Wed, 29 Aug 2018 at 15:53, Larry McVoy <lm at mcvoy.com> wrote:
> > The BSDs have a less than optimal VM system.  Having SunOS opened up
> > > would at least let people see what they are missing.  Maybe I have
> > > rose colored glasses on but it was the only kernel that came into
> > > focus for me and you could see the architecture from the code.
> > > Everything else seems like a mess to me.
> > >
> >
> > That may have been true in the late 80s and even early 90s but I'd have
> > thought FreeBSD, NetBSD and OpenBSD would have useable VMs by now.
>
> I wandered through the FreeBSD VM recently.  Perhaps I'm just old and
> tired but it looked pretty messy to me.  Still Mach based and the
> Mach VM system, which came about at about the same time as the SunOS
> VM system, doesn't remotely compare.  Sun had some exceptional
> talent at the time, there was a reason I fought hard to join that
> group, I wanted to work with people who were better than me.
>

It is still technically mach based, but it's fixed most of the scalability
issues Mach had (and that MacOS still has).

There's much clutter in the VM, and there's areas that could stand to be
rewritten, or to get at least a good cleaning.

The SunOS vm was far superior in its day, and likely is still cleaner than
what's in FreeBSD. But it can't scale like FreeBSD's vm (or NetBSD's or
even MacOS's) because it hasn't had the same care and feeding for the last
25 years. It's still single threaded and hasn't had the care and feeding to
make it perform well in MP situations. Solbourne spent years hacking it to
make it scale better, but even with 16 processors that was the high end for
them, and they were barely 10x faster than a uniprocessor for many work
loads due, in part, to vm contention limiting scalability. We had 2 8 CPU
machines that could build our software ~20% faster (with netmake) than the
1 16 CPU machine the OS group had, for example... I recall many discussions
with Dave Barak who did the fine-grained work on the 4.0 SunOS kernel
complaining about how many of the clever tricks in different subsystems
that worked great on UP were terrible for MP...

I don't doubt we'd be in an even better place today if we'd started with
the SunOS vm system in 4.4BSD rather than mach. Don't get me wrong. And
I'll not be the first in line to defend its elegance or clarity of design
(in fact, it has many design issues that took a decade to recode to
properly scale, and we're still not done). And lord knows even though I'm
not close to the foremost expert in the vm, I could easily put together an
hour or two talk on how all the areas of the VM that are holding us back.
Yet even with all that, I think that the ugly, warty, co-evolved code we
have in FreeBSD performs better than the SunOS vm code on any objective
benchmark you could have.

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

From gtaylor at tnetconsulting.net  Sun Sep  2 02:16:01 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Sat, 1 Sep 2018 10:16:01 -0600
Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?=
In-Reply-To: <alpine.BSF.2.21.9999.1809011646550.22638@aneurin.horsfall.org>
References: <f3f250f4-cffd-794c-450a-d1c3829c890e@spamtrap.tnetconsulting.net>
 <1F62F4D0-7AD1-43C2-A9B7-CF9DF239C3D9@berlan.de>
 <f923f2ae-0463-e3e6-c0fb-55124edb92ff@spamtrap.tnetconsulting.net>
 <2e58402b-6366-4f74-757b-b7c8dd1b729c@texoma.net>
 <alpine.BSF.2.21.9999.1809010911470.22638@aneurin.horsfall.org>
 <alpine.BSF.2.21.9999.1809011646550.22638@aneurin.horsfall.org>
Message-ID: <ad5a9a1c-5cee-073e-6371-fdb3269eef5e@spamtrap.tnetconsulting.net>

On 09/01/2018 12:52 AM, Dave Horsfall wrote:
> Hmmm...  Looking at my reject log, I see this:
> 
>      Date: Aug 31 17:09:49 (w7V79WBG017201)
>      from=<retronet-bounces at mailman.chivanet.org>
>      relay=[208.45.186.204]
>      reject=550 5.7.1 <dave at horsfall.org>... Fix reverse DNS for 
> 208.45.186.204
> 
> Would that be it?

Yep, that's it.

> I have some vicious spam defences here, and requiring rDNS (anything will 
> do) is one of them; I could always whitelist the IP if it won't change, 
> or perhaps chivanet.org if that will be the origin.

I think that JPW was going to email you directly (reply to the message I 
sent you).

TL;DR:  His T1 upstream won't play ball.

I added an entry to my hosts file and things have been fine for me.



-- 
Grant. . . .
unix || die

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

From kevin.bowling at kev009.com  Sun Sep  2 02:27:46 2018
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Sat, 1 Sep 2018 09:27:46 -0700
Subject: [TUHS] SunOS code?
In-Reply-To: <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com>
 <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net>
Message-ID: <CAK7dMtB8AmPG5ZMceGZdD8sxL10horfO0ZYLfXuX=4Dp8u7bwQ@mail.gmail.com>

On Fri, Aug 31, 2018 at 4:02 PM, Arthur Krewat <krewat at kilonet.net> wrote:
> On 8/31/2018 5:58 PM, Larry McVoy wrote:
>>
>>
>> Solaris was Sys Vr4 (which, if I recall correctly, differed from r3
>> largely due to some stuff being ported over from SunOS).  Both the kernel
>> and user space went to a Sys V compat system, it no longer felt anything
>> like BSD.
>>
>
> I would be very interested in anyone's recollections of how Solaris
> eventually turned out performance-wise, say version 9+, compared to other
> operating systems. SunOS, Linux, AIX, etc.

Linux started pulling away fast even on high end systems by the early
2000s.  IBM and SGI dumped a ton of money, knowledge, and talent into
this.  By Linux kernel 2.6 the race was entirely won.

After this HP-UX, AIX, and Solaris persist mainly in mainframe-like
vertical stacks used mainly to host mission critical applications that
are sold in bundles or "solutions"

> I find it's about equal, and even exceeds Linux in terms of it's NUMA
> support and multi-processor support. I need to move some systems away from
> Solaris and off to Linux, and I find it's NUMA support lacking in certain
> ways.

This is pure fantasy.  To understand Linux performance on high core
count and multi-socket machines is to have at least passing knowledge
of Paul McKenney's genius work on RCU [1] and NUMA [2] at Sequent [3]
and on Linux.  IBM bought Sequent, made a favorable patent grant of
RCU for Linux, and the rest history.

There is a single feature I have seen in Solaris NUMA that should be
implemented elsewhere.  It does a micro-benchmark on boot to figure
out the inter-core latency map.  On stupid technology like Intel's
ACPI and Xeon Cluster-on-Die and Sub-NUMA-Clustering, you get bogus
data back in the SRAT table describing where the cores are on the on
chip network it just chops things in half and doesn't reflect where
the cores actually were fused off for yield or binning reasons which
is statistically almost always asymmetric.  On better engineered
technology like IBM's POWER8/9 and OPAL firmware, you get the real
locality information of where cores and cache groups actually are.
Solaris' neat little micro-benchmark would work optimally even on the
brain damaged data from Intel.

[1] http://www2.rdrop.com/~paulmck/RCU/
[2] http://www2.rdrop.com/~paulmck/scalability/
[3] http://www2.rdrop.com/~paulmck/techreports/stingcacm3.1999.08.04a.pdf

Regards,
Kevin


From kevin.bowling at kev009.com  Sun Sep  2 02:29:31 2018
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Sat, 1 Sep 2018 09:29:31 -0700
Subject: [TUHS] SunOS code?
In-Reply-To: <20180901032318.GD27277@thunk.org>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com>
 <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net>
 <20180901015741.GN28971@mcvoy.com>
 <20180901032318.GD27277@thunk.org>
Message-ID: <CAK7dMtCTWAbVJNv+xSaGS+NmzFsR_+0+SR55Ajt4Qq-fp9QmUg@mail.gmail.com>

I am surprised how good Sun's technical marketing was for you to think
this.  Linux has scaled better since the early 2000s.  The Solaris
x86-64 port has some real gaffes in it to this day at least as visible
in the OpenSolaris derivative codebases, serialization in the locking
primitives kind of things.

On Fri, Aug 31, 2018 at 8:23 PM, Theodore Y. Ts'o <tytso at mit.edu> wrote:
> On Fri, Aug 31, 2018 at 06:57:41PM -0700, Larry McVoy wrote:
>>
>> But all that said, you need to be specific about what perf you care
>> about.  These days the kernel is far more complicated, NUMA etc,
>> and you might care about parallel make (I doubt it) or you might care
>> about Oracle or something like that.
>
> It wouldn't surprise me if Solaris was more scalable for gazillion
> dollar SMP machines with a huge number of cores.  That was one of the
> reason as I recall why Solaris had a reputation of being slow; being
> scalable to big (and much more profitable) servers was considered more
> important than the smaller systems that were probably more numerous
> (but not nearly as profitable).
>
>                                         - Ted


From lm at mcvoy.com  Sun Sep  2 02:35:24 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 1 Sep 2018 09:35:24 -0700
Subject: [TUHS] SunOS code?
In-Reply-To: <CAK7dMtCTWAbVJNv+xSaGS+NmzFsR_+0+SR55Ajt4Qq-fp9QmUg@mail.gmail.com>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch>
 <20180831215854.GB28971@mcvoy.com>
 <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net>
 <20180901015741.GN28971@mcvoy.com>
 <20180901032318.GD27277@thunk.org>
 <CAK7dMtCTWAbVJNv+xSaGS+NmzFsR_+0+SR55Ajt4Qq-fp9QmUg@mail.gmail.com>
Message-ID: <20180901163524.GX28971@mcvoy.com>

On Sat, Sep 01, 2018 at 09:29:31AM -0700, Kevin Bowling wrote:
> I am surprised how good Sun's technical marketing was for you to think
> this.  Linux has scaled better since the early 2000s.  The Solaris
> x86-64 port has some real gaffes in it to this day at least as visible
> in the OpenSolaris derivative codebases, serialization in the locking
> primitives kind of things.

I think the SPARC bias was very apparent.  Sun loved their own chips, to
their detriment IMO.  I have no personal knowledge of the x86_64 efforts,
but I do know about the Sun i386 efforts.  That was very looked down
upon by the powers that were, the main kernel group, etc.  Those poor
guys had an uphill battle to get anything integrated, nobody wanted it.

So it would not surprise me in the slightest if the x86_64 was a half
assed effort without a lot of attention to stuff like performance.
I don't think they wanted Solaris/x86 to be a success, they wanted
SPARC to be a success.

It was that kind of attitude that has pissed me off at every company
I have ever worked for.  I'm fine with marketing to customers but I
hate it when people believe their own marketing.  Internally, I think
you should be very skeptical, judgemental, critical, whatever you want
to call it, if your code sucks or your hardware sucks, don't pretend
it doesn't, own it and fix it.  That's how you win.

> On Fri, Aug 31, 2018 at 8:23 PM, Theodore Y. Ts'o <tytso at mit.edu> wrote:
> > On Fri, Aug 31, 2018 at 06:57:41PM -0700, Larry McVoy wrote:
> >>
> >> But all that said, you need to be specific about what perf you care
> >> about.  These days the kernel is far more complicated, NUMA etc,
> >> and you might care about parallel make (I doubt it) or you might care
> >> about Oracle or something like that.
> >
> > It wouldn't surprise me if Solaris was more scalable for gazillion
> > dollar SMP machines with a huge number of cores.  That was one of the
> > reason as I recall why Solaris had a reputation of being slow; being
> > scalable to big (and much more profitable) servers was considered more
> > important than the smaller systems that were probably more numerous
> > (but not nearly as profitable).
> >
> >                                         - Ted

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


From paul.winalski at gmail.com  Sun Sep  2 03:03:16 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Sat, 1 Sep 2018 13:03:16 -0400
Subject: [TUHS] UNIX System names - since UNIX was a Trademark
In-Reply-To: <alpine.BSF.2.21.9999.1809011711200.22638@aneurin.horsfall.org>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808300825340.41601@aneurin.horsfall.org>
 <20180829233605.GJ8423@mcvoy.com>
 <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com>
 <CAK7dMtDgkkkP1kGbGRt48ON1BrMkN2GSsi8bfe=EeOGT3O8esw@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808311023210.41601@aneurin.horsfall.org>
 <CAC20D2OecE9WX8o4A+VgtEi51c3_QiXQQSq7_t1YGwNK_FG8kw@mail.gmail.com>
 <3b0a2895-4a6b-48c4-87da-cc1018d7b665.maildroid@localhost>
 <CAC0cEp_7jwxdywgs8es0qSBJty3D92BM192-coNEz-EuVQi+pg@mail.gmail.com>
 <261201d44189$60c7aa50$2256fef0$@ronnatalie.com>
 <CAJfiPzwpZofM9CbjbY5z4Wp5nHxsLuSsLK4Wjd9xggy768K7ng@mail.gmail.com>
 <alpine.BSF.2.21.9999.1809011711200.22638@aneurin.horsfall.org>
Message-ID: <CABH=_VSUfT0eQY9gnKJqYOfNC_9E3=OGuhFicv26-rFxJNKMNA@mail.gmail.com>

On 9/1/18, Dave Horsfall <dave at horsfall.org> wrote:
>
> Oh, and I also trained myself to use a mouse in my left hand (in
> right-hand mode, and in my SunOS days too!) which is apparently quite
> common amongst the righties; after all, why waste a perfectly good hand?
> It's hilarious watching someone letting go of the mouse to write something
> down, then back to the mouse again...

I'm left-handed but I trained myself to use a mouse in my right hand,
for the reason you point out--I still have my dominant hand free to
write things down.  It also means that when I'm using someone else's
machine, most of the time their mouse is configured the way I'm used
to.

-Paul W.


From krewat at kilonet.net  Sun Sep  2 03:17:59 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Sat, 1 Sep 2018 13:17:59 -0400
Subject: [TUHS] SunOS code?
In-Reply-To: <CAK7dMtB8AmPG5ZMceGZdD8sxL10horfO0ZYLfXuX=4Dp8u7bwQ@mail.gmail.com>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com>
 <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net>
 <CAK7dMtB8AmPG5ZMceGZdD8sxL10horfO0ZYLfXuX=4Dp8u7bwQ@mail.gmail.com>
Message-ID: <ee7772a4-c23a-3344-4f10-c561047ffbb5@kilonet.net>

On 9/1/2018 12:27 PM, Kevin Bowling wrote:
>> I find it's about equal, and even exceeds Linux in terms of it's NUMA
>> support and multi-processor support. I need to move some systems away from
>> Solaris and off to Linux, and I find it's NUMA support lacking in certain
>> ways.
> This is pure fantasy.  To understand Linux performance on high core
> count and multi-socket machines is to have at least passing knowledge
> of Paul McKenney's genius work on RCU [1] and NUMA [2] at Sequent [3]
> and on Linux.  IBM bought Sequent, made a favorable patent grant of
> RCU for Linux, and the rest history.

Thanks :) - I'm basing this on Oracle database performance, for the most 
part, and it's weird way of supporting NUMA on Linux in a bass-ackwards 
sort of way. Nothing I see in the latest RedHat/CentOS tells me it even 
cares about NUMA, but maybe that's more of their "we know better than 
you" mentality and it's all hidden under the covers somewhere.

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

From steve.mynott at gmail.com  Sun Sep  2 04:24:43 2018
From: steve.mynott at gmail.com (Steve Mynott)
Date: Sat, 1 Sep 2018 19:24:43 +0100
Subject: [TUHS] SunOS code?
In-Reply-To: <CANCZdfptkUFVC27aWeLUY1Wh3=XgwHmUXznO5CB8P6OGixP2Qw@mail.gmail.com>
References: <201808280601.w7S61oLM030628@freefriends.org>
 <alpine.BSF.2.21.9999.1808290821350.41601@aneurin.horsfall.org>
 <c5abd058-2035-d105-2df2-3f94e5d59035@gmail.com>
 <20180829004627.GG317@mcvoy.com>
 <201808290529.w7T5TFKa006049@freefriends.org>
 <CANCZdfrcZ5Gt_+wNKZ7zqzzWaGoSPE1rtCHEDrqh4eozdnHKAQ@mail.gmail.com>
 <20180829145300.GP317@mcvoy.com>
 <CANuZA8S33HVVCSNY32aWLXU=BttPodT75BstOy4OyAob4cwudg@mail.gmail.com>
 <20180901150109.GT28971@mcvoy.com>
 <CANCZdfptkUFVC27aWeLUY1Wh3=XgwHmUXznO5CB8P6OGixP2Qw@mail.gmail.com>
Message-ID: <20180901182442.GA29206@sunny.my.domain>

There is a paper on the SunOS 4 VM available at

<https://web.archive.org/web/20000817230720/http://www.sun.com/smcc/solaris-migration/docs/postscript/vm-impl.ps>

(for some reason I always forget the ghostview binary is actually called
gv the rare time I use it!)

Some basic grepping suggests at least some of the tags in the paper were
still in use in Open Solaris at:

<https://github.com/illumos/illumos-gate/tree/master/usr/src/uts/common/vm>

There is a paper on UVM as well.

<https://www.usenix.org/legacy/event/usenix99/full_papers/cranor/cranor.pdf>

This says the original 4.4BSD Mach VM suffered from "swap memory leak
deadlock" and claims of its sibling (at least in 1999) that although the
FreeBSD VM is improved that "it still suffers from the object chaining
model it inherited".

The FreeBSD VM was documented before 2013 in

<https://www.freebsd.org/doc/en_US.ISO8859-1/articles/vm-design/article.html>

"Much of the apparent complexity of the FreeBSD design, especially in
the VM/Swap subsystem, is a direct result of having to solve serious
performance issues that occur under various conditions."

-- 
Steve Mynott <steve.mynott at gmail.com>
cv25519/ECF8B611205B447E091246AF959E3D6197190DD5


From lm at mcvoy.com  Sun Sep  2 04:38:48 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 1 Sep 2018 11:38:48 -0700
Subject: [TUHS] SunOS code?
In-Reply-To: <20180901182442.GA29206@sunny.my.domain>
References: <alpine.BSF.2.21.9999.1808290821350.41601@aneurin.horsfall.org>
 <c5abd058-2035-d105-2df2-3f94e5d59035@gmail.com>
 <20180829004627.GG317@mcvoy.com>
 <201808290529.w7T5TFKa006049@freefriends.org>
 <CANCZdfrcZ5Gt_+wNKZ7zqzzWaGoSPE1rtCHEDrqh4eozdnHKAQ@mail.gmail.com>
 <20180829145300.GP317@mcvoy.com>
 <CANuZA8S33HVVCSNY32aWLXU=BttPodT75BstOy4OyAob4cwudg@mail.gmail.com>
 <20180901150109.GT28971@mcvoy.com>
 <CANCZdfptkUFVC27aWeLUY1Wh3=XgwHmUXznO5CB8P6OGixP2Qw@mail.gmail.com>
 <20180901182442.GA29206@sunny.my.domain>
Message-ID: <20180901183848.GD28971@mcvoy.com>

All of those papers are here:

http://mcvoy.com/lm/papers/
	SunOS.nvram.pdf
	SunOS.shlib.pdf
	SunOS.smoosh.pdf
	SunOS.tfs.pdf
	SunOS.ufs_clustering.pdf
	SunOS.vfs_arch.pdf
	SunOS.vm_arch.pdf
	SunOS.vm_impl.pdf

If you have pointers to a paper that is Sun related that I don't have 
I'd like to see that.

> <https://web.archive.org/web/20000817230720/http://www.sun.com/smcc/solaris-migration/docs/postscript/vm-impl.ps>
> 
> There is a paper on UVM as well.
> 
> <https://www.usenix.org/legacy/event/usenix99/full_papers/cranor/cranor.pdf>

That's interesting, reading.



From lm at mcvoy.com  Sun Sep  2 04:50:53 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 1 Sep 2018 11:50:53 -0700
Subject: [TUHS] UVM VM system
Message-ID: <20180901185053.GA20993@mcvoy.com>

So I just read this

https://www.usenix.org/legacy/event/usenix99/full_papers/cranor/cranor.pdf

and it looks encouraging.  Apparently NetBSD is using it.  Does anyone
know if they are happy with it?

Has FreeBSD considered this?

Has anyone benchmarked FreeBSD against NetBSD to see which is faster
for VM stuff?


From imp at bsdimp.com  Sun Sep  2 05:07:45 2018
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 1 Sep 2018 13:07:45 -0600
Subject: [TUHS] UVM VM system
In-Reply-To: <20180901185053.GA20993@mcvoy.com>
References: <20180901185053.GA20993@mcvoy.com>
Message-ID: <CANCZdfqR8JePBjQieotr8UN2+3+tM2LYrvZ8RR6m3+dKwGaFkA@mail.gmail.com>

On Sat, Sep 1, 2018 at 12:51 PM Larry McVoy <lm at mcvoy.com> wrote:

> So I just read this
>
> https://www.usenix.org/legacy/event/usenix99/full_papers/cranor/cranor.pdf
>
> and it looks encouraging.  Apparently NetBSD is using it.  Does anyone
> know if they are happy with it?
>

They are relatively happy with it...


> Has FreeBSD considered this?
>

Yes, but it would be a huge porting effort.


> Has anyone benchmarked FreeBSD against NetBSD to see which is faster
> for VM stuff?
>

Generally, the benchmarks favor FreeBSD. Again, it's a cleaner design, but
the time spent optimizing FreeBSD's and eliminating the bottle necks has
paid off...

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

From clemc at ccc.com  Sun Sep  2 05:16:42 2018
From: clemc at ccc.com (Clem Cole)
Date: Sat, 1 Sep 2018 15:16:42 -0400
Subject: [TUHS] UVM VM system
In-Reply-To: <20180901185053.GA20993@mcvoy.com>
References: <20180901185053.GA20993@mcvoy.com>
Message-ID: <CAC20D2OXVo0ng5bnpjVO_uLRLqGo3ROxhCNdJaTmr8qa3Nb_EQ@mail.gmail.com>

On Sat, Sep 1, 2018 at 2:51 PM Larry McVoy <lm at mcvoy.com> wrote:

> So I just read this
>
> https://www.usenix.org/legacy/event/usenix99/full_papers/cranor/cranor.pdf

I remember that presentsation, it was exciting and very cool ;-)



>
>
> and it looks encouraging.  Apparently NetBSD is using it.

Hmm - integrated/used it at one time ... but ... I'm not sure of that is
still true of it it even really made it out.  That was all happening when I
was still hacking on Alphas (which was a long time ago).   We'd need the
active NetBSD folks to chime in on curent state.



>   Does anyone
>
> know if they are happy with it?
>
At the time (and I'm doing this by memory) the buffer cache stuff needed a
rewrite which I thought FreeBSD did/was doing at the time.
In those days, FreeBSD was within epislon on of Tru64 on Alpha performance
and NetBSD had a ways to go.  At the time, I gave a couple of Alphas to
somebody in the UK (I've forgotten whom); who was going to redo it.



>
> Has FreeBSD considered this?
>
Last I knew, no.  I was under the impression, the work FreeBSD did
rewriting the Mach stuff paid off for them at the time.  I have FreeBSD,
OpenBSD and Linux (and Mac OSx) all running on my systems here.   But the
problem is that the HW is all over the map in termns of release date, so
I'm not sure which is faster at this point.   The *BSD systems are the
easiest to admin and clean/simplest (which is why they only systems I have
exposed is an OpenBSD box).  But they have uses ;-)



>
> Has anyone benchmarked FreeBSD against NetBSD to see which is faster
> for VM stuff?
>

My data was from those days, and FreeBSD was winning, but thats a >>long<<
time ago.  Lots of bits have been types into to the kernel of both systems,
so you tell me,

Clem

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

From clemc at ccc.com  Sun Sep  2 05:32:18 2018
From: clemc at ccc.com (Clem Cole)
Date: Sat, 1 Sep 2018 15:32:18 -0400
Subject: [TUHS] SunOS code?
In-Reply-To: <20180901163524.GX28971@mcvoy.com>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com>
 <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net>
 <20180901015741.GN28971@mcvoy.com>
 <20180901032318.GD27277@thunk.org>
 <CAK7dMtCTWAbVJNv+xSaGS+NmzFsR_+0+SR55Ajt4Qq-fp9QmUg@mail.gmail.com>
 <20180901163524.GX28971@mcvoy.com>
Message-ID: <CAC20D2OL2=Nwij_wmA7xDNBHH6g_1xB2bPu4n1sOpLM=fGuj=Q@mail.gmail.com>

below...

On Sat, Sep 1, 2018 at 12:35 PM Larry McVoy <lm at mcvoy.com> wrote:

>
> It was that kind of attitude that has pissed me off at every company
> I have ever worked for.  I'm fine with marketing to customers but I
> hate it when people believe their own marketing.  Internally, I think
> you should be very skeptical, judgemental, critical, whatever you want
> to call it, if your code sucks or your hardware sucks, don't pretend
> it doesn't, own it and fix it.  That's how you win.
>

Amen....
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180901/1484ab7d/attachment.html>

From rminnich at gmail.com  Sun Sep  2 05:41:54 2018
From: rminnich at gmail.com (ron minnich)
Date: Sat, 1 Sep 2018 12:41:54 -0700
Subject: [TUHS] UVM VM system
In-Reply-To: <CAC20D2OXVo0ng5bnpjVO_uLRLqGo3ROxhCNdJaTmr8qa3Nb_EQ@mail.gmail.com>
References: <20180901185053.GA20993@mcvoy.com>
 <CAC20D2OXVo0ng5bnpjVO_uLRLqGo3ROxhCNdJaTmr8qa3Nb_EQ@mail.gmail.com>
Message-ID: <CAP6exYKs9H=GKxeOxu6vcf1By3CZP-Hjk0K1dPgfH67K=WQNQQ@mail.gmail.com>

I was his advisor on that thesis so I got to watch it roll out as it
happened.

uvm replaced the machvm in netbsd.

For a time, Chuck set it up to run in parallel with the existing VM. You
could start a process and pick which vm it used. For a while, it defaulted
to the existing one. Then, at some point, it defaulted to uvm. Then, at
some point, the old one was removed.

more here:

http://www.netbsd.org/docs/kernel/uvm.html

via search terms
uvm replaces machvm netbsd

chuck was a long time contributor to netbsd IIRC, but last time we talked,
he was using Linux.

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

From rminnich at gmail.com  Sun Sep  2 05:45:28 2018
From: rminnich at gmail.com (ron minnich)
Date: Sat, 1 Sep 2018 12:45:28 -0700
Subject: [TUHS] UVM VM system
In-Reply-To: <CAP6exYKs9H=GKxeOxu6vcf1By3CZP-Hjk0K1dPgfH67K=WQNQQ@mail.gmail.com>
References: <20180901185053.GA20993@mcvoy.com>
 <CAC20D2OXVo0ng5bnpjVO_uLRLqGo3ROxhCNdJaTmr8qa3Nb_EQ@mail.gmail.com>
 <CAP6exYKs9H=GKxeOxu6vcf1By3CZP-Hjk0K1dPgfH67K=WQNQQ@mail.gmail.com>
Message-ID: <CAP6exYLGAU29hYjGbzbCGbfdQHvLgMPQzTs7ZPFTuhTVKwn9Uw@mail.gmail.com>

I said that wrong, I was not his advisor, Guru was;I was the external
committee member or external advisor or some such thing.  Chuck and I
talked an awful lot because I was doing a lot in the sunos and AIX VMs at
the time, and Chuck and I had known each other from udel days.



On Sat, Sep 1, 2018 at 12:41 PM ron minnich <rminnich at gmail.com> wrote:

> I was his advisor on that thesis so I got to watch it roll out as it
> happened.
>
> uvm replaced the machvm in netbsd.
>
> For a time, Chuck set it up to run in parallel with the existing VM. You
> could start a process and pick which vm it used. For a while, it defaulted
> to the existing one. Then, at some point, it defaulted to uvm. Then, at
> some point, the old one was removed.
>
> more here:
>
> http://www.netbsd.org/docs/kernel/uvm.html
>
> via search terms
> uvm replaces machvm netbsd
>
> chuck was a long time contributor to netbsd IIRC, but last time we talked,
> he was using Linux.
>
> ron
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180901/42f30523/attachment.html>

From brad at anduin.eldar.org  Sun Sep  2 05:53:25 2018
From: brad at anduin.eldar.org (Brad Spencer)
Date: Sat, 01 Sep 2018 15:53:25 -0400
Subject: [TUHS] UVM VM system
In-Reply-To: <CAC20D2OXVo0ng5bnpjVO_uLRLqGo3ROxhCNdJaTmr8qa3Nb_EQ@mail.gmail.com> (message
 from Clem Cole on Sat, 1 Sep 2018 15:16:42 -0400)
Message-ID: <xon7ek50zbe.fsf@anduin.eldar.org>

Clem Cole <clemc at ccc.com> writes:

[snip]

>> and it looks encouraging.  Apparently NetBSD is using it.
>
> Hmm - integrated/used it at one time ... but ... I'm not sure of that is
> still true of it it even really made it out.  That was all happening when I
> was still hacking on Alphas (which was a long time ago).   We'd need the
> active NetBSD folks to chime in on curent state.
>

[snip]




Yes, UVM has been used with NetBSD for a very long time.  The browseable
CVS repo at www.netbsd.org suggests that work started in 1997 - 1998 or
so.  Looks like in 1999 the Mach VM was completely removed from NetBSD
except for some include files, but clean up appears to have continued
into 2000.



-- 
Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org


From imp at bsdimp.com  Sun Sep  2 06:25:55 2018
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 1 Sep 2018 14:25:55 -0600
Subject: [TUHS] UVM VM system
In-Reply-To: <CAP6exYKs9H=GKxeOxu6vcf1By3CZP-Hjk0K1dPgfH67K=WQNQQ@mail.gmail.com>
References: <20180901185053.GA20993@mcvoy.com>
 <CAC20D2OXVo0ng5bnpjVO_uLRLqGo3ROxhCNdJaTmr8qa3Nb_EQ@mail.gmail.com>
 <CAP6exYKs9H=GKxeOxu6vcf1By3CZP-Hjk0K1dPgfH67K=WQNQQ@mail.gmail.com>
Message-ID: <CANCZdfogHqPr6GQ50y_8gVrhnNG-KxPWARuAoGHbKNOL_BKU6A@mail.gmail.com>

On Sat, Sep 1, 2018, 1:42 PM ron minnich <rminnich at gmail.com> wrote:

> I was his advisor on that thesis so I got to watch it roll out as it
> happened.
>
> uvm replaced the machvm in netbsd.
>
> For a time, Chuck set it up to run in parallel with the existing VM. You
> could start a process and pick which vm it used. For a while, it defaulted
> to the existing one. Then, at some point, it defaulted to uvm. Then, at
> some point, the old one was removed.
>
> more here:
>
> http://www.netbsd.org/docs/kernel/uvm.html
>
> via search terms
> uvm replaces machvm netbsd
>
> chuck was a long time contributor to netbsd IIRC, but last time we talked,
> he was using Linux.
>

These days I know he's hacking on FreeBSD's storage stack with me at work
:). I think he's still a netbsd contributor. I see his name in the commit
log often..

Warner

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

From will.senn at gmail.com  Sun Sep  2 06:31:21 2018
From: will.senn at gmail.com (Will Senn)
Date: Sat, 1 Sep 2018 15:31:21 -0500
Subject: [TUHS] Public access multics
Message-ID: <899D86D7-1601-4FDA-869A-10EC46500D0D@gmail.com>

So, it looks like someone has gone and started running a multics instance:

http://lists.nycbug.org/pipermail/semibug/2018-August/000288.html

That’s interesting, and y’all may even have been aware of it. But, I was thinking that Multics was a failed predecessor of unix and it’s craziness an inspiration for how unix isn’t multics... straighten me out :)

Will



Sent from my iPhone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180901/980d84e5/attachment.html>

From clemc at ccc.com  Sun Sep  2 06:50:40 2018
From: clemc at ccc.com (Clem Cole)
Date: Sat, 1 Sep 2018 16:50:40 -0400
Subject: [TUHS] Fwd:  Public access multics
In-Reply-To: <CAC20D2N-Q4VY8TLZagS6J2-US1G3emXVcOdX1BQZ44HYukD6ug@mail.gmail.com>
References: <899D86D7-1601-4FDA-869A-10EC46500D0D@gmail.com>
 <CAC20D2N-Q4VY8TLZagS6J2-US1G3emXVcOdX1BQZ44HYukD6ug@mail.gmail.com>
Message-ID: <CAC20D2PhOMwh0BH6nE5JrzTwJ1t3RN7eYSaayD=893J6eZE1iQ@mail.gmail.com>

below...

On Sat, Sep 1, 2018 at 4:37 PM Will Senn <will.senn at gmail.com> wrote:

> So, it looks like someone has gone and started running a multics instance:
>
> http://lists.nycbug.org/pipermail/semibug/2018-August/000288.html
>
> That’s interesting, and y’all may even have been aware of it. But, I was
> thinking that Multics was a failed predecessor of unix and it’s craziness
> an inspiration for how unix isn’t multics... straighten me out :)
>
>
https://www.quora.com/Why-did-Unix-succeed-and-not-Multics/answer/Clem-Cole
ᐧ
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180901/085f62da/attachment.html>

From rminnich at gmail.com  Sun Sep  2 07:15:58 2018
From: rminnich at gmail.com (ron minnich)
Date: Sat, 1 Sep 2018 14:15:58 -0700
Subject: [TUHS] UVM VM system
In-Reply-To: <CANCZdfogHqPr6GQ50y_8gVrhnNG-KxPWARuAoGHbKNOL_BKU6A@mail.gmail.com>
References: <20180901185053.GA20993@mcvoy.com>
 <CAC20D2OXVo0ng5bnpjVO_uLRLqGo3ROxhCNdJaTmr8qa3Nb_EQ@mail.gmail.com>
 <CAP6exYKs9H=GKxeOxu6vcf1By3CZP-Hjk0K1dPgfH67K=WQNQQ@mail.gmail.com>
 <CANCZdfogHqPr6GQ50y_8gVrhnNG-KxPWARuAoGHbKNOL_BKU6A@mail.gmail.com>
Message-ID: <CAP6exYJCnJB_UrGxYxOUu8byZwdexM9geLsBqWi5t_9bhJyvzA@mail.gmail.com>

good to know!

On Sat, Sep 1, 2018 at 1:26 PM Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Sat, Sep 1, 2018, 1:42 PM ron minnich <rminnich at gmail.com> wrote:
>
>> I was his advisor on that thesis so I got to watch it roll out as it
>> happened.
>>
>> uvm replaced the machvm in netbsd.
>>
>> For a time, Chuck set it up to run in parallel with the existing VM. You
>> could start a process and pick which vm it used. For a while, it defaulted
>> to the existing one. Then, at some point, it defaulted to uvm. Then, at
>> some point, the old one was removed.
>>
>> more here:
>>
>> http://www.netbsd.org/docs/kernel/uvm.html
>>
>> via search terms
>> uvm replaces machvm netbsd
>>
>> chuck was a long time contributor to netbsd IIRC, but last time we
>> talked, he was using Linux.
>>
>
> These days I know he's hacking on FreeBSD's storage stack with me at work
> :). I think he's still a netbsd contributor. I see his name in the commit
> log often..
>
> Warner
>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180901/9e6b3b4c/attachment.html>

From don at DonHopkins.com  Sun Sep  2 07:21:49 2018
From: don at DonHopkins.com (Don Hopkins)
Date: Sat, 1 Sep 2018 23:21:49 +0200
Subject: [TUHS] TUHS Digest, Vol 34, Issue 4
In-Reply-To: <mailman.98.1535822297.3725.tuhs@minnie.tuhs.org>
References: <mailman.98.1535822297.3725.tuhs@minnie.tuhs.org>
Message-ID: <586F623A-C819-4E77-9986-88C322E36AFD@gmail.com>



> On 1 Sep 2018, at 19:18,Warner Losh <imp at bsdimp.com <mailto:imp at bsdimp.com>> wrote:
> 
> I recall a more knowledgeable friend complaining about FreeBSD VM in 1994 or so.
> 
> It used to be downright aweful.
> 

That sounds like a GOOD thing: full of awe! 

At least it wasn’t offal: decomposing animal flesh. 

-Don

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

From lists at irreal.org  Sun Sep  2 07:27:19 2018
From: lists at irreal.org (jcs)
Date: Sat, 01 Sep 2018 17:27:19 -0400
Subject: [TUHS] Public access multics
In-Reply-To: <899D86D7-1601-4FDA-869A-10EC46500D0D@gmail.com>
References: <899D86D7-1601-4FDA-869A-10EC46500D0D@gmail.com>
Message-ID: <m2y3ck6h8o.fsf@irreal.org>


Will Senn <will.senn at gmail.com> writes:

> So, it looks like someone has gone and started running a multics 
> instance:
>
> http://lists.nycbug.org/pipermail/semibug/2018-August/000288.html
>
> That’s interesting, and y’all may even have been aware of it. 
> But, I was thinking that Multics was a failed predecessor of 
> unix and it’s craziness an inspiration for how unix isn’t 
> multics... straighten me out :)

Failed only in the sense that the Labs withdrew from the project. 
Honeywell, which bought out GE's computer division, sold Multics 
systems, although I don't remember them being very successful.

The real mystery is what it's running on. Multics originally ran 
on the GE/H 600(0) systems. I doubt any are still around. It's 
probably a simulator but I've never heard of one for the H6000.


From tytso at mit.edu  Sun Sep  2 08:19:33 2018
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Sat, 1 Sep 2018 18:19:33 -0400
Subject: [TUHS] SunOS code?
In-Reply-To: <ee7772a4-c23a-3344-4f10-c561047ffbb5@kilonet.net>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch>
 <20180831215854.GB28971@mcvoy.com>
 <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net>
 <CAK7dMtB8AmPG5ZMceGZdD8sxL10horfO0ZYLfXuX=4Dp8u7bwQ@mail.gmail.com>
 <ee7772a4-c23a-3344-4f10-c561047ffbb5@kilonet.net>
Message-ID: <20180901221933.GA2214@thunk.org>

On Sat, Sep 01, 2018 at 01:17:59PM -0400, Arthur Krewat wrote:
> On 9/1/2018 12:27 PM, Kevin Bowling wrote:
> > > I find it's about equal, and even exceeds Linux in terms of it's NUMA
> > > support and multi-processor support. I need to move some systems away from
> > > Solaris and off to Linux, and I find it's NUMA support lacking in certain
> > > ways.
> > This is pure fantasy.  To understand Linux performance on high core
> > count and multi-socket machines is to have at least passing knowledge
> > of Paul McKenney's genius work on RCU [1] and NUMA [2] at Sequent [3]
> > and on Linux.  IBM bought Sequent, made a favorable patent grant of
> > RCU for Linux, and the rest history.
> 
> Thanks :) - I'm basing this on Oracle database performance, for the most
> part, and it's weird way of supporting NUMA on Linux in a bass-ackwards sort
> of way. Nothing I see in the latest RedHat/CentOS tells me it even cares
> about NUMA, but maybe that's more of their "we know better than you"
> mentality and it's all hidden under the covers somewhere.

It wouldn't surprise me if Linux's NUMA performance is pretty weak
compared to Solaris.  There was an attempt to try to make NUMA work
well on Linux, with a lot of the effort coming from IBM and SGI, but
that effort was overtaken by events.  Back in Sequent's day, the
remote to local memory latency was ten to one, so making the system
NUMA aware was critical.  But by early 2000's, the remote to local
ratio was under 3:1 (or 2:1) for 4 socket systems, and with AMD's
"Sufficiently Uniform Memory Organization" (SUMO), the ratio was under
1.5:1 or less.

The main reason for this was that Windows was (and as far as I know,
still is) NUMA oblivious.  So x86 chip and motherboard designers
solved the problem, by brute foruce, in hardware.  So by 2003 or 2004,
the Linux Scalability Effort had more or less petered out.  (You can
see the leftover remnants at http://lse.sourceforge.net)

Fundamentally, the economics of 4 socket and higher machines was such
that for many workloads, scale out was much cheaper than scale up.  So
why buy super-expensive IBM X440, x450, and x460 servers, which were
huge cabinets connected by one or more "scalability cables" (sometimes
referred to as the "scalability bottleneck"), when most of the time,
you could just buy a rack of 2U x86 servers which would be much, much
cheaper?

There were certainly workloads this wasn't applicable, of course.  But
when Sun was selling Sun 10k's to web startups during the dot com
boom, and they were using it to serve web traffic, they probably had
too much VC money to burn, because that was *not* the most cost
effective way to do things.

Don't get me wrong; the Read Copy Update (RCU) technique was certainly
very important, and is responsible for much of Linux's SMP scalability
today.  But these days, when you can get up to 28 cores (56 threads)
on a single socket, the need for more than 2 socket systems is already
somewhat niche, and by the time you get to more than 4 sockets, it's
positively microscopic.  As a result, NUMA support on Linux is
certainly not as strong as it could be, and it wouldn't surprise me
that Solaris has developed much better ways of handling the behemoths
such as Sun Enterprise 10k.

					- Ted

P.S.  IBM made the RCU patent available for any GPL code, well before
Sun decided on the CDDL for Solaris.  So if Sun management had chosen
GPL, they could have used RCU....


From jpl.jpl at gmail.com  Sun Sep  2 09:24:56 2018
From: jpl.jpl at gmail.com (John P. Linderman)
Date: Sat, 1 Sep 2018 19:24:56 -0400
Subject: [TUHS] Public access multics
In-Reply-To: <m2y3ck6h8o.fsf@irreal.org>
References: <899D86D7-1601-4FDA-869A-10EC46500D0D@gmail.com>
 <m2y3ck6h8o.fsf@irreal.org>
Message-ID: <CAC0cEp9w=-EVT5jJheEQfgqyKvirkt1pEPo6YNhE1ThC521SRw@mail.gmail.com>

I was at MIT in the late 60's, using Multics when Bell Labs decided to pull
out. A problem, in retrospect, was the use of PL/I as the primary language.
PL/I was a language designed by a committee, and it showed. It would never
have made a plausible systems programming language. But Multics was a lot
more fun to use than CTSS, which it replaced.

On Sat, Sep 1, 2018 at 5:27 PM, jcs <lists at irreal.org> wrote:

>
> Will Senn <will.senn at gmail.com> writes:
>
> So, it looks like someone has gone and started running a multics instance:
>>
>> http://lists.nycbug.org/pipermail/semibug/2018-August/000288.html
>>
>> That’s interesting, and y’all may even have been aware of it. But, I was
>> thinking that Multics was a failed predecessor of unix and it’s craziness
>> an inspiration for how unix isn’t multics... straighten me out :)
>>
>
> Failed only in the sense that the Labs withdrew from the project.
> Honeywell, which bought out GE's computer division, sold Multics systems,
> although I don't remember them being very successful.
>
> The real mystery is what it's running on. Multics originally ran on the
> GE/H 600(0) systems. I doubt any are still around. It's probably a
> simulator but I've never heard of one for the H6000.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180901/f47782d3/attachment.html>

From jnc at mercury.lcs.mit.edu  Sun Sep  2 09:25:37 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat,  1 Sep 2018 19:25:37 -0400 (EDT)
Subject: [TUHS] Fwd:  Public access multics
Message-ID: <20180901232537.615A418C09E@mercury.lcs.mit.edu>

    > From: Will Senn

    > I was thinking that Multics was a failed predecessor of unix
    > ... straighten me out :)

I'd start with:

  https://multicians.org/myths.html


    > From: Clem Cole <clemc at ccc.com>

    > https://www.quora.com/Why-did-Unix-succeed-and-not-Multics/answer/Clem-Cole

Clem, I think that's too limited in scope.

Like a lot of 'big' 'failures' (defined in Multics' case as 'failure to grow
to significant market share, and continue in the long term'), I don't think
Multics 'failed' for a single reason.

In general, in large failures, there are a number of causes, all doing their
bit. Now, if there are M causes, ranked in priority, maybe the first N1 are
_each_ big enough that _any one_ of them could have led to that outcome. Or
maybe not; maybe it needed the first N2, all acting in concert.


My crystal ball isn't that accurate. But here's my take on _some_ of Multics'
main issues.

- Management: if you look at:

  https://multicians.org/hill-mgt.html

it's clear that Honeywell top management didn't understand Multics, and
didn't understand that it had a long-term potential. They terminated
investment in new hardware, and that was what finally killed Multics.

- Non-portability: the system was too tied to a specific platform; it
couldn't really be moved elsewhere. (E.g. the code is riddled with 'fixed bin
18'; yes, that could be changed with a program to edit the source, but there
are lots of dependencies on the specifics of the machine's architecture.) It
would be possible to re-write it to run on, say, a 386, but you'd pretty much
have to start from scratch.

- Built for the wrong future: a key assumption was that people would continue
to get their computes from large centralized machines. Clearly, that was
wrong (and it played into the issues with Honeywell management)>. Multics
_could_ have made the transition to today's 'small' (physically) machines, in
which case it would have been really good to have - e.g. if we could run
browsers in AIM boxes a lot of malware simply would not be an issue. But the
point above prevented that.


Those are some of the big ones; I may come up with more. I've CC'd a couple
of Multicians - perhaps they can add additional insight.

	Noel


From jnc at mercury.lcs.mit.edu  Sun Sep  2 09:33:41 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat,  1 Sep 2018 19:33:41 -0400 (EDT)
Subject: [TUHS] Public access multics
Message-ID: <20180901233341.0CAB118C09E@mercury.lcs.mit.edu>

    > From: jcs

    > The real mystery is what it's running on. ... It's=20 probably a
    > simulator but I've never heard of one for the H6000.

Per:

  https://multicians.org/multics.htmlhttps://multicians.org/multics.html

"Harry Reed and Charles Anthony reached a major milestone on the Multics
simulator on Saturday 08 November, 2014. Their SIMH-based simulator booted
Multics MR 12.5, came to operator command level, entered admin mode, created a
small PL/I program, compiled and executed it, and shut down. Release 1.0 of
the simulator is now available."

    Noel


From lists at irreal.org  Sun Sep  2 09:44:12 2018
From: lists at irreal.org (jcs)
Date: Sat, 01 Sep 2018 19:44:12 -0400
Subject: [TUHS] Public access multics
In-Reply-To: <20180901233341.0CAB118C09E@mercury.lcs.mit.edu>
References: <20180901233341.0CAB118C09E@mercury.lcs.mit.edu>
Message-ID: <m2wos46awj.fsf@irreal.org>


Noel Chiappa <jnc at mercury.lcs.mit.edu> writes:

> Per:
>
>   https://multicians.org/multics.htmlhttps://multicians.org/multics.html
>
> "Harry Reed and Charles Anthony reached a major milestone on the 
> Multics
> simulator on Saturday 08 November, 2014. Their SIMH-based 
> simulator booted
> Multics MR 12.5, came to operator command level, entered admin 
> mode, created a
> small PL/I program, compiled and executed it, and shut down. 
> Release 1.0 of
> the simulator is now available."

Hmmm. That's interesting. Back in the 70's I earned my living 
working on H6000s (although not on Multics). I'm pretty sure that 
no one would have bothered with a simulator if not for Multics so 
that's another reason not to dismiss Multics as a failure: 
someone, today, still cares enough to write a simulator just to 
run it.


From crossd at gmail.com  Sun Sep  2 10:57:17 2018
From: crossd at gmail.com (Dan Cross)
Date: Sat, 1 Sep 2018 20:57:17 -0400
Subject: [TUHS] Public access multics
In-Reply-To: <m2y3ck6h8o.fsf@irreal.org>
References: <899D86D7-1601-4FDA-869A-10EC46500D0D@gmail.com>
 <m2y3ck6h8o.fsf@irreal.org>
Message-ID: <CAEoi9W4vdNp8yX9E__0i_8_qJ16fDr=5gLShTJHeFQc01cOx_w@mail.gmail.com>

On Sat, Sep 1, 2018 at 6:15 PM jcs <lists at irreal.org> wrote:

> Will Senn <will.senn at gmail.com> writes:
> > So, it looks like someone has gone and started running a multics
> > instance:
> >
> > http://lists.nycbug.org/pipermail/semibug/2018-August/000288.html
> >
> > That’s interesting, and y’all may even have been aware of it.
>

Yup. A few Multics sites are publicly accessible; the one at the Living
Computer Museum has a guest account, a few others one can get an account if
one asks the site administrator nicely. Some amount of Multics maintenance
has been restarted.

> But, I was thinking that Multics was a failed predecessor of
> > unix and it’s craziness an inspiration for how unix isn’t
> > multics... straighten me out :)
>

Multics was the immediate predecessor of Unix, and one can certainly see
some of the influence, though of course many of the details are different.

Failed only in the sense that the Labs withdrew from the project.
> Honeywell, which bought out GE's computer division, sold Multics
> systems, although I don't remember them being very successful.
>

The multicians.org site has a lot of good information on Multics and what
ultimately become of it. (jcs probably knows this already; I'm writing this
more for general information of those who may not have been following these
developments.) The TL;DR was that a smallish number of sites eventually
installed Multics and it was a moderate success for Honeywell, but for the
reasons that have been mentioned (failure to market, lack of management
understanding, tied to a decomposing architecture well past its prime) it
never carved out more than a niche.

The real mystery is what it's running on. Multics originally ran
> on the GE/H 600(0) systems. I doubt any are still around. It's
> probably a simulator but I've never heard of one for the H6000.
>

The last working hardware installation was shut down in, I think, 2000. An
DPS8/M emulator has been built on top of the SIMH framework, and is what
folks are running Multics on. Some more details are here:
https://multicians.org/simulator.html.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180901/7ad2dac5/attachment.html>

From gtaylor at tnetconsulting.net  Sun Sep  2 12:06:10 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Sat, 1 Sep 2018 20:06:10 -0600
Subject: [TUHS] Public access multics
In-Reply-To: <CAEoi9W4vdNp8yX9E__0i_8_qJ16fDr=5gLShTJHeFQc01cOx_w@mail.gmail.com>
References: <899D86D7-1601-4FDA-869A-10EC46500D0D@gmail.com>
 <m2y3ck6h8o.fsf@irreal.org>
 <CAEoi9W4vdNp8yX9E__0i_8_qJ16fDr=5gLShTJHeFQc01cOx_w@mail.gmail.com>
Message-ID: <268aed6e-0398-d368-5325-8ca536d310dc@spamtrap.tnetconsulting.net>

On 09/01/2018 06:57 PM, Dan Cross wrote:
> Yup. A few Multics sites are publicly accessible; the one at the Living 
> Computer Museum has a guest account, a few others one can get an account 
> if one asks the site administrator nicely. Some amount of Multics 
> maintenance has been restarted.

I was chatting with modern day Multicians within the last week.  They 
were actively working on getting a 3270 interface working for Multics 
running in an emulator.

They are hanging out in the #multics channel on freenode.



-- 
Grant. . . .
unix || die

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

From charles.unix.pro at gmail.com  Sun Sep  2 12:32:53 2018
From: charles.unix.pro at gmail.com (Charles Anthony)
Date: Sat, 1 Sep 2018 19:32:53 -0700
Subject: [TUHS] Public access multics
In-Reply-To: <m2y3ck6h8o.fsf@irreal.org>
References: <899D86D7-1601-4FDA-869A-10EC46500D0D@gmail.com>
 <m2y3ck6h8o.fsf@irreal.org>
Message-ID: <CANV78LSN=dWOwH+1+Pj7YmyOvs7okdbkNc2Cbz+5zCpAPDA=Fw@mail.gmail.com>

>
>
>
> The real mystery is what it's running on. Multics originally ran
> on the GE/H 600(0) systems. I doubt any are still around. It's
> probably a simulator but I've never heard of one for the H6000.
>

A simulator. Originally running Multics release 12.5, but a dedicated team
of new and original Multicians have completed the Y2K transition, fixed
some bugs and added some features, so now running release 12.6f.

All of the original systems are believed to be destroyed with the exception
of DOCKMASTER (an NSA machine), now in possession of the National
Cryptographic Museum, but warehoused.

A video of the Living Computer Museum's Multics emulator (with maintenance
panel) booting: https://www.youtube.com/watch?v=jni7wk7bjxA

At least one of the new Multicians (me) is subscribed to TUHS.

-- Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180901/8e387dd5/attachment.html>

From lm at mcvoy.com  Sun Sep  2 12:52:23 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 1 Sep 2018 19:52:23 -0700
Subject: [TUHS] Public access multics
In-Reply-To: <CANV78LSN=dWOwH+1+Pj7YmyOvs7okdbkNc2Cbz+5zCpAPDA=Fw@mail.gmail.com>
References: <899D86D7-1601-4FDA-869A-10EC46500D0D@gmail.com>
 <m2y3ck6h8o.fsf@irreal.org>
 <CANV78LSN=dWOwH+1+Pj7YmyOvs7okdbkNc2Cbz+5zCpAPDA=Fw@mail.gmail.com>
Message-ID: <20180902025223.GQ28971@mcvoy.com>

On Sat, Sep 01, 2018 at 07:32:53PM -0700, Charles Anthony wrote:
> At least one of the new Multicians (me) is subscribed to TUHS.

Welcome.  You'll find this list to be pleasant, it's mostly Unix but
we've got Ted from Linux (which is a big deal, he has a lot of history
in his head and is a good guy), Ken is on here though he rarely posts
(and we all try and be nice to keep him around), Doug is here, Steve is
here, and all of us wannabes are here.

I love being on this list, as a young dude I was pretty unhappy that I 
was born at the wrong time, I really really wanted be part of Bell Labs.
But I got to be part of Sun, which I think was the Bell Labs of their
time.  And then there is this list which has some of the Bell Labs folks.

It reminds me of the Band, there is a video and Neil Young says "it's
one of the pleasures of my life to be on stage with these people".  
Yeah, it's one of the great pleasures of my life to be able to talk
the Bell Labs people on this list.  And other fans of the Unix history,
love this list.

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


From trnsz at pobox.com  Sun Sep  2 13:17:02 2018
From: trnsz at pobox.com (Jeffrey H. Johnson)
Date: Sat, 1 Sep 2018 23:17:02 -0400
Subject: [TUHS] Public access multics
References: <5B48F6A3-374A-4579-AE8F-35BD328D07F9@reagan.com>
Message-ID: <EE36B4F0-6DE1-4B26-B30F-527DCA69C823@pobox.com>

Greetings,

Multics, while not a 'massive' sales success in retrospect, was certainly not the failure commonly believed and wasn't treated as one in the press of the time - at least not until after the decision was made by Honeywell-Bull to phase out the the Multics (and CP-6) products to focus on GCOS - GCOS7/GCOS8 is still a major player today.

"Honeywell is having considerable — and surprising — success with the ultra-secure Multics operating system … Besides 3-5 systems within Honeywell, Multics has been installed or committed within Nippon Electric, Rome Air Development Center, USAF Data Services Center, and Ford." from mid-1970's industry press.

See also https://multicians.org/myths.html

We have about 120 members on BAN - including many original and new Multicians who make the project possible. We're always working on new things and projects - see "pmotd -a" when logged in for some of the most recent activity.

I'd be happy to answer any questions on BAN.AI if anyone has particular questions - or just ssh to dps8 at m.trnsz.com - feel free to use the guest account. I don't want to take the list too off-topic. We have many exclusive features that I hope makes BAN.AI a 'special' (and loved) system, a lot more coming.


--
https://ban.ai/multics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180901/9379c48f/attachment.html>

From will.senn at gmail.com  Sun Sep  2 14:05:39 2018
From: will.senn at gmail.com (Will Senn)
Date: Sat, 1 Sep 2018 23:05:39 -0500
Subject: [TUHS] Fwd:  Public access multics
In-Reply-To: <20180901232537.615A418C09E@mercury.lcs.mit.edu>
References: <20180901232537.615A418C09E@mercury.lcs.mit.edu>
Message-ID: <10B61FE8-1418-4201-A782-76E07BD2D34A@gmail.com>

On Sep 1, 2018, at 6:25 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:

>> From: Will Senn
> 
>> I was thinking that Multics was a failed predecessor of unix
>> ... straighten me out :)
> 
> I'd start with:
> 
>  https://multicians.org/myths.html
>> 

Noel, Fascinating read. I must’ve read at least a good handful of the references leading to the myths described in the writeup. As usual, I can trust the folks who lived history to remember it more clearly than many revisionists writing about it later.

Thanks for sharing.

Now, I’m wondering what awesome features Multics had that we’re still lacking in modern *nices... anything as amazing as say, my favorite filesystem, ZFS?

Will

From trnsz at pobox.com  Sun Sep  2 14:25:44 2018
From: trnsz at pobox.com (Jeffrey H. Johnson)
Date: Sun, 2 Sep 2018 00:25:44 -0400
Subject: [TUHS] Public access multics
In-Reply-To: <10B61FE8-1418-4201-A782-76E07BD2D34A@gmail.com>
References: <20180901232537.615A418C09E@mercury.lcs.mit.edu>
 <10B61FE8-1418-4201-A782-76E07BD2D34A@gmail.com>
Message-ID: <0D39179A-9133-4388-ABEC-DCD769E9CD24@pobox.com>

While the best loved feature is probably the pervasive dynamic linking, which is still unrivaled, and the security features (ring brackets, AIM (multilevel labeling), and ACLs) which are the most famous, a feature that isn't built in to Unix and is constantly being reinvented that was available in Multics is the ability to easily set aside a CPU and some memory and disk, while leaving the system in operation, and start another separate instance to do development work, and then when the work is done, be reconfigured to merge the system back into one instance, without disrupting production work.  

That dynamic reconfiguration was one original design specifications of the system, as opposed to being added later. Much of what makes Multics wonderful to me is just how amazingly sturdily it's engineered and how complete the implementations of these ideas are.

Another thing to comes to mind immediately is how hierarchical the system is. For example, users are registered on to projects, and a project administrator can be delegated the task of registering and deregistering user accounts and managing the system resources such as disk quota and access to printers and other physical resources for their project. 

The system administrator can manage the resources assigned to projects, and the project administration handles how that's further carved up amongst the users.

You can have similar granularity in assigning the distribution of resources such as CPU and memory use, by using the workload management features to ensure that high priority tasks/users/projects will always have needed resources available, preempting lower priority tasks if necessary. 

The I/O system, (while not exceedingly elegant - see iox_), far exceeds what is available in Unix today, but by design.

The reputation of Multics as a 'complex' system is, in my experience, well deserved, but that complexity does not mean it's a terrible system to use or administer. I find it quite refreshing and it almost never feels dated.

-- Jeff
https://ban.ai/multics

> On Sep 2, 2018, at 12:05 AM, Will Senn <will.senn at gmail.com> wrote:
> 
> On Sep 1, 2018, at 6:25 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> 
>>> From: Will Senn
>> 
>>> I was thinking that Multics was a failed predecessor of unix
>>> ... straighten me out :)
>> 
>> I'd start with:
>> 
>> https://multicians.org/myths.html
> 
> Noel, Fascinating read. I must’ve read at least a good handful of the references leading to the myths described in the writeup. As usual, I can trust the folks who lived history to remember it more clearly than many revisionists writing about it later.
> 
> Thanks for sharing.
> 
> Now, I’m wondering what awesome features Multics had that we’re still lacking in modern *nices... anything as amazing as say, my favorite filesystem, ZFS?
> 
> Will



From kevin.bowling at kev009.com  Sun Sep  2 15:05:06 2018
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Sat, 1 Sep 2018 22:05:06 -0700
Subject: [TUHS] SunOS code?
In-Reply-To: <20180901221933.GA2214@thunk.org>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com>
 <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net>
 <CAK7dMtB8AmPG5ZMceGZdD8sxL10horfO0ZYLfXuX=4Dp8u7bwQ@mail.gmail.com>
 <ee7772a4-c23a-3344-4f10-c561047ffbb5@kilonet.net>
 <20180901221933.GA2214@thunk.org>
Message-ID: <CAK7dMtC4VL56Utb67-LJfXrZ2oStUb_MDFO4q-PakGjjHOF82w@mail.gmail.com>

On Sat, Sep 1, 2018 at 3:19 PM, Theodore Y. Ts'o <tytso at mit.edu> wrote:
> On Sat, Sep 01, 2018 at 01:17:59PM -0400, Arthur Krewat wrote:
>> On 9/1/2018 12:27 PM, Kevin Bowling wrote:
>> > > I find it's about equal, and even exceeds Linux in terms of it's NUMA
>> > > support and multi-processor support. I need to move some systems away from
>> > > Solaris and off to Linux, and I find it's NUMA support lacking in certain
>> > > ways.
>> > This is pure fantasy.  To understand Linux performance on high core
>> > count and multi-socket machines is to have at least passing knowledge
>> > of Paul McKenney's genius work on RCU [1] and NUMA [2] at Sequent [3]
>> > and on Linux.  IBM bought Sequent, made a favorable patent grant of
>> > RCU for Linux, and the rest history.
>>
>> Thanks :) - I'm basing this on Oracle database performance, for the most
>> part, and it's weird way of supporting NUMA on Linux in a bass-ackwards sort
>> of way. Nothing I see in the latest RedHat/CentOS tells me it even cares
>> about NUMA, but maybe that's more of their "we know better than you"
>> mentality and it's all hidden under the covers somewhere.
>
> It wouldn't surprise me if Linux's NUMA performance is pretty weak
> compared to Solaris.  There was an attempt to try to make NUMA work
> well on Linux, with a lot of the effort coming from IBM and SGI, but
> that effort was overtaken by events.  Back in Sequent's day, the
> remote to local memory latency was ten to one, so making the system
> NUMA aware was critical.  But by early 2000's, the remote to local
> ratio was under 3:1 (or 2:1) for 4 socket systems, and with AMD's
> "Sufficiently Uniform Memory Organization" (SUMO), the ratio was under
> 1.5:1 or less.

Sorry this is just bogus about being weak compared to Solaris.  Are
you looking back with rosy glasses or have you scanned the code in the
past couple years?  I have and there is nothing particularly special
about Solaris internals here or elsewhere.  In fact, there are a lot
of pessimization all over the place.  As Larry said, a lot of folks in
the Linux community clearly cared about performance.  Although the
Solaris code is fairly clean It's not clear Sun valued performance at
all.  A stroll through arch/*/include/asm/ was enough to convince me
of Larry's claims.  I'm not a Linux fanboy but credit goes where it's
due.

Solaris has lgroups, which are a clean design but that is the extent
of its NUMA support, one shot at placement and scheduling.  Linux has
a NUMA allocator, aware scheduler, NUMA-optimized spinlocks and
mutexes, various subsystems correctly use the primitives, and can use
cgroups to contain or gang things.  There is a userland policy tool
called numad that tries to add some additional runtime affinity and
movement policy decisions.

I agree that architecturally Linux NUMA is nowhere near where Sequent
and especially SGI was.  And the reasons you cite are valid, Linux
implementation is good for maybe 8-16 sockets of modern core count
with a much tighter off chip network than the big dogs were building.

Keep in mind IBM wants to sell RockHoppers and E980s (4 drawers, 16
sockets, 768 threads) for dedicated Linux use which have similar
north/south and east/west off chip networks.  They have a lot of very
talented people on the firmware, kernel, compilers to make these
things work fast, including Paul.

> The main reason for this was that Windows was (and as far as I know,
> still is) NUMA oblivious.  So x86 chip and motherboard designers
> solved the problem, by brute foruce, in hardware.  So by 2003 or 2004,
> the Linux Scalability Effort had more or less petered out.  (You can
> see the leftover remnants at http://lse.sourceforge.net)

Windows' NUMA support is on par with Solaris insofar as there is
domain aware memory allocator and scheduler hierarchy that takes the
domain (and SMT etc) into account.  What Windows lacks is the finely
tuned concurrency primitives and everything else Linux has done..
which Solaris lacks as well.  I'm not even talking about RCU (or epoch
based reclamation or proxy collection or hazard pointers, at least one
of which is not patent encumbered), I'm just talking about the quality
of primitives like spinlocks and mutex and rwlock.  There are big
tradeoffs to the implementations of these in terms of fairness,
progress guarantees, and thread scalability.  Linux leads the pack by
a long shot in this department.

Where you start going beyond Linux-like NUMA IMO is when you get
Irix-like features of page copying, migration, and multiple advanced
placement policies.

> Fundamentally, the economics of 4 socket and higher machines was such
> that for many workloads, scale out was much cheaper than scale up.  So
> why buy super-expensive IBM X440, x450, and x460 servers, which were
> huge cabinets connected by one or more "scalability cables" (sometimes
> referred to as the "scalability bottleneck"), when most of the time,
> you could just buy a rack of 2U x86 servers which would be much, much
> cheaper?

Agreed, this is why x86 has dominated the server market for a long time.

> There were certainly workloads this wasn't applicable, of course.  But
> when Sun was selling Sun 10k's to web startups during the dot com
> boom, and they were using it to serve web traffic, they probably had
> too much VC money to burn, because that was *not* the most cost
> effective way to do things.

Agreed.  Those big margins must have caused them to take their eye off
what mattered right at the time Linux was getting some momentum from
the big HW vendors.

> Don't get me wrong; the Read Copy Update (RCU) technique was certainly
> very important, and is responsible for much of Linux's SMP scalability
> today.  But these days, when you can get up to 28 cores (56 threads)
> on a single socket, the need for more than 2 socket systems is already
> somewhat niche, and by the time you get to more than 4 sockets, it's
> positively microscopic.  As a result, NUMA support on Linux is
> certainly not as strong as it could be, and it wouldn't surprise me
> that Solaris has developed much better ways of handling the behemoths
> such as Sun Enterprise 10k.

The E10k was only a 64-core machine on a tight backplane compared to
other large systems.  It didn't have any of the pressing needs that
Sequent and SGI did with multi-drawer interconnects to drive
excellence in NUMA.

These are strange times.  Intel's been putting out some real doozy
chips.  The mesh in Skylake is a partial improvement over the dual
rings of Haswell (though they did some goofy things to increase
latency in undesirable ways), and they aren't going to continue to
brute force it like IBM did with their 17 metal layer process node..
many SKUs in Cascade Lake will be a dual die design and cost a
hilarious amount of money.  AMD's EPYC is really bad in this
department too, one EPYC behaves identically to a 4 socket system with
extremely poor inter-die latency [1].  I think POWER9 is universally
better and the high bin chips (22 core, 88 thread, mega cache) are
only around $2500 compared to Skylake's absurd $12,000.  POWER9 is a
single on chip NUMA domain for 24 cores.  Google publicly stated they
are using it for GPU servers, and that all their monorepo is built for
multiple ISAs.  Through the grapevine I've heard gmail is running on
POWER9 as well now.  That is pretty competent, the reason Intel is
sucking so bad is because people allowed themselves such lock in.  A
hyperscaler should be able to change between a couple ISAs as needed
between purchasing cycles.

>                                         - Ted
>
> P.S.  IBM made the RCU patent available for any GPL code, well before
> Sun decided on the CDDL for Solaris.  So if Sun management had chosen
> GPL, they could have used RCU...

True.  There is also at least one unencumbered strategy such as epoch
based reclamation which was known about around that time [2]

[1] https://www.servethehome.com/amd-epyc-infinity-fabric-latency-ddr4-2400-v-2666-a-snapshot/
[2] https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-579.pdf

Regards,
Kevin


From kevin.bowling at kev009.com  Sun Sep  2 15:19:41 2018
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Sat, 1 Sep 2018 22:19:41 -0700
Subject: [TUHS] UVM VM system
In-Reply-To: <CANCZdfogHqPr6GQ50y_8gVrhnNG-KxPWARuAoGHbKNOL_BKU6A@mail.gmail.com>
References: <20180901185053.GA20993@mcvoy.com>
 <CAC20D2OXVo0ng5bnpjVO_uLRLqGo3ROxhCNdJaTmr8qa3Nb_EQ@mail.gmail.com>
 <CAP6exYKs9H=GKxeOxu6vcf1By3CZP-Hjk0K1dPgfH67K=WQNQQ@mail.gmail.com>
 <CANCZdfogHqPr6GQ50y_8gVrhnNG-KxPWARuAoGHbKNOL_BKU6A@mail.gmail.com>
Message-ID: <CAK7dMtBM6YhEPpsxwnvuZabcF6YVYTsx7jof4GQak6QcP2yh+g@mail.gmail.com>

Seems like Chuck Cranor is at CMU http://chuck.cranor.org/.  Chuck
Silvers is with you?

On Sat, Sep 1, 2018 at 1:25 PM, Warner Losh <imp at bsdimp.com> wrote:
>
>
> On Sat, Sep 1, 2018, 1:42 PM ron minnich <rminnich at gmail.com> wrote:
>>
>> I was his advisor on that thesis so I got to watch it roll out as it
>> happened.
>>
>> uvm replaced the machvm in netbsd.
>>
>> For a time, Chuck set it up to run in parallel with the existing VM. You
>> could start a process and pick which vm it used. For a while, it defaulted
>> to the existing one. Then, at some point, it defaulted to uvm. Then, at some
>> point, the old one was removed.
>>
>> more here:
>>
>> http://www.netbsd.org/docs/kernel/uvm.html
>>
>> via search terms
>> uvm replaces machvm netbsd
>>
>> chuck was a long time contributor to netbsd IIRC, but last time we talked,
>> he was using Linux.
>
>
> These days I know he's hacking on FreeBSD's storage stack with me at work
> :). I think he's still a netbsd contributor. I see his name in the commit
> log often..
>
> Warner


From akosela at andykosela.com  Sun Sep  2 16:29:42 2018
From: akosela at andykosela.com (Andy Kosela)
Date: Sun, 2 Sep 2018 08:29:42 +0200
Subject: [TUHS] UVM VM system
In-Reply-To: <CAC20D2OXVo0ng5bnpjVO_uLRLqGo3ROxhCNdJaTmr8qa3Nb_EQ@mail.gmail.com>
References: <20180901185053.GA20993@mcvoy.com>
 <CAC20D2OXVo0ng5bnpjVO_uLRLqGo3ROxhCNdJaTmr8qa3Nb_EQ@mail.gmail.com>
Message-ID: <CALMnNGhtP3fvGNHJ2XFmiVUGhRpjQRAViHLE4yi+zB-StJdUdg@mail.gmail.com>

On Saturday, September 1, 2018, Clem Cole <clemc at ccc.com> wrote:
>
>
>
>>
>> Has FreeBSD considered this?
>>
> Last I knew, no.  I was under the impression, the work FreeBSD did
> rewriting the Mach stuff paid off for them at the time.  I have FreeBSD,
> OpenBSD and Linux (and Mac OSx) all running on my systems here.   But the
> problem is that the HW is all over the map in termns of release date, so
> I'm not sure which is faster at this point.   The *BSD systems are the
> easiest to admin and clean/simplest (which is why they only systems I have
> exposed is an OpenBSD box).
>

OpenBSD is also using uvm[1].  But these days it certainly differs from
NetBSD implementation as it was hacked on by different people during the
last several years.

[1] https://man.openbsd.org/uvm.9

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

From steve.mynott at gmail.com  Sun Sep  2 18:07:02 2018
From: steve.mynott at gmail.com (Steve Mynott)
Date: Sun, 2 Sep 2018 09:07:02 +0100
Subject: [TUHS] UVM VM system
In-Reply-To: <CALMnNGhtP3fvGNHJ2XFmiVUGhRpjQRAViHLE4yi+zB-StJdUdg@mail.gmail.com>
References: <20180901185053.GA20993@mcvoy.com>
 <CAC20D2OXVo0ng5bnpjVO_uLRLqGo3ROxhCNdJaTmr8qa3Nb_EQ@mail.gmail.com>
 <CALMnNGhtP3fvGNHJ2XFmiVUGhRpjQRAViHLE4yi+zB-StJdUdg@mail.gmail.com>
Message-ID: <20180902080701.i5juplmwihwtppnp@zippy.shellcode.eu>

On Sun, Sep 02, 2018 at 08:29:42AM +0200, Andy Kosela typed:

> OpenBSD is also using uvm[1].  But these days it certainly differs from
> NetBSD implementation as it was hacked on by different people during the
> last several years.
> 
> [1] https://man.openbsd.org/uvm.9

Both forks now include a unified buffer cache.

There is an interesting series of blog posts at

<http://blog.pr4tt.com/2016/02/02/BSD-virtual-memory/>

The OpenBSD UVM has particularly diverged from the original with the
addition of a "dead entry queue" and the blog author complains about its
lack of documentation.  He also mentions an experimental RadixVM as
being current "state of the art" although its not available on any
mainstream systems.

-- 
Steve Mynott <steve.mynott at gmail.com>
cv25519/ECF8B611205B447E091246AF959E3D6197190DD5


From dave at horsfall.org  Sun Sep  2 23:06:19 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 2 Sep 2018 23:06:19 +1000 (EST)
Subject: [TUHS] Public access multics
In-Reply-To: <CAC0cEp9w=-EVT5jJheEQfgqyKvirkt1pEPo6YNhE1ThC521SRw@mail.gmail.com>
References: <899D86D7-1601-4FDA-869A-10EC46500D0D@gmail.com>
 <m2y3ck6h8o.fsf@irreal.org>
 <CAC0cEp9w=-EVT5jJheEQfgqyKvirkt1pEPo6YNhE1ThC521SRw@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.1809022258340.28912@aneurin.horsfall.org>

On Sat, 1 Sep 2018, John P. Linderman wrote:

> PL/I was a language designed by a committee, and it showed. [...]

I have never seen a full-blown PL/I compiler (only subsets), and I recall 
being told that there never will be one because it is simply impossible, 
given the spec.

Naturally I am happy to be proven wrong on this.

-- Dave


From imp at bsdimp.com  Mon Sep  3 00:55:29 2018
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 2 Sep 2018 08:55:29 -0600
Subject: [TUHS] UVM VM system
In-Reply-To: <CAK7dMtBM6YhEPpsxwnvuZabcF6YVYTsx7jof4GQak6QcP2yh+g@mail.gmail.com>
References: <20180901185053.GA20993@mcvoy.com>
 <CAC20D2OXVo0ng5bnpjVO_uLRLqGo3ROxhCNdJaTmr8qa3Nb_EQ@mail.gmail.com>
 <CAP6exYKs9H=GKxeOxu6vcf1By3CZP-Hjk0K1dPgfH67K=WQNQQ@mail.gmail.com>
 <CANCZdfogHqPr6GQ50y_8gVrhnNG-KxPWARuAoGHbKNOL_BKU6A@mail.gmail.com>
 <CAK7dMtBM6YhEPpsxwnvuZabcF6YVYTsx7jof4GQak6QcP2yh+g@mail.gmail.com>
Message-ID: <CANCZdfpezckxXh5j2RO4K=W_Zq+eVGcsauC4h9sw4r+pZRe=YA@mail.gmail.com>

On Sat, Sep 1, 2018, 11:19 PM Kevin Bowling <kevin.bowling at kev009.com>
wrote:

> Seems like Chuck Cranor is at CMU http://chuck.cranor.org/.  Chuck
> Silvers is with you?
>

Why I'm embarrassed to admit you are right. Chuck Silvers also did some VM
work, but not uvm.

Warner

On Sat, Sep 1, 2018 at 1:25 PM, Warner Losh <imp at bsdimp.com> wrote:
> >
> >
> > On Sat, Sep 1, 2018, 1:42 PM ron minnich <rminnich at gmail.com> wrote:
> >>
> >> I was his advisor on that thesis so I got to watch it roll out as it
> >> happened.
> >>
> >> uvm replaced the machvm in netbsd.
> >>
> >> For a time, Chuck set it up to run in parallel with the existing VM. You
> >> could start a process and pick which vm it used. For a while, it
> defaulted
> >> to the existing one. Then, at some point, it defaulted to uvm. Then, at
> some
> >> point, the old one was removed.
> >>
> >> more here:
> >>
> >> http://www.netbsd.org/docs/kernel/uvm.html
> >>
> >> via search terms
> >> uvm replaces machvm netbsd
> >>
> >> chuck was a long time contributor to netbsd IIRC, but last time we
> talked,
> >> he was using Linux.
> >
> >
> > These days I know he's hacking on FreeBSD's storage stack with me at work
> > :). I think he's still a netbsd contributor. I see his name in the commit
> > log often..
> >
> > Warner
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180902/270d760a/attachment.html>

From will.senn at gmail.com  Mon Sep  3 01:28:36 2018
From: will.senn at gmail.com (Will Senn)
Date: Sun, 2 Sep 2018 10:28:36 -0500
Subject: [TUHS] UVM VM system
In-Reply-To: <CANCZdfpezckxXh5j2RO4K=W_Zq+eVGcsauC4h9sw4r+pZRe=YA@mail.gmail.com>
References: <20180901185053.GA20993@mcvoy.com>
 <CAC20D2OXVo0ng5bnpjVO_uLRLqGo3ROxhCNdJaTmr8qa3Nb_EQ@mail.gmail.com>
 <CAP6exYKs9H=GKxeOxu6vcf1By3CZP-Hjk0K1dPgfH67K=WQNQQ@mail.gmail.com>
 <CANCZdfogHqPr6GQ50y_8gVrhnNG-KxPWARuAoGHbKNOL_BKU6A@mail.gmail.com>
 <CAK7dMtBM6YhEPpsxwnvuZabcF6YVYTsx7jof4GQak6QcP2yh+g@mail.gmail.com>
 <CANCZdfpezckxXh5j2RO4K=W_Zq+eVGcsauC4h9sw4r+pZRe=YA@mail.gmail.com>
Message-ID: <82A3E3CE-2A86-4DDA-9C70-A2B6EE4872F7@gmail.com>

According to the Netbsd page:

Chuck Cranor designed and implemented UVM, Matthew Green handled integration issues and wrote the swap subsystem, Chuck Silvers wrote the anonymous memory object pager (which added support for shared memory), and various other developers have converted the appropriate ports across. Andrew Brown modified UVM to be able to do top down memory management.

It appears both Chuck’s contributed!

Will

Sent from my iPhone

> On Sep 2, 2018, at 9:55 AM, Warner Losh <imp at bsdimp.com> wrote:
> 
> 
> 
>> On Sat, Sep 1, 2018, 11:19 PM Kevin Bowling <kevin.bowling at kev009.com> wrote:
>> Seems like Chuck Cranor is at CMU http://chuck.cranor.org/.  Chuck
>> Silvers is with you?
> 
> 
> Why I'm embarrassed to admit you are right. Chuck Silvers also did some VM work, but not uvm.
> 
> Warner
> 
>> On Sat, Sep 1, 2018 at 1:25 PM, Warner Losh <imp at bsdimp.com> wrote:
>> >
>> >
>> > On Sat, Sep 1, 2018, 1:42 PM ron minnich <rminnich at gmail.com> wrote:
>> >>
>> >> I was his advisor on that thesis so I got to watch it roll out as it
>> >> happened.
>> >>
>> >> uvm replaced the machvm in netbsd.
>> >>
>> >> For a time, Chuck set it up to run in parallel with the existing VM. You
>> >> could start a process and pick which vm it used. For a while, it defaulted
>> >> to the existing one. Then, at some point, it defaulted to uvm. Then, at some
>> >> point, the old one was removed.
>> >>
>> >> more here:
>> >>
>> >> http://www.netbsd.org/docs/kernel/uvm.html
>> >>
>> >> via search terms
>> >> uvm replaces machvm netbsd
>> >>
>> >> chuck was a long time contributor to netbsd IIRC, but last time we talked,
>> >> he was using Linux.
>> >
>> >
>> > These days I know he's hacking on FreeBSD's storage stack with me at work
>> > :). I think he's still a netbsd contributor. I see his name in the commit
>> > log often..
>> >
>> > Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180902/ca5f6a4b/attachment.html>

From charles.unix.pro at gmail.com  Mon Sep  3 02:23:15 2018
From: charles.unix.pro at gmail.com (Charles Anthony)
Date: Sun, 2 Sep 2018 09:23:15 -0700
Subject: [TUHS] Public access multics
In-Reply-To: <alpine.BSF.2.21.9999.1809022258340.28912@aneurin.horsfall.org>
References: <899D86D7-1601-4FDA-869A-10EC46500D0D@gmail.com>
 <m2y3ck6h8o.fsf@irreal.org>
 <CAC0cEp9w=-EVT5jJheEQfgqyKvirkt1pEPo6YNhE1ThC521SRw@mail.gmail.com>
 <alpine.BSF.2.21.9999.1809022258340.28912@aneurin.horsfall.org>
Message-ID: <CANV78LSfeJMw8gA8+=SYxiiOb2_k+zZt1PUe4ScPOsAnOdzv5A@mail.gmail.com>

On Sun, Sep 2, 2018 at 6:07 AM Dave Horsfall <dave at horsfall.org> wrote:

> On Sat, 1 Sep 2018, John P. Linderman wrote:
>
> > PL/I was a language designed by a committee, and it showed. [...]
>
> I have never seen a full-blown PL/I compiler (only subsets), and I recall
> being told that there never will be one because it is simply impossible,
> given the spec.
>
> Naturally I am happy to be proven wrong on this.
>
>
AM83 Multics PL1 Reference Manual, pg 1-1: "Multics PL/I is closely related
to American National Standards Programming Language PL/I. ... ANSI
X3.53-1976... For a complete description of the differences between Multics
PL/I and Standard PL/I, see Appendix A of the PL/I Language Specification."

Appendix A, pp A-1 to A-4:
https://drive.google.com/open?id=12wRW7vgCVTP4bL7942YiEEUQc2J9bWes
https://drive.google.com/open?id=1McndftW6HPioowfIAmL1P8WhabpvYeWg
https://drive.google.com/open?id=1XJdaj8YGHTERjTu9xq3KEM0nAGiAFm2M
https://drive.google.com/open?id=18VdXROFQmkm_9zL1XLHZCeOxiPLmWDMD

-- Charles



-- Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180902/857bae02/attachment.html>

From paul.winalski at gmail.com  Mon Sep  3 04:18:06 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Sun, 2 Sep 2018 14:18:06 -0400
Subject: [TUHS] Public access multics
In-Reply-To: <alpine.BSF.2.21.9999.1809022258340.28912@aneurin.horsfall.org>
References: <899D86D7-1601-4FDA-869A-10EC46500D0D@gmail.com>
 <m2y3ck6h8o.fsf@irreal.org>
 <CAC0cEp9w=-EVT5jJheEQfgqyKvirkt1pEPo6YNhE1ThC521SRw@mail.gmail.com>
 <alpine.BSF.2.21.9999.1809022258340.28912@aneurin.horsfall.org>
Message-ID: <CABH=_VTwNPFf8rei_aMsjPqK=vu6wG=ULBtHdGaJ_0=va8Ra=Q@mail.gmail.com>

On 9/2/18, Dave Horsfall <dave at horsfall.org> wrote:
>
> I have never seen a full-blown PL/I compiler (only subsets), and I recall
> being told that there never will be one because it is simply impossible,
> given the spec.
>
> Naturally I am happy to be proven wrong on this.

IBM had PL/I compilers for TOS, DOS, and OS on System/360, and for
DOS/VS and OS/VS on System/370.  If those weren't full implementations
of the original spec, they were pretty close.

IBM PL/I had a good number of what I call toxic language features,
such as the DEFAULT statement (which was Fortran's IMPLICIT on
steroids).  Most PL/I shops had as part of their coding standards a
set of language features banned from the code.  The ANSI standard
eliminated a lot of these, although it also threw out some useful
features such as iSUB defining and by-name structure assignment.

One of my favourite features was sterling pictures, with pounds,
shillings, and pence fields (represented internally as a packed
decimal value in pence).  Sterling pictures weren't finally deprecated
in the IBM PL/I compilers until 1979, IIRC.

-Paul W,.


From paul.winalski at gmail.com  Mon Sep  3 05:09:37 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Sun, 2 Sep 2018 15:09:37 -0400
Subject: [TUHS] Public access multics
In-Reply-To: <CABH=_VTwNPFf8rei_aMsjPqK=vu6wG=ULBtHdGaJ_0=va8Ra=Q@mail.gmail.com>
References: <899D86D7-1601-4FDA-869A-10EC46500D0D@gmail.com>
 <m2y3ck6h8o.fsf@irreal.org>
 <CAC0cEp9w=-EVT5jJheEQfgqyKvirkt1pEPo6YNhE1ThC521SRw@mail.gmail.com>
 <alpine.BSF.2.21.9999.1809022258340.28912@aneurin.horsfall.org>
 <CABH=_VTwNPFf8rei_aMsjPqK=vu6wG=ULBtHdGaJ_0=va8Ra=Q@mail.gmail.com>
Message-ID: <CABH=_VTK2WE9iJE14hcg6dR2udfwXrRr=1bC5aoDX1DPYT7+7w@mail.gmail.com>

On 9/2/18, Paul Winalski <paul.winalski at gmail.com> wrote:
>
> IBM had PL/I compilers for TOS, DOS, and OS on System/360, and for
> DOS/VS and OS/VS on System/370.  If those weren't full implementations
> of the original spec, they were pretty close.

TOS, DOS, and DOS/VS PL/I didn't implement PL/I's multitasking
features (such as TASKs and EVENTs) because those OSes had no
multitasking support.

-Paul W.


From tytso at mit.edu  Mon Sep  3 05:43:01 2018
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Sun, 2 Sep 2018 15:43:01 -0400
Subject: [TUHS] SunOS code?
In-Reply-To: <CAK7dMtC4VL56Utb67-LJfXrZ2oStUb_MDFO4q-PakGjjHOF82w@mail.gmail.com>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch>
 <20180831215854.GB28971@mcvoy.com>
 <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net>
 <CAK7dMtB8AmPG5ZMceGZdD8sxL10horfO0ZYLfXuX=4Dp8u7bwQ@mail.gmail.com>
 <ee7772a4-c23a-3344-4f10-c561047ffbb5@kilonet.net>
 <20180901221933.GA2214@thunk.org>
 <CAK7dMtC4VL56Utb67-LJfXrZ2oStUb_MDFO4q-PakGjjHOF82w@mail.gmail.com>
Message-ID: <20180902194301.GA22518@thunk.org>

On Sat, Sep 01, 2018 at 10:05:06PM -0700, Kevin Bowling wrote:
> 
> Sorry this is just bogus about being weak compared to Solaris.  Are
> you looking back with rosy glasses or have you scanned the code in the
> past couple years?  I have and there is nothing particularly special
> about Solaris internals here or elsewhere.

I haven't looked at Solaris code; I had just *assumed* that if they
were selling million dollar E10k's, they would have had NUMA support
at *least* as good as SGI's Irix.  And it would have been an excuse
for their pathetic performance on UP and 2-4 SMP systems.

> Keep in mind IBM wants to sell RockHoppers and E980s (4 drawers, 16
> sockets, 768 threads) for dedicated Linux use which have similar
> north/south and east/west off chip networks.  They have a lot of very
> talented people on the firmware, kernel, compilers to make these
> things work fast, including Paul.
> ...
> Where you start going beyond Linux-like NUMA IMO is when you get
> Irix-like features of page copying, migration, and multiple advanced
> placement policies.

One thing to consider is that IBM really only cared about optimizing
hardware for DB2, Oracle, and Webshpere.  That's one of the reason why
you didn't see much in the way of innovative file system work, ala
ZFS.  There was no business justification for pouring 100+ engineer
years to develop a next-generation file systesm --- and they had
already done that once already for GPFS, a cluster file system.  As
far as local disk file system was concerned, the only real business
value it had was to serve as a program loader for DB2 and Websphere.  :-)

(I'm exagerating a little for effect, but *only* a little.)

So as far as NUMA was concerned, there was almost certainly not have
been much perceived business value in having sophisticated
auto-migration for arbitrary workloads in the kernel.  Something basic
which was good enough for Oracle, DB2, etc., was all that would be
needed.  (And if you needed to hire consultants from IBM Global
Services to mind-meld with the configuration documentation in order to
get the best out of your Rockhopper.... well, shucks, darn.  :-)

At IBM the business people really did make the funding decisions of
what to work on.  ZFS could have never happened at IBM because no one
would have thought that a even a tiny number of IBM's current or
potential customer base would abandon AIX or Linux and switch to
Solaris, or buy Sun hardware instead of IBM hardware --- just for the
sake of ZFS.  And that's how decision-makers at IBM really thought.
(And to be fair to those decision-makers, IBM is still in business as
a free-standing business --- and Sun is not.)

  			     	     	- Ted


From doug at cs.dartmouth.edu  Mon Sep  3 07:47:01 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sun, 02 Sep 2018 17:47:01 -0400
Subject: [TUHS] Public access multics
Message-ID: <201809022147.w82Ll1nu034542@tahoe.cs.Dartmouth.EDU>

Caveat: As a member of the PL/I committee, and the person who brought
the new and unimplemented language to the attention of Multics, let a
disastrous contract for a compiler, and finally helped cobble together
a rudimentary compiler that got the project off the ground, I am not
exactly an unbiased observer.

A ground tenet of Multics was that it would be programmed in a higher
level language. A subsidiary requirement, which was generally agreed
upon, was language-level access to the logical operators and address
manipulation inherent in the hardware.  No widely used language of the
time met this requirement.  And they didn't want to get sidetracked into
language design.

Discussions finally boiled down to AED, developed at MIT by Doug Ross, and
PL/I. Ross was a brilliant software innovator with a mystical outlook that
made it difficult to distinguish his vision of what could be done from
what actually existed. AED was definitely a moving target. By contrast
PL/I had a written spec, so you knew exactly what could be done in it,
though not how well the compiler would do it.

PL/I  was very big; we deliberately (and explicitly) omitted about
half the spec. The remainder was definitely seen as a "plausible
systems programming language".

>From the perspective of the time, why do you think the contrary?

Doug


From will.senn at gmail.com  Mon Sep  3 08:30:25 2018
From: will.senn at gmail.com (Will Senn)
Date: Sun, 2 Sep 2018 17:30:25 -0500
Subject: [TUHS] Public access multics
In-Reply-To: <0D39179A-9133-4388-ABEC-DCD769E9CD24@pobox.com>
References: <20180901232537.615A418C09E@mercury.lcs.mit.edu>
 <10B61FE8-1418-4201-A782-76E07BD2D34A@gmail.com>
 <0D39179A-9133-4388-ABEC-DCD769E9CD24@pobox.com>
Message-ID: <FE0CD5D4-A239-4D41-A3FE-1D914BBB1541@gmail.com>

Nice. I’ve always marveled at how, dare I say it while not doing anything about it, badly, dynamic linking has fared in nearly every os I can think of? It is a very convenient feature to have, but the way are implemented can be a little frustrating to a user who isn’t steeped in the internals of the implementation.

Thanks for the lesson!

Sent from my iPhone

> On Sep 1, 2018, at 11:25 PM, Jeffrey H. Johnson <trnsz at pobox.com> wrote:
> 
> While the best loved feature is probably the pervasive dynamic linking, which is still unrivaled, and the security features (ring brackets, AIM (multilevel labeling), and ACLs) which are the most famous, a feature that isn't built in to Unix and is constantly being reinvented that was available in Multics is the ability to easily set aside a CPU and some memory and disk, while leaving the system in operation, and start another separate instance to do development work, and then when the work is done, be reconfigured to merge the system back into one instance, without disrupting production work.  
> 
> That dynamic reconfiguration was one original design specifications of the system, as opposed to being added later. Much of what makes Multics wonderful to me is just how amazingly sturdily it's engineered and how complete the implementations of these ideas are.
> 
> Another thing to comes to mind immediately is how hierarchical the system is. For example, users are registered on to projects, and a project administrator can be delegated the task of registering and deregistering user accounts and managing the system resources such as disk quota and access to printers and other physical resources for their project. 
> 
> The system administrator can manage the resources assigned to projects, and the project administration handles how that's further carved up amongst the users.
> 
> You can have similar granularity in assigning the distribution of resources such as CPU and memory use, by using the workload management features to ensure that high priority tasks/users/projects will always have needed resources available, preempting lower priority tasks if necessary. 
> 
> The I/O system, (while not exceedingly elegant - see iox_), far exceeds what is available in Unix today, but by design.
> 
> The reputation of Multics as a 'complex' system is, in my experience, well deserved, but that complexity does not mean it's a terrible system to use or administer. I find it quite refreshing and it almost never feels dated.
> 
> -- Jeff
> https://ban.ai/multics
> 
>> On Sep 2, 2018, at 12:05 AM, Will Senn <will.senn at gmail.com> wrote:
>> 
>> On Sep 1, 2018, at 6:25 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>> 
>>>> From: Will Senn
>>> 
>>>> I was thinking that Multics was a failed predecessor of unix
>>>> ... straighten me out :)
>>> 
>>> I'd start with:
>>> 
>>> https://multicians.org/myths.html
>> 
>> Noel, Fascinating read. I must’ve read at least a good handful of the references leading to the myths described in the writeup. As usual, I can trust the folks who lived history to remember it more clearly than many revisionists writing about it later.
>> 
>> Thanks for sharing.
>> 
>> Now, I’m wondering what awesome features Multics had that we’re still lacking in modern *nices... anything as amazing as say, my favorite filesystem, ZFS?
>> 
>> Will
> 


From dfawcus+lists-tuhs at employees.org  Mon Sep  3 08:45:15 2018
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Sun, 2 Sep 2018 23:45:15 +0100
Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?=
In-Reply-To: <49620ace-ca66-c288-2ab3-3a0fe4af640e@spamtrap.tnetconsulting.net>
References: <f3f250f4-cffd-794c-450a-d1c3829c890e@spamtrap.tnetconsulting.net>
 <20180830175420.3zs4gpyacsgrh7wc@h-174-65.A328.priv.bahnhof.se>
 <49620ace-ca66-c288-2ab3-3a0fe4af640e@spamtrap.tnetconsulting.net>
Message-ID: <20180902224515.GA57766@bugle.employees.org>

On Thu, Aug 30, 2018 at 12:11:17PM -0600, Grant Taylor via TUHS wrote:
> But if you want to use 
> RetroNet to play Doom across IPX with buddies across town, then you 
> should be able to do so.

Err - maybe not.

I recall doing that once or twice on our office LAN at the time,
it was very chatty - as I recall it sucked most of the available b/w.

(Or maybe that was just 'cause it was using broadcast packets)

DF


From gtaylor at tnetconsulting.net  Mon Sep  3 09:29:04 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Sun, 2 Sep 2018 17:29:04 -0600
Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?=
In-Reply-To: <20180902224515.GA57766@bugle.employees.org>
References: <f3f250f4-cffd-794c-450a-d1c3829c890e@spamtrap.tnetconsulting.net>
 <20180830175420.3zs4gpyacsgrh7wc@h-174-65.A328.priv.bahnhof.se>
 <49620ace-ca66-c288-2ab3-3a0fe4af640e@spamtrap.tnetconsulting.net>
 <20180902224515.GA57766@bugle.employees.org>
Message-ID: <da948c7a-bdd1-0c97-8b37-1a447d2d6864@spamtrap.tnetconsulting.net>

On 09/02/2018 04:45 PM, Derek Fawcus wrote:
> Err - maybe not.

O.o?

> I recall doing that once or twice on our office LAN at the time, it was 
> very chatty - as I recall it sucked most of the available b/w.

That surprises me.

Though to be fair, I never did it that often and it was always during 
times that bandwidth wasn't an issue.

> (Or maybe that was just 'cause it was using broadcast packets)

I don't know.

I will say, functionality is different than feasibility.



-- 
Grant. . . .
unix || die

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

From robert at timetraveller.org  Mon Sep  3 11:14:07 2018
From: robert at timetraveller.org (Robert Brockway)
Date: Mon, 3 Sep 2018 11:14:07 +1000 (AEST)
Subject: [TUHS] UNIX System names - since UNIX was a Trademark
In-Reply-To: <CABH=_VSUfT0eQY9gnKJqYOfNC_9E3=OGuhFicv26-rFxJNKMNA@mail.gmail.com>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808300825340.41601@aneurin.horsfall.org>
 <20180829233605.GJ8423@mcvoy.com>
 <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com>
 <CAK7dMtDgkkkP1kGbGRt48ON1BrMkN2GSsi8bfe=EeOGT3O8esw@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808311023210.41601@aneurin.horsfall.org>
 <CAC20D2OecE9WX8o4A+VgtEi51c3_QiXQQSq7_t1YGwNK_FG8kw@mail.gmail.com>
 <3b0a2895-4a6b-48c4-87da-cc1018d7b665.maildroid@localhost>
 <CAC0cEp_7jwxdywgs8es0qSBJty3D92BM192-coNEz-EuVQi+pg@mail.gmail.com>
 <261201d44189$60c7aa50$2256fef0$@ronnatalie.com>
 <CAJfiPzwpZofM9CbjbY5z4Wp5nHxsLuSsLK4Wjd9xggy768K7ng@mail.gmail.com>
 <alpine.BSF.2.21.9999.1809011711200.22638@aneurin.horsfall.org>
 <CABH=_VSUfT0eQY9gnKJqYOfNC_9E3=OGuhFicv26-rFxJNKMNA@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1809031104250.650@mira.opentrend.net>

On Sat, 1 Sep 2018, Paul Winalski wrote:

> On 9/1/18, Dave Horsfall <dave at horsfall.org> wrote:
>>
>> Oh, and I also trained myself to use a mouse in my left hand (in
>> right-hand mode, and in my SunOS days too!) which is apparently quite
>> common amongst the righties; after all, why waste a perfectly good hand?
>> It's hilarious watching someone letting go of the mouse to write something
>> down, then back to the mouse again...
>
> I'm left-handed but I trained myself to use a mouse in my right hand,
> for the reason you point out--I still have my dominant hand free to
> write things down.  It also means that when I'm using someone else's
> machine, most of the time their mouse is configured the way I'm used
> to.

At the risk of making a 'me too' post (especially these days) I am also 
left handed and trained myself to use a mouse right handed for both of the 
reasons you mention.

Left handedness is very well studied so I wondered if there were any 
studies on this.

While looking I found one that argues that numeric keypads and using the 
mouse on the right don't mix.  Maybe time to run with a keyboard with no 
numeric keypad again.[1]

https://www.ncbi.nlm.nih.gov/pubmed/14985137

[1] As a leftie it's on the wrong side anyway.

Rob


From jsteve at superglobalmegacorp.com  Mon Sep  3 11:11:08 2018
From: jsteve at superglobalmegacorp.com (jsteve at superglobalmegacorp.com)
Date: Mon, 3 Sep 2018 09:11:08 +0800
Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?=
In-Reply-To: <20180902224515.GA57766@bugle.employees.org>
References: <f3f250f4-cffd-794c-450a-d1c3829c890e@spamtrap.tnetconsulting.net>
 <20180830175420.3zs4gpyacsgrh7wc@h-174-65.A328.priv.bahnhof.se>
 <49620ace-ca66-c288-2ab3-3a0fe4af640e@spamtrap.tnetconsulting.net>
 <20180902224515.GA57766@bugle.employees.org>
Message-ID: <b8627162-558b-415a-b3d5-b64b48ba74f4@SG2APC01FT026.eop-APC01.prod.protection.outlook.com>

That is the first version.  It sent out full 1500 byte frames. Later versions had corrected that. They were padded to all zeros, so they compress quite nicely.


Sent from my Windows 10 phone

From: Derek Fawcus
Sent: Monday, 3 September 2018 06:45
To: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] RetroNet…

On Thu, Aug 30, 2018 at 12:11:17PM -0600, Grant Taylor via TUHS wrote:
> But if you want to use 
> RetroNet to play Doom across IPX with buddies across town, then you 
> should be able to do so.

Err - maybe not.

I recall doing that once or twice on our office LAN at the time,
it was very chatty - as I recall it sucked most of the available b/w.

(Or maybe that was just 'cause it was using broadcast packets)

DF

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

From arnold at skeeve.com  Mon Sep  3 16:18:54 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 03 Sep 2018 00:18:54 -0600
Subject: [TUHS] Public access multics
In-Reply-To: <201809022147.w82Ll1nu034542@tahoe.cs.Dartmouth.EDU>
References: <201809022147.w82Ll1nu034542@tahoe.cs.Dartmouth.EDU>
Message-ID: <201809030618.w836IsgW017828@freefriends.org>

Was Algol 60 any kind of viable alternative at the time? IIRC
manufacturers in Europe were using it for systems programming.
(This is all before my time, so I could be wrong, which is why
I'm curious.)  In the US Burroughs used Algol, but that may have
been later than the mid-60s timeframe of Multics.

Thanks,

Arnold

Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> Caveat: As a member of the PL/I committee, and the person who brought
> the new and unimplemented language to the attention of Multics, let a
> disastrous contract for a compiler, and finally helped cobble together
> a rudimentary compiler that got the project off the ground, I am not
> exactly an unbiased observer.
>
> A ground tenet of Multics was that it would be programmed in a higher
> level language. A subsidiary requirement, which was generally agreed
> upon, was language-level access to the logical operators and address
> manipulation inherent in the hardware.  No widely used language of the
> time met this requirement.  And they didn't want to get sidetracked into
> language design.
>
> Discussions finally boiled down to AED, developed at MIT by Doug Ross, and
> PL/I. Ross was a brilliant software innovator with a mystical outlook that
> made it difficult to distinguish his vision of what could be done from
> what actually existed. AED was definitely a moving target. By contrast
> PL/I had a written spec, so you knew exactly what could be done in it,
> though not how well the compiler would do it.
>
> PL/I  was very big; we deliberately (and explicitly) omitted about
> half the spec. The remainder was definitely seen as a "plausible
> systems programming language".
>
> From the perspective of the time, why do you think the contrary?
>
> Doug


From trnsz at pobox.com  Mon Sep  3 17:02:28 2018
From: trnsz at pobox.com (Jeffrey H. Johnson)
Date: Mon, 3 Sep 2018 03:02:28 -0400
Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?=
In-Reply-To: <20180902224515.GA57766@bugle.employees.org>
References: <f3f250f4-cffd-794c-450a-d1c3829c890e@spamtrap.tnetconsulting.net>
 <20180830175420.3zs4gpyacsgrh7wc@h-174-65.A328.priv.bahnhof.se>
 <49620ace-ca66-c288-2ab3-3a0fe4af640e@spamtrap.tnetconsulting.net>
 <20180902224515.GA57766@bugle.employees.org>
Message-ID: <FB0B84A0-002A-46AA-A9BE-19124C02686D@pobox.com>

Interestingly - 

https://virtuallyfun.com/wordpress/2013/10/25/doom-ipx-revisited/ has a good writeup on the Doom IPX issue - it was a poor implementation sending mainly empty frames.  https://virtuallyfun.com/wordpress/2014/06/10/announcing-hecnetnt/ shows how adding compression to a bridge is able to eliminate 80% of the traffic.

Bring this back on topic, perhaps adding optional LZO compression, but enabled by default, would be a good idea for RetroNet.

--Jeff 

> On Sep 2, 2018, at 6:45 PM, Derek Fawcus <dfawcus+lists-tuhs at employees.org> wrote:
> 
>> On Thu, Aug 30, 2018 at 12:11:17PM -0600, Grant Taylor via TUHS wrote:
>> But if you want to use RetroNet to play Doom across IPX with buddies across town, then you should be able to do so.
> 
> Err - maybe not.
> 
> I recall doing that once or twice on our office LAN at the time, it was very chatty - as I recall it sucked most of the available b/w.
> 
> (Or maybe that was just 'cause it was using broadcast packets)
> 
> DF
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180903/d66b76d2/attachment.html>

From erc at pobox.com  Mon Sep  3 17:21:00 2018
From: erc at pobox.com (Ed Carp)
Date: Mon, 3 Sep 2018 00:21:00 -0700
Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?=
In-Reply-To: <20180829202111.GA17007@minnie.tuhs.org>
References: <f3f250f4-cffd-794c-450a-d1c3829c890e@spamtrap.tnetconsulting.net>
 <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com>
 <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net>
 <6e3a87ce-f573-4258-9db5-a5f99b5b89b1.maildroid@localhost>
 <20180829202111.GA17007@minnie.tuhs.org>
Message-ID: <CACYmRND_fh-pnPyEp5a5_7XYtEV2ZsWK_stMnrL2VWv_NBS8Fg@mail.gmail.com>

Wow, that takes me back quite a ways. I think I've still got my UUCP
setup somewhere on a backup. UUCP works great over anything from ssh
over tcpip to 1200 baud half-duplex packet connections.

Fond memories.

On 8/29/18, Warren Toomey <wkt at tuhs.org> wrote:
> On Wed, Aug 29, 2018 at 02:38:20PM -0400, William Pechter wrote:
>> Count me in.  Do we need to work up a UUCP mapping project.
>
> Argh, argh! I did a lot of this last year. It's all on Github at
> https://github.com/DoctorWkt/4bsd-uucp/
>
> We got as far as recreating this microcosm of Usenet
> https://github.com/DoctorWkt/4bsd-uucp/blob/4.3BSD/uucp.png
>
> before it all petered out!
>
> Cheers, Warren
>


From jsteve at superglobalmegacorp.com  Mon Sep  3 18:24:47 2018
From: jsteve at superglobalmegacorp.com (jsteve at superglobalmegacorp.com)
Date: Mon, 3 Sep 2018 16:24:47 +0800
Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?=
In-Reply-To: <FB0B84A0-002A-46AA-A9BE-19124C02686D@pobox.com>
References: <f3f250f4-cffd-794c-450a-d1c3829c890e@spamtrap.tnetconsulting.net>
 <20180830175420.3zs4gpyacsgrh7wc@h-174-65.A328.priv.bahnhof.se>
 <49620ace-ca66-c288-2ab3-3a0fe4af640e@spamtrap.tnetconsulting.net>
 <20180902224515.GA57766@bugle.employees.org>
 <FB0B84A0-002A-46AA-A9BE-19124C02686D@pobox.com>
Message-ID: <c6448cc8-27d5-47b9-af55-8dcb73e0247b@SG2APC01FT048.eop-APC01.prod.protection.outlook.com>

Yes, I’m familiar with that write up…. I wrote it!

And yes, it's why I later grabbed a bunch of compression algorithms and went with lzss as it compressed well, fast an ld was tiny compared to others...

https://virtuallyfun.com/wordpress/2014/06/06/i-forget-what-i-was-looking-for/

I would highly recommend compressing the frames for sure.  On high latency links it sure helps too.  

It's also why cisco had licensed LZS compression for their serial links.  And totally worth looking at.

From: Jeffrey H. Johnson
Sent: Monday, 3 September 2018 15:12
To: Derek Fawcus
Cc: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] RetroNet…

Interestingly - 

https://virtuallyfun.com/wordpress/2013/10/25/doom-ipx-revisited/ has a good writeup on the Doom IPX issue - it was a poor implementation sending mainly empty frames.  https://virtuallyfun.com/wordpress/2014/06/10/announcing-hecnetnt/ shows how adding compression to a bridge is able to eliminate 80% of the traffic.

Bring this back on topic, perhaps adding optional LZO compression, but enabled by default, would be a good idea for RetroNet.

--Jeff 


On Sep 2, 2018, at 6:45 PM, Derek Fawcus <dfawcus+lists-tuhs at employees.org> wrote:
On Thu, Aug 30, 2018 at 12:11:17PM -0600, Grant Taylor via TUHS wrote:

But if you want to use RetroNet to play Doom across IPX with buddies across town, then you should be able to do so.

Err - maybe not.

I recall doing that once or twice on our office LAN at the time, it was very chatty - as I recall it sucked most of the available b/w.

(Or maybe that was just 'cause it was using broadcast packets)

DF

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

From doug at cs.dartmouth.edu  Mon Sep  3 23:29:05 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Mon, 03 Sep 2018 09:29:05 -0400
Subject: [TUHS] Public access multics
Message-ID: <201809031329.w83DT5q0105108@tahoe.cs.Dartmouth.EDU>

> Was Algol 60 any kind of viable alternative at the time?

The operating system for the Burroughs B5000 had been written in
Burroughs Algol. That punctured the widespread belief that OS's
were so particular to the hardware that they had to be written
in machine language. I don't recall how far Burroughs Algol
went beyond Algol 60, nor why Multics did not want to follow
that lead.  ("Viable" is a slippery concept when choosing
among Turing-complete alternatives.)

Doug


From gtaylor at tnetconsulting.net  Tue Sep  4 02:42:38 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Mon, 3 Sep 2018 10:42:38 -0600
Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?=
In-Reply-To: <FB0B84A0-002A-46AA-A9BE-19124C02686D@pobox.com>
References: <f3f250f4-cffd-794c-450a-d1c3829c890e@spamtrap.tnetconsulting.net>
 <20180830175420.3zs4gpyacsgrh7wc@h-174-65.A328.priv.bahnhof.se>
 <49620ace-ca66-c288-2ab3-3a0fe4af640e@spamtrap.tnetconsulting.net>
 <20180902224515.GA57766@bugle.employees.org>
 <FB0B84A0-002A-46AA-A9BE-19124C02686D@pobox.com>
Message-ID: <f76d5153-9477-836c-673f-23fb344e4a95@spamtrap.tnetconsulting.net>

On 09/03/2018 01:02 AM, Jeffrey H. Johnson wrote:
> Bring this back on topic, perhaps adding optional LZO compression, but 
> enabled by default, would be a good idea for RetroNet.

Interesting idea Jeff.

I don't know that any of the Lego bricks that we're currently using 
support any form of compression.

We'll have to investigate.

Consider compression to be on the "It would be really nice to have" list.



-- 
Grant. . . .
unix || die

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

From ca6c at bitmessage.ch  Tue Sep  4 04:04:01 2018
From: ca6c at bitmessage.ch (=?utf-8?B?Q8OhZw==?=)
Date: Mon, 03 Sep 2018 13:04:01 -0500
Subject: [TUHS] cat -v and other complaints
In-Reply-To: <CAD-qYGqsq=kZKrHcqUws4mpjV9VGnpNFb31ubUOZ67yOfZMWZA@mail.gmail.com>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <20180831215636.-eCEx%ca6c@bitmessage.ch>
 <CAD-qYGqsq=kZKrHcqUws4mpjV9VGnpNFb31ubUOZ67yOfZMWZA@mail.gmail.com>
Message-ID: <20180903180401.u4MVs%ca6c@bitmessage.ch>

Andrew Warkentin wrote:

> I'd say features like history, completion, and line editing really
> don't belong in a shell. They should be handled by a separate listener
> process with a simple API that shells and other client processes can
> use for controlling them. That's one good example of Plan 9
> prioritizing minimalism above everything else.

http://wiki.c2.com/?WhatIsNotInPlanNine

> fn history {grep '^term%' /mnt/wsys/text|sed -e 's/^term%//'} term%

This is sure better.

On top of that I don't get how Acme adheres to the philosophy. It's
basically a reverse engineered, unavailable on the console, GNU Emacs
with a mouse-driven interface.

--
caóc



From khm at sciops.net  Tue Sep  4 04:11:33 2018
From: khm at sciops.net (Kurt H Maier)
Date: Mon, 3 Sep 2018 11:11:33 -0700
Subject: [TUHS] cat -v and other complaints
In-Reply-To: <20180903180401.u4MVs%ca6c@bitmessage.ch>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <20180831215636.-eCEx%ca6c@bitmessage.ch>
 <CAD-qYGqsq=kZKrHcqUws4mpjV9VGnpNFb31ubUOZ67yOfZMWZA@mail.gmail.com>
 <20180903180401.u4MVs%ca6c@bitmessage.ch>
Message-ID: <20180903181133.GB81368@wopr>

On Mon, Sep 03, 2018 at 01:04:01PM -0500, Cág wrote:
>
> On top of that I don't get how Acme adheres to the philosophy. It's
> basically a reverse engineered, unavailable on the console, GNU Emacs
> with a mouse-driven interface.
>
       
My pet theory is that Acme was going to replace Rio, at which time it
would be 'the interface' again instead of a text editor with a
slightly-incompatible filesystem interface.  There are some hints toward
this if you squint hard enough, but I can't prove it.
       
"Unavailable on the console" is kind of a cheap shot when talking about
an operating system that deliberately doesn't support consoles.  Part of
the point was outgrowing TTYs.
       
The emacs comparison is a favorite of mine because it's so close to
being an anagram, but obviously Acme never suffered from lisp fetishism.
I still dislike Acme for basically all the same reasons I dislike emacs.
       
khm


From ca6c at bitmessage.ch  Tue Sep  4 04:56:16 2018
From: ca6c at bitmessage.ch (=?utf-8?B?Q8OhZw==?=)
Date: Mon, 03 Sep 2018 13:56:16 -0500
Subject: [TUHS] cat -v and other complaints
In-Reply-To: <20180903181133.GB81368@wopr>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <20180831215636.-eCEx%ca6c@bitmessage.ch>
 <CAD-qYGqsq=kZKrHcqUws4mpjV9VGnpNFb31ubUOZ67yOfZMWZA@mail.gmail.com>
 <20180903180401.u4MVs%ca6c@bitmessage.ch> <20180903181133.GB81368@wopr>
Message-ID: <20180903185616.ZnkRk%ca6c@bitmessage.ch>

Kurt H Maier wrote:

> My pet theory is that Acme was going to replace Rio, at which time it
> would be 'the interface' again instead of a text editor with a
> slightly-incompatible filesystem interface.  There are some hints toward
> this if you squint hard enough, but I can't prove it.

Oberon 2.0
        
> "Unavailable on the console" is kind of a cheap shot when talking about
> an operating system that deliberately doesn't support consoles.  Part of
> the point was outgrowing TTYs.

Yeah, I guess I should've started with that :) I love Unix for the
console.

--
caóc



From bakul at bitblocks.com  Tue Sep  4 06:08:41 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Mon, 3 Sep 2018 13:08:41 -0700
Subject: [TUHS] cat -v and other complaints
In-Reply-To: <20180903181133.GB81368@wopr>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <20180831215636.-eCEx%ca6c@bitmessage.ch>
 <CAD-qYGqsq=kZKrHcqUws4mpjV9VGnpNFb31ubUOZ67yOfZMWZA@mail.gmail.com>
 <20180903180401.u4MVs%ca6c@bitmessage.ch> <20180903181133.GB81368@wopr>
Message-ID: <B38971F7-CF92-431A-BB10-8F5B05C33F71@bitblocks.com>

On Sep 3, 2018, at 11:11 AM, Kurt H Maier <khm at sciops.net> wrote:
> 
> I still dislike Acme for basically all the same reasons I dislike emacs.

What text editor do you like?

One measure of success of a program is additional tools people build
to work with it. By that measure emacs has succeeded very well. Acme
is used by far fewer people but it too has had additional tools built. And
even standard tools such as grep work well with it. You can also view it
as an experiment and not an end product. That is, nothing to prevent
anyone from extending it or changing it. The same is true of plan9 too.
An experiment in seeing how far “representing resources as filesystems”
model can be pushed. But for some reason this never happened.  




From khm at sciops.net  Tue Sep  4 06:41:15 2018
From: khm at sciops.net (Kurt H Maier)
Date: Mon, 3 Sep 2018 13:41:15 -0700
Subject: [TUHS] cat -v and other complaints
In-Reply-To: <B38971F7-CF92-431A-BB10-8F5B05C33F71@bitblocks.com>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <20180831215636.-eCEx%ca6c@bitmessage.ch>
 <CAD-qYGqsq=kZKrHcqUws4mpjV9VGnpNFb31ubUOZ67yOfZMWZA@mail.gmail.com>
 <20180903180401.u4MVs%ca6c@bitmessage.ch>
 <20180903181133.GB81368@wopr>
 <B38971F7-CF92-431A-BB10-8F5B05C33F71@bitblocks.com>
Message-ID: <20180903204115.GC99551@wopr>

On Mon, Sep 03, 2018 at 01:08:41PM -0700, Bakul Shah wrote:
> 
> One measure of success of a program is additional tools people build
> to work with it. 

This is true, but unix and plan 9 are special because they have
facilities that let many tools work together.  Unix has pipes, plan 9
has the plumber on top of that, and so forth.  I prefer tools that work
with these systems to create an environment that lets me use the whole
world to do my job.

Emacs pointlessly restricts itself to its own reinventions of the world
it inhabits.  It makes sense if you are using a LispM but it
constitutes a rejection of the 'system' component of 'operating system'
when you transplant it to an ecosystem built on a different paradigm.

The current modality of this antisocial behavior is the web; we've come
full circle, and now we have bespoke web browsers shoved into the
text-editing role, reinventing everything from character addressing to
memory management on the way, treating the underlying system as an
unfortunate accident of history instead of integrating with (or even
learning from) it.

Acme is a bad citizen in similar ways, but as I said, I suspect that's
because it was intended to supplant Rio rather than infect it.

When people talk about "the unix way," they usually hyperfocus on "do
one thing well" and leave composability by the wayside, and that's a
shame, because that's where the real power comes from.  "Do one thing
well" is a method to achieve quality when you're building a piece of a
well-integrated system.  If you're not building a well-integrated
system, you *can't* "do one thing well," because you've signed on to do
everything, come hell or high water.

khm


From bakul at bitblocks.com  Tue Sep  4 07:46:14 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Mon, 3 Sep 2018 14:46:14 -0700
Subject: [TUHS] cat -v and other complaints
In-Reply-To: <20180903204115.GC99551@wopr>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <20180831215636.-eCEx%ca6c@bitmessage.ch>
 <CAD-qYGqsq=kZKrHcqUws4mpjV9VGnpNFb31ubUOZ67yOfZMWZA@mail.gmail.com>
 <20180903180401.u4MVs%ca6c@bitmessage.ch> <20180903181133.GB81368@wopr>
 <B38971F7-CF92-431A-BB10-8F5B05C33F71@bitblocks.com>
 <20180903204115.GC99551@wopr>
Message-ID: <DD463A42-AF09-46C2-99F6-F2328DDDC4EF@bitblocks.com>

On Sep 3, 2018, at 1:41 PM, Kurt H Maier <khm at sciops.net> wrote:
> 
> Acme is a bad citizen in similar ways, but as I said, I suspect that's
> because it was intended to supplant Rio rather than infect it.

I’m still not clear on why you think acme is a bad citizen. If anything it
makes its windows more accessible to other tools. Unlike emacs or vim
or any IDE. What could acme have differently or what other editor is
not a “bad citizen”.

> When people talk about "the unix way," they usually hyperfocus on "do
> one thing well" and leave composability by the wayside, and that's a
> shame, because that's where the real power comes from.  "Do one thing
> well" is a method to achieve quality when you're building a piece of a
> well-integrated system.  If you're not building a well-integrated
> system, you *can't* "do one thing well," because you've signed on to do
> everything, come hell or high water.

Composability is implicitly the key point in “the Unix way” but typically
editors are not very composable. Or composable in a different domain.
Similarly GUI. Once you add a human in your composition, further
composability falls apart! A human being the ultimate “do everything”
kitchen sink:-)

The question is what can be done to improve composability beyond the
“Unix way” or plan9 way.


From dave at horsfall.org  Tue Sep  4 09:01:47 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 4 Sep 2018 09:01:47 +1000 (EST)
Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?=
In-Reply-To: <CACYmRND_fh-pnPyEp5a5_7XYtEV2ZsWK_stMnrL2VWv_NBS8Fg@mail.gmail.com>
References: <f3f250f4-cffd-794c-450a-d1c3829c890e@spamtrap.tnetconsulting.net>
 <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com>
 <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net>
 <6e3a87ce-f573-4258-9db5-a5f99b5b89b1.maildroid@localhost>
 <20180829202111.GA17007@minnie.tuhs.org>
 <CACYmRND_fh-pnPyEp5a5_7XYtEV2ZsWK_stMnrL2VWv_NBS8Fg@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.1809040836290.28912@aneurin.horsfall.org>

On Mon, 3 Sep 2018, Ed Carp wrote:

> Wow, that takes me back quite a ways. I think I've still got my UUCP 
> setup somewhere on a backup. UUCP works great over anything from ssh 
> over tcpip to 1200 baud half-duplex packet connections.

If you're referring to "Amateur" i.e. "ham radio" packet radio than yes, 
I'm told that it works great i.e. half-duplex -> large data -> short ACK.

> Fond memories.

Heh heh - I once ran *raw* Xmodem over packet i.e. not encapsulated in 
that protocol-from-hell AX.25 i.e. technically illegal[*]; it worked great 
until a packet was lost (the "hidden transmitter" problem) and the various 
timeouts concerned (Xmodem vs. the TNCs themselves) went completely 
pear-shaped...

[*]

Stuff the legality; isn't Amateur radio all about experimentation?  But we 
did announce on that frequency that we were about to conduct an 
experiment.  And whoever designed AX.25 (yes, I have studied it in great 
detail) must've been on something at the time...  Protocol layers? 
What's that?

-- Dave (VK2KFU)


From dave at horsfall.org  Tue Sep  4 09:41:27 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 4 Sep 2018 09:41:27 +1000 (EST)
Subject: [TUHS] Public access multics
In-Reply-To: <201809031329.w83DT5q0105108@tahoe.cs.Dartmouth.EDU>
References: <201809031329.w83DT5q0105108@tahoe.cs.Dartmouth.EDU>
Message-ID: <alpine.BSF.2.21.9999.1809040937410.28912@aneurin.horsfall.org>

On Mon, 3 Sep 2018, Doug McIlroy wrote:

>> Was Algol 60 any kind of viable alternative at the time?
>
> The operating system for the Burroughs B5000 had been written in 
> Burroughs Algol. That punctured the widespread belief that OS's were so 
> particular to the hardware that they had to be written in machine 
> language. I don't recall how far Burroughs Algol went beyond Algol 60, 
> nor why Multics did not want to follow that lead.  ("Viable" is a 
> slippery concept when choosing among Turing-complete alternatives.)

Call me memory-challenged (which I am these days), but wasn't Burroughs' 
OS known as Master Control Program (MCP - Male Chauvinist Pig)?

-- Dave, who has fond memories of the B1500...


From khm at sciops.net  Tue Sep  4 10:52:13 2018
From: khm at sciops.net (Kurt H Maier)
Date: Mon, 3 Sep 2018 17:52:13 -0700
Subject: [TUHS] cat -v and other complaints
In-Reply-To: <DD463A42-AF09-46C2-99F6-F2328DDDC4EF@bitblocks.com>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <20180831215636.-eCEx%ca6c@bitmessage.ch>
 <CAD-qYGqsq=kZKrHcqUws4mpjV9VGnpNFb31ubUOZ67yOfZMWZA@mail.gmail.com>
 <20180903180401.u4MVs%ca6c@bitmessage.ch>
 <20180903181133.GB81368@wopr>
 <B38971F7-CF92-431A-BB10-8F5B05C33F71@bitblocks.com>
 <20180903204115.GC99551@wopr>
 <DD463A42-AF09-46C2-99F6-F2328DDDC4EF@bitblocks.com>
Message-ID: <20180904005213.GD99551@wopr>

On Mon, Sep 03, 2018 at 02:46:14PM -0700, Bakul Shah wrote:
> 
> I’m still not clear on why you think acme is a bad citizen. If anything it
> makes its windows more accessible to other tools. Unlike emacs or vim
> or any IDE. What could acme have differently or what other editor is
> not a “bad citizen”.
> 

Ok.  I apologize for expressing myself poorly.  I give up.

> Composability is implicitly the key point in “the Unix way” but typically
> editors are not very composable. Or composable in a different domain.
> Similarly GUI. Once you add a human in your composition, further
> composability falls apart! A human being the ultimate “do everything”
> kitchen sink:-)

I don't consider myself on an equal footing as the tools I use.  I don't
"add a human in my composition."  I compose.  This is a pretty
fundamental difference between me and software.

> The question is what can be done to improve composability beyond the
> “Unix way” or plan9 way.

I have about a million questions to answer first, and I suspect the
industry as a whole will collapse and re-form a few times before anyone
gets around to answering that one.

We haven't even fully developed composability in "the unix way" since
market forces seem to have frozen things in a sort of late-1980s amber.
I envy the future generation that rediscovers the core concept and
runs with it, but I doubt I'll be around then.  Information technology
is entering an ice age in which general-purpose computing is not
guaranteed to select for survival; the barrier to entry for
understanding systems has never been higher, there is a distinct and
global trend against it, and the cost of thirty years' abuse of Moore's
law is coming due.

Hunter Thompson's high-water mark comes to mind.  

I am grateful, for these reasons, for the efforts of people like TUHS
and Bitsavers, so that I can still find and use the tools that were made
back before people confused the simplistic for the simple, even if it
gets harder to make a living with them each passing year.

khm


From trnsz at pobox.com  Tue Sep  4 12:47:46 2018
From: trnsz at pobox.com (Jeffrey H. Johnson)
Date: Mon, 3 Sep 2018 22:47:46 -0400
Subject: [TUHS] Public access multics
In-Reply-To: <alpine.BSF.2.21.9999.1809040937410.28912@aneurin.horsfall.org>
References: <201809031329.w83DT5q0105108@tahoe.cs.Dartmouth.EDU>
 <alpine.BSF.2.21.9999.1809040937410.28912@aneurin.horsfall.org>
Message-ID: <AC815801-DD2A-4933-8C24-3081CFA21156@pobox.com>

Yes, correct - I don't want to bring the list too off-topic, but Unisys (UNIVAC + Burroughs) still maintains those two platforms (OS 2000 from the UNIVAC line and MCP from Burroughs), and they have a hobbyist program for both systems.

https://www.unisys.com/offerings/clearpath-forward/clearpath-forward-products/clearpath-os-2200-software/clearpath-os-2200-express

and

https://www.unisys.com/offerings/clearpath-forward/clearpath-forward-products/clearpath-mcp-software/clearpath-mcp-express

Unisys has also released older versions of MCP (1970s) as well with less restrictive licensing, and the community has built an emulator capable of running them on an emulated B5500 system - http://www.phkimpel.us/B5500/

The Burroughs MCP name supposedly inspired the MCP villain in TRON as well. 

I've never used Burroughs Algol nor Honeywell Algol, but I am aware you can use Honeywell Algol on Multics via gcos_tss (the GCOS Time Sharing Simulator).

-- Jeff

> On Sep 3, 2018, at 7:41 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> On Mon, 3 Sep 2018, Doug McIlroy wrote:
> 
>>> Was Algol 60 any kind of viable alternative at the time?
>> 
>> The operating system for the Burroughs B5000 had been written in Burroughs Algol. That punctured the widespread belief that OS's were so particular to the hardware that they had to be written in machine language. I don't recall how far Burroughs Algol went beyond Algol 60, nor why Multics did not want to follow that lead.  ("Viable" is a slippery concept when choosing among Turing-complete alternatives.)
> 
> Call me memory-challenged (which I am these days), but wasn't Burroughs' OS known as Master Control Program (MCP - Male Chauvinist Pig)?
> 
> -- Dave, who has fond memories of the B1500...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180903/e21d0651/attachment.html>

From akosela at andykosela.com  Tue Sep  4 16:10:26 2018
From: akosela at andykosela.com (Andy Kosela)
Date: Tue, 4 Sep 2018 08:10:26 +0200
Subject: [TUHS] cat -v and other complaints
In-Reply-To: <20180903185616.ZnkRk%ca6c@bitmessage.ch>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <20180831215636.-eCEx%ca6c@bitmessage.ch>
 <CAD-qYGqsq=kZKrHcqUws4mpjV9VGnpNFb31ubUOZ67yOfZMWZA@mail.gmail.com>
 <20180903180401.u4MVs%ca6c@bitmessage.ch> <20180903181133.GB81368@wopr>
 <20180903185616.ZnkRk%ca6c@bitmessage.ch>
Message-ID: <CALMnNGgwaGU842g3y8aAdjrjwFPHxR4ysuddKLeKqoGJ2=LDtA@mail.gmail.com>

On Monday, September 3, 2018, Cág <ca6c at bitmessage.ch> wrote:

> Kurt H Maier wrote:
>
> > My pet theory is that Acme was going to replace Rio, at which time it
> > would be 'the interface' again instead of a text editor with a
> > slightly-incompatible filesystem interface.  There are some hints toward
> > this if you squint hard enough, but I can't prove it.
>
> Oberon 2.0
>
> > "Unavailable on the console" is kind of a cheap shot when talking about
> > an operating system that deliberately doesn't support consoles.  Part of
> > the point was outgrowing TTYs.
>
> Yeah, I guess I should've started with that :) I love Unix for the
> console.
>

Pure text interface will always be the most elegant way to converse with a
machine.  And Unix is the most elegant command line based system.

The world lost something when it moved to GUI.  I still prefer to use the
old phosphor based CRT monitors even with modern computers and because the
text mode is still inherent in modern graphics cards (as a legacy mode), it
is possible to not use GUI at all even today.

That was one of the main reasons I disliked Plan9.  It embraced the
"windows interface" trend of the mid 80s.

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

From rminnich at gmail.com  Tue Sep  4 16:41:49 2018
From: rminnich at gmail.com (ron minnich)
Date: Mon, 3 Sep 2018 23:41:49 -0700
Subject: [TUHS] cat -v and other complaints
In-Reply-To: <CALMnNGgwaGU842g3y8aAdjrjwFPHxR4ysuddKLeKqoGJ2=LDtA@mail.gmail.com>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <20180831215636.-eCEx%ca6c@bitmessage.ch>
 <CAD-qYGqsq=kZKrHcqUws4mpjV9VGnpNFb31ubUOZ67yOfZMWZA@mail.gmail.com>
 <20180903180401.u4MVs%ca6c@bitmessage.ch> <20180903181133.GB81368@wopr>
 <20180903185616.ZnkRk%ca6c@bitmessage.ch>
 <CALMnNGgwaGU842g3y8aAdjrjwFPHxR4ysuddKLeKqoGJ2=LDtA@mail.gmail.com>
Message-ID: <CAP6exYJTE_p8QYcLCN98kbqZaqPogenv6BTx5wVQKED7Kugiwg@mail.gmail.com>

On Mon, Sep 3, 2018 at 11:11 PM Andy Kosela <akosela at andykosela.com> wrote:

>
> That was one of the main reasons I disliked Plan9.  It embraced the
> "windows interface" trend of the mid 80s.
>
>
>
well, you can believe that, and I can't stop you, but it's wrong.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180903/97337ddf/attachment.html>

From dfawcus+lists-tuhs at employees.org  Tue Sep  4 18:52:27 2018
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Tue, 4 Sep 2018 09:52:27 +0100
Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?=
In-Reply-To: <alpine.BSF.2.21.9999.1809040836290.28912@aneurin.horsfall.org>
References: <f3f250f4-cffd-794c-450a-d1c3829c890e@spamtrap.tnetconsulting.net>
 <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com>
 <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net>
 <6e3a87ce-f573-4258-9db5-a5f99b5b89b1.maildroid@localhost>
 <20180829202111.GA17007@minnie.tuhs.org>
 <CACYmRND_fh-pnPyEp5a5_7XYtEV2ZsWK_stMnrL2VWv_NBS8Fg@mail.gmail.com>
 <alpine.BSF.2.21.9999.1809040836290.28912@aneurin.horsfall.org>
Message-ID: <20180904085226.GA81023@bugle.employees.org>

On Tue, Sep 04, 2018 at 09:01:47AM +1000, Dave Horsfall wrote:
> 
> Heh heh - I once ran *raw* Xmodem over packet i.e. not encapsulated in 
> that protocol-from-hell AX.25 i.e. technically illegal[*];

Why would that be illegal?

Last time I checked (in the UK) we can use any form of modulation or
encoding we want [*], as long as we record/log it, and don't use encryption.

DF

[*] Except spark gap transmitters


From akosela at andykosela.com  Tue Sep  4 19:34:45 2018
From: akosela at andykosela.com (Andy Kosela)
Date: Tue, 4 Sep 2018 11:34:45 +0200
Subject: [TUHS] cat -v and other complaints
In-Reply-To: <CAP6exYJTE_p8QYcLCN98kbqZaqPogenv6BTx5wVQKED7Kugiwg@mail.gmail.com>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <20180831215636.-eCEx%ca6c@bitmessage.ch>
 <CAD-qYGqsq=kZKrHcqUws4mpjV9VGnpNFb31ubUOZ67yOfZMWZA@mail.gmail.com>
 <20180903180401.u4MVs%ca6c@bitmessage.ch> <20180903181133.GB81368@wopr>
 <20180903185616.ZnkRk%ca6c@bitmessage.ch>
 <CALMnNGgwaGU842g3y8aAdjrjwFPHxR4ysuddKLeKqoGJ2=LDtA@mail.gmail.com>
 <CAP6exYJTE_p8QYcLCN98kbqZaqPogenv6BTx5wVQKED7Kugiwg@mail.gmail.com>
Message-ID: <CALMnNGj8gP=aPwNSTy82d33ffcU6naEZ=2==xs-N6kf-j9Dg0Q@mail.gmail.com>

On Tuesday, September 4, 2018, ron minnich <rminnich at gmail.com> wrote:

>
>
> On Mon, Sep 3, 2018 at 11:11 PM Andy Kosela <akosela at andykosela.com>
> wrote:
>
>>
>> That was one of the main reasons I disliked Plan9.  It embraced the
>> "windows interface" trend of the mid 80s.
>>
>>
>>
> well, you can believe that, and I can't stop you, but it's wrong.
>

Can you elaborate more on your point of view?

There has been a slow shift in the way we use computer interfaces and the
start of the "windows computing" revolution certainly happened around mid
80s with companies like Apple, Microsoft or Commodore developing their own
version of GUI (which goes back to Xerox PARC of course).  Unix received X
Window System from MIT in 1984.

At the time people thought that GUI is the best and most useful interface
for the new era and text terminal computing is about to die pretty soon.
Well it took at least 10 more years to happen and the introduction of World
Wide Web and Windows 95 certainly help solidify it.

When Plan 9 was created in the mid-late 80s exactly those ideas
circulated.  Nothing comes from nothing, everything has its historical
context.  In the late 80s in order to "innovate" it was natural to think
that abandoning text terminals is a "progress".

Unix was born in the different era.  Same with the original IBM PC.  That
is why they revolve around pure text interface.  I'm just glad that text
mode survived and it is still available even on modern PC's.  But most kids
these days don't even know what it is...  They have GUIs everywhere, from
their smartphones to their laptops.

It is a very sad state of things when people more and more abandon text
computing for the image based computing.  I agree with Kurt that we are
already in the Information Technology ice age.

General purpose pure text based computing is slowly becoming just a retro
hobby.

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

From akosela at andykosela.com  Tue Sep  4 19:39:42 2018
From: akosela at andykosela.com (Andy Kosela)
Date: Tue, 4 Sep 2018 11:39:42 +0200
Subject: [TUHS] SunOS code?
In-Reply-To: <CANCZdfqsd4YnLZDZD5JBuayJ-dcNJSt3yWmiAjCRgVp5o0tB5w@mail.gmail.com>
References: <f28da67c-b9af-b038-556b-f2e3012ddcff@mhorton.net>
 <CAC20D2PgjftUBz=wq2=ThZ4HU8yP1KuQ1iCWek-T4R0H17iP6Q@mail.gmail.com>
 <alpine.BSF.2.21.9999.1808281017090.41601@aneurin.horsfall.org>
 <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org>
 <alpine.BSF.2.21.9999.1808290821350.41601@aneurin.horsfall.org>
 <c5abd058-2035-d105-2df2-3f94e5d59035@gmail.com>
 <20180829004627.GG317@mcvoy.com>
 <201808290529.w7T5TFKa006049@freefriends.org>
 <CANCZdfrcZ5Gt_+wNKZ7zqzzWaGoSPE1rtCHEDrqh4eozdnHKAQ@mail.gmail.com>
 <20180829145300.GP317@mcvoy.com>
 <CANuZA8S33HVVCSNY32aWLXU=BttPodT75BstOy4OyAob4cwudg@mail.gmail.com>
 <CALMnNGi0z050w3qWD6Mr=CxBkwAHPa2EohYhj9P5CrGn298J9w@mail.gmail.com>
 <CANCZdfqsd4YnLZDZD5JBuayJ-dcNJSt3yWmiAjCRgVp5o0tB5w@mail.gmail.com>
Message-ID: <CALMnNGi7vf3MnDPpp8XpzZ=5zYZBo2XcXTczX=irQ4GUrbK5pQ@mail.gmail.com>

On Saturday, September 1, 2018, Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Sat, Sep 1, 2018 at 7:50 AM Andy Kosela <akosela at andykosela.com> wrote:
>
>>
>>
>> On Saturday, September 1, 2018, Steve Mynott <steve.mynott at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Wed, 29 Aug 2018 at 15:53, Larry McVoy <lm at mcvoy.com> wrote:
>>>
>>> The BSDs have a less than optimal VM system.  Having SunOS opened up
>>>> would at least let people see what they are missing.  Maybe I have
>>>> rose colored glasses on but it was the only kernel that came into
>>>> focus for me and you could see the architecture from the code.
>>>> Everything else seems like a mess to me.
>>>>
>>>
>>> That may have been true in the late 80s and even early 90s but I'd have
>>> thought FreeBSD, NetBSD and OpenBSD would have useable VMs by now.
>>>
>>> I've vague recollections that these all originally used the VM from Mach
>>> which did have problems at first.
>>>
>>
> Yes. CSRG used Mach VM because it was available, not because it was
> awesome. The folks at CSRG approached Sun to have them donate their VM to
> BSD, and there were serious talks about doing this until the lawyers got
> involved and explained that would require a serious write down on their
> quarterly report so that nixed the whole thing.
>
>
>> I recall a more knowledgeable friend complaining about FreeBSD VM in 1994
>>> or so.
>>>
>>
> It used to be downright aweful.
>
>
>> I think the latter two use UVM and FreeBSD improved their Mach one (which
>>> has a SunOS kvmish API anyway). I've not seen complaints about modern BSD.
>>>
>>
> OpenBSD and NetBSD both moved to uvm.
>
>
>> Wasn't the whole FreeBSD VM rewritten by John Dyson and David Greenman in
>> the mid-late 90's?  And then further improved by Matthew Dillon.
>>
>> Unfortunately they are not affiliated with the project anymore.  All
>> three had exceptional coding skills.
>>
>
> With the exception of David, it's not unfortunate at all. Although they
> were good for the project's code, they weren't good for the project. They
> didn't work well with others and caused much more grief than the code they
> contributed. There comes a time when there's just too much drama and the
> rest of the code gets much much better when you aren't always fighting
> drama :(. It was a tough decision to make when I was on the core team to
> show Dillon the door. One not made lightly, nor without a lot of effort to
> work through the issues. In the end, though, we had to part ways. Dillon
> has done well with DragonFly, however.
>

Well, there are certainly as many sides to this story as there are people
involved.  Same with NetBSD/OpenBSD split.  Let's leave it as that as I
don't believe we have mentioned people on this list so they can't defend
themselves.

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

From crossd at gmail.com  Tue Sep  4 20:23:26 2018
From: crossd at gmail.com (Dan Cross)
Date: Tue, 4 Sep 2018 06:23:26 -0400
Subject: [TUHS] cat -v and other complaints
In-Reply-To: <CALMnNGj8gP=aPwNSTy82d33ffcU6naEZ=2==xs-N6kf-j9Dg0Q@mail.gmail.com>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <20180831215636.-eCEx%ca6c@bitmessage.ch>
 <CAD-qYGqsq=kZKrHcqUws4mpjV9VGnpNFb31ubUOZ67yOfZMWZA@mail.gmail.com>
 <20180903180401.u4MVs%ca6c@bitmessage.ch> <20180903181133.GB81368@wopr>
 <20180903185616.ZnkRk%ca6c@bitmessage.ch>
 <CALMnNGgwaGU842g3y8aAdjrjwFPHxR4ysuddKLeKqoGJ2=LDtA@mail.gmail.com>
 <CAP6exYJTE_p8QYcLCN98kbqZaqPogenv6BTx5wVQKED7Kugiwg@mail.gmail.com>
 <CALMnNGj8gP=aPwNSTy82d33ffcU6naEZ=2==xs-N6kf-j9Dg0Q@mail.gmail.com>
Message-ID: <CAEoi9W4Od+SP-27+OMu5Uqt_Jpmmy+NYvyZbp9O8YAUeG-fAZw@mail.gmail.com>

On Tue, Sep 4, 2018 at 5:35 AM Andy Kosela <akosela at andykosela.com> wrote:

> On Tuesday, September 4, 2018, ron minnich <rminnich at gmail.com> wrote:
>>
>> On Mon, Sep 3, 2018 at 11:11 PM Andy Kosela <akosela at andykosela.com>
>> wrote:
>>
>>> That was one of the main reasons I disliked Plan9.  It embraced the
>>> "windows interface" trend of the mid 80s.
>>>
>>
>> well, you can believe that, and I can't stop you, but it's wrong.
>>
>
> Can you elaborate more on your point of view?
>

I don't mean to speak for Ron, but I think I know where he's coming from.

There has been a slow shift in the way we use computer interfaces and the
> start of the "windows computing" revolution certainly happened around mid
> 80s with companies like Apple, Microsoft or Commodore developing their own
> version of GUI (which goes back to Xerox PARC of course).  Unix received X
> Window System from MIT in 1984.
>

Don't mistake "windows" (as in "stacking window manager") for "bitmapped
graphical displays."

At the time people thought that GUI is the best and most useful interface
> for the new era and text terminal computing is about to die pretty soon.
> Well it took at least 10 more years to happen and the introduction of World
> Wide Web and Windows 95 certainly help solidify it.
>
> When Plan 9 was created in the mid-late 80s exactly those ideas
> circulated.  Nothing comes from nothing, everything has its historical
> context.  In the late 80s in order to "innovate" it was natural to think
> that abandoning text terminals is a "progress".
>

This is conflating two things: textual interfaces and the graphical
presentation of those interfaces. Plan 9 is about both.

Unix was born in an era where the TTY (that is, tele-typewriter, as in
"prints to paper") was still very much a force in mediating the interaction
between user and computer. That evolved rather quickly to the "green
screen" terminals of the 70s and early 80s, but the paradigm was basically
the same: the serial terminal was a window showing the tail of an infinite
scroll of data. The "terminal", as in the TTY, was and is a central
abstraction in Unix.

By the late 80s, when plan9 got started, the paradigm had shifted: machines
now had relatively high resolution bitmapped graphical interfaces, and by
and large you weren't sitting in front of a serial terminal anymore. Being
tied to a single "terminal" was a hindrance and led to a lot of complexity
(job control, terminal interactions with process groups, POSIX sessions,
signals and ioctls for window-size changes for programs that wanted to
continue believing that they're using a serial terminal, even though they
haven't been for years...).

Plan9 wanted to take advantage of the new graphics functionality but didn't
want to be chained to the complexity associated with obsolete hardware
(e.g., the TTY abstraction, which _still persists_ and has its fingers in
weird parts of the kernel).

They still wanted a text-oriented interface though, and that's what plan9
provides. You sweep out a rio window and it's running a shell. Text in acme
is usually editable and there aren't a lot of strange glyphs to click on;
commands are strings. And you're no longer chained to a "terminal": I can
have many shells running in many windows and they're all more or less the
same. And it allowed them to move beyond the limitations of
cursor-addressed user interfaces. They could, for example, write (or more
precisely adapt) text editors like `sam`, which is fundamentally a textual
program but uses the GUI to very nice effect. It may seem dated by today's
standards, but it still works very nicely (indeed, I had to run a coworker
through a sam session last Thursday; he was a continent away from me
connecting to a plan9 system but we were able to do what needed to be done
relatively quickly because it's all text and so simple...).

I remember when I was in high school driving over to New Jersey and going
to Bell Labs and meeting Dennis Ritchie for the first time (a college
student I knew was doing an internship there and let me come visit). Dennis
showed me plan9 on his gnot (this was back in the 8.5 days), and
specifically talked about this: the focus was text, which was editable,
could be manipulated, combined, split apart, was self-explanatory etc,
instead of little icons like MS Windows and the Mac which were
simultaneously static and cryptic. It *is* a textual interface, though it's
*presented* and *multiplexed* via a bitmapped graphics display.

I distinctly remember feeling blown away by the powerful marriage of text
with bitmapped displays; it was a GUI for a Unix-like experience done
right. They didn't sacrifice anything, but they gained so much more.

Unix was born in the different era.  Same with the original IBM PC.  That
> is why they revolve around pure text interface.
>

Unix and the PC date from radically different eras.

The original IBM PC had a graphics adapter, and that was the expected mode
of interaction, not the serial port. Granted that adapter was pretty weak,
but it was there. Using a PC, you were using a graphical representation of
your text interface. Unlike a serial terminal, where you simply emit the
text to the terminal and the terminal deals with displaying it, writing an
interface for CGA or MGA -- even in text mode -- involves scrolling the
buffer, handling line feeds, tab and backspace expansion, and all the rest
of it in software (granted, lots of serial drivers for Unix handle tab and
BS expansion, too). But you, the programmer, have to manually keep track of
your position in that little 4k buffer. You have to deal with moving the
cursor around, etc.

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

From kevin.bowling at kev009.com  Tue Sep  4 21:47:39 2018
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Tue, 4 Sep 2018 04:47:39 -0700
Subject: [TUHS] SunOS code?
In-Reply-To: <20180902194301.GA22518@thunk.org>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com>
 <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net>
 <CAK7dMtB8AmPG5ZMceGZdD8sxL10horfO0ZYLfXuX=4Dp8u7bwQ@mail.gmail.com>
 <ee7772a4-c23a-3344-4f10-c561047ffbb5@kilonet.net>
 <20180901221933.GA2214@thunk.org>
 <CAK7dMtC4VL56Utb67-LJfXrZ2oStUb_MDFO4q-PakGjjHOF82w@mail.gmail.com>
 <20180902194301.GA22518@thunk.org>
Message-ID: <CAK7dMtBqzt=vNeKLWjz=xGj6o=mpFq1P8m86_daznR3xHa60LA@mail.gmail.com>

On Sun, Sep 2, 2018 at 12:43 PM, Theodore Y. Ts'o <tytso at mit.edu> wrote:
> On Sat, Sep 01, 2018 at 10:05:06PM -0700, Kevin Bowling wrote:
>>
>> Sorry this is just bogus about being weak compared to Solaris.  Are
>> you looking back with rosy glasses or have you scanned the code in the
>> past couple years?  I have and there is nothing particularly special
>> about Solaris internals here or elsewhere.
>
> I haven't looked at Solaris code; I had just *assumed* that if they
> were selling million dollar E10k's, they would have had NUMA support
> at *least* as good as SGI's Irix.  And it would have been an excuse
> for their pathetic performance on UP and 2-4 SMP systems.

One would hope so, but that was the strategy that got them eaten by a
grue.  Another funny anecdote about this aloofness.. Linux on sparc64
uses the Relaxed Memory Order mode that the hardware offers .
Solaris.. Total Store Order.  There are tons of things like this in
the code that blow my mind.  I would have been pissed if I were on the
hardware side of SPARC.

>
>> Keep in mind IBM wants to sell RockHoppers and E980s (4 drawers, 16
>> sockets, 768 threads) for dedicated Linux use which have similar
>> north/south and east/west off chip networks.  They have a lot of very
>> talented people on the firmware, kernel, compilers to make these
>> things work fast, including Paul.
>> ...
>> Where you start going beyond Linux-like NUMA IMO is when you get
>> Irix-like features of page copying, migration, and multiple advanced
>> placement policies.
>
> One thing to consider is that IBM really only cared about optimizing
> hardware for DB2, Oracle, and Webshpere.  That's one of the reason why
> you didn't see much in the way of innovative file system work, ala
> ZFS.  There was no business justification for pouring 100+ engineer
> years to develop a next-generation file systesm --- and they had
> already done that once already for GPFS, a cluster file system.  As
> far as local disk file system was concerned, the only real business
> value it had was to serve as a program loader for DB2 and Websphere.  :-)
>
> (I'm exagerating a little for effect, but *only* a little.)

Hmm, I think they've been pretty earnest at wanting to be 2+ years
ahead of the general market with POWER for as long as I can see, lots
of HPC money has been subsidizing that.  Depends on the workload but
bus and memory bandwidth right now with PCIe Gen4 and NvLink can
really cut down on server sprawl.  I've met with the GM/chief
architect and they see OpenPOWER positioned as a full frontal
competitor to Intel Xeon.  I'm fairly disappointed in my
contemporaries for not recognizing the value of a completely open
source firmware and on chip controller stack; especially after the
recent snafu where Intel changed the microcode license to disallow
benchmarks and claimed it was an accident.

Your statements make sense to me with respect to AIX, as Linux has
been the main effort since the 2000s.  GPFS looks neat, I wish it were
open or at least internals documented well enough to study the
implementation academically.

>
> So as far as NUMA was concerned, there was almost certainly not have
> been much perceived business value in having sophisticated
> auto-migration for arbitrary workloads in the kernel.  Something basic
> which was good enough for Oracle, DB2, etc., was all that would be
> needed.  (And if you needed to hire consultants from IBM Global
> Services to mind-meld with the configuration documentation in order to
> get the best out of your Rockhopper.... well, shucks, darn.  :-)

That's probably the dirty little secret.  It's long been profitable to
carefully plan software interrupt handlers, user threads, and memory
allocation even on pedestrian servers if they are running a fixed
function.  I guess Google's Borg and the new workalikes could do
semi-automagic things with cgroups these days.  There is evidence of
people getting pretty crazy with it when we see things like Intel
cache allocation features.

> At IBM the business people really did make the funding decisions of
> what to work on.  ZFS could have never happened at IBM because no one
> would have thought that a even a tiny number of IBM's current or
> potential customer base would abandon AIX or Linux and switch to
> Solaris, or buy Sun hardware instead of IBM hardware --- just for the
> sake of ZFS.  And that's how decision-makers at IBM really thought.
> (And to be fair to those decision-makers, IBM is still in business as
> a free-standing business --- and Sun is not.)

Agreed, one of these companies is doing pretty well with a fat
dividend yield, that other has basically been dismantled for all but a
couple remaining desirable platform control points like Java and
MySQL.

Many things in tech are happy accidents and a small number of
motivated people at the right place and time.  A Sun engineer admitted
on some video I've seen that the green light was really given for ZFS
because they got stumped by some UFS bugs.. once enough of ZFS was
written to test the end to end checksumming features they found out
some of these heisenbugs were LSI HBA and disk firmware issues :o)

Surveying some of these filesystems.. JFS2 is a decent, nowhere near
the capabilities of ZFS but even today it's not in dire need of
replacement.. I suspect another issue complementary to your point is
the standalone storage business is many $B of revenue.  ESS/DS8000 and
the like are preferred revenue.  IBM and HP were more in the SAN game
than Sun and SGI who let the customers configure systems themselves be
used as storage (Sun was using VxFS for a long time, SGI had some CXFS
things IIRC).  Tru64 had a pretty interesting filesystem on paper,
curious if you ever looked at its design since they open sourced it.

Regards,
Kevin


From rminnich at gmail.com  Wed Sep  5 00:22:02 2018
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Sep 2018 07:22:02 -0700
Subject: [TUHS] cat -v and other complaints
In-Reply-To: <CALMnNGj8gP=aPwNSTy82d33ffcU6naEZ=2==xs-N6kf-j9Dg0Q@mail.gmail.com>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <20180831215636.-eCEx%ca6c@bitmessage.ch>
 <CAD-qYGqsq=kZKrHcqUws4mpjV9VGnpNFb31ubUOZ67yOfZMWZA@mail.gmail.com>
 <20180903180401.u4MVs%ca6c@bitmessage.ch> <20180903181133.GB81368@wopr>
 <20180903185616.ZnkRk%ca6c@bitmessage.ch>
 <CALMnNGgwaGU842g3y8aAdjrjwFPHxR4ysuddKLeKqoGJ2=LDtA@mail.gmail.com>
 <CAP6exYJTE_p8QYcLCN98kbqZaqPogenv6BTx5wVQKED7Kugiwg@mail.gmail.com>
 <CALMnNGj8gP=aPwNSTy82d33ffcU6naEZ=2==xs-N6kf-j9Dg0Q@mail.gmail.com>
Message-ID: <CAP6exYJ2nPJpc=qFqyG1TCQidOLaxC9O=C+W8CSH3bcW_OXY-w@mail.gmail.com>

On Tue, Sep 4, 2018 at 2:34 AM Andy Kosela <akosela at andykosela.com> wrote:

> When Plan 9 was created in the mid-late 80s exactly those ideas
> circulated.  Nothing comes from nothing, everything has its historical
> context.  In the late 80s in order to "innovate" it was natural to think
> that abandoning text terminals is a "progress".
>
>
I don't get the sense, from reading this, that you have ever used Plan 9
for serious work, or indeed done more than see or run a demo. I'm keeping
this short because this is TUHS, not T9HS. But your characterization of
Plan 9 is just wrong.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180904/b075cb53/attachment.html>

From gilles at gravier.org  Wed Sep  5 03:39:00 2018
From: gilles at gravier.org (Gilles Gravier)
Date: Tue, 4 Sep 2018 19:39:00 +0200
Subject: [TUHS] SunOS code?
In-Reply-To: <CAK7dMtBqzt=vNeKLWjz=xGj6o=mpFq1P8m86_daznR3xHa60LA@mail.gmail.com>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com>
 <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net>
 <CAK7dMtB8AmPG5ZMceGZdD8sxL10horfO0ZYLfXuX=4Dp8u7bwQ@mail.gmail.com>
 <ee7772a4-c23a-3344-4f10-c561047ffbb5@kilonet.net>
 <20180901221933.GA2214@thunk.org>
 <CAK7dMtC4VL56Utb67-LJfXrZ2oStUb_MDFO4q-PakGjjHOF82w@mail.gmail.com>
 <20180902194301.GA22518@thunk.org>
 <CAK7dMtBqzt=vNeKLWjz=xGj6o=mpFq1P8m86_daznR3xHa60LA@mail.gmail.com>
Message-ID: <CABq8+zeSWXV-OCs=0noyD6aQ1-Ge2pU0ynj3bcqkr=830v7V8g@mail.gmail.com>

This link :
https://vetusware.com/download/SunOS%20Source%20Code%204.1.3/?id=13475
seems to have the right file (registration required, but it's free, use a
disposable email).

Beats my having to find a SCSI adaptor, a QIC-150 drive, and trying to read
my old QIC-150 tape with the source code on it...

Gilles

Le mar. 4 sept. 2018 à 13:48, Kevin Bowling <kevin.bowling at kev009.com> a
écrit :

> On Sun, Sep 2, 2018 at 12:43 PM, Theodore Y. Ts'o <tytso at mit.edu> wrote:
> > On Sat, Sep 01, 2018 at 10:05:06PM -0700, Kevin Bowling wrote:
> >>
> >> Sorry this is just bogus about being weak compared to Solaris.  Are
> >> you looking back with rosy glasses or have you scanned the code in the
> >> past couple years?  I have and there is nothing particularly special
> >> about Solaris internals here or elsewhere.
> >
> > I haven't looked at Solaris code; I had just *assumed* that if they
> > were selling million dollar E10k's, they would have had NUMA support
> > at *least* as good as SGI's Irix.  And it would have been an excuse
> > for their pathetic performance on UP and 2-4 SMP systems.
>
> One would hope so, but that was the strategy that got them eaten by a
> grue.  Another funny anecdote about this aloofness.. Linux on sparc64
> uses the Relaxed Memory Order mode that the hardware offers .
> Solaris.. Total Store Order.  There are tons of things like this in
> the code that blow my mind.  I would have been pissed if I were on the
> hardware side of SPARC.
>
> >
> >> Keep in mind IBM wants to sell RockHoppers and E980s (4 drawers, 16
> >> sockets, 768 threads) for dedicated Linux use which have similar
> >> north/south and east/west off chip networks.  They have a lot of very
> >> talented people on the firmware, kernel, compilers to make these
> >> things work fast, including Paul.
> >> ...
> >> Where you start going beyond Linux-like NUMA IMO is when you get
> >> Irix-like features of page copying, migration, and multiple advanced
> >> placement policies.
> >
> > One thing to consider is that IBM really only cared about optimizing
> > hardware for DB2, Oracle, and Webshpere.  That's one of the reason why
> > you didn't see much in the way of innovative file system work, ala
> > ZFS.  There was no business justification for pouring 100+ engineer
> > years to develop a next-generation file systesm --- and they had
> > already done that once already for GPFS, a cluster file system.  As
> > far as local disk file system was concerned, the only real business
> > value it had was to serve as a program loader for DB2 and Websphere.  :-)
> >
> > (I'm exagerating a little for effect, but *only* a little.)
>
> Hmm, I think they've been pretty earnest at wanting to be 2+ years
> ahead of the general market with POWER for as long as I can see, lots
> of HPC money has been subsidizing that.  Depends on the workload but
> bus and memory bandwidth right now with PCIe Gen4 and NvLink can
> really cut down on server sprawl.  I've met with the GM/chief
> architect and they see OpenPOWER positioned as a full frontal
> competitor to Intel Xeon.  I'm fairly disappointed in my
> contemporaries for not recognizing the value of a completely open
> source firmware and on chip controller stack; especially after the
> recent snafu where Intel changed the microcode license to disallow
> benchmarks and claimed it was an accident.
>
> Your statements make sense to me with respect to AIX, as Linux has
> been the main effort since the 2000s.  GPFS looks neat, I wish it were
> open or at least internals documented well enough to study the
> implementation academically.
>
> >
> > So as far as NUMA was concerned, there was almost certainly not have
> > been much perceived business value in having sophisticated
> > auto-migration for arbitrary workloads in the kernel.  Something basic
> > which was good enough for Oracle, DB2, etc., was all that would be
> > needed.  (And if you needed to hire consultants from IBM Global
> > Services to mind-meld with the configuration documentation in order to
> > get the best out of your Rockhopper.... well, shucks, darn.  :-)
>
> That's probably the dirty little secret.  It's long been profitable to
> carefully plan software interrupt handlers, user threads, and memory
> allocation even on pedestrian servers if they are running a fixed
> function.  I guess Google's Borg and the new workalikes could do
> semi-automagic things with cgroups these days.  There is evidence of
> people getting pretty crazy with it when we see things like Intel
> cache allocation features.
>
> > At IBM the business people really did make the funding decisions of
> > what to work on.  ZFS could have never happened at IBM because no one
> > would have thought that a even a tiny number of IBM's current or
> > potential customer base would abandon AIX or Linux and switch to
> > Solaris, or buy Sun hardware instead of IBM hardware --- just for the
> > sake of ZFS.  And that's how decision-makers at IBM really thought.
> > (And to be fair to those decision-makers, IBM is still in business as
> > a free-standing business --- and Sun is not.)
>
> Agreed, one of these companies is doing pretty well with a fat
> dividend yield, that other has basically been dismantled for all but a
> couple remaining desirable platform control points like Java and
> MySQL.
>
> Many things in tech are happy accidents and a small number of
> motivated people at the right place and time.  A Sun engineer admitted
> on some video I've seen that the green light was really given for ZFS
> because they got stumped by some UFS bugs.. once enough of ZFS was
> written to test the end to end checksumming features they found out
> some of these heisenbugs were LSI HBA and disk firmware issues :o)
>
> Surveying some of these filesystems.. JFS2 is a decent, nowhere near
> the capabilities of ZFS but even today it's not in dire need of
> replacement.. I suspect another issue complementary to your point is
> the standalone storage business is many $B of revenue.  ESS/DS8000 and
> the like are preferred revenue.  IBM and HP were more in the SAN game
> than Sun and SGI who let the customers configure systems themselves be
> used as storage (Sun was using VxFS for a long time, SGI had some CXFS
> things IIRC).  Tru64 had a pretty interesting filesystem on paper,
> curious if you ever looked at its design since they open sourced it.
>
> Regards,
> Kevin
>


-- 
*Gilles Gravier*  - Gilles at Gravier.org
GSM : +33618347147 and +41794728437
Skype : ggravier | PGP Key : 0x8DE6D026
<http://pgp.mit.edu:11371/pks/lookup?search=0x8DE6D026&op=index>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180904/d3128c92/attachment.html>

From henry.r.bent at gmail.com  Wed Sep  5 03:45:37 2018
From: henry.r.bent at gmail.com (Henry Bent)
Date: Tue, 4 Sep 2018 13:45:37 -0400
Subject: [TUHS] SunOS code?
In-Reply-To: <CABq8+zeSWXV-OCs=0noyD6aQ1-Ge2pU0ynj3bcqkr=830v7V8g@mail.gmail.com>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com>
 <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net>
 <CAK7dMtB8AmPG5ZMceGZdD8sxL10horfO0ZYLfXuX=4Dp8u7bwQ@mail.gmail.com>
 <ee7772a4-c23a-3344-4f10-c561047ffbb5@kilonet.net>
 <20180901221933.GA2214@thunk.org>
 <CAK7dMtC4VL56Utb67-LJfXrZ2oStUb_MDFO4q-PakGjjHOF82w@mail.gmail.com>
 <20180902194301.GA22518@thunk.org>
 <CAK7dMtBqzt=vNeKLWjz=xGj6o=mpFq1P8m86_daznR3xHa60LA@mail.gmail.com>
 <CABq8+zeSWXV-OCs=0noyD6aQ1-Ge2pU0ynj3bcqkr=830v7V8g@mail.gmail.com>
Message-ID: <CAEdTPBetBFP_sL2X1M2MdrwU1Oimm27FjMtcYxs9WSsQT_Gh5g@mail.gmail.com>

On Tue, Sep 4, 2018, 13:40 Gilles Gravier <gilles at gravier.org> wrote:

> This link :
> https://vetusware.com/download/SunOS%20Source%20Code%204.1.3/?id=13475
> seems to have the right file (registration required, but it's free, use a
> disposable email).
>
> Beats my having to find a SCSI adaptor, a QIC-150 drive, and trying to
> read my old QIC-150 tape with the source code on it...
>
> Gilles
>

I feel like we've been through this before on this list, but perhaps it
bears repeating: just because you can find source (or binaries, or CD
images, etc.) on the internet, that doesn't make it the least bit legal.
That is clearly the case here. Sadly, there are even higher profile sites
like the Internet Archive that have this problem too.  The concept of
"abandonware" has no legal footing whatsoever.

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

From jnc at mercury.lcs.mit.edu  Wed Sep  5 03:58:04 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue,  4 Sep 2018 13:58:04 -0400 (EDT)
Subject: [TUHS] SunOS code?
Message-ID: <20180904175804.06F7418C0CE@mercury.lcs.mit.edu>

    > From: Henry Bent

    > just because you can find source (or binaries, or CD images, etc.) on
    > the internet, that doesn't make it the least bit legal. ... The concept
    > of "abandonware" has no legal footing whatsoever.

True; but if all the copies of a particular item are discarded, one can make
all the lawyers on the planet as happy as clams, and it won't do a bit of
good. Save the bits, _then_ work out the legal issues, is my thinking on
priorities.

     Noel

(PS: 'Internet' is spelled with a capital; there are many internets, but only
one Internet, just as there are many white houses, but only one White House. If
the technical community, which _does_ understand the difference, can't get it's
act together, how can we expect the media, etc, to do the right thing?)


From wkt at tuhs.org  Wed Sep  5 06:33:11 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 5 Sep 2018 06:33:11 +1000
Subject: [TUHS] Saving the Unix Bits
In-Reply-To: <20180904175804.06F7418C0CE@mercury.lcs.mit.edu>
References: <20180904175804.06F7418C0CE@mercury.lcs.mit.edu>
Message-ID: <20180904203311.GA21089@minnie.tuhs.org>

On Tue, Sep 04, 2018 at 01:58:04PM -0400, Noel Chiappa wrote:
> True; but if all the copies of a particular item are discarded, one can make
> all the lawyers on the planet as happy as clams, and it won't do a bit of
> good. Save the bits, _then_ work out the legal issues, is my thinking on
> priorities.

I'll also follow up on Henry and Noel's e-mail w.r.t the Unix Archive that
TUHS provides. The only files in the public archive are ones where the legal
issues have been resolved. I also keep a hidden archive of files where the
legal issues have not been resolved.

As always, if you would like me to keep an off-site backup of your Unix
bits, the hidden Unix archive is write-only. Save the bits, and also
be mindful of the legal issues.

Cheers, Warren


From clemc at ccc.com  Wed Sep  5 06:39:36 2018
From: clemc at ccc.com (Clem Cole)
Date: Tue, 4 Sep 2018 16:39:36 -0400
Subject: [TUHS] Saving the Unix Bits
In-Reply-To: <20180904203311.GA21089@minnie.tuhs.org>
References: <20180904175804.06F7418C0CE@mercury.lcs.mit.edu>
 <20180904203311.GA21089@minnie.tuhs.org>
Message-ID: <CAC20D2O6CRNBZRvCU_-1dNmEpC3ws_AnsKsdcOaRcXoQAVJGWw@mail.gmail.com>

On Tue, Sep 4, 2018 at 4:34 PM Warren Toomey <wkt at tuhs.org> wrote:

> On Tue, Sep 04, 2018 at 01:58:04PM -0400, Noel Chiappa wrote:
> > True; but if all the copies of a particular item are discarded, one can
> make
> > all the lawyers on the planet as happy as clams, and it won't do a bit of
> > good. Save the bits, _then_ work out the legal issues, is my thinking on
> > priorities.
>
Amen!!!


>
> Save the bits, and also
> be mindful of the legal issues.
>
Exactly -- we do need to be respectful of the legal issues. That is
reality; but as Noel suggest and Warren has demonstrated -- a museum has to
have the object in its posession, before you can argue who owns it ;-)

Clem

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

From pechter at gmail.com  Wed Sep  5 06:53:43 2018
From: pechter at gmail.com (William Pechter)
Date: Tue, 4 Sep 2018 16:53:43 -0400
Subject: [TUHS] Saving the Unix Bits
In-Reply-To: <20180904203311.GA21089@minnie.tuhs.org>
References: <20180904175804.06F7418C0CE@mercury.lcs.mit.edu>
 <20180904203311.GA21089@minnie.tuhs.org>
Message-ID: <CALwkMd1A3zn45KC_jLpp8z5J+hZvUF-AKd1-+pNcZW84m5TMSA@mail.gmail.com>

One thing I'd like to see saved for the historical value is Pyramid OS/x.
It was one of those things I'd have liked to see the internals of -- but I
wasn't supposed to have that level accesss in Ed Services.

It is an interesting mix of both the SysV and BSD environments and it's a
shame it's probably completely gone now.

I think the last work on it may have been at Siemens, since I think the
last bit of Pyramid that was left was rumored to
go to SVR4 (I was there for the DC/OSx transition -- I worked on the
courseware fixes and beta testing).

I heard from a friend that they may have gone to Solaris before the end
hit.  I think they were swallowed by Fujitsu.

Amazingly, I heard some of my SVR4 courseware stuff ended up in
illustrations used in Solaris courseware.  My name was in the illustration
of the password file.  A trainer hired at least 5 years after me went to
Sun and I hear some of my stuff went along for the ride.

I long wished they had done the full Linux dual universe thing on a *BSD
varient.

I'd be running FreeBSD on my desktop if I could just watch Netflix with
it.  Linux, Windows and MacOS have enough pull for Google to port their
Widevine

Bill





--
  d|i|g|i|t|a|l had it THEN.  Don't you wish you could still buy it now!
 pechter-at-gmail.com


On Tue, Sep 4, 2018 at 4:34 PM Warren Toomey <wkt at tuhs.org> wrote:

> On Tue, Sep 04, 2018 at 01:58:04PM -0400, Noel Chiappa wrote:
> > True; but if all the copies of a particular item are discarded, one can
> make
> > all the lawyers on the planet as happy as clams, and it won't do a bit of
> > good. Save the bits, _then_ work out the legal issues, is my thinking on
> > priorities.
>
> I'll also follow up on Henry and Noel's e-mail w.r.t the Unix Archive that
> TUHS provides. The only files in the public archive are ones where the
> legal
> issues have been resolved. I also keep a hidden archive of files where the
> legal issues have not been resolved.
>
> As always, if you would like me to keep an off-site backup of your Unix
> bits, the hidden Unix archive is write-only. Save the bits, and also
> be mindful of the legal issues.
>
> Cheers, Warren
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180904/4447bbe7/attachment.html>

From gtaylor at tnetconsulting.net  Wed Sep  5 08:18:16 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 4 Sep 2018 16:18:16 -0600
Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?=
In-Reply-To: <20180904085226.GA81023@bugle.employees.org>
References: <f3f250f4-cffd-794c-450a-d1c3829c890e@spamtrap.tnetconsulting.net>
 <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com>
 <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net>
 <6e3a87ce-f573-4258-9db5-a5f99b5b89b1.maildroid@localhost>
 <20180829202111.GA17007@minnie.tuhs.org>
 <CACYmRND_fh-pnPyEp5a5_7XYtEV2ZsWK_stMnrL2VWv_NBS8Fg@mail.gmail.com>
 <alpine.BSF.2.21.9999.1809040836290.28912@aneurin.horsfall.org>
 <20180904085226.GA81023@bugle.employees.org>
Message-ID: <f79ffdcf-0efb-d461-84ca-457c111682b6@spamtrap.tnetconsulting.net>

On 09/04/2018 02:52 AM, Derek Fawcus wrote:
> Last time I checked (in the UK) we can use any form of modulation or
> encoding we want [*], as long as we record/log it, and don't use encryption.

I think similar is the case here in the US too.

The key being "encoding" and decidedly NOT "encryption".

Further, you must make said encodings available to anyone and everyone 
that asks, including the F.C.C.



-- 
Grant. . . .
unix || die

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

From dot at dotat.at  Wed Sep  5 10:10:41 2018
From: dot at dotat.at (Tony Finch)
Date: Wed, 5 Sep 2018 01:10:41 +0100
Subject: [TUHS] SunOS code?
In-Reply-To: <CAK7dMtC4VL56Utb67-LJfXrZ2oStUb_MDFO4q-PakGjjHOF82w@mail.gmail.com>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com>
 <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net>
 <CAK7dMtB8AmPG5ZMceGZdD8sxL10horfO0ZYLfXuX=4Dp8u7bwQ@mail.gmail.com>
 <ee7772a4-c23a-3344-4f10-c561047ffbb5@kilonet.net>
 <20180901221933.GA2214@thunk.org>
 <CAK7dMtC4VL56Utb67-LJfXrZ2oStUb_MDFO4q-PakGjjHOF82w@mail.gmail.com>
Message-ID: <2E7183C5-45CD-4F81-84FC-66EEDF4286A9@dotat.at>


> On 2 Sep 2018, at 06:05, Kevin Bowling <kevin.bowling at kev009.com> wrote:
> 
> The E10k was only a 64-core machine on a tight backplane compared to
> other large systems.  It didn't have any of the pressing needs that
> Sequent and SGI did with multi-drawer interconnects to drive
> excellence in NUMA.

When I started work at Cambridge in 2002 our central supercomputer was being replaced with a cluster of Sun Fire E15K machines with a fancy interconnect - it topped out at position 199 on the top500 list https://www.top500.org/list/2003/06/?page=2 with a 300 core configuration. It looks like they never managed to get the whole thing working as a single cluster since the other two thirds of the installation had positions 200 and 201! (The Nov. 2002 top500 list has it in 6 x 144 core shards.) Here’s a news item about it: https://www.cnet.com/news/sun-expands-supercomputer-effort/

> True.  There is also at least one unencumbered strategy such as epoch
> based reclamation which was known about around that time [2]
> 
> [2] https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-579.pdf

The big benchmarks in this lovely thesis were run on one of the E15K supercomputer boxes :-)

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at

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

From imp at bsdimp.com  Wed Sep  5 13:39:40 2018
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 4 Sep 2018 21:39:40 -0600
Subject: [TUHS] Speaking of legality...
Message-ID: <CANCZdfq0R1EtVQ4=MhAB4M+F7pPxCq=fCDXUcP516=xxRV3=2g@mail.gmail.com>

I have a question...

I'm trying to recreate "a" source representation of the Venix for Rainbow
that I have. It's a v7 port, and I have all the .o's for it.

Most of the .o's compile, with the proper compiler, to the same code that
are in the .o's, at least judging from the .c file of the same name in the
TUHS archive.

The question is, what are the legal ramifications of publishing my
reconstruction?

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

From wkt at tuhs.org  Wed Sep  5 13:48:05 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 5 Sep 2018 13:48:05 +1000
Subject: [TUHS] Speaking of legality...
In-Reply-To: <CANCZdfq0R1EtVQ4=MhAB4M+F7pPxCq=fCDXUcP516=xxRV3=2g@mail.gmail.com>
References: <CANCZdfq0R1EtVQ4=MhAB4M+F7pPxCq=fCDXUcP516=xxRV3=2g@mail.gmail.com>
Message-ID: <20180905034805.GA23662@minnie.tuhs.org>

On Tue, Sep 04, 2018 at 09:39:40PM -0600, Warner Losh wrote:
>    I'm trying to recreate "a" source representation of the Venix for
>    Rainbow that I have. It's a v7 port, and I have all the .o's for it.
>    Most of the .o's compile, with the proper compiler, to the same code
>    that are in the .o's, at least judging from the .c file of the same
>    name in the TUHS archive.
>    The question is, what are the legal ramifications of publishing my
>    reconstruction?

Good question. IANAL of course. Obviously, it's a port of V7 and the
vanilla V7 is now under a free license. So I would guess that you only
have to worry about the files in Venix which are different: drivers etc.

Cheers, Warren


From erc at pobox.com  Wed Sep  5 15:17:47 2018
From: erc at pobox.com (Ed Carp)
Date: Tue, 4 Sep 2018 22:17:47 -0700
Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?=
In-Reply-To: <alpine.BSF.2.21.9999.1809040836290.28912@aneurin.horsfall.org>
References: <f3f250f4-cffd-794c-450a-d1c3829c890e@spamtrap.tnetconsulting.net>
 <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com>
 <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net>
 <6e3a87ce-f573-4258-9db5-a5f99b5b89b1.maildroid@localhost>
 <20180829202111.GA17007@minnie.tuhs.org>
 <CACYmRND_fh-pnPyEp5a5_7XYtEV2ZsWK_stMnrL2VWv_NBS8Fg@mail.gmail.com>
 <alpine.BSF.2.21.9999.1809040836290.28912@aneurin.horsfall.org>
Message-ID: <CACYmRNBy-2t2zBvG+O9Qk7z6=jC8NZZVyYm=SHP39PZhC0n9eQ@mail.gmail.com>

I just put the TNC into transparent mode and let the Linux boxes talk
to each other via UUCP. I guess I could've used KISS, but it was a
quick-and-dirty hack so I could read email from my laptop in bed :)

On 9/3/18, Dave Horsfall <dave at horsfall.org> wrote:
> On Mon, 3 Sep 2018, Ed Carp wrote:
>
>> Wow, that takes me back quite a ways. I think I've still got my UUCP
>> setup somewhere on a backup. UUCP works great over anything from ssh
>> over tcpip to 1200 baud half-duplex packet connections.
>
> If you're referring to "Amateur" i.e. "ham radio" packet radio than yes,
> I'm told that it works great i.e. half-duplex -> large data -> short ACK.
>
>> Fond memories.
>
> Heh heh - I once ran *raw* Xmodem over packet i.e. not encapsulated in
> that protocol-from-hell AX.25 i.e. technically illegal[*]; it worked great
> until a packet was lost (the "hidden transmitter" problem) and the various
> timeouts concerned (Xmodem vs. the TNCs themselves) went completely
> pear-shaped...
>
> [*]
>
> Stuff the legality; isn't Amateur radio all about experimentation?  But we
> did announce on that frequency that we were about to conduct an
> experiment.  And whoever designed AX.25 (yes, I have studied it in great
> detail) must've been on something at the time...  Protocol layers?
> What's that?
>
> -- Dave (VK2KFU)
>


From gilles at gravier.org  Wed Sep  5 16:31:52 2018
From: gilles at gravier.org (Gilles Gravier)
Date: Wed, 5 Sep 2018 08:31:52 +0200
Subject: [TUHS] SunOS code?
In-Reply-To: <CAEdTPBetBFP_sL2X1M2MdrwU1Oimm27FjMtcYxs9WSsQT_Gh5g@mail.gmail.com>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com>
 <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net>
 <CAK7dMtB8AmPG5ZMceGZdD8sxL10horfO0ZYLfXuX=4Dp8u7bwQ@mail.gmail.com>
 <ee7772a4-c23a-3344-4f10-c561047ffbb5@kilonet.net>
 <20180901221933.GA2214@thunk.org>
 <CAK7dMtC4VL56Utb67-LJfXrZ2oStUb_MDFO4q-PakGjjHOF82w@mail.gmail.com>
 <20180902194301.GA22518@thunk.org>
 <CAK7dMtBqzt=vNeKLWjz=xGj6o=mpFq1P8m86_daznR3xHa60LA@mail.gmail.com>
 <CABq8+zeSWXV-OCs=0noyD6aQ1-Ge2pU0ynj3bcqkr=830v7V8g@mail.gmail.com>
 <CAEdTPBetBFP_sL2X1M2MdrwU1Oimm27FjMtcYxs9WSsQT_Gh5g@mail.gmail.com>
Message-ID: <CABq8+zcm4oAzTkOtkd-ZeG12Aq-h_oYHOYGH+kGaMS87qN6kXA@mail.gmail.com>

(Henri, you're in copy of this again, because first time I did a Reply
instead of Reply to list/all. Sorry.)

Le mar. 4 sept. 2018 à 19:45, Henry Bent <henry.r.bent at gmail.com> a écrit :

>
>
> On Tue, Sep 4, 2018, 13:40 Gilles Gravier <gilles at gravier.org> wrote:
>
>> This link :
>> https://vetusware.com/download/SunOS%20Source%20Code%204.1.3/?id=13475
>> seems to have the right file (registration required, but it's free, use a
>> disposable email).
>>
>> Beats my having to find a SCSI adaptor, a QIC-150 drive, and trying to
>> read my old QIC-150 tape with the source code on it...
>>
>> Gilles
>>
>
> I feel like we've been through this before on this list, but perhaps it
> bears repeating: just because you can find source (or binaries, or CD
> images, etc.) on the internet, that doesn't make it the least bit legal.
> That is clearly the case here. Sadly, there are even higher profile sites
> like the Internet Archive that have this problem too.  The concept of
> "abandonware" has no legal footing whatsoever.
>
> -Henry
>

Oh I definitely know the sources aren't officially accessible. By the way,
I had copies of them (my QIC tape) when I was a student. I still have the
QIC.

It's the common example that I use to tell people that opensourcing
software makes it more secure because the good guys have access to the
source code at the same time as the bad guys, which gives them a fair
chance to fix bugs before the bad guys use them.

With closed source (SunOS, VMS...) the good guys don't have access to the
source code... but the bad guys will always (either by paying somebody
enough to make a copy for them, or by finding them on some non legitimate
place). As a student I had the source of SunOS (4.1.3) but also VMS (on a
few TK-50 tapes).

For me, that vetusware site is certainly not legitimate... but since I have
the QIC tape at home, I just used it as an easy alternative to having to
get the hardware to read my tape back in working order...

I certainly do not consider it a legally approved way of distributing code
which is, as we all agree, NOT open source.

Gilles

-- 
*Gilles Gravier*  - Gilles at Gravier.org
GSM : +33618347147 and +41794728437
Skype : ggravier | PGP Key : 0x8DE6D026
<http://pgp.mit.edu:11371/pks/lookup?search=0x8DE6D026&op=index>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180905/2c5f85c9/attachment.html>

From krewat at kilonet.net  Wed Sep  5 22:55:02 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 5 Sep 2018 08:55:02 -0400
Subject: [TUHS] SunOS code?
In-Reply-To: <CABq8+zcm4oAzTkOtkd-ZeG12Aq-h_oYHOYGH+kGaMS87qN6kXA@mail.gmail.com>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com>
 <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net>
 <CAK7dMtB8AmPG5ZMceGZdD8sxL10horfO0ZYLfXuX=4Dp8u7bwQ@mail.gmail.com>
 <ee7772a4-c23a-3344-4f10-c561047ffbb5@kilonet.net>
 <20180901221933.GA2214@thunk.org>
 <CAK7dMtC4VL56Utb67-LJfXrZ2oStUb_MDFO4q-PakGjjHOF82w@mail.gmail.com>
 <20180902194301.GA22518@thunk.org>
 <CAK7dMtBqzt=vNeKLWjz=xGj6o=mpFq1P8m86_daznR3xHa60LA@mail.gmail.com>
 <CABq8+zeSWXV-OCs=0noyD6aQ1-Ge2pU0ynj3bcqkr=830v7V8g@mail.gmail.com>
 <CAEdTPBetBFP_sL2X1M2MdrwU1Oimm27FjMtcYxs9WSsQT_Gh5g@mail.gmail.com>
 <CABq8+zcm4oAzTkOtkd-ZeG12Aq-h_oYHOYGH+kGaMS87qN6kXA@mail.gmail.com>
Message-ID: <be545932-5813-5b6a-1304-c33f1a71712c@kilonet.net>



On 9/5/2018 2:31 AM, Gilles Gravier wrote:
> It's the common example that I use to tell people that opensourcing 
> software makes it more secure because the good guys have access to the 
> source code at the same time as the bad guys, which gives them a fair 
> chance to fix bugs before the bad guys use them.


Bash/Shellshock kinda proves that premise incorrect, although it's 
pretty much the worst-case example, but still...  ;)

Announced in 2014, it goes back to September 1989 (according to a 
wikipedia article, so I'm not sure about that date's accuracy).

https://en.wikipedia.org/wiki/Shellshock_(software_bug)

https://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33
https://www.cvedetails.com/product/17/IBM-AIX.html?vendor_id=14
https://www.cvedetails.com/product/20/HP-Hp-ux.html?vendor_id=10
https://www.cvedetails.com/product/19755/Oracle-Solaris.html?vendor_id=93

It could be argued that the above CVE results are either under-reported 
(closed-source), or over-reported (open-source). Or vice-versa ;)

ak







From norman at oclsc.org  Thu Sep  6 01:04:41 2018
From: norman at oclsc.org (Norman Wilson)
Date: Wed, 05 Sep 2018 11:04:41 -0400
Subject: [TUHS] Cryptic Unix Commands
Message-ID: <1536159885.28857.for-standards-violators@oclsc.org>

Ron Natalie:

  I use the numbers but I think it stems from the days when kill didn't take
  the names.    It's easier for me to remember -1 and -9 than to remember what
  the mnemonics are.

====

Me too.  And not just the kill command; the (real) shell's
trap command too.

It's all just muscle memory, not a desire to save keystrokes.

On the rare occasions when I need to send a post-modern signal
like SIGSTOP or SIGCONT, I use the name.

As an aside, why do modern kill and sh accept only the
abbreviated form of the signal name, not the full name;
e.g. kill -STOP is OK, kill -SIGSTOP an error?  When we
taught kill about that sometime in (I think) the 9th Edition
era at Research, we allowed either form.  I think it was
Doug who insisted on it, and he was right.

All this applies to shell commands, not to programs.
It is just plain wrong to code
	kill(9, pid)
in C.

Norman Wilson
Toronto ON


From imp at bsdimp.com  Thu Sep  6 01:26:52 2018
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 5 Sep 2018 09:26:52 -0600
Subject: [TUHS] SunOS code?
In-Reply-To: <be545932-5813-5b6a-1304-c33f1a71712c@kilonet.net>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com>
 <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net>
 <CAK7dMtB8AmPG5ZMceGZdD8sxL10horfO0ZYLfXuX=4Dp8u7bwQ@mail.gmail.com>
 <ee7772a4-c23a-3344-4f10-c561047ffbb5@kilonet.net>
 <20180901221933.GA2214@thunk.org>
 <CAK7dMtC4VL56Utb67-LJfXrZ2oStUb_MDFO4q-PakGjjHOF82w@mail.gmail.com>
 <20180902194301.GA22518@thunk.org>
 <CAK7dMtBqzt=vNeKLWjz=xGj6o=mpFq1P8m86_daznR3xHa60LA@mail.gmail.com>
 <CABq8+zeSWXV-OCs=0noyD6aQ1-Ge2pU0ynj3bcqkr=830v7V8g@mail.gmail.com>
 <CAEdTPBetBFP_sL2X1M2MdrwU1Oimm27FjMtcYxs9WSsQT_Gh5g@mail.gmail.com>
 <CABq8+zcm4oAzTkOtkd-ZeG12Aq-h_oYHOYGH+kGaMS87qN6kXA@mail.gmail.com>
 <be545932-5813-5b6a-1304-c33f1a71712c@kilonet.net>
Message-ID: <CANCZdfrvtbtN7Kfg3EeB3gYHvWUxOEb7OLT31zjGNxd0YVZQ2w@mail.gmail.com>

On Wed, Sep 5, 2018 at 6:55 AM Arthur Krewat <krewat at kilonet.net> wrote:

>
>
> On 9/5/2018 2:31 AM, Gilles Gravier wrote:
> > It's the common example that I use to tell people that opensourcing
> > software makes it more secure because the good guys have access to the
> > source code at the same time as the bad guys, which gives them a fair
> > chance to fix bugs before the bad guys use them.
>
>
> Bash/Shellshock kinda proves that premise incorrect, although it's
> pretty much the worst-case example, but still...  ;)
>

I'm not sure it does. It proves that bugs aren't instantly found, true. It
doesn't provide perfection, but does make it easier to find / fix bugs
before the bad guys. How long would such a bug have languished it if were
buried inside of DCL.B32 instead of being out in the open?

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

From chet.ramey at case.edu  Thu Sep  6 01:42:09 2018
From: chet.ramey at case.edu (Chet Ramey)
Date: Wed, 5 Sep 2018 11:42:09 -0400
Subject: [TUHS] Cryptic Unix Commands
In-Reply-To: <1536159885.28857.for-standards-violators@oclsc.org>
References: <1536159885.28857.for-standards-violators@oclsc.org>
Message-ID: <8a4c50b5-bd1f-3778-5166-a0a886a59e31@case.edu>

On 9/5/18 11:04 AM, Norman Wilson wrote:

> As an aside, why do modern kill and sh accept only the
> abbreviated form of the signal name, not the full name;
> e.g. kill -STOP is OK, kill -SIGSTOP an error?  

It's the standard:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/kill.html#tag_20_64

"Historical versions of kill have not written the SIG prefix for the -l
option and have not recognized the SIG prefix on signal_names."

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_28

"Implementations may also accept the names with the SIG prefix; no known
historical shell does so."

-- 
``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 chet.ramey at case.edu  Thu Sep  6 01:36:48 2018
From: chet.ramey at case.edu (Chet Ramey)
Date: Wed, 5 Sep 2018 11:36:48 -0400
Subject: [TUHS] SunOS code?
In-Reply-To: <CANCZdfrvtbtN7Kfg3EeB3gYHvWUxOEb7OLT31zjGNxd0YVZQ2w@mail.gmail.com>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com>
 <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net>
 <CAK7dMtB8AmPG5ZMceGZdD8sxL10horfO0ZYLfXuX=4Dp8u7bwQ@mail.gmail.com>
 <ee7772a4-c23a-3344-4f10-c561047ffbb5@kilonet.net>
 <20180901221933.GA2214@thunk.org>
 <CAK7dMtC4VL56Utb67-LJfXrZ2oStUb_MDFO4q-PakGjjHOF82w@mail.gmail.com>
 <20180902194301.GA22518@thunk.org>
 <CAK7dMtBqzt=vNeKLWjz=xGj6o=mpFq1P8m86_daznR3xHa60LA@mail.gmail.com>
 <CABq8+zeSWXV-OCs=0noyD6aQ1-Ge2pU0ynj3bcqkr=830v7V8g@mail.gmail.com>
 <CAEdTPBetBFP_sL2X1M2MdrwU1Oimm27FjMtcYxs9WSsQT_Gh5g@mail.gmail.com>
 <CABq8+zcm4oAzTkOtkd-ZeG12Aq-h_oYHOYGH+kGaMS87qN6kXA@mail.gmail.com>
 <be545932-5813-5b6a-1304-c33f1a71712c@kilonet.net>
 <CANCZdfrvtbtN7Kfg3EeB3gYHvWUxOEb7OLT31zjGNxd0YVZQ2w@mail.gmail.com>
Message-ID: <3960b738-0939-d43d-e8b3-4454954f31a9@case.edu>

On 9/5/18 11:26 AM, Warner Losh wrote:

>     On 9/5/2018 2:31 AM, Gilles Gravier wrote:
>     > It's the common example that I use to tell people that opensourcing
>     > software makes it more secure because the good guys have access to the
>     > source code at the same time as the bad guys, which gives them a fair
>     > chance to fix bugs before the bad guys use them.
> 
> 
>     Bash/Shellshock kinda proves that premise incorrect, although it's
>     pretty much the worst-case example, but still...  ;)
> 
> 
> I'm not sure it does. It proves that bugs aren't instantly found, true. It
> doesn't provide perfection, but does make it easier to find / fix bugs
> before the bad guys. How long would such a bug have languished it if were
> buried inside of DCL.B32 instead of being out in the open?

It proves that if there is someone who has an idea, or who thinks about a
thing in new ways, he can verify his suspicions without too much trouble.
The barrier to investigation is lowered.

Chet


-- 
``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  Thu Sep  6 01:43:53 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 5 Sep 2018 11:43:53 -0400
Subject: [TUHS] SunOS code?
In-Reply-To: <CANCZdfrvtbtN7Kfg3EeB3gYHvWUxOEb7OLT31zjGNxd0YVZQ2w@mail.gmail.com>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com>
 <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net>
 <CAK7dMtB8AmPG5ZMceGZdD8sxL10horfO0ZYLfXuX=4Dp8u7bwQ@mail.gmail.com>
 <ee7772a4-c23a-3344-4f10-c561047ffbb5@kilonet.net>
 <20180901221933.GA2214@thunk.org>
 <CAK7dMtC4VL56Utb67-LJfXrZ2oStUb_MDFO4q-PakGjjHOF82w@mail.gmail.com>
 <20180902194301.GA22518@thunk.org>
 <CAK7dMtBqzt=vNeKLWjz=xGj6o=mpFq1P8m86_daznR3xHa60LA@mail.gmail.com>
 <CABq8+zeSWXV-OCs=0noyD6aQ1-Ge2pU0ynj3bcqkr=830v7V8g@mail.gmail.com>
 <CAEdTPBetBFP_sL2X1M2MdrwU1Oimm27FjMtcYxs9WSsQT_Gh5g@mail.gmail.com>
 <CABq8+zcm4oAzTkOtkd-ZeG12Aq-h_oYHOYGH+kGaMS87qN6kXA@mail.gmail.com>
 <be545932-5813-5b6a-1304-c33f1a71712c@kilonet.net>
 <CANCZdfrvtbtN7Kfg3EeB3gYHvWUxOEb7OLT31zjGNxd0YVZQ2w@mail.gmail.com>
Message-ID: <a5f18bfe-8010-2bc1-6dc2-1c7c837aa36b@kilonet.net>

On 9/5/2018 11:26 AM, Warner Losh wrote:
>
> I'm not sure it does. It proves that bugs aren't instantly found, 
> true. It doesn't provide perfection, but does make it easier to find / 
> fix bugs before the bad guys. How long would such a bug have 
> languished it if were buried inside of DCL.B32 instead of being out in 
> the open?

It depends on how it was found in the first place. A quick Google 
doesn't tell me much about exactly how it was discovered initially. Nor 
is there any background information that says it wasn't (or was) 
exploited before the announcement. Was it discovered because someone 
(Stéphane Chazelas) was just reading open source code? Or was he trying 
to do something innocent and it broke in such a way that it was obvious 
bash was doing something bad? Or was he investigating a break-in and 
found the vector? Serious questions, I'd love to hear from anyone who 
knows more.

My original point remains: Open Source doesn't necessarily mean more 
secure if a really bad exploit was allowed to exist for 25 years.

No offense intended to anyone on this list.

ak






From jnc at mercury.lcs.mit.edu  Thu Sep  6 01:44:35 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed,  5 Sep 2018 11:44:35 -0400 (EDT)
Subject: [TUHS] Cryptic Unix Commands
Message-ID: <20180905154435.103E118C0A0@mercury.lcs.mit.edu>

    > From: Norman Wilson

    > It is just plain wrong to code
    >  kill(9, pid)

_All_ uses of magic numbers in numeric form are wrong!

	Noel


From jpl.jpl at gmail.com  Thu Sep  6 02:12:15 2018
From: jpl.jpl at gmail.com (John P. Linderman)
Date: Wed, 5 Sep 2018 12:12:15 -0400
Subject: [TUHS] Cryptic Unix Commands
In-Reply-To: <20180905154435.103E118C0A0@mercury.lcs.mit.edu>
References: <20180905154435.103E118C0A0@mercury.lcs.mit.edu>
Message-ID: <CAC0cEp_yYYhwi1SinvsHeT=WhismC7gsM3mBnBTpsX2FmcS6Zg@mail.gmail.com>

On Wed, Sep 5, 2018 at 11:44 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Norman Wilson
>
>     > It is just plain wrong to code
>     >  kill(9, pid)
>
> _All_ uses of magic numbers in numeric form are wrong!
>
>         Noel
>

I completely agree, although you can do worse. A junior programmer I worked
with at MIT wrote (in IBM assembler)

twelv dc 10

(I probably have the syntax wrong, but he was declaring the value of
symbolic name 'twelv' to be 10). I have no idea why he did this. He didn't
last long.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180905/9bae5277/attachment.html>

From khm at sciops.net  Thu Sep  6 02:45:37 2018
From: khm at sciops.net (Kurt H Maier)
Date: Wed, 5 Sep 2018 09:45:37 -0700
Subject: [TUHS] Cryptic Unix Commands
In-Reply-To: <20180905154435.103E118C0A0@mercury.lcs.mit.edu>
References: <20180905154435.103E118C0A0@mercury.lcs.mit.edu>
Message-ID: <20180905164537.GA81179@wopr>

On Wed, Sep 05, 2018 at 11:44:35AM -0400, Noel Chiappa wrote:
>     > From: Norman Wilson
> 
>     > It is just plain wrong to code
>     >  kill(9, pid)
> 
> _All_ uses of magic numbers in numeric form are wrong!
> 
> 	Noel

https://www.boost.org/doc/libs/1_68_0/boost/utility/binary.hpp


khm


From clemc at ccc.com  Thu Sep  6 05:17:22 2018
From: clemc at ccc.com (Clem Cole)
Date: Wed, 5 Sep 2018 15:17:22 -0400
Subject: [TUHS] Speaking of legality...
In-Reply-To: <20180905034805.GA23662@minnie.tuhs.org>
References: <CANCZdfq0R1EtVQ4=MhAB4M+F7pPxCq=fCDXUcP516=xxRV3=2g@mail.gmail.com>
 <20180905034805.GA23662@minnie.tuhs.org>
Message-ID: <CAC20D2OP9svQUm01d0r6UPF_=8nrg46HfMoTiu_T+Ek=rTBe9Q@mail.gmail.com>

On Tue, Sep 4, 2018 at 11:48 PM Warren Toomey <wkt at tuhs.org> wrote:

> On Tue, Sep 04, 2018 at 09:39:40PM -0600, Warner Losh wrote:
> >    I'm trying to recreate "a" source representation of the Venix for
> >    Rainbow that I have. It's a v7 port, and I have all the .o's for it.
> >    Most of the .o's compile, with the proper compiler, to the same code
> >    that are in the .o's, at least judging from the .c file of the same
> >    name in the TUHS archive.
> >    The question is, what are the legal ramifications of publishing my
> >    reconstruction?
>
> Good question. IANAL of course. Obviously, it's a port of V7 and the
> vanilla V7 is now under a free license. So I would guess that you only
> have to worry about the files in Venix which are different: drivers etc.
>
> Right, but the AT&T parts you need to be sure to attribute them,

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

From imp at bsdimp.com  Thu Sep  6 05:37:07 2018
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 5 Sep 2018 13:37:07 -0600
Subject: [TUHS] Speaking of legality...
In-Reply-To: <CAC20D2OP9svQUm01d0r6UPF_=8nrg46HfMoTiu_T+Ek=rTBe9Q@mail.gmail.com>
References: <CANCZdfq0R1EtVQ4=MhAB4M+F7pPxCq=fCDXUcP516=xxRV3=2g@mail.gmail.com>
 <20180905034805.GA23662@minnie.tuhs.org>
 <CAC20D2OP9svQUm01d0r6UPF_=8nrg46HfMoTiu_T+Ek=rTBe9Q@mail.gmail.com>
Message-ID: <CANCZdfr_nK-grF5_sXfAb-YUr0xmWHhdgJPWvOitJA6KW-GzqA@mail.gmail.com>

On Wed, Sep 5, 2018 at 1:17 PM Clem Cole <clemc at ccc.com> wrote:

>
>
> On Tue, Sep 4, 2018 at 11:48 PM Warren Toomey <wkt at tuhs.org> wrote:
>
>> On Tue, Sep 04, 2018 at 09:39:40PM -0600, Warner Losh wrote:
>> >    I'm trying to recreate "a" source representation of the Venix for
>> >    Rainbow that I have. It's a v7 port, and I have all the .o's for it.
>> >    Most of the .o's compile, with the proper compiler, to the same code
>> >    that are in the .o's, at least judging from the .c file of the same
>> >    name in the TUHS archive.
>> >    The question is, what are the legal ramifications of publishing my
>> >    reconstruction?
>>
>> Good question. IANAL of course. Obviously, it's a port of V7 and the
>> vanilla V7 is now under a free license. So I would guess that you only
>> have to worry about the files in Venix which are different: drivers etc.
>>
>> Right, but the AT&T parts you need to be sure to attribute them,
>
>

Of course...

Warner

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

From dds at aueb.gr  Thu Sep  6 07:31:15 2018
From: dds at aueb.gr (Diomidis Spinellis)
Date: Thu, 6 Sep 2018 00:31:15 +0300
Subject: [TUHS] Usenix: no official Unix 50th celebration, apparently
In-Reply-To: <20180826041046.GA3176@thunk.org>
References: <20180826003127.GA18905@minnie.tuhs.org>
 <alpine.BSF.2.21.9999.1808261237290.41601@aneurin.horsfall.org>
 <20180826041046.GA3176@thunk.org>
Message-ID: <53afe3bc-b775-154b-b764-7bc6ac4769ec@aueb.gr>

On 26/08/2018 07:10, Theodore Y. Ts'o wrote:
[...]
> The question I would raise is whether some kind of 50th celebration
> has to be colocated with Usenix ATC, especially if the Usenix BoD is
> not innterested in lending much in the way of financial or staff
> support.  For example, maybe something combined with some kind of
> fund-raising event held at the Compute History Museum in the Bay Area?
> 
> Or perhaps the Linux Foundation might be willing to do a Unix 50th
> celebration at their 2019 Open Source Summit event?
> 
> It does seem to me that Usenix ought to have the right of first
> refusal to host such a celebration, but if the Board isn't willing to
> step it up, there are other possibilities that could be explored.

One possibility might be to propose a "50th Unix Anniversary" Developer 
Room at FOSDEM 2019 [1].  FOSDEM is a free event for software developers 
to meet, share ideas and collaborate.  It takes place every year with 
thousands of developers of free and open source software from all over 
the world gathering in Brussels.

Our room can be used to host presentations related to topics such as the 
Unix history, the 50th anniversary, and the reconstruction efforts of 
historic editions.  The many *BSD and Linux folks that attend FOSDEM 
together with thousands of other open source aficionados provide an 
excellent audience for our event.  We can also combine the presentations 
with a TUHS stand where we can display running historic software.

The deadline for room proposals is September 20th and for stands 
November 2nd [2].  FOSDEM is entirely organized by volunteers and 
attendance is free without registration.  We don't have to pay anything 
for the room and the stand, but we also can't expect any funding from 
the organizers for flying people in.

[1] https://fosdem.org/2019/
[2] https://fosdem.org/2019/news/2018-08-10-call-for-participation/

Diomidis


From dave at horsfall.org  Thu Sep  6 09:40:30 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 6 Sep 2018 09:40:30 +1000 (EST)
Subject: [TUHS] SunOS code?
In-Reply-To: <CABq8+zcm4oAzTkOtkd-ZeG12Aq-h_oYHOYGH+kGaMS87qN6kXA@mail.gmail.com>
References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu>
 <CAK7dMtDabPX9O7Qk1fCGuzLuAc0Ke8S7qS0ArEzsW3cGMiFJUg@mail.gmail.com>
 <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com>
 <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net>
 <CAK7dMtB8AmPG5ZMceGZdD8sxL10horfO0ZYLfXuX=4Dp8u7bwQ@mail.gmail.com>
 <ee7772a4-c23a-3344-4f10-c561047ffbb5@kilonet.net>
 <20180901221933.GA2214@thunk.org>
 <CAK7dMtC4VL56Utb67-LJfXrZ2oStUb_MDFO4q-PakGjjHOF82w@mail.gmail.com>
 <20180902194301.GA22518@thunk.org>
 <CAK7dMtBqzt=vNeKLWjz=xGj6o=mpFq1P8m86_daznR3xHa60LA@mail.gmail.com>
 <CABq8+zeSWXV-OCs=0noyD6aQ1-Ge2pU0ynj3bcqkr=830v7V8g@mail.gmail.com>
 <CAEdTPBetBFP_sL2X1M2MdrwU1Oimm27FjMtcYxs9WSsQT_Gh5g@mail.gmail.com>
 <CABq8+zcm4oAzTkOtkd-ZeG12Aq-h_oYHOYGH+kGaMS87qN6kXA@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.1809060933040.28912@aneurin.horsfall.org>

On Wed, 5 Sep 2018, Gilles Gravier wrote:

> (Henri, you're in copy of this again, because first time I did a Reply 
> instead of Reply to list/all. Sorry.)

One of my pet hates is people who use "Reply All" because either they are 
too lazy to edit the Reply (and they top-post, too), or the list is set up 
that way.

I really don't need my own personal copy, as well as a list copy.

Oh, and people who are too lazy to trim their replies too, because they
are encouraged to top-post.

-- Dave


From clemc at ccc.com  Thu Sep  6 10:23:27 2018
From: clemc at ccc.com (Clem cole)
Date: Wed, 5 Sep 2018 20:23:27 -0400
Subject: [TUHS] Usenix: no official Unix 50th celebration, apparently
In-Reply-To: <53afe3bc-b775-154b-b764-7bc6ac4769ec@aueb.gr>
References: <20180826003127.GA18905@minnie.tuhs.org>
 <alpine.BSF.2.21.9999.1808261237290.41601@aneurin.horsfall.org>
 <20180826041046.GA3176@thunk.org>
 <53afe3bc-b775-154b-b764-7bc6ac4769ec@aueb.gr>
Message-ID: <778C65CA-0447-41F0-8F6F-3E3277CFA847@ccc.com>

I’ll ok into it. 

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Sep 5, 2018, at 5:31 PM, Diomidis Spinellis <dds at aueb.gr> wrote:
> 
>> On 26/08/2018 07:10, Theodore Y. Ts'o wrote:
>> [...]
>> The question I would raise is whether some kind of 50th celebration
>> has to be colocated with Usenix ATC, especially if the Usenix BoD is
>> not innterested in lending much in the way of financial or staff
>> support.  For example, maybe something combined with some kind of
>> fund-raising event held at the Compute History Museum in the Bay Area?
>> Or perhaps the Linux Foundation might be willing to do a Unix 50th
>> celebration at their 2019 Open Source Summit event?
>> It does seem to me that Usenix ought to have the right of first
>> refusal to host such a celebration, but if the Board isn't willing to
>> step it up, there are other possibilities that could be explored.
> 
> One possibility might be to propose a "50th Unix Anniversary" Developer Room at FOSDEM 2019 [1].  FOSDEM is a free event for software developers to meet, share ideas and collaborate.  It takes place every year with thousands of developers of free and open source software from all over the world gathering in Brussels.
> 
> Our room can be used to host presentations related to topics such as the Unix history, the 50th anniversary, and the reconstruction efforts of historic editions.  The many *BSD and Linux folks that attend FOSDEM together with thousands of other open source aficionados provide an excellent audience for our event.  We can also combine the presentations with a TUHS stand where we can display running historic software.
> 
> The deadline for room proposals is September 20th and for stands November 2nd [2].  FOSDEM is entirely organized by volunteers and attendance is free without registration.  We don't have to pay anything for the room and the stand, but we also can't expect any funding from the organizers for flying people in.
> 
> [1] https://fosdem.org/2019/
> [2] https://fosdem.org/2019/news/2018-08-10-call-for-participation/
> 
> Diomidis


From dave at horsfall.org  Thu Sep  6 10:39:18 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 6 Sep 2018 10:39:18 +1000 (EST)
Subject: [TUHS] SunOS code?
In-Reply-To: <20180904175804.06F7418C0CE@mercury.lcs.mit.edu>
References: <20180904175804.06F7418C0CE@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.21.9999.1809061033400.28912@aneurin.horsfall.org>

On Tue, 4 Sep 2018, Noel Chiappa wrote:

> (PS: 'Internet' is spelled with a capital; there are many internets, but 
> only one Internet, just as there are many white houses, but only one 
> White House. If the technical community, which _does_ understand the 
> difference, can't get it's act together, how can we expect the media, 
> etc, to do the right thing?)

Thank you.  Thank you.  Thank you.

At every technical lecture I do, I insist upon Internet, but the younger 
generation these days think that they invented it because of Google 
browsing etc.

-- Dave, in a grouchy mood having having three teeth pulled out


From dave at horsfall.org  Thu Sep  6 10:48:19 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 6 Sep 2018 10:48:19 +1000 (EST)
Subject: [TUHS] Saving the Unix Bits
In-Reply-To: <20180904203311.GA21089@minnie.tuhs.org>
References: <20180904175804.06F7418C0CE@mercury.lcs.mit.edu>
 <20180904203311.GA21089@minnie.tuhs.org>
Message-ID: <alpine.BSF.2.21.9999.1809061041350.28912@aneurin.horsfall.org>

On Wed, 5 Sep 2018, Warren Toomey wrote:

> As always, if you would like me to keep an off-site backup of your Unix 
> bits, the hidden Unix archive is write-only. Save the bits, and also be 
> mindful of the legal issues.

It is really important that Unix history is preserved, lest the 
revisionists (they start with an "L") take over.

Disclaimer: I have a hidden archive of some of the "naughty" bits.

-- Dave


From erc at pobox.com  Thu Sep  6 12:11:22 2018
From: erc at pobox.com (Ed Carp)
Date: Wed, 5 Sep 2018 19:11:22 -0700
Subject: [TUHS] RetroNet???
In-Reply-To: <83698bdc-c636-5688-5619-27c8c4b41500@spamtrap.tnetconsulting.net>
References: <f3f250f4-cffd-794c-450a-d1c3829c890e@spamtrap.tnetconsulting.net>
 <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com>
 <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net>
 <20180829183632.GD8423@mcvoy.com>
 <CAEoi9W7P-Cz8K2etu=SzAmamE=cUtmxm8wLGOHKW=9KuqqKDrQ@mail.gmail.com>
 <D83B5D0F-BC43-4A85-BEED-98F2B1EF190A@alchemistowl.org>
 <83698bdc-c636-5688-5619-27c8c4b41500@spamtrap.tnetconsulting.net>
Message-ID: <CACYmRNC50hLLOSu5111R3eGCESMyCfSR9O5899Jy1NkyLhTZrQ@mail.gmail.com>

I've read that Taylor UUCP fixed a bunch of issues with HDB UUCP -
have you considered using it?

On 8/29/18, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
> On 08/29/2018 01:28 PM, Arrigo Triulzi wrote:
>> Have you considered asking Peter Honeyman if he wishes to collaborate
>> in the UUCP project (the “Honey” in HoneyDanBer UUCP)?
>
> I hadn't thought about it.
>
> Please reply to me directly / off list with contact information if you
> have it and I'll happily send him an email.
>
>
>
> --
> Grant. . . .
> unix || die
>
>


From grog at lemis.com  Thu Sep  6 13:21:09 2018
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Thu, 6 Sep 2018 13:21:09 +1000
Subject: [TUHS] Mail etiquette (was: SunOS code?)
In-Reply-To: <alpine.BSF.2.21.9999.1809060933040.28912@aneurin.horsfall.org>
References: <CAK7dMtB8AmPG5ZMceGZdD8sxL10horfO0ZYLfXuX=4Dp8u7bwQ@mail.gmail.com>
 <ee7772a4-c23a-3344-4f10-c561047ffbb5@kilonet.net>
 <20180901221933.GA2214@thunk.org>
 <CAK7dMtC4VL56Utb67-LJfXrZ2oStUb_MDFO4q-PakGjjHOF82w@mail.gmail.com>
 <20180902194301.GA22518@thunk.org>
 <CAK7dMtBqzt=vNeKLWjz=xGj6o=mpFq1P8m86_daznR3xHa60LA@mail.gmail.com>
 <CABq8+zeSWXV-OCs=0noyD6aQ1-Ge2pU0ynj3bcqkr=830v7V8g@mail.gmail.com>
 <CAEdTPBetBFP_sL2X1M2MdrwU1Oimm27FjMtcYxs9WSsQT_Gh5g@mail.gmail.com>
 <CABq8+zcm4oAzTkOtkd-ZeG12Aq-h_oYHOYGH+kGaMS87qN6kXA@mail.gmail.com>
 <alpine.BSF.2.21.9999.1809060933040.28912@aneurin.horsfall.org>
Message-ID: <20180906032109.GC76566@eureka.lemis.com>

On Thursday,  6 September 2018 at  9:40:30 +1000, Dave Horsfall wrote:
> On Wed, 5 Sep 2018, Gilles Gravier wrote:
>
>> (Henri, you're in copy of this again, because first time I did a Reply
>> instead of Reply to list/all. Sorry.)
>
> One of my pet hates is people who use "Reply All" because either they are
> too lazy to edit the Reply (and they top-post, too), or the list is set up
> that way.

That's a matter of opinion.  Many people consider it good manners to
specifically mention people participating in a discussion.  For
example,
https://www.freebsd.org/doc/en_US.ISO8859-1/articles/freebsd-questions/article.html#idp53204040
specifically states:

  Unless there is a good reason to do otherwise, reply to the sender
  and to FreeBSD-questions [the list].

> I really don't need my own personal copy, as well as a list copy.

That's what procmail is for.

> Oh, and people who are too lazy to trim their replies too, because
> they are encouraged to top-post.

Yes, that's in that URL too:

  Put your response in the correct place (after the text to which it
  replies). It is very difficult to read a thread of responses where
  each reply comes before the text to which it replies.

Also another thing that I still think very important:

  If the submitter did not abide by format conventions (lines too
  long, inappropriate subject line), please fix it. In the case of an
  incorrect subject line (such as âHELP!!??â), change the subject line
  to (say) âRe: Difficulties with sync PPP (was: HELP!!??)â. That way
  other people trying to follow the thread will have less difficulty
  following it.

That doesn't explicitly address the issue of change of topic within a
thread, but it should.

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

From gtaylor at tnetconsulting.net  Thu Sep  6 15:07:00 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 5 Sep 2018 23:07:00 -0600
Subject: [TUHS] RetroNet???
In-Reply-To: <CACYmRNC50hLLOSu5111R3eGCESMyCfSR9O5899Jy1NkyLhTZrQ@mail.gmail.com>
References: <f3f250f4-cffd-794c-450a-d1c3829c890e@spamtrap.tnetconsulting.net>
 <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com>
 <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net>
 <20180829183632.GD8423@mcvoy.com>
 <CAEoi9W7P-Cz8K2etu=SzAmamE=cUtmxm8wLGOHKW=9KuqqKDrQ@mail.gmail.com>
 <D83B5D0F-BC43-4A85-BEED-98F2B1EF190A@alchemistowl.org>
 <83698bdc-c636-5688-5619-27c8c4b41500@spamtrap.tnetconsulting.net>
 <CACYmRNC50hLLOSu5111R3eGCESMyCfSR9O5899Jy1NkyLhTZrQ@mail.gmail.com>
Message-ID: <55496B84-3FA8-4921-A524-A3513D611327@tnetconsulting.net>

On Sep 5, 2018, at 8:11 PM, Ed Carp <erc at pobox.com> wrote:
> I've read that Taylor UUCP fixed a bunch of issues with HDB UUCP -
> have you considered using it?

Taylor UUCP (no known relationship) is the default on every Linux distribution (including Cygwin) that I’ve used. Thus it’s the bulk of what I’ve used.

I feel like TUHS is a good place to learn about the differences. I’d be interested in anything (history, gotchas, pro tips, lore, etc., that people have to offer. #learningisfun



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

From clemc at ccc.com  Fri Sep  7 04:22:05 2018
From: clemc at ccc.com (Clem Cole)
Date: Thu, 6 Sep 2018 14:22:05 -0400
Subject: [TUHS] RetroNet???
In-Reply-To: <CACYmRNC50hLLOSu5111R3eGCESMyCfSR9O5899Jy1NkyLhTZrQ@mail.gmail.com>
References: <f3f250f4-cffd-794c-450a-d1c3829c890e@spamtrap.tnetconsulting.net>
 <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com>
 <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net>
 <20180829183632.GD8423@mcvoy.com>
 <CAEoi9W7P-Cz8K2etu=SzAmamE=cUtmxm8wLGOHKW=9KuqqKDrQ@mail.gmail.com>
 <D83B5D0F-BC43-4A85-BEED-98F2B1EF190A@alchemistowl.org>
 <83698bdc-c636-5688-5619-27c8c4b41500@spamtrap.tnetconsulting.net>
 <CACYmRNC50hLLOSu5111R3eGCESMyCfSR9O5899Jy1NkyLhTZrQ@mail.gmail.com>
Message-ID: <CAC20D2O_FraVYFV-Me322t5=Ujewuc3WoaguDMQEh9OjG2XGXQ@mail.gmail.com>

On Wed, Sep 5, 2018 at 10:12 PM Ed Carp <erc at pobox.com> wrote:

> I've read that Taylor UUCP fixed a bunch of issues with HDB UUCP -
> have you considered using it?
>
Hmmm.. the only thing it really fixed was the licensing.  HBD was part of
distributed in the 'toolkit' and as part of Svs V.  I think it was part of
PWB 3.0, as we shipped it with RTU; but we have have gotten it via the
toolkit license [I'm too lazy to look at Warren's System files to check].

HDB was the huge fix of the original version that went 'wide' with V7 and
BSD.   The primary changes were in house directories and the queues were
handled, which had huge performance impact; particularly for large sites
with an heavy UUCPnet load (a.k.a. the 'Usenet').   The other things that
was in HDB was some collected alternate protocols besides Greg Chesson's
original 'g' protocol; although those had all been distributed on the
Usenet as net.noise, so all it really did is become a packaging thing.

There were a number of UUCP clones written in those days, and PC-uucp was
popular for CP/M and later DOS systems that wanted to join the Usenet [Rick
Adams, I think had a packaged version of some of them for his non-UNIX
customers IIRC).

As to why Dave Taylor decided to write another one in thoses, you'ld have
to ask him; but in the end it replaced the V7 one in BSD.   But a lot of
effort was made to make sure Taylor UUCP was more than a functional
work-alike.   It had admin like HBD and use the same queues etc.     What I
do not remember, Mary Ann might, is if Berkeley had been running HDB from
the Toolkit on ucbvax internally, but could not have easily redistribute it
( seem to remember there were).   They funny part is that most Academics
had a toolkit license by then becsuse they wanted HDB and ksh as a minimum,
so most were running HDB; but the rules in the toolkit for academics were
different than the original base license (I've forgotten them -- I had left
academia so it did not effect me).   But it was around this time the Keith
was start to try to remove code that  was knows to have AT&T copyright
issues, when their was an alternative implementation that had BSD style
licenses (which Taylor UUCP, as did Clark's troff as I recall).

BTW Grant, Linux picked up Taylor UUCP after BSD (it was not in the
original distros and I suspect would have crashed the kernel in those days
if the site was as all loaded).
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180906/6fc62bf9/attachment.html>

From akosela at andykosela.com  Fri Sep  7 06:02:06 2018
From: akosela at andykosela.com (Andy Kosela)
Date: Thu, 06 Sep 2018 22:02:06 +0200
Subject: [TUHS] cat -v and other complaints
In-Reply-To: <CAP6exYJ2nPJpc=qFqyG1TCQidOLaxC9O=C+W8CSH3bcW_OXY-w@mail.gmail.com>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <20180831215636.-eCEx%ca6c@bitmessage.ch>
 <CAD-qYGqsq=kZKrHcqUws4mpjV9VGnpNFb31ubUOZ67yOfZMWZA@mail.gmail.com>
 <20180903180401.u4MVs%ca6c@bitmessage.ch> <20180903181133.GB81368@wopr>
 <20180903185616.ZnkRk%ca6c@bitmessage.ch>
 <CALMnNGgwaGU842g3y8aAdjrjwFPHxR4ysuddKLeKqoGJ2=LDtA@mail.gmail.com>
 <CAP6exYJTE_p8QYcLCN98kbqZaqPogenv6BTx5wVQKED7Kugiwg@mail.gmail.com>
 <CALMnNGj8gP=aPwNSTy82d33ffcU6naEZ=2==xs-N6kf-j9Dg0Q@mail.gmail.com>
 <CAP6exYJ2nPJpc=qFqyG1TCQidOLaxC9O=C+W8CSH3bcW_OXY-w@mail.gmail.com>
Message-ID: <5b9187be.JqdXbAJqb0gb8I/y%akosela@andykosela.com>

ron minnich <rminnich at gmail.com> wrote:

> On Tue, Sep 4, 2018 at 2:34 AM Andy Kosela <akosela at andykosela.com> wrote:
>
> > When Plan 9 was created in the mid-late 80s exactly those ideas
> > circulated.  Nothing comes from nothing, everything has its historical
> > context.  In the late 80s in order to "innovate" it was natural to think
> > that abandoning text terminals is a "progress".
> >
> >
> I don't get the sense, from reading this, that you have ever used Plan 9
> for serious work, or indeed done more than see or run a demo. I'm keeping
> this short because this is TUHS, not T9HS. But your characterization of
> Plan 9 is just wrong.

I understand that we are drifting a bit off-topic here, but for the sake
of all reading it, it probably would be relevant to at least offer some
more explanation of your point.  Saying 'you are wrong' is not very
informative.  I still think that you just misinterpret my words though.

One still cannot ignore the fact that Unix and Plan 9 offer two
completely different approaches to displaying text.  I think it also
would not be very productive nor it was intended to use Plan 9 without
mouse and rio(1).
--Andy


From norman at oclsc.org  Fri Sep  7 06:29:36 2018
From: norman at oclsc.org (Norman Wilson)
Date: Thu, 06 Sep 2018 16:29:36 -0400
Subject: [TUHS] cat -v and other complaints
Message-ID: <1536265780.5213.for-standards-violators@oclsc.org>

Andy Kosela:

  One still cannot ignore the fact that Unix and Plan 9 offer two
  completely different approaches to displaying text.

I admit I've never actually used Plan 9.  Can you elaborate on
the different approaches?

One difference from most of what passes for UNIX these days is
probably that the basic terminal model allows one to edit anything
on the screen, using the mouse and keyboard and a simple button-2
menu similar to that of sam.  You can edit what some program has
already printed, then pick it up and send it back as input.  You
can even edit text in the current line that hasn't been sent yet
(because you haven't hit a return yet); in effect the canonical-line
part of the tty driver is in the terminal.

But you probably don't mean that, both because it's not really
such a radical difference, and because it doesn't conflict at all
with UNIX.  In fact it originated on UNIX, five or six years before
Plan 9 was thought of: it's the model from the terminal program
in mux, the more-advanced version of the Blit/Jerq window manager
that nearly everybody used in 1127 by the time I arrived in 1984.

And I still use it every day, even on Linux (and in years past
on Solaris and IRIX and Digital UNIX and Ultrix).  The modern
version of the program to do that is called 9term.  It doesn't
work quite as well as I'd like on Linux due to changes in the
tty driver that make it hard for a program to learn right away
when tty modes are changed (in particular when echo is turned off
or on), and it does conflict with the GNU readline junk because
that turns off canonical processing, but to those of us who have
a taste for it it's still just fine.

As I say, I don't think that's the difference you mean, so please
step in and supersede me.

(And feel free to use my referring to something that is part of
the latter-day Research editions as an excuse to continue discussing
it.  I think of Plan 9 as a successor to those systems anyway, and
therefore related to UNIX heritage, at least as long as we're
comparing and contrasting the systems.)

Norman Wilson
Toronto ON


From rminnich at gmail.com  Fri Sep  7 06:49:57 2018
From: rminnich at gmail.com (ron minnich)
Date: Thu, 6 Sep 2018 13:49:57 -0700
Subject: [TUHS] cat -v and other complaints
In-Reply-To: <5b9187be.JqdXbAJqb0gb8I/y%akosela@andykosela.com>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <20180831215636.-eCEx%ca6c@bitmessage.ch>
 <CAD-qYGqsq=kZKrHcqUws4mpjV9VGnpNFb31ubUOZ67yOfZMWZA@mail.gmail.com>
 <20180903180401.u4MVs%ca6c@bitmessage.ch> <20180903181133.GB81368@wopr>
 <20180903185616.ZnkRk%ca6c@bitmessage.ch>
 <CALMnNGgwaGU842g3y8aAdjrjwFPHxR4ysuddKLeKqoGJ2=LDtA@mail.gmail.com>
 <CAP6exYJTE_p8QYcLCN98kbqZaqPogenv6BTx5wVQKED7Kugiwg@mail.gmail.com>
 <CALMnNGj8gP=aPwNSTy82d33ffcU6naEZ=2==xs-N6kf-j9Dg0Q@mail.gmail.com>
 <CAP6exYJ2nPJpc=qFqyG1TCQidOLaxC9O=C+W8CSH3bcW_OXY-w@mail.gmail.com>
 <5b9187be.JqdXbAJqb0gb8I/y%akosela@andykosela.com>
Message-ID: <CAP6exYJVvCZP5_psdLQWN+pSN4i5jyCU65QqBbH_G06f3dhRkA@mail.gmail.com>

On Thu, Sep 6, 2018 at 1:02 PM Andy Kosela <akosela at andykosela.com> wrote:

> One still cannot ignore the fact that Unix and Plan 9 offer two
> completely different approaches to displaying text.  I think it also
> would not be very productive nor it was intended to use Plan 9 without
> mouse and rio(1).
>

I spent four years using Plan 9 on the Blue Gene supercomputer (I led the
team that did the port). I also spent years using it on embedded systems
with no windowing system at all.

What you're saying does not accord with anything I experienced with Plan 9
over a dozen year span. I also don't believe your claims are driven by
experience using Plan 9; am I missing something? What is the basis of your
statement?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180906/df76b800/attachment.html>

From akosela at andykosela.com  Fri Sep  7 07:55:52 2018
From: akosela at andykosela.com (Andy Kosela)
Date: Thu, 06 Sep 2018 23:55:52 +0200
Subject: [TUHS] cat -v and other complaints
In-Reply-To: <CAP6exYJVvCZP5_psdLQWN+pSN4i5jyCU65QqBbH_G06f3dhRkA@mail.gmail.com>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <20180831215636.-eCEx%ca6c@bitmessage.ch>
 <CAD-qYGqsq=kZKrHcqUws4mpjV9VGnpNFb31ubUOZ67yOfZMWZA@mail.gmail.com>
 <20180903180401.u4MVs%ca6c@bitmessage.ch> <20180903181133.GB81368@wopr>
 <20180903185616.ZnkRk%ca6c@bitmessage.ch>
 <CALMnNGgwaGU842g3y8aAdjrjwFPHxR4ysuddKLeKqoGJ2=LDtA@mail.gmail.com>
 <CAP6exYJTE_p8QYcLCN98kbqZaqPogenv6BTx5wVQKED7Kugiwg@mail.gmail.com>
 <CALMnNGj8gP=aPwNSTy82d33ffcU6naEZ=2==xs-N6kf-j9Dg0Q@mail.gmail.com>
 <CAP6exYJ2nPJpc=qFqyG1TCQidOLaxC9O=C+W8CSH3bcW_OXY-w@mail.gmail.com>
 <5b9187be.JqdXbAJqb0gb8I/y%akosela@andykosela.com>
 <CAP6exYJVvCZP5_psdLQWN+pSN4i5jyCU65QqBbH_G06f3dhRkA@mail.gmail.com>
Message-ID: <5b91a268.lXqMJkXVvoGUv0XA%akosela@andykosela.com>

ron minnich <rminnich at gmail.com> wrote:

> On Thu, Sep 6, 2018 at 1:02 PM Andy Kosela <akosela at andykosela.com> wrote:
>
> > One still cannot ignore the fact that Unix and Plan 9 offer two
> > completely different approaches to displaying text.  I think it also
> > would not be very productive nor it was intended to use Plan 9 without
> > mouse and rio(1).
> >
>
> I spent four years using Plan 9 on the Blue Gene supercomputer (I led the
> team that did the port). I also spent years using it on embedded systems
> with no windowing system at all.
>
> What you're saying does not accord with anything I experienced with Plan 9
> over a dozen year span. I also don't believe your claims are driven by
> experience using Plan 9; am I missing something? What is the basis of your
> statement?

Just from personal experience running Plan 9.  Well, you can't tell me
this system was designed with the idea of running it using text terminal
and no mouse.  There is also no cursor addressing, no curses.  Like I
written before it was born in the different era -- they tried to not
build it on the idea of character based TTY, but rather incorporate
graphical element into it.

If it is possible to be fully productive in Plan 9 using just VGA text
mode (720x400) and not any of the bitmap modes, with Unix like cursor
addressing and with no rio(1) and no mouse then it's something I never
really explored.

--Andy


From akosela at andykosela.com  Fri Sep  7 08:16:21 2018
From: akosela at andykosela.com (Andy Kosela)
Date: Fri, 07 Sep 2018 00:16:21 +0200
Subject: [TUHS] cat -v and other complaints
In-Reply-To: <1536265780.5213.for-standards-violators@oclsc.org>
References: <1536265780.5213.for-standards-violators@oclsc.org>
Message-ID: <5b91a735.NY0ZEcIRVoU4KsK1%akosela@andykosela.com>

Norman Wilson <norman at oclsc.org> wrote:

> Andy Kosela:
>
>   One still cannot ignore the fact that Unix and Plan 9 offer two
>   completely different approaches to displaying text.
>
> I admit I've never actually used Plan 9.  Can you elaborate on
> the different approaches?
>
> One difference from most of what passes for UNIX these days is
> probably that the basic terminal model allows one to edit anything
> on the screen, using the mouse and keyboard and a simple button-2
> menu similar to that of sam.  You can edit what some program has
> already printed, then pick it up and send it back as input.  You
> can even edit text in the current line that hasn't been sent yet
> (because you haven't hit a return yet); in effect the canonical-line
> part of the tty driver is in the terminal.
>
> But you probably don't mean that, both because it's not really
> such a radical difference, and because it doesn't conflict at all
> with UNIX.  In fact it originated on UNIX, five or six years before
> Plan 9 was thought of: it's the model from the terminal program
> in mux, the more-advanced version of the Blit/Jerq window manager
> that nearly everybody used in 1127 by the time I arrived in 1984.
>
> And I still use it every day, even on Linux (and in years past
> on Solaris and IRIX and Digital UNIX and Ultrix).  The modern
> version of the program to do that is called 9term.  It doesn't
> work quite as well as I'd like on Linux due to changes in the
> tty driver that make it hard for a program to learn right away
> when tty modes are changed (in particular when echo is turned off
> or on), and it does conflict with the GNU readline junk because
> that turns off canonical processing, but to those of us who have
> a taste for it it's still just fine.
>
> As I say, I don't think that's the difference you mean, so please
> step in and supersede me.

In short, character based approach vs. bitmap based.  Yes, in Unix you
also has a windowing system which is bitmap based, but IMHO this was
always an add-on and not an essential part of the system.  Plan 9 on the
other hand seems to be designed with more of a graphical based approach
than the old school character based approach.

--Andy


From pnr at planet.nl  Fri Sep  7 09:56:35 2018
From: pnr at planet.nl (Paul Ruizendaal)
Date: Fri, 7 Sep 2018 01:56:35 +0200
Subject: [TUHS] plan9 first edition
Message-ID: <2BEA2847-0FFE-4835-A59C-098E62DB5C0F@planet.nl>

Somewhat off topic, for which apologies beforehand.

I’m looking for source code of Plan9’s first edition. A quick search on Google came up dry.

Would that source be publicly available? Or were the licensing restrictions such that it only exists in non-public archives?



From crossd at gmail.com  Fri Sep  7 11:59:05 2018
From: crossd at gmail.com (Dan Cross)
Date: Thu, 6 Sep 2018 21:59:05 -0400
Subject: [TUHS] cat -v and other complaints
In-Reply-To: <5b91a268.lXqMJkXVvoGUv0XA%akosela@andykosela.com>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <20180831215636.-eCEx%ca6c@bitmessage.ch>
 <CAD-qYGqsq=kZKrHcqUws4mpjV9VGnpNFb31ubUOZ67yOfZMWZA@mail.gmail.com>
 <20180903180401.u4MVs%ca6c@bitmessage.ch> <20180903181133.GB81368@wopr>
 <20180903185616.ZnkRk%ca6c@bitmessage.ch>
 <CALMnNGgwaGU842g3y8aAdjrjwFPHxR4ysuddKLeKqoGJ2=LDtA@mail.gmail.com>
 <CAP6exYJTE_p8QYcLCN98kbqZaqPogenv6BTx5wVQKED7Kugiwg@mail.gmail.com>
 <CALMnNGj8gP=aPwNSTy82d33ffcU6naEZ=2==xs-N6kf-j9Dg0Q@mail.gmail.com>
 <CAP6exYJ2nPJpc=qFqyG1TCQidOLaxC9O=C+W8CSH3bcW_OXY-w@mail.gmail.com>
 <5b9187be.JqdXbAJqb0gb8I/y%akosela@andykosela.com>
 <CAP6exYJVvCZP5_psdLQWN+pSN4i5jyCU65QqBbH_G06f3dhRkA@mail.gmail.com>
 <5b91a268.lXqMJkXVvoGUv0XA%akosela@andykosela.com>
Message-ID: <CAEoi9W5BBxOsYvQ5RAiJWHy0CKRTxeUPOGFCDfs4zKkNvKmc6g@mail.gmail.com>

On Thu, Sep 6, 2018 at 5:56 PM Andy Kosela <akosela at andykosela.com> wrote:

> [snip]  Well, you can't tell me
> this system was designed with the idea of running it using text terminal
> and no mouse.


I won't, because it wouldn't be true. You are correct that it was always
intended to be used with a graphical console. But you keep talking about
"text terminals" and therein lies the confusion: our text terminals haven't
been purely "text" since the teletype days. Even green-screen serial
terminals have graphics adapters to draw characters on the screen.

There is also no cursor addressing, no curses.


Actually, there *is* a graphical program to emulate a vt-series terminal,
but pretty much no one uses it. So while strictly speaking this is
incorrect, it is essentially correct for all intents and purposes.

But it begs the question: why would you *want* to use that sort of
interface? That was appropriate for an HP or DEC terminal connected via a
low-bandwidth link (e.g., serial) or a shared host computer. Once we moved
onto personal workstation-class machines with graphics adapters, why
continue with that paradigm? Your framebuffer doesn't care that,
'\033[H\033[J' means "move the cursor to the upper-left corner and clear
the current line to the end of the screen", so why should your terminal
emulator? For that matter, if logged into the text-only console on a Linux
or FreeBSD machine, why does running `stty` say your graphics adapter has a
BAUD rate? The plan9 authors decided to leave such historical debris behind.


> Like I
> written before it was born in the different era -- they tried to not
> build it on the idea of character based TTY, but rather incorporate
> graphical element into it.
>

Correct. I wasn't there, but the observation surely must have been in part
that the user was *already* using a graphical environment, just not to very
good effect.

If it is possible to be fully productive in Plan 9 using just VGA text
> mode (720x400) and not any of the bitmap modes, with Unix like cursor
> addressing and with no rio(1) and no mouse then it's something I never
> really explored.
>

You could skip `rio` and just run `vt` on the console. I doubt the
emulation is very good and it wouldn't be an acceptable substitute for
serious use. `vt` was really intended as a stop-gap for accessing older
systems; the plan9 model was different, and instead of accessing remote
resources, the idea was that those resources would be shared with the
(plan9) network and imported locally for manipulation. That is, I wouldn't
`ssh` into some machine to make use of something on it; instead I'd use
`import` to bring those resources into my namespace locally and I'd
manipulate them there.

I did a writeup of this a while back:
http://pub.gajendra.net/2016/05/plan9part1

I should probably do parts 2 and 3....

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180906/788b485b/attachment.html>

From akosela at andykosela.com  Fri Sep  7 14:40:37 2018
From: akosela at andykosela.com (Andy Kosela)
Date: Fri, 07 Sep 2018 06:40:37 +0200
Subject: [TUHS] cat -v and other complaints
In-Reply-To: <CAEoi9W5BBxOsYvQ5RAiJWHy0CKRTxeUPOGFCDfs4zKkNvKmc6g@mail.gmail.com>
References: <CAC20D2ODDO+OTUf8wA4bXu9M5M0kswJqT97qRAnV9EOzMGKRvQ@mail.gmail.com>
 <20180831215636.-eCEx%ca6c@bitmessage.ch>
 <CAD-qYGqsq=kZKrHcqUws4mpjV9VGnpNFb31ubUOZ67yOfZMWZA@mail.gmail.com>
 <20180903180401.u4MVs%ca6c@bitmessage.ch> <20180903181133.GB81368@wopr>
 <20180903185616.ZnkRk%ca6c@bitmessage.ch>
 <CALMnNGgwaGU842g3y8aAdjrjwFPHxR4ysuddKLeKqoGJ2=LDtA@mail.gmail.com>
 <CAP6exYJTE_p8QYcLCN98kbqZaqPogenv6BTx5wVQKED7Kugiwg@mail.gmail.com>
 <CALMnNGj8gP=aPwNSTy82d33ffcU6naEZ=2==xs-N6kf-j9Dg0Q@mail.gmail.com>
 <CAP6exYJ2nPJpc=qFqyG1TCQidOLaxC9O=C+W8CSH3bcW_OXY-w@mail.gmail.com>
 <5b9187be.JqdXbAJqb0gb8I/y%akosela@andykosela.com>
 <CAP6exYJVvCZP5_psdLQWN+pSN4i5jyCU65QqBbH_G06f3dhRkA@mail.gmail.com>
 <5b91a268.lXqMJkXVvoGUv0XA%akosela@andykosela.com>
 <CAEoi9W5BBxOsYvQ5RAiJWHy0CKRTxeUPOGFCDfs4zKkNvKmc6g@mail.gmail.com>
Message-ID: <5b920145.7aDYuhN/FRnTadNW%akosela@andykosela.com>

Dan Cross <crossd at gmail.com> wrote:

> On Thu, Sep 6, 2018 at 5:56 PM Andy Kosela <akosela at andykosela.com> wrote:
>
> > [snip]  Well, you can't tell me
> > this system was designed with the idea of running it using text terminal
> > and no mouse.
>
>
> I won't, because it wouldn't be true. You are correct that it was always
> intended to be used with a graphical console. But you keep talking about
> "text terminals" and therein lies the confusion: our text terminals haven't
> been purely "text" since the teletype days. Even green-screen serial
> terminals have graphics adapters to draw characters on the screen.

I think I was clear enough and meant 'text terminal' as a physical glass
TTY e.g.  vt220 from DEC, but understand now why someone might have
interpreted it differently.

There is also a big difference between a text mode (character mode)
where what we see on the screen is addressed in terms of characters
rather than individual pixels and a bitmap mode (graphics mode) also
known as APA (all points addressable) mode where every pixel is
addressable[1].

Inherent in the text mode is also the concept of monospace fonts which
some people prefer to this day.

>
> There is also no cursor addressing, no curses.
>
>
> Actually, there *is* a graphical program to emulate a vt-series terminal,
> but pretty much no one uses it. So while strictly speaking this is
> incorrect, it is essentially correct for all intents and purposes.
>
> But it begs the question: why would you *want* to use that sort of
> interface? That was appropriate for an HP or DEC terminal connected via a
> low-bandwidth link (e.g., serial) or a shared host computer. Once we moved
> onto personal workstation-class machines with graphics adapters, why
> continue with that paradigm? 

Why there are still people running C64, Atari XL/XE or Amiga?  Even
more, some of them think those computers are still better than the
machines of today...

In the Unix community there are some that still prefer to use old CRT
terminals or MS-DOS era PC monitors using only text mode.  Why I can't
speak for all of them, I can speak for myself and explain my motivation
behind it.  I instantly fell in love with a text mode when I first
started computing on Commodore and Atari machines in the 80s and then
naturally advanced to a text mode on MS-DOS era PC's. 

I never really ran Linux or *BSDs with X Window System -- always
preferred pure text mode.  It is aesthetically pleasing and most elegant
to converse with a machine using only text, and a text mode as displayed
on cathode ray tube (CRT) is the most beautiful representation of such
an idea. 

Although these days I'm using sometimes MacBook (who doesn't?)
which is using of course the bitmap mode, I still prefer to experience
the full text mode on a real CRT and actually collect them as they are
becoming more and more rare.

[1] https://en.wikipedia.org/wiki/Text_mode


--Andy


From web at loomcom.com  Sat Sep  8 05:50:46 2018
From: web at loomcom.com (Seth Morabito)
Date: Fri, 07 Sep 2018 12:50:46 -0700
Subject: [TUHS] Public System V UNIX Release 3 (3B2/400) Access
Message-ID: <1536349846.1862327.1500626664.39CC3CE7@webmail.messagingengine.com>

Hello all,

I'm beta-testing a service I've set up to allow public access to a network of computers running System V UNIX Release 3.2. This is only tangentially related to RetroNet, and we hope to peer with them once RetroNet has UUCP peering going!

The network consists of three emulated 3B2/400s linked by UUCP, and connected to the Internet through a gateway system. E-mail (UUCP, UUCP-to-SMTP, and SMTP-to-UUCP) works in and out of the network.

There is a small private Net News setup running BNews for that true historic flair. All machines have access to the "retronet.*" news hierarchy. (There is no public Usenet access, sorry!)

If you're interested in reliving some UNIX history, consider signing up for an account. You'll be randomly assigned a home host in the network.

Account signup form is here:

https://loomcom.net/

Access is via SSH-to-Telnet gateway, by connecting to:

        $ ssh access at loomcom.net

(No password is needed for the SSH gateway, it is a captive portal)

-Seth
-- 
  Seth Morabito
  Poulsbo, WA
  web at loomcom.com


From doug at cs.dartmouth.edu  Sat Sep  8 22:02:24 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sat, 08 Sep 2018 08:02:24 -0400
Subject: [TUHS] [TUHS} cat -v and other complaints
Message-ID: <201809081202.w88C2OCj038136@tahoe.cs.Dartmouth.EDU>

> you can't tell me
> this system was designed with the idea of running it using text terminal
> and no mouse.  There is also no cursor addressing, no curses.

The well named Curses and the associated vi were an ugly outgrowth
of glass screens--an outgrowth many of us in the Unix lab never
adopted. That branch of evolution was unrelated to the Blit branch that
essentially preserved the old TTY interface, except that one could have
multiple terminals on screen and a mouse was available to give mechanical
help for manual cut/paste/edit activities. Plan 9 terminal-handling
smoothly continued that evolutionary branch.

Mouse support could have been used to take off in a radical direction,
but it wasn't. To my mind, the primary innovation in Plan 9 was not
terminal support, nor everything-is-a-file. Rather it was an advance in
what Vyssotsky called "distributable computing", where components can
collaborate in a uniform way, no matter where they are. The key was the 9P
protocol that unpacked the notion of file type--a unifying principle
that brought simplicity and generality to a diversity of particulars.


From will.senn at gmail.com  Sat Sep  8 23:36:56 2018
From: will.senn at gmail.com (Will Senn)
Date: Sat, 8 Sep 2018 08:36:56 -0500
Subject: [TUHS] [TUHS} cat -v and other complaints
In-Reply-To: <201809081202.w88C2OCj038136@tahoe.cs.Dartmouth.EDU>
References: <201809081202.w88C2OCj038136@tahoe.cs.Dartmouth.EDU>
Message-ID: <3054F86A-0FDA-4266-B8B8-EE53869F3700@gmail.com>

Doug et al.,

I’m interested in learning about this curses vs blit business. Is there a writeup or book chapter out there that covers this in any detail?

Thanks,

Will

Sent from my iPhone

On Sep 8, 2018, at 7:02 AM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:

>> you can't tell me
>> this system was designed with the idea of running it using text terminal
>> and no mouse.  There is also no cursor addressing, no curses.
> 
> The well named Curses and the associated vi were an ugly outgrowth
> of glass screens--an outgrowth many of us in the Unix lab never
> adopted. That branch of evolution was unrelated to the Blit branch that
> essentially preserved the old TTY interface, except that one could have
> multiple terminals on screen and a mouse was available to give mechanical
> help for manual cut/paste/edit activities. Plan 9 terminal-handling
> smoothly continued that evolutionary branch.
> 
> Mouse support could have been used to take off in a radical direction,
> but it wasn't. To my mind, the primary innovation in Plan 9 was not
> terminal support, nor everything-is-a-file. Rather it was an advance in
> what Vyssotsky called "distributable computing", where components can
> collaborate in a uniform way, no matter where they are. The key was the 9P
> protocol that unpacked the notion of file type--a unifying principle
> that brought simplicity and generality to a diversity of particulars.


From ralph at inputplus.co.uk  Sun Sep  9 00:22:12 2018
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Sat, 08 Sep 2018 15:22:12 +0100
Subject: [TUHS] cat -v and other complaints
In-Reply-To: <3054F86A-0FDA-4266-B8B8-EE53869F3700@gmail.com>
References: <201809081202.w88C2OCj038136@tahoe.cs.Dartmouth.EDU>
 <3054F86A-0FDA-4266-B8B8-EE53869F3700@gmail.com>
Message-ID: <20180908142212.167B1218D6@orac.inputplus.co.uk>

Hi Will,

> I'm interested in learning about this curses vs blit business. Is
> there a writeup or book chapter out there that covers this in any
> detail?

https://en.wikipedia.org/wiki/Blit_(computer_terminal) is a jumping-off
point.  And I suppose the same goes for curses(3):
https://en.wikipedia.org/wiki/Curses_(programming_library)

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From krewat at kilonet.net  Sun Sep  9 02:10:00 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Sat, 8 Sep 2018 12:10:00 -0400
Subject: [TUHS] cat -v and other complaints
In-Reply-To: <20180908142212.167B1218D6@orac.inputplus.co.uk>
References: <201809081202.w88C2OCj038136@tahoe.cs.Dartmouth.EDU>
 <3054F86A-0FDA-4266-B8B8-EE53869F3700@gmail.com>
 <20180908142212.167B1218D6@orac.inputplus.co.uk>
Message-ID: <f07bf5a5-b39d-90a4-5edf-2af87c25c0d5@kilonet.net>

On 9/8/2018 10:22 AM, Ralph Corderoy wrote:
>
>> I'm interested in learning about this curses vs blit business. Is
>> there a writeup or book chapter out there that covers this in any
>> detail?
> https://en.wikipedia.org/wiki/Blit_(computer_terminal) is a jumping-off
> point.  And I suppose the same goes for curses(3):
> https://en.wikipedia.org/wiki/Curses_(programming_library)
>

In my opinion (as retarded as I can be sometimes), this is an 
apples-and-oranges comparison.

Blit is a completely new terminal type, with specific operating 
system/software support.

Curses is a way to control various already-existing terminal types. DEC 
terminals, Hazeltine, etc. A recent termcap on my Solaris server has 472 
entries. The wide-ranging support was quite important.

Many people/institutions had a variety of terminals already, usually 
recycled from previous systems. I remember one instance when I was 17 
years old working at BOCES/LIRICS on Long Island, and an office worker 
in a local high-school looked at me like a deer in the headlights when 
they could no longer use their current-loop terminal and acoustic 
coupler. Sorry, the leased-line mux in the other room can't do that. It 
has to be RS232. We gladly gave them a new LA36. Which invoked another 
set of "how do I..." questions. Ah, progress. (This was to support 
TOPS-10 on DEC KS10's, but the same thing happened many times over my 
early career. People just didn't want to give up what they already had)

ak




From dave at horsfall.org  Sun Sep  9 09:02:00 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 9 Sep 2018 09:02:00 +1000 (EST)
Subject: [TUHS] Happy birthday, Dennis Ritchie
Message-ID: <alpine.BSF.2.21.9999.1809090852060.28912@aneurin.horsfall.org>

Co-inventor of Unix, and sadly lost to us in 2011, he was born on this day 
in 1941.

Thank you Dennis (and of course Ken), for that wonderful OS that we still 
use to this day, and imitated by others.

-- Dave


From Caipenghui_c at 163.com  Sun Sep  9 19:02:24 2018
From: Caipenghui_c at 163.com (Caipenghui)
Date: Sun, 09 Sep 2018 09:02:24 +0000
Subject: [TUHS] Happy birthday Dennis Ritchie
Message-ID: <6003545F-2925-49B0-8829-67E330FD466C@163.com>

Today, a great scientist Dennis Ritchie was born, he did too much for humanity! I can't describe him in words, Dennis wishes you a happy birthday!
               
                                              Caipenghui



From dave at horsfall.org  Mon Sep 10 16:35:56 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 10 Sep 2018 16:35:56 +1000 (EST)
Subject: [TUHS]
 =?utf-8?q?=5BCOFF=5D__RetroNet=E2=80=A6_Virtual_is_cheap?=
 =?utf-8?q?=2E?=
In-Reply-To: <20180901222055.GA71355@server.rulingia.com>
References: <f3f250f4-cffd-794c-450a-d1c3829c890e@spamtrap.tnetconsulting.net>
 <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com>
 <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net>
 <1d8c0539-8b43-9954-d8a7-db4dcc22b27d@texoma.net>
 <e0aa9929-d1fc-43fb-8eae-1c2bad859244.maildroid@localhost>
 <ff99cbb7-1069-9a08-2e41-d1781fe91125@texoma.net>
 <0b739af0-da9e-6bdb-fe17-6f2dda837de5@spamtrap.tnetconsulting.net>
 <20180901222055.GA71355@server.rulingia.com>
Message-ID: <alpine.BSF.2.21.9999.1809101620020.28912@aneurin.horsfall.org>

On Sun, 2 Sep 2018, Peter Jeremy wrote:

> [2] This is good enough because Australian ISPs don't believe in IPv6

If I go to a site that reports my IP address, I get IPv6 (I have a static 
IPv4 address), which appears to be the default used by my router (a 
Fastnet 5355 or something, which T$ appear to be unloading on us).

I tried asking T$ for a static IPv6 range, but was unable to find anyone 
who even knew what I was talking about.

-- Dave


From jacob.ritorto at gmail.com  Tue Sep 18 11:27:12 2018
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Mon, 17 Sep 2018 21:27:12 -0400
Subject: [TUHS] unix svr1 install docs
Message-ID: <CAHYQbfD8Kj1m_b6b0b8zwCnU2sQPc39+s+fE++YsfX09xh0CJA@mail.gmail.com>

Hi,
  I'm hoping to run System V Release 1 on my pdp11/45, provided I can find
a controller that'll emulate one of the few disks it supports.  I've been
looking around trying to find the installation manual to no avail.  The
programmers manual, user's manual and error manual are all readily
available, but nothing about install aside from some anecdotal lines from a
simh install.  Would anyone have a hint on where to find it or perhaps a
real copy to lend?  Happy to scan and mail back if so.

thx
jake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180917/e6a58c2c/attachment.html>

From wlc at jctaylor.com  Tue Sep 18 12:39:20 2018
From: wlc at jctaylor.com (William Corcoran)
Date: Tue, 18 Sep 2018 02:39:20 +0000
Subject: [TUHS] unix svr1 install docs
In-Reply-To: <CAHYQbfD8Kj1m_b6b0b8zwCnU2sQPc39+s+fE++YsfX09xh0CJA@mail.gmail.com>
References: <CAHYQbfD8Kj1m_b6b0b8zwCnU2sQPc39+s+fE++YsfX09xh0CJA@mail.gmail.com>
Message-ID: <E9F155D3-9B00-481F-968A-F3400407362C@jctaylor.com>

Hello Jacob, 

Below, please find the installation details.  This is from the TUHS archive (Papenhoff Distribution).  

SVR1 is an incredibly stable port.   I have an AWS cloud instance running SVR1 and the last reboot was in May.  
Random832 fixed a defect with flsbuf.c for me.  This corrected an issue with Standard Error.  If you want it, let me know.   

Truly, 

Bill Corcoran    



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180918/27fe0e44/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT00001.txt
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180918/27fe0e44/attachment.txt>

From wlc at jctaylor.com  Tue Sep 18 13:39:47 2018
From: wlc at jctaylor.com (William Corcoran)
Date: Tue, 18 Sep 2018 03:39:47 +0000
Subject: [TUHS] unix svr1 install docs
In-Reply-To: <E9F155D3-9B00-481F-968A-F3400407362C@jctaylor.com>
References: <CAHYQbfD8Kj1m_b6b0b8zwCnU2sQPc39+s+fE++YsfX09xh0CJA@mail.gmail.com>,
 <E9F155D3-9B00-481F-968A-F3400407362C@jctaylor.com>
Message-ID: <2AA7374C-5E79-430F-BDAC-C70A87BDDFFD@jctaylor.com>

Hello Jacob, 

Strike my earlier remarks about the source location.  It is on github.  

Bill Corcoran. 

> On Sep 17, 2018, at 10:56 PM, William Corcoran <wlc at jctaylor.com> wrote:
> 
> Hello Jacob, 
> 
> Below, please find the installation details.  This is from the TUHS archive (Papenhoff Distribution).  
> 
> SVR1 is an incredibly stable port.   I have an AWS cloud instance running SVR1 and the last reboot was in May.  
> Random832 fixed a defect with flsbuf.c for me.  This corrected an issue with Standard Error.  If you want it, let me know.   
> 
> Truly, 
> 
> Bill Corcoran    
> 
> 
> 
> <UNIX System V Release 1 on PDP-11.html>
> 
> 
> 
> 
> 
> 
> 
> On Sep 17, 2018, at 9:27 PM, Jacob Ritorto <jacob.ritorto at gmail.com> wrote:
> 
> Hi,
>  I'm hoping to run System V Release 1 on my pdp11/45, provided I can find a controller that'll emulate one of the few disks it supports.  I've been looking around trying to find the installation manual to no avail.  The programmers manual, user's manual and error manual are all readily available, but nothing about install aside from some anecdotal lines from a simh install.  Would anyone have a hint on where to find it or perhaps a real copy to lend?  Happy to scan and mail back if so.
> 
> thx
> jake
> 


From aap at papnet.eu  Tue Sep 18 15:24:12 2018
From: aap at papnet.eu (Angelo Papenhoff)
Date: Tue, 18 Sep 2018 07:24:12 +0200
Subject: [TUHS] unix svr1 install docs
In-Reply-To: <CAHYQbfD8Kj1m_b6b0b8zwCnU2sQPc39+s+fE++YsfX09xh0CJA@mail.gmail.com>
References: <CAHYQbfD8Kj1m_b6b0b8zwCnU2sQPc39+s+fE++YsfX09xh0CJA@mail.gmail.com>
Message-ID: <20180918052412.GA82105@indra.papnet.eu>

On 17/09/18, Jacob Ritorto wrote:
> Hi,
>   I'm hoping to run System V Release 1 on my pdp11/45, provided I can find
> a controller that'll emulate one of the few disks it supports.  I've been
> looking around trying to find the installation manual to no avail.  The
> programmers manual, user's manual and error manual are all readily
> available, but nothing about install aside from some anecdotal lines from a
> simh install.  Would anyone have a hint on where to find it or perhaps a
> real copy to lend?  Happy to scan and mail back if so.

My guide was already linked, but here again from me personally:
http://a.papnet.eu/UNIX/sysV_pdp11/Installation
Hope it helps.
There's also some other guides there.

aap


From jacob.ritorto at gmail.com  Thu Sep 20 05:15:11 2018
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Wed, 19 Sep 2018 15:15:11 -0400
Subject: [TUHS] unix svr1 install docs
In-Reply-To: <20180918052412.GA82105@indra.papnet.eu>
References: <CAHYQbfD8Kj1m_b6b0b8zwCnU2sQPc39+s+fE++YsfX09xh0CJA@mail.gmail.com>
 <20180918052412.GA82105@indra.papnet.eu>
Message-ID: <CAHYQbfANPb827fEzs-j2x1BxOndNDhiOaEUDLNV368uzYQLznA@mail.gmail.com>

Cool, Angelo, thank you - your writeup was the only hint I'd found and I
did manage to follow along and get it to run in the emulator.  Was there a
source you referred to in figuring out how to do what you did?  I imagine
there's an original AT&T doc out there somewhere that'd describe the whole
install process for real iron.


thx
jake

On Tue, Sep 18, 2018 at 1:32 AM Angelo Papenhoff <aap at papnet.eu> wrote:

> On 17/09/18, Jacob Ritorto wrote:
> > Hi,
> >   I'm hoping to run System V Release 1 on my pdp11/45, provided I can
> find
> > a controller that'll emulate one of the few disks it supports.  I've been
> > looking around trying to find the installation manual to no avail.  The
> > programmers manual, user's manual and error manual are all readily
> > available, but nothing about install aside from some anecdotal lines
> from a
> > simh install.  Would anyone have a hint on where to find it or perhaps a
> > real copy to lend?  Happy to scan and mail back if so.
>
> My guide was already linked, but here again from me personally:
> http://a.papnet.eu/UNIX/sysV_pdp11/Installation
> Hope it helps.
> There's also some other guides there.
>
> aap
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180919/833b3f1a/attachment.html>

From aap at papnet.eu  Thu Sep 20 06:03:36 2018
From: aap at papnet.eu (Angelo Papenhoff)
Date: Wed, 19 Sep 2018 22:03:36 +0200
Subject: [TUHS] unix svr1 install docs
In-Reply-To: <CAHYQbfANPb827fEzs-j2x1BxOndNDhiOaEUDLNV368uzYQLznA@mail.gmail.com>
References: <CAHYQbfD8Kj1m_b6b0b8zwCnU2sQPc39+s+fE++YsfX09xh0CJA@mail.gmail.com>
 <20180918052412.GA82105@indra.papnet.eu>
 <CAHYQbfANPb827fEzs-j2x1BxOndNDhiOaEUDLNV368uzYQLznA@mail.gmail.com>
Message-ID: <20180919200335.GA21575@indra.papnet.eu>

On 19/09/18, Jacob Ritorto wrote:
> Cool, Angelo, thank you - your writeup was the only hint I'd found and I
> did manage to follow along and get it to run in the emulator.  Was there a
> source you referred to in figuring out how to do what you did?  I imagine
> there's an original AT&T doc out there somewhere that'd describe the whole
> install process for real iron.

I think I just did mostly the same as I did for installing System III,
which comes with documentation. It's really simple, just follow the
prompts to install the base system and then extract the extra cpio
archives.

BTW, if anyone has SysVR1 for VAX, I'd like to add this to my site as
well.

aap


From don at DonHopkins.com  Mon Sep 24 04:37:01 2018
From: don at DonHopkins.com (Don Hopkins)
Date: Sun, 23 Sep 2018 20:37:01 +0200
Subject: [TUHS] SPARC is CRAPS spelled backwards.
In-Reply-To: <mailman.98.1535822297.3725.tuhs@minnie.tuhs.org>
References: <mailman.98.1535822297.3725.tuhs@minnie.tuhs.org>
Message-ID: <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com>

Its register windows have spilled out into the SCRAP heap of history.
But to its credit, the SPARCSTATION represents PANTISOCRACY with NO RACIST PAST. 
It ROASTS CATNIP for SATANIC SPORT with no PARTISAN COST. 
It can create a CAT SOPRANIST with a CASTRATO SNIP.

-Don

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

From a.phillip.garcia at gmail.com  Mon Sep 24 05:49:28 2018
From: a.phillip.garcia at gmail.com (A. P. Garcia)
Date: Sun, 23 Sep 2018 15:49:28 -0400
Subject: [TUHS] SPARC is CRAPS spelled backwards.
In-Reply-To: <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com>
References: <mailman.98.1535822297.3725.tuhs@minnie.tuhs.org>
 <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com>
Message-ID: <CAFCBnZufqk1SmOVdWLK19a0oQ1FjFe7ebDDa+T54yrNo=19eDw@mail.gmail.com>

On Sun, Sep 23, 2018, 2:37 PM Don Hopkins <don at donhopkins.com> wrote:

> Its register windows have spilled out into the SCRAP heap of history.
> But to its credit, the SPARCSTATION represents PANTISOCRACY with NO RACIST
> PAST.
> It ROASTS CATNIP for SATANIC SPORT with no PARTISAN COST.
> It can create a CAT SOPRANIST with a CASTRATO SNIP.
>
In trying to steer this word salad towards some semblance of meaningful
discussion, is SPARC dead? Practically, yes, I would say so. Or at least it
seems to be heading in that direction. Is RISC dead? Not at all. ARM is
doing quite well, and the old "CISC vs RISC" thing seems to be a non-issue
now, as even the current x86 processors have adopted many design features
that originated in RISC research.

The saddest thing about the death of SPARC, in my opinion, is that it
likely also means the death of the most advanced OS with "true" UNIX roots.
CDDL was ostensibly chosen to prevent Linux from cannibalizing the best
parts of Solaris. But it only seems to have slowed that down.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180923/f33d89b9/attachment.html>

From paul.winalski at gmail.com  Mon Sep 24 07:17:35 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Sun, 23 Sep 2018 17:17:35 -0400
Subject: [TUHS] SPARC is CRAPS spelled backwards.
In-Reply-To: <CAFCBnZufqk1SmOVdWLK19a0oQ1FjFe7ebDDa+T54yrNo=19eDw@mail.gmail.com>
References: <mailman.98.1535822297.3725.tuhs@minnie.tuhs.org>
 <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com>
 <CAFCBnZufqk1SmOVdWLK19a0oQ1FjFe7ebDDa+T54yrNo=19eDw@mail.gmail.com>
Message-ID: <CABH=_VR1KrWbN2o7_+RiEOBXmkGsGsKYjMqO4V-TD8Ado+3eTw@mail.gmail.com>

On 9/23/18, A. P. Garcia <a.phillip.garcia at gmail.com> wrote:
>
> In trying to steer this word salad towards some semblance of meaningful
> discussion, is SPARC dead? Practically, yes, I would say so. Or at least it
> seems to be heading in that direction. Is RISC dead? Not at all. ARM is
> doing quite well, and the old "CISC vs RISC" thing seems to be a non-issue
> now, as even the current x86 processors have adopted many design features
> that originated in RISC research.

In general, a CISC instruction set encoding can express the same
algorithm more compactly than a RISC instruction set.  Once CISC
technology solved the instruction pipelining and decoding problem, it
gained an advantage over RISC architectures such as Alpha because the
instruction set stream was less verbose.  Modern x86 designs have a
bit of logic stuck in one corner that translates the x86 instruction
stream into a string of RISC-style micro-operations.  The cores
execute the micro-ops.  Micro-op sequences can be cached, so the
translation is done only once for loops.  The result is, as it were,
the best of both worlds--the compactness of a CISC instruction stream
and the simpler and faster circuitry of RISC.

-Paul W.


From dot at dotat.at  Mon Sep 24 21:25:46 2018
From: dot at dotat.at (Tony Finch)
Date: Mon, 24 Sep 2018 12:25:46 +0100
Subject: [TUHS] SPARC is CRAPS spelled backwards.
In-Reply-To: <CABH=_VR1KrWbN2o7_+RiEOBXmkGsGsKYjMqO4V-TD8Ado+3eTw@mail.gmail.com>
References: <mailman.98.1535822297.3725.tuhs@minnie.tuhs.org>
 <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com>
 <CAFCBnZufqk1SmOVdWLK19a0oQ1FjFe7ebDDa+T54yrNo=19eDw@mail.gmail.com>
 <CABH=_VR1KrWbN2o7_+RiEOBXmkGsGsKYjMqO4V-TD8Ado+3eTw@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1809241212560.3596@grey.csi.cam.ac.uk>

Paul Winalski <paul.winalski at gmail.com> wrote:
>
> In general, a CISC instruction set encoding can express the same
> algorithm more compactly than a RISC instruction set.  Once CISC
> technology solved the instruction pipelining and decoding problem, it
> gained an advantage over RISC architectures such as Alpha because the
> instruction set stream was less verbose.

It's more subtle than that, I think. One of the best contributions to this
discussion was John Mashey's classic comp.arch article (which I originally
read in 1994, I think) -

https://yarchive.net/comp/risc_definition.html

What is striking about it is that the two dominant architectures now are
(very roughly) the least CISCy CISC and the least RISCy RISC. In
particular x86 did not go in for elaborate addressing modes and highly
orthogonal instruction sets that allow you to use the elaborate addressing
modes multiple times in one instruction. (Compare it with later 68Ks, for
contrast.) So the translation to RISC-style micro-ops does not end up with
ridiculously long dependency chains within most instructions.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Shannon: South 3 or 4, increasing 5 to 7, perhaps gale 8 later. Moderate,
becoming rough, then very rough later in far northwest. Fair then occasional
rain. Good, becoming moderate, occasionally poor.


From jnc at mercury.lcs.mit.edu  Mon Sep 24 21:48:04 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 24 Sep 2018 07:48:04 -0400 (EDT)
Subject: [TUHS] SPARC is CRAPS spelled backwards.
Message-ID: <20180924114804.CFF9B18C082@mercury.lcs.mit.edu>

    > From: Paul Winalski

    > In general, a CISC instruction set encoding can express the same
    > algorithm more compactly than a RISC instruction set.

I have often pointed to memory bandwidth as one of the key factors in the
evolution of CISC and RISC. When it was low, compared to CPU speeds (most of
the core era), CISC made sense. When it increased (with DRAM), RISC made more
sense, because it allowed CPUs to run faster (via simpler instructions).

Caching made the picture a little more complex; and today, with the incredible
mismatch between memory speeds and CPU speeds, caching dominates, whether you
have RISC or CISC.

     Noel


From peter at rulingia.com  Tue Sep 25 05:46:47 2018
From: peter at rulingia.com (Peter Jeremy)
Date: Tue, 25 Sep 2018 05:46:47 +1000
Subject: [TUHS] SPARC is CRAPS spelled backwards.
In-Reply-To: <CABH=_VR1KrWbN2o7_+RiEOBXmkGsGsKYjMqO4V-TD8Ado+3eTw@mail.gmail.com>
References: <mailman.98.1535822297.3725.tuhs@minnie.tuhs.org>
 <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com>
 <CAFCBnZufqk1SmOVdWLK19a0oQ1FjFe7ebDDa+T54yrNo=19eDw@mail.gmail.com>
 <CABH=_VR1KrWbN2o7_+RiEOBXmkGsGsKYjMqO4V-TD8Ado+3eTw@mail.gmail.com>
Message-ID: <20180924194647.GA29897@server.rulingia.com>

On 2018-Sep-23 17:17:35 -0400, Paul Winalski <paul.winalski at gmail.com> wrote:
>In general, a CISC instruction set encoding can express the same
>algorithm more compactly than a RISC instruction set.  Once CISC
>technology solved the instruction pipelining and decoding problem, it
>gained an advantage over RISC architectures such as Alpha because the
>instruction set stream was less verbose.

RISC architectures have another advantage that instructions are always
aligned on known boundaries (typically 2 or 4 bytes).  This simplifies
the logic around (pre-)fetching instructions.

>Modern x86 designs have a
>bit of logic stuck in one corner that translates the x86 instruction
>stream into a string of RISC-style micro-operations.

Where "modern" is "this century".

...
>the best of both worlds--the compactness of a CISC instruction stream
>and the simpler and faster circuitry of RISC.

In the specific case of x86, I would dispute that.  The various warts in the
x86 instruction set and "architecture" mean that x86 code density is
relatively low and on a par with SPARC code.  I agree that the overall
performance is impressive but that is more a measure of the abilities of
Intel's engineers than the overall approach.

-- 
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/20180925/d8225df5/attachment.sig>

From paul.winalski at gmail.com  Tue Sep 25 06:20:17 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Mon, 24 Sep 2018 16:20:17 -0400
Subject: [TUHS] SPARC is CRAPS spelled backwards.
In-Reply-To: <20180924194647.GA29897@server.rulingia.com>
References: <mailman.98.1535822297.3725.tuhs@minnie.tuhs.org>
 <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com>
 <CAFCBnZufqk1SmOVdWLK19a0oQ1FjFe7ebDDa+T54yrNo=19eDw@mail.gmail.com>
 <CABH=_VR1KrWbN2o7_+RiEOBXmkGsGsKYjMqO4V-TD8Ado+3eTw@mail.gmail.com>
 <20180924194647.GA29897@server.rulingia.com>
Message-ID: <CABH=_VT37mKrH_=-R=GbSO1cffxuVsjiY6JZCNa+9zOH=9S-qA@mail.gmail.com>

On 9/24/18, Peter Jeremy <peter at rulingia.com> wrote:
>
> In the specific case of x86, I would dispute that.  The various warts in
> the
> x86 instruction set and "architecture" mean that x86 code density is
> relatively low and on a par with SPARC code.  I agree that the overall
> performance is impressive but that is more a measure of the abilities of
> Intel's engineers than the overall approach.

No doubt about it--x86 instruction encoding is butt-ugly and wasteful,
due to the need for backward compatibility with what was originally an
8-bit architecture.  Does SPARC have the vector instructions that have
been added to x86 over the years?

-Paul W.


From krewat at kilonet.net  Tue Sep 25 06:45:13 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Mon, 24 Sep 2018 16:45:13 -0400
Subject: [TUHS] SPARC is CRAPS spelled backwards.
In-Reply-To: <CABH=_VT37mKrH_=-R=GbSO1cffxuVsjiY6JZCNa+9zOH=9S-qA@mail.gmail.com>
References: <mailman.98.1535822297.3725.tuhs@minnie.tuhs.org>
 <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com>
 <CAFCBnZufqk1SmOVdWLK19a0oQ1FjFe7ebDDa+T54yrNo=19eDw@mail.gmail.com>
 <CABH=_VR1KrWbN2o7_+RiEOBXmkGsGsKYjMqO4V-TD8Ado+3eTw@mail.gmail.com>
 <20180924194647.GA29897@server.rulingia.com>
 <CABH=_VT37mKrH_=-R=GbSO1cffxuVsjiY6JZCNa+9zOH=9S-qA@mail.gmail.com>
Message-ID: <f3766b0c-398b-2498-a9cd-fb089c7ed568@kilonet.net>

On 9/24/2018 4:20 PM, Paul Winalski wrote:
> No doubt about it--x86 instruction encoding is butt-ugly and wasteful,
> due to the need for backward compatibility with what was originally an
> 8-bit architecture.  Does SPARC have the vector instructions that have
> been added to x86 over the years?
The 8086 was the first of the "x86" line, which was 16-bit, although 
it's I/O was more 8080-ish if I recall correctly. The 8088 was an 8-bit 
data bus, granted, but having done both 8080 and 8086+ assembler, you 
couldn't really tell the difference, programming-wise between the 8086 
and the 8088, 16-bit registers, and all.

Cutting costs, as always, IBM opted for the 8088, which allowed them to 
use an 8085-style I/O architecture.

Also, granted, to this day you can still use only 8-bits of a register: 
MOV AL,0x80

art k.



From dot at dotat.at  Tue Sep 25 20:00:37 2018
From: dot at dotat.at (Tony Finch)
Date: Tue, 25 Sep 2018 11:00:37 +0100
Subject: [TUHS] SPARC is CRAPS spelled backwards.
In-Reply-To: <20180924194647.GA29897@server.rulingia.com>
References: <mailman.98.1535822297.3725.tuhs@minnie.tuhs.org>
 <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com>
 <CAFCBnZufqk1SmOVdWLK19a0oQ1FjFe7ebDDa+T54yrNo=19eDw@mail.gmail.com>
 <CABH=_VR1KrWbN2o7_+RiEOBXmkGsGsKYjMqO4V-TD8Ado+3eTw@mail.gmail.com>
 <20180924194647.GA29897@server.rulingia.com>
Message-ID: <alpine.DEB.2.20.1809251058140.3596@grey.csi.cam.ac.uk>

Peter Jeremy <peter at rulingia.com> wrote:

> In the specific case of x86, I would dispute that.  The various warts in
> the x86 instruction set and "architecture" mean that x86 code density is
> relatively low and on a par with SPARC code.

This paper has a nice survey of instruction set densities, which very much
disagrees with your statement:

http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Dogger, Fisher, German Bight, Humber: West or northwest 4 backing southwest 5
to 7, occasionally gale 8 later except in Humber. Slight or moderate becoming
moderate or rough, then very rough later in Fisher. Showers. Good.


From jnc at mercury.lcs.mit.edu  Tue Sep 25 22:12:12 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue, 25 Sep 2018 08:12:12 -0400 (EDT)
Subject: [TUHS] SPARC is CRAPS spelled backwards.
Message-ID: <20180925121212.C179D18C08D@mercury.lcs.mit.edu>

    > From: Arthur Krewat

    > Also, granted, to this day you can still use only 8-bits of a register:

Yeah, but that's not totally useless; lots of byte-organized data out there in
the world, e.g. ASCII strings. 16-bit data, less so, although there is some in
networking protocols (checksums, ports, etc - although the checksums you
_compute_ using bigger chunks).

(Not a defense of the x86 instruction set, mind!)

     Noel



From tytso at mit.edu  Wed Sep 26 00:49:08 2018
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Tue, 25 Sep 2018 10:49:08 -0400
Subject: [TUHS] SPARC is CRAPS spelled backwards.
In-Reply-To: <20180925121212.C179D18C08D@mercury.lcs.mit.edu>
References: <20180925121212.C179D18C08D@mercury.lcs.mit.edu>
Message-ID: <20180925144908.GA2933@thunk.org>

On Tue, Sep 25, 2018 at 08:12:12AM -0400, Noel Chiappa wrote:
>     > From: Arthur Krewat
> 
>     > Also, granted, to this day you can still use only 8-bits of a register:
> 
> Yeah, but that's not totally useless; lots of byte-organized data out there in
> the world, e.g. ASCII strings. 16-bit data, less so, although there is some in
> networking protocols (checksums, ports, etc - although the checksums you
> _compute_ using bigger chunks).

Windows and Microsoft Office still uses UTF-16....

					- Ted


From lm at mcvoy.com  Wed Sep 26 01:01:52 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 25 Sep 2018 08:01:52 -0700
Subject: [TUHS] SPARC is CRAPS spelled backwards.
In-Reply-To: <alpine.DEB.2.20.1809251058140.3596@grey.csi.cam.ac.uk>
References: <mailman.98.1535822297.3725.tuhs@minnie.tuhs.org>
 <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com>
 <CAFCBnZufqk1SmOVdWLK19a0oQ1FjFe7ebDDa+T54yrNo=19eDw@mail.gmail.com>
 <CABH=_VR1KrWbN2o7_+RiEOBXmkGsGsKYjMqO4V-TD8Ado+3eTw@mail.gmail.com>
 <20180924194647.GA29897@server.rulingia.com>
 <alpine.DEB.2.20.1809251058140.3596@grey.csi.cam.ac.uk>
Message-ID: <20180925150152.GJ10989@mcvoy.com>

On Tue, Sep 25, 2018 at 11:00:37AM +0100, Tony Finch wrote:
> Peter Jeremy <peter at rulingia.com> wrote:
> 
> > In the specific case of x86, I would dispute that.  The various warts in
> > the x86 instruction set and "architecture" mean that x86 code density is
> > relatively low and on a par with SPARC code.
> 
> This paper has a nice survey of instruction set densities, which very much
> disagrees with your statement:
> 
> http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf

That's a neat paper, I like it, thanks for the pointer.  I'm curious
why Peter thought what he thought, my guess would have been more like
what the paper showed, but that was a "hand optimized assembly", maybe
the compilers aren't that good?  I dunno, Peter, care to comment?


From krewat at kilonet.net  Wed Sep 26 01:29:01 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Tue, 25 Sep 2018 11:29:01 -0400
Subject: [TUHS] SPARC is CRAPS spelled backwards.
In-Reply-To: <20180925121212.C179D18C08D@mercury.lcs.mit.edu>
References: <20180925121212.C179D18C08D@mercury.lcs.mit.edu>
Message-ID: <78271134-1774-9c43-2df0-9bcd5174a349@kilonet.net>

On 9/25/2018 8:12 AM, Noel Chiappa wrote:
>      > From: Arthur Krewat
>
>      > Also, granted, to this day you can still use only 8-bits of a register:
>
> Yeah, but that's not totally useless; lots of byte-organized data out there in
> the world, e.g. ASCII strings. 16-bit data, less so, although there is some in
> networking protocols (checksums, ports, etc - although the checksums you
> _compute_ using bigger chunks).
>
> (Not a defense of the x86 instruction set, mind!)
>
>       Noel
>
>
Oh, I like 8-bit operations... I use them a lot. Coming from MACRO-10 on 
a 36-bit PDP-10 I used in high school, the move to microcomputers was 
challenging in some ways, but much easier in others. Especially 7 or 8 
bit operations.


From paul.winalski at gmail.com  Wed Sep 26 04:34:46 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Tue, 25 Sep 2018 14:34:46 -0400
Subject: [TUHS] SPARC is CRAPS spelled backwards.
In-Reply-To: <alpine.DEB.2.20.1809251058140.3596@grey.csi.cam.ac.uk>
References: <mailman.98.1535822297.3725.tuhs@minnie.tuhs.org>
 <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com>
 <CAFCBnZufqk1SmOVdWLK19a0oQ1FjFe7ebDDa+T54yrNo=19eDw@mail.gmail.com>
 <CABH=_VR1KrWbN2o7_+RiEOBXmkGsGsKYjMqO4V-TD8Ado+3eTw@mail.gmail.com>
 <20180924194647.GA29897@server.rulingia.com>
 <alpine.DEB.2.20.1809251058140.3596@grey.csi.cam.ac.uk>
Message-ID: <CABH=_VSzRRoPLnB1j0RBuYL=Vp3Vc4xv7ceUTbg8xL85KvyWmg@mail.gmail.com>

On 9/25/18, Tony Finch <dot at dotat.at> wrote:
> Peter Jeremy <peter at rulingia.com> wrote:
>
> This paper has a nice survey of instruction set densities, which very much
> disagrees with your statement:
>
> http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf

Thanks for the pointer to that paper.  Interesting reading.

There is an error in Table I (Summary of Investigated Architectures).
VAX is a pure little-endian architecture and can't operate on
big-endian data without byte swizzling.  Alpha, on the other hand, can
operate either big- or little-endian (selectable at system boot time).

The version of the Intel C compiler that they used--version 9--is a
little old in the tooth.  There have been several versions released
since then.

Interesting, and disappointing, that linking statically drags in the
entire C runtime.  Lo-level RTLs such as libc ought to be designed to
minimize dependencies between individual library routines (e.g., if I
call only strcmp(), strcmp.o and nothing else should participate in
the static link).

As the paper points out, compilers are usually designed to optimize
for execution speed rather than code size these days.

-Paul W.


From jnc at mercury.lcs.mit.edu  Wed Sep 26 04:41:55 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue, 25 Sep 2018 14:41:55 -0400 (EDT)
Subject: [TUHS] SPARC is CRAPS spelled backwards.
Message-ID: <20180925184155.50F5518C08D@mercury.lcs.mit.edu>

    > From: Tony Finch

    > This paper has a nice survey of instruction set densities

And the winner is.... the PDP-11!

I'm not too surprised by this; back in the days of core memory (and limited,
at that - the first PDP-11's came standard with ... 8KB of memory :-), having
the denset possible code had real savings.

    Noel



From peter at rulingia.com  Wed Sep 26 05:48:17 2018
From: peter at rulingia.com (Peter Jeremy)
Date: Wed, 26 Sep 2018 05:48:17 +1000
Subject: [TUHS] SPARC is CRAPS spelled backwards.
In-Reply-To: <20180925150152.GJ10989@mcvoy.com>
References: <mailman.98.1535822297.3725.tuhs@minnie.tuhs.org>
 <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com>
 <CAFCBnZufqk1SmOVdWLK19a0oQ1FjFe7ebDDa+T54yrNo=19eDw@mail.gmail.com>
 <CABH=_VR1KrWbN2o7_+RiEOBXmkGsGsKYjMqO4V-TD8Ado+3eTw@mail.gmail.com>
 <20180924194647.GA29897@server.rulingia.com>
 <alpine.DEB.2.20.1809251058140.3596@grey.csi.cam.ac.uk>
 <20180925150152.GJ10989@mcvoy.com>
Message-ID: <20180925194817.GB29897@server.rulingia.com>

On 2018-Sep-25 08:01:52 -0700, Larry McVoy <lm at mcvoy.com> wrote:
>On Tue, Sep 25, 2018 at 11:00:37AM +0100, Tony Finch wrote:
>> Peter Jeremy <peter at rulingia.com> wrote:
>> 
>> > In the specific case of x86, I would dispute that.  The various warts in
>> > the x86 instruction set and "architecture" mean that x86 code density is
>> > relatively low and on a par with SPARC code.
>> 
>> This paper has a nice survey of instruction set densities, which very much
>> disagrees with your statement:
>> 
>> http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf
>
>That's a neat paper, I like it, thanks for the pointer.  I'm curious
>why Peter thought what he thought, my guess would have been more like
>what the paper showed, but that was a "hand optimized assembly", maybe
>the compilers aren't that good?  I dunno, Peter, care to comment?

I agree that looks like an interesting paper - I've skimmed it and
will have to read it in details.  I was thinking back to when I was
using a mixture of SPARC and x86 at a previous job.  I didn't do any
careful analysis, more eyeballing various executables and gut feeling.
I no longer have access to that environment.  In view of that paper,
I'll withdraw my claim since it's not backed up by evidence.

-- 
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/20180926/1ad5d9be/attachment.sig>

From peter at rulingia.com  Wed Sep 26 16:20:00 2018
From: peter at rulingia.com (Peter Jeremy)
Date: Wed, 26 Sep 2018 16:20:00 +1000
Subject: [TUHS] SPARC is CRAPS spelled backwards.
In-Reply-To: <f3766b0c-398b-2498-a9cd-fb089c7ed568@kilonet.net>
References: <mailman.98.1535822297.3725.tuhs@minnie.tuhs.org>
 <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com>
 <CAFCBnZufqk1SmOVdWLK19a0oQ1FjFe7ebDDa+T54yrNo=19eDw@mail.gmail.com>
 <CABH=_VR1KrWbN2o7_+RiEOBXmkGsGsKYjMqO4V-TD8Ado+3eTw@mail.gmail.com>
 <20180924194647.GA29897@server.rulingia.com>
 <CABH=_VT37mKrH_=-R=GbSO1cffxuVsjiY6JZCNa+9zOH=9S-qA@mail.gmail.com>
 <f3766b0c-398b-2498-a9cd-fb089c7ed568@kilonet.net>
Message-ID: <20180926062000.GC29897@server.rulingia.com>

On 2018-Sep-24 16:45:13 -0400, Arthur Krewat <krewat at kilonet.net> wrote:
>The 8086 was the first of the "x86" line, which was 16-bit, although 
>it's I/O was more 8080-ish if I recall correctly.

The 8086/8088 bus was designed to be similar to the 8085 to allow 8080/8085
peripherals to support 8086 systems.  This saved Intel the effort of
developing a new range of support peripherals and made it quicker for
vendors to build 8086 systems because they didn't need to wait for the
peripheral chips.  There are still 8080 support chips - 8253, 8257, 8259 -
embedded in PC Southbridge chips.

>The 8088 was an 8-bit 
>data bus, granted, but having done both 8080 and 8086+ assembler, you 
>couldn't really tell the difference, programming-wise between the 8086 
>and the 8088, 16-bit registers, and all.

This was deliberate - the 8080 was an upgraded 8008 and Intel made the 8086
similar enough to allow automated ASM translation.  It seems highly likely
that the undocumented 8085 opcodes were undocumented because they weren't
readily translatable to 8086.

>Cutting costs, as always, IBM opted for the 8088, which allowed them to 
>use an 8085-style I/O architecture.

An 8-bit memory bus means half as many RAM chips and buffers.  Keep in mind
that the IBM 5150 was intentionally crippled to ensure it didn't compete with
IBM's low-end minis.

-- 
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/20180926/19266f58/attachment.sig>

From lars at nocrew.org  Wed Sep 26 16:46:20 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Wed, 26 Sep 2018 06:46:20 +0000
Subject: [TUHS] SPARC is CRAPS spelled backwards.
In-Reply-To: <20180926062000.GC29897@server.rulingia.com> (Peter Jeremy's
 message of "Wed, 26 Sep 2018 16:20:00 +1000")
References: <mailman.98.1535822297.3725.tuhs@minnie.tuhs.org>
 <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com>
 <CAFCBnZufqk1SmOVdWLK19a0oQ1FjFe7ebDDa+T54yrNo=19eDw@mail.gmail.com>
 <CABH=_VR1KrWbN2o7_+RiEOBXmkGsGsKYjMqO4V-TD8Ado+3eTw@mail.gmail.com>
 <20180924194647.GA29897@server.rulingia.com>
 <CABH=_VT37mKrH_=-R=GbSO1cffxuVsjiY6JZCNa+9zOH=9S-qA@mail.gmail.com>
 <f3766b0c-398b-2498-a9cd-fb089c7ed568@kilonet.net>
 <20180926062000.GC29897@server.rulingia.com>
Message-ID: <7wsh1wdadf.fsf@junk.nocrew.org>

Peter Jeremy wrote:
> the 8080 was an upgraded 8008

Also note the 8008 instruction set originated at Compuer Terminal
Corporation (later Datapoint), for use as a text terminal controller.
I'd say it's an OK design for that purpose...


From tytso at mit.edu  Thu Sep 27 01:03:52 2018
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Wed, 26 Sep 2018 11:03:52 -0400
Subject: [TUHS] SPARC is CRAPS spelled backwards.
In-Reply-To: <7wsh1wdadf.fsf@junk.nocrew.org>
References: <mailman.98.1535822297.3725.tuhs@minnie.tuhs.org>
 <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com>
 <CAFCBnZufqk1SmOVdWLK19a0oQ1FjFe7ebDDa+T54yrNo=19eDw@mail.gmail.com>
 <CABH=_VR1KrWbN2o7_+RiEOBXmkGsGsKYjMqO4V-TD8Ado+3eTw@mail.gmail.com>
 <20180924194647.GA29897@server.rulingia.com>
 <CABH=_VT37mKrH_=-R=GbSO1cffxuVsjiY6JZCNa+9zOH=9S-qA@mail.gmail.com>
 <f3766b0c-398b-2498-a9cd-fb089c7ed568@kilonet.net>
 <20180926062000.GC29897@server.rulingia.com>
 <7wsh1wdadf.fsf@junk.nocrew.org>
Message-ID: <20180926150352.GE3321@thunk.org>

On Wed, Sep 26, 2018 at 06:46:20AM +0000, Lars Brinkhoff wrote:
> Peter Jeremy wrote:
> > the 8080 was an upgraded 8008
> 
> Also note the 8008 instruction set originated at Compuer Terminal
> Corporation (later Datapoint), for use as a text terminal controller.
> I'd say it's an OK design for that purpose...

That's not that only CPU for which this was true.  The IBM PC/RT
(e.g., the 6150) CPU was originally designed to be used as a
typewriter controller.  It was a RISC design which was approximately 3
times faster than a Microvax, which meant that it was quite popular
for students using MIT's Project Athenna who needed to run Scribe or
TeX/LaTeX.  :-)

					- Ted


From paul.winalski at gmail.com  Thu Sep 27 01:32:47 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Wed, 26 Sep 2018 11:32:47 -0400
Subject: [TUHS] SPARC is CRAPS spelled backwards.
In-Reply-To: <20180926150352.GE3321@thunk.org>
References: <mailman.98.1535822297.3725.tuhs@minnie.tuhs.org>
 <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com>
 <CAFCBnZufqk1SmOVdWLK19a0oQ1FjFe7ebDDa+T54yrNo=19eDw@mail.gmail.com>
 <CABH=_VR1KrWbN2o7_+RiEOBXmkGsGsKYjMqO4V-TD8Ado+3eTw@mail.gmail.com>
 <20180924194647.GA29897@server.rulingia.com>
 <CABH=_VT37mKrH_=-R=GbSO1cffxuVsjiY6JZCNa+9zOH=9S-qA@mail.gmail.com>
 <f3766b0c-398b-2498-a9cd-fb089c7ed568@kilonet.net>
 <20180926062000.GC29897@server.rulingia.com>
 <7wsh1wdadf.fsf@junk.nocrew.org> <20180926150352.GE3321@thunk.org>
Message-ID: <CABH=_VRoxNYmcLCr5pXH7i6eoxe4te3Wha3NCJwiCt3uFPr6Fw@mail.gmail.com>

On 9/26/18, Theodore Y. Ts'o <tytso at mit.edu> wrote:
>
> That's not that only CPU for which this was true.  The IBM PC/RT
> (e.g., the 6150) CPU was originally designed to be used as a
> typewriter controller.

The CPU in the IBM 5100 was a 16-bit processor originally designed for
use in System/370 I/O peripheral controllers.

-Paul W.


From henry.r.bent at gmail.com  Thu Sep 27 01:44:11 2018
From: henry.r.bent at gmail.com (Henry Bent)
Date: Wed, 26 Sep 2018 11:44:11 -0400
Subject: [TUHS] SPARC is CRAPS spelled backwards.
In-Reply-To: <20180926062000.GC29897@server.rulingia.com>
References: <mailman.98.1535822297.3725.tuhs@minnie.tuhs.org>
 <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com>
 <CAFCBnZufqk1SmOVdWLK19a0oQ1FjFe7ebDDa+T54yrNo=19eDw@mail.gmail.com>
 <CABH=_VR1KrWbN2o7_+RiEOBXmkGsGsKYjMqO4V-TD8Ado+3eTw@mail.gmail.com>
 <20180924194647.GA29897@server.rulingia.com>
 <CABH=_VT37mKrH_=-R=GbSO1cffxuVsjiY6JZCNa+9zOH=9S-qA@mail.gmail.com>
 <f3766b0c-398b-2498-a9cd-fb089c7ed568@kilonet.net>
 <20180926062000.GC29897@server.rulingia.com>
Message-ID: <CAEdTPBc_zsmOADtASLKjoAPFMkEFTCYp0Zd9P_iiRwimWeUSfw@mail.gmail.com>

On Wed, 26 Sep 2018 at 02:21, Peter Jeremy <peter at rulingia.com> wrote:

>
> An 8-bit memory bus means half as many RAM chips and buffers.  Keep in mind
> that the IBM 5150 was intentionally crippled to ensure it didn't compete
> with
> IBM's low-end minis.
>

Did the 5150 have a UNIX available anywhere near its launch date?   I know
that it had DOS, CP/M-86, and the UCSD p-System relatively early on.  It's
not clear to me whether Xenix ever supported the original PC; were there
other early porting efforts?

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

From pechter at gmail.com  Thu Sep 27 02:02:43 2018
From: pechter at gmail.com (William Pechter)
Date: Wed, 26 Sep 2018 12:02:43 -0400
Subject: [TUHS] Fwd: Re:  SPARC is CRAPS spelled backwards.
In-Reply-To: <ceae72ff-ca8b-4cc1-9666-82253c1e1683.maildroid@localhost>
References: <mailman.98.1535822297.3725.tuhs@minnie.tuhs.org>
 <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com>
 <CAFCBnZufqk1SmOVdWLK19a0oQ1FjFe7ebDDa+T54yrNo=19eDw@mail.gmail.com>
 <CABH=_VR1KrWbN2o7_+RiEOBXmkGsGsKYjMqO4V-TD8Ado+3eTw@mail.gmail.com>
 <20180924194647.GA29897@server.rulingia.com>
 <CABH=_VT37mKrH_=-R=GbSO1cffxuVsjiY6JZCNa+9zOH=9S-qA@mail.gmail.com>
 <f3766b0c-398b-2498-a9cd-fb089c7ed568@kilonet.net>
 <20180926062000.GC29897@server.rulingia.com>
 <CAEdTPBc_zsmOADtASLKjoAPFMkEFTCYp0Zd9P_iiRwimWeUSfw@mail.gmail.com>
 <ceae72ff-ca8b-4cc1-9666-82253c1e1683.maildroid@localhost>
Message-ID: <8aef3a1c-f21d-4909-9df2-b9ed6c5fc562.maildroid@localhost>

Should have copied the list... 

-----Original Message-----
From: William Pechter <pechter at gmail.com>
To: Henry Bent <henry.r.bent at gmail.com>
Sent: Wed, 26 Sep 2018 11:59
Subject: Re: [TUHS] SPARC is CRAPS spelled backwards.

There was Xenix-86 which ran on the AT&T 6300, and IBM PC/XT.  I ran it on an 8MHz NEC V30 cpu on the 6300.  I would love to install it on my Panasonic Sr. Partner but lost the install key. 

-----Original Message-----
From: Henry Bent <henry.r.bent at gmail.com>
To: TUHS main list <tuhs at minnie.tuhs.org>
Sent: Wed, 26 Sep 2018 11:45
Subject: Re: [TUHS] SPARC is CRAPS spelled backwards.

On Wed, 26 Sep 2018 at 02:21, Peter Jeremy <peter at rulingia.com> wrote:

>
> An 8-bit memory bus means half as many RAM chips and buffers.  Keep in mind
> that the IBM 5150 was intentionally crippled to ensure it didn't compete
> with
> IBM's low-end minis.
>

Did the 5150 have a UNIX available anywhere near its launch date?   I know
that it had DOS, CP/M-86, and the UCSD p-System relatively early on.  It's
not clear to me whether Xenix ever supported the original PC; were there
other early porting efforts?

-Henry


From mutiny.mutiny at india.com  Thu Sep 27 04:24:01 2018
From: mutiny.mutiny at india.com (Donald ODona)
Date: Wed, 26 Sep 2018 18:24:01 +0000 (UTC)
Subject: [TUHS] SPARC is CRAPS spelled backwards.
In-Reply-To: <CAEdTPBc_zsmOADtASLKjoAPFMkEFTCYp0Zd9P_iiRwimWeUSfw@mail.gmail.com>
References: <mailman.98.1535822297.3725.tuhs@minnie.tuhs.org>
 <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com>
 <CAFCBnZufqk1SmOVdWLK19a0oQ1FjFe7ebDDa+T54yrNo=19eDw@mail.gmail.com>
 <CABH=_VR1KrWbN2o7_+RiEOBXmkGsGsKYjMqO4V-TD8Ado+3eTw@mail.gmail.com>
 <20180924194647.GA29897@server.rulingia.com>
 <CABH=_VT37mKrH_=-R=GbSO1cffxuVsjiY6JZCNa+9zOH=9S-qA@mail.gmail.com>
 <f3766b0c-398b-2498-a9cd-fb089c7ed568@kilonet.net>
 <20180926062000.GC29897@server.rulingia.com>,
 <CAEdTPBc_zsmOADtASLKjoAPFMkEFTCYp0Zd9P_iiRwimWeUSfw@mail.gmail.com>
Message-ID: <190720804.17371.1537986240922.JavaMail.tomcat@india-live-be02>



At 26 Sep 2018 15:45:25 +0000 (+00:00) from Henry Bent <henry.r.bent at gmail.com>:
> Did the 5150 have a UNIX available anywhere near its launch date?   I know
> that it had DOS, CP/M-86, and the UCSD p-System relatively early on.  It's
> not clear to me whether Xenix ever supported the original PC; were there
> other early porting efforts?
read more here:
http://www.softpanorama.org/People/Torvalds/Finland_period/xenix_microsoft_shortlived_love_affair_with_unix.shtml


From dfawcus+lists-tuhs at employees.org  Thu Sep 27 05:31:55 2018
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Wed, 26 Sep 2018 20:31:55 +0100
Subject: [TUHS] SPARC is CRAPS spelled backwards.
In-Reply-To: <20180925144908.GA2933@thunk.org>
References: <20180925121212.C179D18C08D@mercury.lcs.mit.edu>
 <20180925144908.GA2933@thunk.org>
Message-ID: <20180926193155.GA88914@bugle.employees.org>

On Tue, Sep 25, 2018 at 10:49:08AM -0400, Theodore Y. Ts'o wrote:
> 
> Windows and Microsoft Office still uses UTF-16....

As do Mac's, and probably iOS; the Foundation framework uses it for NSString.

DF


From pnr at planet.nl  Thu Sep 27 17:35:44 2018
From: pnr at planet.nl (Paul Ruizendaal)
Date: Thu, 27 Sep 2018 09:35:44 +0200
Subject: [TUHS] SPARC is CRAPS spelled backwards.
Message-ID: <A301BE83-980F-4A42-8600-0EACC179B8F8@planet.nl>

> Did the 5150 have a UNIX available anywhere near its launch date?   I know
> that it had DOS, CP/M-86, and the UCSD p-System relatively early on.  It's
> not clear to me whether Xenix ever supported the original PC; were there
> other early porting efforts?

The first version of Venix-86 ran on the PC/XT, almost a 5150, in May 83. It was V7 based. I think it was the first Unix on a PC.

Heinz Lycklama (who did Unix LSX and MX at Bell labs in the 70’s) did PC/IX about a year later, based  on Sys III. This was marketed by IBM.

Based on the early Xenix porting chart here http://seefigure1.com/2014/04/15/xenixtime.html , a PC/XT version of Xenix appeared around the same time as PC/IX. However, if the chart is correct there may have been Xenix versions for other 8086-based machines a year before that. Note that in this chart the “Xenix 2.0” and “Xenix 3.0” labels refer to MS internal versions, i.e. these numbers are not to be confused with the marketing labels IBM PC Xenix 2.0 and 3.0.

These versions are a hole in the TUHS archive (unless they are in the confidential archive). It would be wonderful if MS would open up pre-1984 Xenix on the occasion of Unix 50th. These builds would well illustrate the broad Unix portability, which was unique at the time.

Paul





From arrigo at alchemistowl.org  Thu Sep 27 17:52:51 2018
From: arrigo at alchemistowl.org (Arrigo Triulzi)
Date: Thu, 27 Sep 2018 09:52:51 +0200
Subject: [TUHS] SPARC is CRAPS spelled backwards.
In-Reply-To: <A301BE83-980F-4A42-8600-0EACC179B8F8@planet.nl>
References: <A301BE83-980F-4A42-8600-0EACC179B8F8@planet.nl>
Message-ID: <93A6E956-D376-409D-995A-785534D7E5D0@alchemistowl.org>

On 27 Sep 2018, at 09:35, Paul Ruizendaal <pnr at planet.nl> wrote:
>> Did the 5150 have a UNIX available anywhere near its launch date?   I know
>> that it had DOS, CP/M-86, and the UCSD p-System relatively early on.  It's
>> not clear to me whether Xenix ever supported the original PC; were there
>> other early porting efforts?
> 
> The first version of Venix-86 ran on the PC/XT, almost a 5150, in May 83. It was V7 based. I think it was the first Unix on a PC.
> 
> Heinz Lycklama (who did Unix LSX and MX at Bell labs in the 70’s) did PC/IX about a year later, based  on Sys III. This was marketed by IBM.
> 
> Based on the early Xenix porting chart here http://seefigure1.com/2014/04/15/xenixtime.html , a PC/XT version of Xenix appeared around the same time as PC/IX. However, if the chart is correct there may have been Xenix versions for other 8086-based machines a year before that. Note that in this chart the “Xenix 2.0” and “Xenix 3.0” labels refer to MS internal versions, i.e. these numbers are not to be confused with the marketing labels IBM PC Xenix 2.0 and 3.0.

I am almost certain of the existence of a Unix variant for the Olivetti M24 which was an 8086-equipped PC (The M24 was rebranded as an AT&T 6300 if memory serves me correctly). It might have been Xenix or Venix but I honestly cannot remember it as I certainly recall Xenix floppies & manuals making the rounds later on 286s in Italy but I only faintly recall the M24 Unix.

Arrigo



From ca6c at bitmessage.ch  Thu Sep 27 22:08:54 2018
From: ca6c at bitmessage.ch (=?utf-8?B?Q8OhZw==?=)
Date: Thu, 27 Sep 2018 07:08:54 -0500
Subject: [TUHS] The origin of /home
Message-ID: <20180927120854.u8rei%ca6c@bitmessage.ch>

Hi,

The earliest I've found to be in the FHS from '94. Are there any earlier
examples of a home directory being at /home instead of /usr/$(user)? Are
there any current Unix systems that don't use /home by default (except
OSX)? Does anybody here do it intentionally? Also, what was the
rationale of moving the directory to /home?

Thanks!

--
caóc



From alec.muffett at gmail.com  Thu Sep 27 22:30:15 2018
From: alec.muffett at gmail.com (Alec Muffett)
Date: Thu, 27 Sep 2018 13:30:15 +0100
Subject: [TUHS] The origin of /home
In-Reply-To: <20180927120854.u8rei%ca6c@bitmessage.ch>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>
Message-ID: <CAFWeb9+C5+=rXopr_No8MSSsPNU3-DJuSwM1NfyETLF7cfK=6w@mail.gmail.com>

Opinion, predating that era: I believe that the driver for /home was
automounter, because of the complexity of referencing local and remote
/export/foo/whatever/username paths consistently across a large NFS-enabled
university deployment with many different platforms and individual systems.


On Thu, 27 Sep 2018, 13:11 Cág, <ca6c at bitmessage.ch> wrote:

> Hi,
>
> The earliest I've found to be in the FHS from '94. Are there any earlier
> examples of a home directory being at /home instead of /usr/$(user)? Are
> there any current Unix systems that don't use /home by default (except
> OSX)? Does anybody here do it intentionally? Also, what was the
> rationale of moving the directory to /home?
>
> Thanks!
>
> --
> caóc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180927/01f062c5/attachment.html>

From mutiny.mutiny at india.com  Thu Sep 27 22:58:49 2018
From: mutiny.mutiny at india.com (Donald ODona)
Date: Thu, 27 Sep 2018 12:58:49 +0000 (UTC)
Subject: [TUHS] The origin of /home
In-Reply-To: <20180927120854.u8rei%ca6c@bitmessage.ch>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>
Message-ID: <633187202.18875.1538053129435.JavaMail.tomcat@india-live-be04>

At 27 Sep 2018 12:11:15 +0000 (+00:00) from "Cág" <ca6c at bitmessage.ch>:
> Hi,
>
Also, what was the
> rationale of moving the directory to /home?
originally /usr, placed on a separate disk, was what became /home much later. Then disk space of / was running out and more an more applications and libs were moved to the /usr device.
Much later in the 80ths much more disk space was available and a separate /home was created. Exacly when I don't know, but there was no /home in Ed. 7 but System V release 3 had it already.


From jpl.jpl at gmail.com  Thu Sep 27 23:54:29 2018
From: jpl.jpl at gmail.com (John P. Linderman)
Date: Thu, 27 Sep 2018 09:54:29 -0400
Subject: [TUHS] The origin of /home
In-Reply-To: <633187202.18875.1538053129435.JavaMail.tomcat@india-live-be04>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>
 <633187202.18875.1538053129435.JavaMail.tomcat@india-live-be04>
Message-ID: <CAC0cEp_CCi5Tjkm4zq1xiWA4mCduphw_N_kae99ZF7rwfk-bgQ@mail.gmail.com>

More opinion, unencumbered by facts. /usr contained many sudirectories,
like /usr/bin and /usr/lib, that were essential to an operational OS. Home
directories, on the other hand, persisted unchanged when new releases of an
OS were installed. Some of us had symlinks from /usr into a separate file
system to make the distinction easier to maintain across releases.

On Thu, Sep 27, 2018 at 8:58 AM, Donald ODona <mutiny.mutiny at india.com>
wrote:

> At 27 Sep 2018 12:11:15 +0000 (+00:00) from "Cág" <ca6c at bitmessage.ch>:
> > Hi,
> >
> Also, what was the
> > rationale of moving the directory to /home?
> originally /usr, placed on a separate disk, was what became /home much
> later. Then disk space of / was running out and more an more applications
> and libs were moved to the /usr device.
> Much later in the 80ths much more disk space was available and a separate
> /home was created. Exacly when I don't know, but there was no /home in Ed.
> 7 but System V release 3 had it already.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180927/fde1f9c5/attachment.html>

From ron at ronnatalie.com  Fri Sep 28 00:09:13 2018
From: ron at ronnatalie.com (Ronald Natalie)
Date: Thu, 27 Sep 2018 10:09:13 -0400
Subject: [TUHS] The origin of /home
In-Reply-To: <CAC0cEp_CCi5Tjkm4zq1xiWA4mCduphw_N_kae99ZF7rwfk-bgQ@mail.gmail.com>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>
 <633187202.18875.1538053129435.JavaMail.tomcat@india-live-be04>
 <CAC0cEp_CCi5Tjkm4zq1xiWA4mCduphw_N_kae99ZF7rwfk-bgQ@mail.gmail.com>
Message-ID: <2F919C1F-3C91-4083-9B46-B5A6D28A1D54@ronnatalie.com>

 Symlinks?   Surely  you jest.   Not in Version 7 or System V.

The idea was to keep root small for convenience in various stages of setup.   /usr was indeed intended to be a separate disk.   If you look at the early distributions like V7, you’ll find the /usr image was a separate tape file.

> On Sep 27, 2018, at 9:54 AM, John P. Linderman <jpl.jpl at gmail.com> wrote:
> 
> More opinion, unencumbered by facts. /usr contained many sudirectories, like /usr/bin and /usr/lib, that were essential to an operational OS. Home directories, on the other hand, persisted unchanged when new releases of an OS were installed. Some of us had symlinks from /usr into a separate file system to make the distinction easier to maintain across releases.
> 
> On Thu, Sep 27, 2018 at 8:58 AM, Donald ODona <mutiny.mutiny at india.com <mailto:mutiny.mutiny at india.com>> wrote:
> At 27 Sep 2018 12:11:15 +0000 (+00:00) from "Cág" <ca6c at bitmessage.ch <mailto:ca6c at bitmessage.ch>>:
> > Hi,
> >
> Also, what was the
> > rationale of moving the directory to /home?
> originally /usr, placed on a separate disk, was what became /home much later. Then disk space of / was running out and more an more applications and libs were moved to the /usr device.
> Much later in the 80ths much more disk space was available and a separate /home was created. Exacly when I don't know, but there was no /home in Ed. 7 but System V release 3 had it already.
> 

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

From nobozo at gmail.com  Fri Sep 28 00:18:48 2018
From: nobozo at gmail.com (Jon Forrest)
Date: Thu, 27 Sep 2018 07:18:48 -0700
Subject: [TUHS] The origin of /home
In-Reply-To: <CAC0cEp_CCi5Tjkm4zq1xiWA4mCduphw_N_kae99ZF7rwfk-bgQ@mail.gmail.com>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>
 <633187202.18875.1538053129435.JavaMail.tomcat@india-live-be04>
 <CAC0cEp_CCi5Tjkm4zq1xiWA4mCduphw_N_kae99ZF7rwfk-bgQ@mail.gmail.com>
Message-ID: <f11ec7b9-0363-1de3-fc72-da8ed7e8f0f7@gmail.com>


Another reason why the home directory part of /usr was made into
/home is because after doing so, it was possible to mount /usr
read-only, and supply it from a server. This was the so-called
"dataless" method. I wrote a short email message summarizing
what we were doing with this in UC Berkeley Comp. Sci., and mentioning
a paper I had written describing how to create a "dataless"
environment for DEC's OSF1 operating system (see
http://beowulf.org/pipermail/beowulf/2008-July/022210.html).

Jon Forrest


From arrigo at alchemistowl.org  Fri Sep 28 00:28:59 2018
From: arrigo at alchemistowl.org (Arrigo Triulzi)
Date: Thu, 27 Sep 2018 16:28:59 +0200
Subject: [TUHS] The origin of /home
In-Reply-To: <f11ec7b9-0363-1de3-fc72-da8ed7e8f0f7@gmail.com>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>
 <633187202.18875.1538053129435.JavaMail.tomcat@india-live-be04>
 <CAC0cEp_CCi5Tjkm4zq1xiWA4mCduphw_N_kae99ZF7rwfk-bgQ@mail.gmail.com>
 <f11ec7b9-0363-1de3-fc72-da8ed7e8f0f7@gmail.com>
Message-ID: <36C6F216-490E-4DE4-B5EF-CED26899542F@alchemistowl.org>

> On 27 Sep 2018, at 16:18, Jon Forrest <nobozo at gmail.com> wrote:
> Another reason why the home directory part of /usr was made into
> /home is because after doing so, it was possible to mount /usr
> read-only, and supply it from a server. This was the so-called
> "dataless" method. I wrote a short email message summarizing
> what we were doing with this in UC Berkeley Comp. Sci., and mentioning
> a paper I had written describing how to create a "dataless"
> environment for DEC's OSF1 operating system (see
> http://beowulf.org/pipermail/beowulf/2008-July/022210.html).

Not to be pedantic but the OSF/1 “dataless” trick is from 1993 in Jon Forrest’s writeup:

https://groups.google.com/d/msg/comp.unix.osf.osf1/-s1xW80zXPE/OGENDhH2Sc0J

As one of the three people figuring out what DEC had told us was impossible I’m pretty sure we were the first - our DEC 3000/400s with OSF/1 T1.0 did not have enough disk space so we struggled to get our network operational serving /usr and /home from the “big” DEC 3000/600 which had two disks (one of which was /home).

Cheers,

Arrigo



From jnc at mercury.lcs.mit.edu  Fri Sep 28 00:31:08 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu, 27 Sep 2018 10:31:08 -0400 (EDT)
Subject: [TUHS] The origin of /home
Message-ID: <20180927143108.C05D418C08E@mercury.lcs.mit.edu>

    > From: Jon Forrest

    > Another reason why the home directory part of /usr was made into /home
    > is because after doing so, it was possible to mount /usr read-only, and
    > supply it from a server.

The real issue is that /usr contained stuff which wasn't true 'user data' -
e.g. /usr/bin. The reasons for that must have seemed good at the time it
started, but it was IMO a mistake. (Disgression about partitions, physical
packs, etc elided for now.)

       Noel


From crossd at gmail.com  Fri Sep 28 00:47:21 2018
From: crossd at gmail.com (Dan Cross)
Date: Thu, 27 Sep 2018 10:47:21 -0400
Subject: [TUHS] The origin of /home
In-Reply-To: <20180927120854.u8rei%ca6c@bitmessage.ch>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>
Message-ID: <CAEoi9W5mnNCUFWWUVs++=adNP7FfB1=iqH6sv5nRF=DxWRHLXA@mail.gmail.com>

On Thu, Sep 27, 2018 at 8:11 AM Cág <ca6c at bitmessage.ch> wrote:

> The earliest I've found to be in the FHS from '94. Are there any earlier
> examples of a home directory being at /home instead of /usr/$(user)? Are
> there any current Unix systems that don't use /home by default (except
> OSX)? Does anybody here do it intentionally? Also, what was the
> rationale of moving the directory to /home?
>

Naming on Unix (and derived systems) is one of those things that has always
had different schools of thought applied to it.

As has been pointed out, the original place for what we now refer to as
"home" directories was /usr, though this may not be entirely accurate: it's
my belief that PDP-7 Unix had separate directories for each user, but I
don't think these were nested under a common 'usr' directory. Someone
please correct me if I'm wrong. The original impetus for moving things
around was surely space considerations on early disk devices: Not only was
space limited, but filesystems couldn't span devices (in the /dev sense)
and often *partition* sizes on a single volume were fixed by the driver for
the underlying storage device. In such a rigidly defined world, varying
conventions would necessary evolve to work around the inevitable
limitations, particular in sites with lots of users like universities and
production-focused corporate groups, including the degeneration of `/usr`
as purely holding user directories. One can easily imagine the
conversation: "we're out of room on the root filesystem and I can't install
this new program in /bin..." "Hmm. Well, we've got space in /usr: create
/usr/bin and we'll fix up the difference in the shell by incorporating some
notion of a search path for binaries." Similarly with lib, man, and all the
rest of it. It's interesting that now /usr is most often devoid of user
data; the intent behind the name seems to be justified after the fact by
asserting that it contains programs, libraries and other data of interest
to users (as opposed to administrators).

That explains why other things starting encroaching and eventually took
over on /usr, but I think the provenance of "/home" specifically relates to
an etymological question. At some point, the "user's directory" as  denoted
in /etc/passwd became known as the "home directory." If that was common
vernacular by the time that `/home` came around as a convention, then it
seems a logical name stemming from that usage. The more intriguing
possibility from the antiquarian point of view is whether someone coined
"/home" and then THAT led to the rise of the "home directory" nomenclature.
man(5) on 7th Edition calls that field the user's "initial working
directory." The first time I see it called "home directory" in my cursory
search is in 4.3 Reno.

I intentionally eschew /home on a few systems. 4.4BSD had a convention of
placing user home directories in /a, /b, etc. 4.4BSD-Lite also had
/var/users. Both of which I occasionally use.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180927/6cfb59d8/attachment.html>

From jnc at mercury.lcs.mit.edu  Fri Sep 28 01:33:53 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu, 27 Sep 2018 11:33:53 -0400 (EDT)
Subject: [TUHS] The origin of /home
Message-ID: <20180927153353.F354118C08E@mercury.lcs.mit.edu>

    > From: Dan Cross

    > particular in sites with lots of users like universities and
    > production-focused corporate groups

The existence of /usr, /usr/bin, /etc, /lib, etc dates back to the Research
group at Bell, so I don't think we can look to these other environments for an
explanation.

    > "Hmm. Well, we've got space in /usr: create /usr/bin

I seem to recall reading (don't recall where, OTTOMY) an explanation for the
creation of /usr/bin, and I think it was performance related; IIRC the issue
was that they wanted to keep the directory size down (both for disk block
caching, and search time, reasons). Or maybe that was later on, and it was
originally created for 'user-maintained' ancillary programs (another vague
memory)?

    > The more intriguing possibility from the antiquarian point of view is
    > whether someone coined "/home" and then THAT led to the rise of the "home
    > directory" nomenclature.

My memory is that the term "home directory" predates /home - perhaps on other
OS's such as TOPS-20, but I don't have time to research that. (I did look
quickly in the Multics docs, and it has 'working directory', i.e. current dir
- but it refers to the home dir as 'original WD', i.e. the WD at the time of
login.)

       Noel


From nobozo at gmail.com  Fri Sep 28 01:36:35 2018
From: nobozo at gmail.com (Jon Forrest)
Date: Thu, 27 Sep 2018 08:36:35 -0700
Subject: [TUHS] The origin of /home
In-Reply-To: <36C6F216-490E-4DE4-B5EF-CED26899542F@alchemistowl.org>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>
 <633187202.18875.1538053129435.JavaMail.tomcat@india-live-be04>
 <CAC0cEp_CCi5Tjkm4zq1xiWA4mCduphw_N_kae99ZF7rwfk-bgQ@mail.gmail.com>
 <f11ec7b9-0363-1de3-fc72-da8ed7e8f0f7@gmail.com>
 <36C6F216-490E-4DE4-B5EF-CED26899542F@alchemistowl.org>
Message-ID: <4caca587-4945-c8be-5a35-c9f0ecfdd08b@gmail.com>



On 9/27/2018 7:28 AM, Arrigo Triulzi wrote:

> Not to be pedantic but the OSF/1 “dataless” trick is from 1993 in Jon
> Forrest’s writeup:

Right, and I am that Jon Forrest

> https://groups.google.com/d/msg/comp.unix.osf.osf1/-s1xW80zXPE/OGENDhH2Sc0J
>
>  As one of the three people figuring out what DEC had told us was
> impossible I’m pretty sure we were the first - our DEC 3000/400s with
> OSF/1 T1.0 did not have enough disk space so we struggled to get our
> network operational serving /usr and /home from the “big” DEC
> 3000/600 which had two disks (one of which was /home).

It's been a while, but what I remember is that DEC actually published
their own method for doing this but it was surprisingly cumbersome.
What I described was incredibly simple but effective. I ran many
Alphas this way with no problems at all.

Jon



From arrigo at alchemistowl.org  Fri Sep 28 01:54:51 2018
From: arrigo at alchemistowl.org (Arrigo Triulzi)
Date: Thu, 27 Sep 2018 17:54:51 +0200
Subject: [TUHS] The origin of /home
In-Reply-To: <4caca587-4945-c8be-5a35-c9f0ecfdd08b@gmail.com>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>
 <633187202.18875.1538053129435.JavaMail.tomcat@india-live-be04>
 <CAC0cEp_CCi5Tjkm4zq1xiWA4mCduphw_N_kae99ZF7rwfk-bgQ@mail.gmail.com>
 <f11ec7b9-0363-1de3-fc72-da8ed7e8f0f7@gmail.com>
 <36C6F216-490E-4DE4-B5EF-CED26899542F@alchemistowl.org>
 <4caca587-4945-c8be-5a35-c9f0ecfdd08b@gmail.com>
Message-ID: <309587CA-4C65-4AFA-ADFF-0E99B430D191@alchemistowl.org>

On 27 Sep 2018, at 17:36, Jon Forrest <nobozo at gmail.com> wrote:
> Right, and I am that Jon Forrest

Well, made a fool of myself there!

> It's been a while, but what I remember is that DEC actually published
> their own method for doing this but it was surprisingly cumbersome.
> What I described was incredibly simple but effective. I ran many
> Alphas this way with no problems at all.

On OSF/1 T1.0, which is what we got shipped with our first Alphas, we were categorically told by REO that we were on our own. At the time there were four Alphas in the UK: three were ours and one was at REO running OpenVMS in the morning and OSF/1 in the afternoon (or vice-versa) and we spent a long weekend napping on the machine room floor and on caffeine trying to figure out how to get /usr mounted despite the SIA startup script as we had no choice and the cluster needed to be up as it had cost a small fortune.

The later DEC solution I recall requiring more disk space on the clients, which we didn’t have, but I’m sure that later ships with sufficient disk space had less issues.

Another weekend was spent getting TeX and LaTeX running with ghostscript MX’d from the Ultrix MIPS binary as we just couldn’t get it to compile. That it even worked using MX remains one of the most beautiful surprises of that install.

Arrigo 



From arnold at skeeve.com  Fri Sep 28 03:20:11 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 27 Sep 2018 11:20:11 -0600
Subject: [TUHS] The origin of /home
In-Reply-To: <CAEoi9W5mnNCUFWWUVs++=adNP7FfB1=iqH6sv5nRF=DxWRHLXA@mail.gmail.com>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>
 <CAEoi9W5mnNCUFWWUVs++=adNP7FfB1=iqH6sv5nRF=DxWRHLXA@mail.gmail.com>
Message-ID: <201809271720.w8RHKBNh031105@freefriends.org>

Dan Cross <crossd at gmail.com> wrote:

> At some point, the "user's directory" as  denoted in /etc/passwd became
> known as the "home directory." If that was common vernacular by the time
> that `/home` came around as a convention, then it seems a logical name
> stemming from that usage.

It most definitely was common usage before /home came along.

As I recall it, in the System V Release 4 time frame, AT&T, Sun, DEC and
UCB agreed on the division of things into /home, /usr, and /var, with
the impetus being that /usr could be mounted read-only from a single file
server (saving many copies of the same files), /home mounted read-write
(or automounted) and /var holding things that were peculiar to each
system but read-write, such as log files and temporary files.

Diskless workstations, or workstations with very small disks for
holding the root filesystem only, were very popular at the time.

Arnold


From mutiny.mutiny at india.com  Fri Sep 28 03:33:03 2018
From: mutiny.mutiny at india.com (Donald ODona)
Date: Thu, 27 Sep 2018 17:33:03 +0000 (UTC)
Subject: [TUHS] The origin of /home
In-Reply-To: <633187202.18875.1538053129435.JavaMail.tomcat@india-live-be04>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>,
 <633187202.18875.1538053129435.JavaMail.tomcat@india-live-be04>
Message-ID: <2042420101.18686.1538069583443.JavaMail.tomcat@india-live-be03>


At 27 Sep 2018 12:59:50 +0000 (+00:00) from Donald ODona <mutiny.mutiny at india.com>:
to the /usr device.
> Much later in the 80ths much more disk space was available and a separate /home was created. Exacly when I don't know, but there was no /home in Ed. 7 but System V release 3 had it already.

4.3 BSD had it, as I found out, after login in a few sconds ago. 4.3BSD was released in June 1986. Thus the /home appeared in between 1979 (Ed 7) and 1986.


From nobozo at gmail.com  Fri Sep 28 04:49:02 2018
From: nobozo at gmail.com (Jon Forrest)
Date: Thu, 27 Sep 2018 11:49:02 -0700
Subject: [TUHS] The origin of /home
In-Reply-To: <309587CA-4C65-4AFA-ADFF-0E99B430D191@alchemistowl.org>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>
 <633187202.18875.1538053129435.JavaMail.tomcat@india-live-be04>
 <CAC0cEp_CCi5Tjkm4zq1xiWA4mCduphw_N_kae99ZF7rwfk-bgQ@mail.gmail.com>
 <f11ec7b9-0363-1de3-fc72-da8ed7e8f0f7@gmail.com>
 <36C6F216-490E-4DE4-B5EF-CED26899542F@alchemistowl.org>
 <4caca587-4945-c8be-5a35-c9f0ecfdd08b@gmail.com>
 <309587CA-4C65-4AFA-ADFF-0E99B430D191@alchemistowl.org>
Message-ID: <52fac873-cd89-420c-c15f-b67df83aa0d3@gmail.com>



On 9/27/2018 8:54 AM, Arrigo Triulzi wrote:
> On 27 Sep 2018, at 17:36, Jon Forrest <nobozo at gmail.com> wrote:
>> Right, and I am that Jon Forrest
> 
> Well, made a fool of myself there!

That's OK. I do things like that at least once a day.

> On OSF/1 T1.0, which is what we got shipped with our first Alphas, we were
> categorically told by REO that we were on our own.

Those were the days when DEC would tell you all kinds of things.
I remember in the late 80s they told me that TCP/IP wasn't going
to catch on, and that I should stick with DecNet.

> The later DEC solution I recall requiring more disk space on the clients,
> which we didn’t have, but I’m sure that later ships with sufficient disk space had less issues.

I actually started my dataless design back when we were running Ultrix.
It worked fine there too, although back then 10Mbs networking was common
so it wasn't super speedy. Of course, neither were the workstations.

The document I quoted also described how the CS department used
an Auspex file server to serve what we called the "Software Warehouse",
which was a collection of open source software that we built
for all the popular architectures then.

Jon



From beebe at math.utah.edu  Fri Sep 28 04:03:26 2018
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Thu, 27 Sep 2018 12:03:26 -0600
Subject: [TUHS] SPARC is CRAPS spelled backwards.
Message-ID: <CMM.0.95.0.1538071406.beebe@gamma.math.utah.edu>

As a followup to discussions on this thread about hardware
architectures, some of you may be interested in this new letter
published today:

	Letters to the editor: Hennessy and Patterson on the roots of RISC
	Comm. ACM 61(10) 6 (2018)
	https://doi.org/10.1145/3273019
	http://delivery.acm.org/10.1145/3280000/3273019/p6-friedman.pdf

The short two-paragraph letter is from Fred Brooks, noted computer
architect, author, and computer scientist.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------


From cym224 at gmail.com  Fri Sep 28 05:34:38 2018
From: cym224 at gmail.com (Nemo)
Date: Thu, 27 Sep 2018 15:34:38 -0400
Subject: [TUHS] SPARC is CRAPS spelled backwards.
In-Reply-To: <CMM.0.95.0.1538071406.beebe@gamma.math.utah.edu>
References: <CMM.0.95.0.1538071406.beebe@gamma.math.utah.edu>
Message-ID: <CAJfiPzzNudEP3KZ+pUmP__8qW9Dnx7QTt488GWvEG5A2OU0Fhw@mail.gmail.com>

On 27/09/2018, Nelson H. F. Beebe <beebe at math.utah.edu> wrote:
> As a followup to discussions on this thread about hardware
> architectures, some of you may be interested in this new letter
> published today:
>
> 	Letters to the editor: Hennessy and Patterson on the roots of RISC
> 	Comm. ACM 61(10) 6 (2018)
> 	https://doi.org/10.1145/3273019
> 	http://delivery.acm.org/10.1145/3280000/3273019/p6-friedman.pdf

Also of interest may be the video "SPARC at 25"
(https://www.youtube.com/watch?v=w3ukXhEaYGI ), wherein Patterson,
Joy, and others discuss SPARC.  (Joy's comment on register windows is
interesting and matches Brooks' remark.)

N.

>
> The short two-paragraph letter is from Fred Brooks, noted computer
> architect, author, and computer scientist.
>
> -------------------------------------------------------------------------------
> - Nelson H. F. Beebe                    Tel: +1 801 581 5254
>  -
> - University of Utah                    FAX: +1 801 581 4148
>  -
> - Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu
>  -
> - 155 S 1400 E RM 233                       beebe at acm.org
> beebe at computer.org -
> - Salt Lake City, UT 84112-0090, USA    URL:
> http://www.math.utah.edu/~beebe/ -
> -------------------------------------------------------------------------------
>


From crossd at gmail.com  Fri Sep 28 06:15:05 2018
From: crossd at gmail.com (Dan Cross)
Date: Thu, 27 Sep 2018 16:15:05 -0400
Subject: [TUHS] The origin of /home
In-Reply-To: <20180927153353.F354118C08E@mercury.lcs.mit.edu>
References: <20180927153353.F354118C08E@mercury.lcs.mit.edu>
Message-ID: <CAEoi9W60U-SnVAWY7Ya3xYcTh9OvNKyDr3wyqcYOx4EHMkU3Gg@mail.gmail.com>

On Thu, Sep 27, 2018 at 11:34 AM Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Dan Cross
>
>     > particular in sites with lots of users like universities and
>     > production-focused corporate groups
>
> The existence of /usr, /usr/bin, /etc, /lib, etc dates back to the Research
> group at Bell, so I don't think we can look to these other environments
> for an
> explanation.
>

Sorry, I was (very) unclear in this point. I was referring to two separate
things:

1) Why things were spread out across multiple filesystems (space and/or
performance considerations dating from the Bell Labs days), and
2) The notion that rigid structures built in at a very low level would
naturally give rise to local naming conventions as "large" sites grew
beyond the limitations built into the system. E.g., /udd/u1 etc vs /home vs
/usr/users vs /net/somehostname vs /var/users vs whatever. As a concrete
example is the use of name-dependent hierarchical home directory paths like
"/home/c/r/cross" because one tried to put too many directories into /home
(I have actually seen the UFS directory entry limit hit in /home on a
machine that had >32k users). Anyway, eventually through whatever accident
of history "/home" seems to have won as a de facto standard.

    > "Hmm. Well, we've got space in /usr: create /usr/bin
>
> I seem to recall reading (don't recall where, OTTOMY) an explanation for
> the
> creation of /usr/bin, and I think it was performance related; IIRC the
> issue
> was that they wanted to keep the directory size down (both for disk block
> caching, and search time, reasons). Or maybe that was later on, and it was
> originally created for 'user-maintained' ancillary programs (another vague
> memory)?
>

I think the latter might be a justification-after-the-fact: /usr as the
filesystem containing stuff of interest to the users.

    > The more intriguing possibility from the antiquarian point of view is
>     > whether someone coined "/home" and then THAT led to the rise of the
> "home
>     > directory" nomenclature.
>
> My memory is that the term "home directory" predates /home - perhaps on
> other
> OS's such as TOPS-20, but I don't have time to research that. (I did look
> quickly in the Multics docs, and it has 'working directory', i.e. current
> dir
> - but it refers to the home dir as 'original WD', i.e. the WD at the time
> of
> login.)
>

If I recall correctly, the mappings from "users" on TOPS-20 to directories
is an injection, but I don't think they used the "home directory"
nomenclature.

Certainly the analogy with one's directory as home is clear enough.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180927/108b52a1/attachment.html>

From crossd at gmail.com  Fri Sep 28 06:30:25 2018
From: crossd at gmail.com (Dan Cross)
Date: Thu, 27 Sep 2018 16:30:25 -0400
Subject: [TUHS] SPARC is CRAPS spelled backwards.
In-Reply-To: <CMM.0.95.0.1538071406.beebe@gamma.math.utah.edu>
References: <CMM.0.95.0.1538071406.beebe@gamma.math.utah.edu>
Message-ID: <CAEoi9W7UcM=JxPudNSccecuXvr8c4UKdmkmDxRuh27CELqYhxQ@mail.gmail.com>

On Thu, Sep 27, 2018 at 3:16 PM Nelson H. F. Beebe <beebe at math.utah.edu>
wrote:

> As a followup to discussions on this thread about hardware
> architectures, some of you may be interested in this new letter
> published today:
>
>         Letters to the editor: Hennessy and Patterson on the roots of RISC
>         Comm. ACM 61(10) 6 (2018)
>         https://doi.org/10.1145/3273019
>         http://delivery.acm.org/10.1145/3280000/3273019/p6-friedman.pdf


Aside: This is taking an inordinately long time to download from the ACM.
It must be "the TUHS effect."

        - Dan C.


> The short two-paragraph letter is from Fred Brooks, noted computer
> architect, author, and computer scientist.
>
>
> -------------------------------------------------------------------------------
> - Nelson H. F. Beebe                    Tel: +1 801 581 5254
>     -
> - University of Utah                    FAX: +1 801 581 4148
>     -
> - Department of Mathematics, 110 LCB    Internet e-mail:
> beebe at math.utah.edu  -
> - 155 S 1400 E RM 233                       beebe at acm.org
> beebe at computer.org -
> - Salt Lake City, UT 84112-0090, USA    URL:
> http://www.math.utah.edu/~beebe/ -
>
> -------------------------------------------------------------------------------
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180927/26144b1b/attachment.html>

From ca6c at bitmessage.ch  Fri Sep 28 06:42:37 2018
From: ca6c at bitmessage.ch (=?utf-8?B?Q8OhZw==?=)
Date: Thu, 27 Sep 2018 15:42:37 -0500
Subject: [TUHS] The origin of /home
In-Reply-To: <CAEoi9W5mnNCUFWWUVs++=adNP7FfB1=iqH6sv5nRF=DxWRHLXA@mail.gmail.com>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>
 <CAEoi9W5mnNCUFWWUVs++=adNP7FfB1=iqH6sv5nRF=DxWRHLXA@mail.gmail.com>
Message-ID: <20180927204237.h3kQJ%ca6c@bitmessage.ch>


Thanks for such an interesting and informative answer, Mr. Cross.

Dan Cross wrote:

> 4.4BSD had a convention of placing user home directories in /a, /b,
> etc.

Do I understand it correctly: they were in just "slash a/b/etc" in
root? Not /home/a or /usr/a but just /a?

> 4.4BSD-Lite also had /var/users.

Was it /var/users/$(user) or /var/$(user)?


To everyone: thanks for all the answers, it's always interesting to read
such things. I try not to miss a single mail after signing up for the
list.

This question actually came up long ago when I first tried Plan 9,
which, as you know, has the directory in /usr, and it was released in
90s, after 4.4BSD. Of course, Plan 9 is(not) (Research) Unix, and
doesn't have a root user, and apparently has a different rationale
behind it -- if I'm not mistaken, it has bin, lib and something else
there, none of which are usually present in /home these days, even bin
is usually in /usr/local.

--
caóc



From steve at quintile.net  Fri Sep 28 06:50:58 2018
From: steve at quintile.net (Steve Simon)
Date: Thu, 27 Sep 2018 21:50:58 +0100
Subject: [TUHS] /home
Message-ID: <A1A27D12-7A36-4507-9CB4-C73F0B5AE84A@quintile.net>


At college we had /h but that may be an interdata/edition7 thing. mine was /h/beng4/ssimon.

each course/year was in a separate disk partition - if group filled their partition other groups could still work.

-Steve


From ca6c at bitmessage.ch  Fri Sep 28 06:51:31 2018
From: ca6c at bitmessage.ch (=?utf-8?B?Q8OhZw==?=)
Date: Thu, 27 Sep 2018 15:51:31 -0500
Subject: [TUHS] SPARC is CRAPS spelled backwards.
In-Reply-To: <CAEoi9W7UcM=JxPudNSccecuXvr8c4UKdmkmDxRuh27CELqYhxQ@mail.gmail.com>
References: <CMM.0.95.0.1538071406.beebe@gamma.math.utah.edu>
 <CAEoi9W7UcM=JxPudNSccecuXvr8c4UKdmkmDxRuh27CELqYhxQ@mail.gmail.com>
Message-ID: <20180927205131.TuTBR%ca6c@bitmessage.ch>

Dan Cross wrote:

>>         Letters to the editor: Hennessy and Patterson on the roots of RISC
>>         Comm. ACM 61(10) 6 (2018)
>>         https://doi.org/10.1145/3273019
>>         http://delivery.acm.org/10.1145/3280000/3273019/p6-friedman.pdf
> 
> Aside: This is taking an inordinately long time to download from the ACM.
> It must be "the TUHS effect."

For me it doesn't even work:
"An error occurred while processing your request."

--
caóc



From henry.r.bent at gmail.com  Fri Sep 28 07:01:15 2018
From: henry.r.bent at gmail.com (Henry Bent)
Date: Thu, 27 Sep 2018 17:01:15 -0400
Subject: [TUHS] SPARC is CRAPS spelled backwards.
In-Reply-To: <20180927205131.TuTBR%ca6c@bitmessage.ch>
References: <CMM.0.95.0.1538071406.beebe@gamma.math.utah.edu>
 <CAEoi9W7UcM=JxPudNSccecuXvr8c4UKdmkmDxRuh27CELqYhxQ@mail.gmail.com>
 <20180927205131.TuTBR%ca6c@bitmessage.ch>
Message-ID: <CAEdTPBdEY-+Xh1nXxiH38GJ=zAJ_3h1tJNNwrZ2mXdzg72F31A@mail.gmail.com>

On Thu, 27 Sep 2018 at 16:52, Cág <ca6c at bitmessage.ch> wrote:

> Dan Cross wrote:
>
> >>         Letters to the editor: Hennessy and Patterson on the roots of
> RISC
> >>         Comm. ACM 61(10) 6 (2018)
> >>         https://doi.org/10.1145/3273019
> >>         http://delivery.acm.org/10.1145/3280000/3273019/p6-friedman.pdf
> >
> > Aside: This is taking an inordinately long time to download from the ACM.
> > It must be "the TUHS effect."
>
> For me it doesn't even work:
> "An error occurred while processing your request."
>

The direct PDF link that Nelson posted doesn't work, but if you go to the
first link and select "PDF" it should work.

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

From ca6c at bitmessage.ch  Fri Sep 28 07:04:19 2018
From: ca6c at bitmessage.ch (=?utf-8?B?Q8OhZw==?=)
Date: Thu, 27 Sep 2018 16:04:19 -0500
Subject: [TUHS] SPARC is CRAPS spelled backwards.
In-Reply-To: <CAEdTPBdEY-+Xh1nXxiH38GJ=zAJ_3h1tJNNwrZ2mXdzg72F31A@mail.gmail.com>
References: <CMM.0.95.0.1538071406.beebe@gamma.math.utah.edu>
 <CAEoi9W7UcM=JxPudNSccecuXvr8c4UKdmkmDxRuh27CELqYhxQ@mail.gmail.com>
 <20180927205131.TuTBR%ca6c@bitmessage.ch>
 <CAEdTPBdEY-+Xh1nXxiH38GJ=zAJ_3h1tJNNwrZ2mXdzg72F31A@mail.gmail.com>
Message-ID: <20180927210419.KyQbu%ca6c@bitmessage.ch>

Henry Bent wrote:

> The direct PDF link that Nelson posted doesn't work, but if you go to the
> first link and select "PDF" it should work.

Thanks! Is it intended?

--
caóc



From crossd at gmail.com  Fri Sep 28 07:07:30 2018
From: crossd at gmail.com (Dan Cross)
Date: Thu, 27 Sep 2018 17:07:30 -0400
Subject: [TUHS] The origin of /home
In-Reply-To: <20180927204237.h3kQJ%ca6c@bitmessage.ch>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>
 <CAEoi9W5mnNCUFWWUVs++=adNP7FfB1=iqH6sv5nRF=DxWRHLXA@mail.gmail.com>
 <20180927204237.h3kQJ%ca6c@bitmessage.ch>
Message-ID: <CAEoi9W5Ex3RzCzTMDZOUZCG81YZZTqyWfWhuLxeadQfT1JKUcw@mail.gmail.com>

On Thu, Sep 27, 2018 at 4:43 PM Cág <ca6c at bitmessage.ch> wrote:

>
> Thanks for such an interesting and informative answer, Mr. Cross.
>

I'm happy to write it!

Dan Cross wrote:
>
> > 4.4BSD had a convention of placing user home directories in /a, /b,
> > etc.
>
> Do I understand it correctly: they were in just "slash a/b/etc" in
> root? Not /home/a or /usr/a but just /a?
>

Correct. I believe the idea was to program the automounter to make these
appear in some directory like /home, but the directories themselves lived
in /a, /b, etc. Presumably these were mount points for separate
disk-resident filesystems.

> 4.4BSD-Lite also had /var/users.
>
> Was it /var/users/$(user) or /var/$(user)?
>

/var/users/$user. For example, 4.4BSD-Lite1 contains entries for Ken and
Dennis in /etc/master.passwd:

dmr:*:10:31::0:0:Dennis Ritchie:/var/users/guest/dmr:
ken:*:11:31::0:0:& Thompson:/var/users/guest/ken:

To everyone: thanks for all the answers, it's always interesting to read
> such things. I try not to miss a single mail after signing up for the
> list.
>
> This question actually came up long ago when I first tried Plan 9,
> which, as you know, has the directory in /usr, and it was released in
> 90s, after 4.4BSD. Of course, Plan 9 is(not) (Research) Unix, and
> doesn't have a root user, and apparently has a different rationale
> behind it -- if I'm not mistaken, it has bin, lib and something else
> there, none of which are usually present in /home these days, even bin
> is usually in /usr/local.
>

Plan 9 represented an opportunity to do things over. Many of us rather
liked it and thought it was a worthy successor to Unix, but it never caught
on in the larger world and now, in the bathed in the cold light of history,
some of its faults are evident.

The issue with bin/ is that it's in several places. In plan9, these are all
bound onto /bin, which is nice.

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

From norman at oclsc.org  Fri Sep 28 07:07:40 2018
From: norman at oclsc.org (Norman Wilson)
Date: Thu, 27 Sep 2018 17:07:40 -0400
Subject: [TUHS] SPARC is CRAPS spelled backwards.
Message-ID: <1538082464.23158.for-standards-violators@oclsc.org>

NUXIi  s artdamera kfoB le laLobarotirse

(A few of you are expected to understand this.)

Norman Wilson
Toronto ON


From clemc at ccc.com  Fri Sep 28 08:04:49 2018
From: clemc at ccc.com (Clem Cole)
Date: Thu, 27 Sep 2018 18:04:49 -0400
Subject: [TUHS] The origin of /home
In-Reply-To: <CAEoi9W5Ex3RzCzTMDZOUZCG81YZZTqyWfWhuLxeadQfT1JKUcw@mail.gmail.com>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>
 <CAEoi9W5mnNCUFWWUVs++=adNP7FfB1=iqH6sv5nRF=DxWRHLXA@mail.gmail.com>
 <20180927204237.h3kQJ%ca6c@bitmessage.ch>
 <CAEoi9W5Ex3RzCzTMDZOUZCG81YZZTqyWfWhuLxeadQfT1JKUcw@mail.gmail.com>
Message-ID: <CAC20D2O_keNWjS+YDgYdMt1Gsq-Qbk3NFCJHTzZ6=DkzGOizXw@mail.gmail.com>

I wish I could remember exactly everything happened, but I cannot say I
do.    Dan Cross, Don and Noel have all said things that line up with what
I remember.   I’m actually thinking the /home came out of a set of
discussions that occurred before what would eventually be called UNIX
International.



As, Noel says, I do remember using the term ‘home directory’ as a student,
so it is likely that was a term being used either by the old PDP-10 or IBM
shops; but like Noel, I cannot pin the term down either.



Don noted that the /home does not come to the BSD strain until 1986, which
also makes sense; because one of the goals of 4.3BSD was to try to make BSD
a little less divergent from the other UNIX paths, and one of the things
Keith did was to start to made an effort to try use some of the same
conventions the industry (Sun and AT&T in particular) were using.



Dan Cross made the most important note and that is that in the early days
the size a disk was quite small.  UNIX Sixth and Seventh edition often ran
on systems that 2 or 3 RK05 drives of 2.5M each [
https://en.wikipedia.org/wiki/RK05] and as Dan point out, there were limits
to the what got put in the what file system.   Simply the guiding principle
at that time was that you stored in the root filesystem; just enough to the
boot the system, pushed everything else to /usr and then used UNIX
mount/name space splicing/path mechanisms to make a uniform set of paths.



BTW: A thing to remember is that symbolic links are not a wide spread when
all of this was going on in the early 1980s, so they really did not have a
lot to do with the /home idea.  In the case of symbolic links, Dennis had
created them as part of V8, but 4.1BSD and System III (PWB 3.0) did not
have the idea yet.   BSD 4.2 would later get them as part of FFS, but I
don’t remember if 4.1c did (the kernel source was not in Warren’s browsable
archive so I could not check).   Dennis had showed them to me on a visit, I
thought they were cool and useful, and put them in Masscomp’s RTU (which
was a System III/4.1 mash up) and then created CDL’s shortly thereafter
which we used for what later Pyramid called Universes (we called it modes
originally but started calling it universes also because it sounded
cooler).    Sun picked up symlinks when they went to the 4.2 kernel and BSD
FFS.



The other missing item was quotas.   The universities in particular needed
quotas, which is one of the reasons why Joy added it to 4.2, as it was a
requested feature by the DARPA community. Before 4.2, people used the
partition size within the disk as a way to have some sort of quotas.



So what happened?



The factiod no one has brought up so far is what would become the
/usr/group standards committee (later Unix International (UI) and before
that was the work Heinz Lycklama and Peter Weiner were doing at Interactive
Systems Corp (ISC).  Heinz wanted an industry wide ABI and was pretty vocal
about it.  He felt the ISVs would never take UNIX seriously if there were
not ‘one true >>binary<< system’ that they compiled too.   The /usr/group
API work got started from that and was the compromise, a programming
interface, not an binary one.   But during the discussions that led up to
the standards committee was a series of meetings originally at USENIX ATC,
where we began to talk about the naming conventions.  They were trying to
agree what needs to be in /bin, /usr/bin, /lib, /usr/lib etc…  and to make
them more 'readonly-ish' primarily so that programs that went amok, did the
least amount of damage.     This was also where the idea of /usr/opt and
/var were born.  /usr/local was a UCB-ism, but people used it for stuff the
built themselves.    Most installed systems /usr1 /usr2 … where the actual
user files were stored.  The commercial folks wanted it more like other
systems were there were some sorts of fences around things.



But …it was basically agreed by the commercial side, that if there ever
were going to be any hope for the ISVs to be able to ship a binary, each
ISV needed her/his own spot.  The idea for them was
/usr/opt/hp,  /usr/opt/intel, /usr/opt/msft and then under that the usual
bin, etc, include, lib, …  Equally /var was deal with things like logs
which were being to show up (the printer and shell accounting were first),
but that way ISVs and random programs did not step on each other.    I
think HP might have actuallybeen  the first of the vendors to start to ship
using that convention, but USL did pick it up by the time of System
V. Similarly, at some point the /usr1, /usr2 etc  … switched to /home
/home1 /home2 etc…     I do remember that there HP guys where pretty vocal
in the arguments when it all went down.





There was (should be) an email/netnews article kicking around with the name
something like ‘standardized UNIX file tree’ or some such.   I would think
this was about 1984 or 1985 time frame.   This email/article was part of
the model that Keith used for 4.3BSD later on; but it is also where my
memory gets hazy and I lost those notebooks in the flood.



I cannot swear by it, but I do seem to think I remember that /home was one
of the directories that came out of that discussion.  The timing is
certainly right, as is the reasoning.


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

From clemc at ccc.com  Fri Sep 28 08:09:09 2018
From: clemc at ccc.com (Clem Cole)
Date: Thu, 27 Sep 2018 18:09:09 -0400
Subject: [TUHS] /home
In-Reply-To: <A1A27D12-7A36-4507-9CB4-C73F0B5AE84A@quintile.net>
References: <A1A27D12-7A36-4507-9CB4-C73F0B5AE84A@quintile.net>
Message-ID: <CAC20D2OvBQO1+fbiFpBmj0nVBTKHu4z-BWqj+cXF2-EDezqSVg@mail.gmail.com>

Right...  was how quotas were done before FFS and 4.2 and very typical of a
university set up
ᐧ

On Thu, Sep 27, 2018 at 4:51 PM Steve Simon <steve at quintile.net> wrote:

>
> At college we had /h but that may be an interdata/edition7 thing. mine was
> /h/beng4/ssimon.
>
> each course/year was in a separate disk partition - if group filled their
> partition other groups could still work.
>
> -Steve
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180927/4a59ed23/attachment.html>

From henry.r.bent at gmail.com  Fri Sep 28 08:18:51 2018
From: henry.r.bent at gmail.com (Henry Bent)
Date: Thu, 27 Sep 2018 18:18:51 -0400
Subject: [TUHS] The origin of /home
In-Reply-To: <CAC20D2O_keNWjS+YDgYdMt1Gsq-Qbk3NFCJHTzZ6=DkzGOizXw@mail.gmail.com>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>
 <CAEoi9W5mnNCUFWWUVs++=adNP7FfB1=iqH6sv5nRF=DxWRHLXA@mail.gmail.com>
 <20180927204237.h3kQJ%ca6c@bitmessage.ch>
 <CAEoi9W5Ex3RzCzTMDZOUZCG81YZZTqyWfWhuLxeadQfT1JKUcw@mail.gmail.com>
 <CAC20D2O_keNWjS+YDgYdMt1Gsq-Qbk3NFCJHTzZ6=DkzGOizXw@mail.gmail.com>
Message-ID: <CAEdTPBc=7xMN=T943Y765ko25R_OGb0CStkBO_JJ+OQryaM-iA@mail.gmail.com>

On Thu, 27 Sep 2018 at 18:06, Clem Cole <clemc at ccc.com> wrote:

>
> BTW: A thing to remember is that symbolic links are not a wide spread when
> all of this was going on in the early 1980s, so they really did not have a
> lot to do with the /home idea.  In the case of symbolic links, Dennis had
> created them as part of V8, but 4.1BSD and System III (PWB 3.0) did not
> have the idea yet.   BSD 4.2 would later get them as part of FFS, but I
> don’t remember if 4.1c did (the kernel source was not in Warren’s browsable
> archive so I could not check).
>

4.1c did indeed have symlinks; the  "4.1c.1" source on the CSRG CD set has
the code for them.  lib/libc/sys/symlink.c revision 4.1 is dated 82/12/04,
so that's about the time they went in.

-Henry

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

From jnc at mercury.lcs.mit.edu  Fri Sep 28 09:14:19 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu, 27 Sep 2018 19:14:19 -0400 (EDT)
Subject: [TUHS] The origin of /home
Message-ID: <20180927231419.6C71718C08E@mercury.lcs.mit.edu>

    > My memory is that the term "home directory" predates /home - perhaps on
    > other OS's such as TOPS-20, but I don't have time to research that.

Well, I looked at the "Introduction to MIT-XX" (a TOPS-20 machine), and it
also used the terms "logged-in directory" (home dir) and "connected directory"
(current dir).

I couldn't find any use of 'home' in the V6 documentation.

I _did_ find "home directory" in the ITS documentation; the oldest doc file I
found it in was dated 5/25/79. If ITS was the source, not sure how it spread -
maybe via EMACS?

       Noel


From grog at lemis.com  Fri Sep 28 10:14:09 2018
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Fri, 28 Sep 2018 10:14:09 +1000
Subject: [TUHS] /home
In-Reply-To: <A1A27D12-7A36-4507-9CB4-C73F0B5AE84A@quintile.net>
References: <A1A27D12-7A36-4507-9CB4-C73F0B5AE84A@quintile.net>
Message-ID: <20180928001409.GH75165@eureka.lemis.com>

On Thursday, 27 September 2018 at 21:50:58 +0100, Steve Simon wrote:
>
> At college we had /h but that may be an interdata/edition7
> thing. mine was /h/beng4/ssimon.

This sounds like a workaround for short pathname limits, particularly
with System V.  I had a file system mounted on /S for the same reason
decades ago.

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

From imp at bsdimp.com  Fri Sep 28 10:19:51 2018
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 27 Sep 2018 18:19:51 -0600
Subject: [TUHS] /home
In-Reply-To: <20180928001409.GH75165@eureka.lemis.com>
References: <A1A27D12-7A36-4507-9CB4-C73F0B5AE84A@quintile.net>
 <20180928001409.GH75165@eureka.lemis.com>
Message-ID: <CANCZdfrUNH3RoAcA7_26ms=ymDv2H5ywiyxjWagRSqvR8N5i4w@mail.gmail.com>

On Thu, Sep 27, 2018 at 6:14 PM Greg 'groggy' Lehey <grog at lemis.com> wrote:

> On Thursday, 27 September 2018 at 21:50:58 +0100, Steve Simon wrote:
> >
> > At college we had /h but that may be an interdata/edition7
> > thing. mine was /h/beng4/ssimon.
>
> This sounds like a workaround for short pathname limits, particularly
> with System V.  I had a file system mounted on /S for the same reason
> decades ago.


At Solboure, we had /h/admin /o/os /o/home /x/build /x/home /x/prod etc.
The reason for this was the SunOS automounter and bugs it had that required
each machine to have a different top level directory. Luckily we only had
like 4 servers... This was to prevent hanging /h mounts when the /x machine
would go away and someone would do an ls in that directory. That bug got
fixed in the 4.0 -> 4.1 transition, but we none-the-less kept the structure
because it was too painful to transition...

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

From tytso at mit.edu  Fri Sep 28 10:50:01 2018
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Thu, 27 Sep 2018 20:50:01 -0400
Subject: [TUHS] The origin of /home
In-Reply-To: <52fac873-cd89-420c-c15f-b67df83aa0d3@gmail.com>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>
 <633187202.18875.1538053129435.JavaMail.tomcat@india-live-be04>
 <CAC0cEp_CCi5Tjkm4zq1xiWA4mCduphw_N_kae99ZF7rwfk-bgQ@mail.gmail.com>
 <f11ec7b9-0363-1de3-fc72-da8ed7e8f0f7@gmail.com>
 <36C6F216-490E-4DE4-B5EF-CED26899542F@alchemistowl.org>
 <4caca587-4945-c8be-5a35-c9f0ecfdd08b@gmail.com>
 <309587CA-4C65-4AFA-ADFF-0E99B430D191@alchemistowl.org>
 <52fac873-cd89-420c-c15f-b67df83aa0d3@gmail.com>
Message-ID: <20180928005001.GA2320@thunk.org>

On Thu, Sep 27, 2018 at 11:49:02AM -0700, Jon Forrest wrote:
> 
> I actually started my dataless design back when we were running Ultrix.
> It worked fine there too, although back then 10Mbs networking was common
> so it wasn't super speedy. Of course, neither were the workstations.

MIT Project Athena had a dataless design in the late 1980's.  For
read-only remote file systems, Athena developed a Remote Virtual Disk
(RVD) which was intergrated into BSD 4.3.  RVD was a networked block
device, since for read-only file systems it had better scaling
properties than NFS.

The Athena technical plan talks about it in a fair amount of detail.

	http://web.mit.edu/Saltzer/www/publications/atp.html

By 1988 or so we had hundreds of workstations all over MIT that had
its system softare deliviered via RVD, and for which no data would be
stored on the public workstations, which were managed using the
"cattle" metaphor.  If a system wasn't working correctly, a
workstation could be TFTP booted and the base software could be
reinstalled automatically, and the reinstall was fast because the only
files that had to be installed on the local disk was essentially
enough for the system to come up on the network and to mount the RVD.

       	       	      	      	    - Ted


From doug at cs.dartmouth.edu  Fri Sep 28 12:39:43 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Thu, 27 Sep 2018 22:39:43 -0400
Subject: [TUHS] The origin of /home
Message-ID: <201809280239.w8S2dhpX048249@tahoe.cs.Dartmouth.EDU>

> I couldn't find any use of 'home' in the V6 documentation.

$HOME was set by default in v7. It probably dates from the
advent of enviroment variables.

Doug


From lars at nocrew.org  Fri Sep 28 15:27:42 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Fri, 28 Sep 2018 05:27:42 +0000
Subject: [TUHS] The origin of /home
In-Reply-To: <20180927231419.6C71718C08E@mercury.lcs.mit.edu> (Noel Chiappa's
 message of "Thu, 27 Sep 2018 19:14:19 -0400 (EDT)")
References: <20180927231419.6C71718C08E@mercury.lcs.mit.edu>
Message-ID: <7wftxu9ooh.fsf@junk.nocrew.org>

Noel Chiappa writes:
> I _did_ find "home directory" in the ITS documentation; the oldest doc
> file I found it in was dated 5/25/79. If ITS was the source, not sure
> how it spread - maybe via EMACS?

I see "home directory" in an ITS file from 1976 (.TECO.; TECORD 508).

There could be a hint the AI memos, but they are hard to search.


From dot at dotat.at  Fri Sep 28 18:33:45 2018
From: dot at dotat.at (Tony Finch)
Date: Fri, 28 Sep 2018 09:33:45 +0100
Subject: [TUHS] The origin of /home
In-Reply-To: <CAEoi9W5mnNCUFWWUVs++=adNP7FfB1=iqH6sv5nRF=DxWRHLXA@mail.gmail.com>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>
 <CAEoi9W5mnNCUFWWUVs++=adNP7FfB1=iqH6sv5nRF=DxWRHLXA@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1809280929040.3596@grey.csi.cam.ac.uk>

Dan Cross <crossd at gmail.com> wrote:
>
> I intentionally eschew /home on a few systems. 4.4BSD had a convention of
> placing user home directories in /a, /b, etc. 4.4BSD-Lite also had
> /var/users. Both of which I occasionally use.

The /a convention seems to go back quite a long way. I was looking through
old password files to see where the home directories were, e.g.

https://www.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/etc/passwd

has a lot of /a/guest whereas 4.3BSD has /usr/guest

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
safeguard the balance of nature and the environment


From beebe at math.utah.edu  Fri Sep 28 22:08:21 2018
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Fri, 28 Sep 2018 06:08:21 -0600
Subject: [TUHS] SPARC is CRAPS spelled backwards.
Message-ID: <CMM.0.96.0.1538136501.beebe@gamma.math.utah.edu>

Noel Chiappa <jnc at mercury.lcs.mit.edu> comments on the use of "home
directory" on Thu, 27 Sep 2018 19:14:19 -0400 (EDT):

>> I _did_ find "home directory" in the ITS documentation; the oldest doc file I
>> found it in was dated 5/25/79. If ITS was the source, not sure how it spread -
>> maybe via EMACS?

I looked in my own TECO code (> 12K lines), and found "home directory"
in two files with internal date headers from 1983.

I scanned my archive of TOPS-20 emacs source code and found these
uses:

	% grep -i 'home dire' *
	babyl.info:operating system; this file resides in the user's "home directory" and
	conv.info:stands for the user's home directory.  If neither file exists, the
	emacs.info:Home Directory  Your home directory is the one on which your mail and
	emacs.info:                may be the same as your home directory's name.
	emacs.mss:@Index{Home Directory}@Index{User Name}
	emacs.mss:it should be called @ITS{<home directory>;<user name> EVARS instead of EMACS.}
	emacs.mss:@Index{Home Directory}
	emacs.mss:EMACS into the file @ITS[<home directory>;TS ESAVE]@Twenex[ESAVE.EXE].
	Binary file mkdump.info matches
	teco.archiv:*) FS U HSNAMEnd FS U MAILllow you to get a user's home directory
	teco.archiv:* FS HSNAME$ is the user's home directory, as a numeric sixbit word.
	teco.archiv:On old versions of ITS that don't have home directories, it is the
	teco.archiv:same as FS MSNAME$.  The home directory is (presumably) where such things
	teco.archiv: B) People whose home directory is a shared directory
	tecord.info:    If you @EJ a file TS FOO on your home directory, then FOO^K
	tecord.info:FS HSNAME   s the user's home directory.  The home directory
	tecord.ref:FS HSNAME    user's home directory
	tecord.ref:FS U HSNAME  used to determine a user's home directory

Here are the file dates:

	% grep -l -i 'home dire' * | xargs ls -log
	-rw-r--r-- 1  51376 Jun  5  1981 babyl.info
	-rw-r--r-- 1  81689 Oct 16  1981 conv.info
	-rw-r--r-- 1 466772 Dec 28  1981 emacs.info
	-rw-r--r-- 1 412673 Oct 16  1981 emacs.mss
	-rw-r--r-- 1  12570 May 24  1982 mkdump.info
	-rw-r--r-- 1 121865 Oct 16  1981 teco.archiv
	-rw-r--r-- 1 225207 Oct 16  1981 tecord.info
	-rw-r--r-- 1  16407 Dec 28  1981 tecord.ref

In another directory named emacs-162, there were 18 files containing
"home directory"; the oldest is dated 6-Mar-1980.

However, when I dug into teco.archiv, I found that the match occurred
in a change log block that begins

	TECO 699:
	RMS 10/14/77  Many changes
	...
	ITS only:

Thus, 14-Oct-1977 is the earliest date that I can find for "home
directory", credited to Richard Stallman.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------


From cym224 at gmail.com  Sat Sep 29 02:02:55 2018
From: cym224 at gmail.com (Nemo)
Date: Fri, 28 Sep 2018 12:02:55 -0400
Subject: [TUHS] The origin of /home
In-Reply-To: <20180927120854.u8rei%ca6c@bitmessage.ch>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>
Message-ID: <CAJfiPzztS2jqYWDKCxVfrZ8Sxe9KEtedqwRjY0wMYN2w=aGCNg@mail.gmail.com>

On 27/09/2018, Cág <ca6c at bitmessage.ch> wrote (in part):
> Hi,
>
> The earliest I've found to be in the FHS from '94. Are there any earlier
> examples of a home directory being at /home instead of /usr/$(user)? Are
> there any current Unix systems that don't use /home by default (except
> OSX)?

This is a bit late but Solaris uses /export/home by default.

N.

> Does anybody here do it intentionally? Also, what was the
> rationale of moving the directory to /home?
>
> Thanks!
>
> --
> caóc


From gtaylor at tnetconsulting.net  Sat Sep 29 02:15:07 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Fri, 28 Sep 2018 10:15:07 -0600
Subject: [TUHS] The origin of /home
In-Reply-To: <CAJfiPzztS2jqYWDKCxVfrZ8Sxe9KEtedqwRjY0wMYN2w=aGCNg@mail.gmail.com>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>
 <CAJfiPzztS2jqYWDKCxVfrZ8Sxe9KEtedqwRjY0wMYN2w=aGCNg@mail.gmail.com>
Message-ID: <fb1dbcce-07ba-c166-d1a0-b59f0ef26486@spamtrap.tnetconsulting.net>

On 09/28/2018 10:02 AM, Nemo wrote:
> This is a bit late but Solaris uses /export/home by default.

I disagree.

Or at least not as such.

Many Solaris systems I've used have put homes in /export/home.  But they 
are /NOT/ supposed to be used /directly/ as the home directory.  The 
intention that they would be NFS exports and that said export would be 
auto mounted to /home.

The /export/home is really the /export/ point, /not/ the location that 
is supposed to be used.



-- 
Grant. . . .
unix || die

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

From krewat at kilonet.net  Sat Sep 29 03:28:01 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Fri, 28 Sep 2018 13:28:01 -0400
Subject: [TUHS] The origin of /home
In-Reply-To: <fb1dbcce-07ba-c166-d1a0-b59f0ef26486@spamtrap.tnetconsulting.net>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>
 <CAJfiPzztS2jqYWDKCxVfrZ8Sxe9KEtedqwRjY0wMYN2w=aGCNg@mail.gmail.com>
 <fb1dbcce-07ba-c166-d1a0-b59f0ef26486@spamtrap.tnetconsulting.net>
Message-ID: <bebc352f-daf1-ec0b-d851-205cbb38a768@kilonet.net>

On 9/28/2018 12:15 PM, Grant Taylor via TUHS wrote:
> On 09/28/2018 10:02 AM, Nemo wrote:
>> This is a bit late but Solaris uses /export/home by default.
>
> I disagree.
>
> Or at least not as such.
>
> Many Solaris systems I've used have put homes in /export/home. But 
> they are /NOT/ supposed to be used /directly/ as the home directory.  
> The intention that they would be NFS exports and that said export 
> would be auto mounted to /home.
>
> The /export/home is really the /export/ point, /not/ the location that 
> is supposed to be used.
>
>
Solaris 10 u10:

beef / # useradd asdf
beef / # grep asdf /etc/passwd
asdf:x:504:1::/home/asdf:/bin/sh

Solaris 11.3:
medusa# useradd asdf
medusa# grep asdf /etc/passwd
asdf:x:65540:10::/export/home/asdf:/usr/bin/bash

When creating a user on Solaris 11, because it requires you to install a 
regular user because you can't login directly as root, it creates the 
home directory in /export/home

Interesting. To be honest, I did not expect Solaris 10 to use /home as 
the default.


From reed at reedmedia.net  Sat Sep 29 04:23:20 2018
From: reed at reedmedia.net (Jeremy C. Reed)
Date: Fri, 28 Sep 2018 13:23:20 -0500 (CDT)
Subject: [TUHS] The origin of /home
In-Reply-To: <alpine.DEB.2.20.1809280929040.3596@grey.csi.cam.ac.uk>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>
 <CAEoi9W5mnNCUFWWUVs++=adNP7FfB1=iqH6sv5nRF=DxWRHLXA@mail.gmail.com>
 <alpine.DEB.2.20.1809280929040.3596@grey.csi.cam.ac.uk>
Message-ID: <alpine.NEB.2.20.1809281232250.6473@t1.m.reedmedia.net>

On Fri, 28 Sep 2018, Tony Finch wrote:

> > I intentionally eschew /home on a few systems. 4.4BSD had a convention of
> > placing user home directories in /a, /b, etc. 4.4BSD-Lite also had
> > /var/users. Both of which I occasionally use.
> 
> The /a convention seems to go back quite a long way. I was looking through
> old password files to see where the home directories were, e.g.
> 
> https://www.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/etc/passwd
> 
> has a lot of /a/guest whereas 4.3BSD has /usr/guest

And the 4.3BSD docs show the /a, /b, /c
https://www.tuhs.org/cgi-bin/utree.pl?file=4.3BSD/usr/man/man8/adduser.8

  Traditionally, user files live on a file system different from /usr.
  Typically the user file systems are mounted on a directories in the
  root named sequentially starting from from the beginning of the
  alphabet, eg /a, /b, /c, etc.  On each such file system there are
  subdirectories there for each group of users, i.e.: ``/a/staff'' and
  ``/b/prof''.  This is not strictly necessary but keeps the number of
  files in the top level directories reasonably small.

By the way, Berkeley early on (at time of the first Berkeley tape) had a 
separate /etc/htmp database to list user's home (or alternate home) 
directories (so didn't have to search "large password files" which were 
"unreasonably slow") and terminal type (part of the precursor to 
termcap). The home's then were like /mnt/staff/mosher, 
/mnt/quals/katseff, /mnt/chuck/, /mnt/jeff. Joy's early 2BSD csh docs 
show /mnt/bill and /usr/ken as "home directory" examples. And 3BSD's 
adduser docs show:

  Traditionally, user files live on the file system /mnt and there are
  subdirectories there for each group of users, i.e.: 
  ``/mnt/staff'' and ``/mnt/prof''.

This got changed for 4BSD (4.0BSD):

  Traditionally, user files live on a file system which has the machines 
  single letter net(1) address as the first of two characters.  Thus on 
  the Berkeley CS Department VAX, whose Berknet address is ``csvax'' 
  abbreviated ``v'' the user file systems are mounted on ``/va'',
  ``/vb'', etc.  On each such filesystem there are subdirectories 
  there for each group of users, i.e.: ``/va/staff'' and ``/vb/prof''.  
  This is not strictly necessary but keeps the number of files in the 
  top level directories reasonably small.

(where net(1) is Schmidt's Berkeley Network)

As for 4.3BSD the only reference I find of /home is from the aardvark 
game from Mike Urban of UCLA (/home/urban). (That is the earliest 
reference of a directory called /home/ I found.)


From gtaylor at tnetconsulting.net  Sat Sep 29 05:38:26 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Fri, 28 Sep 2018 13:38:26 -0600
Subject: [TUHS] The origin of /home
In-Reply-To: <bebc352f-daf1-ec0b-d851-205cbb38a768@kilonet.net>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>
 <CAJfiPzztS2jqYWDKCxVfrZ8Sxe9KEtedqwRjY0wMYN2w=aGCNg@mail.gmail.com>
 <fb1dbcce-07ba-c166-d1a0-b59f0ef26486@spamtrap.tnetconsulting.net>
 <bebc352f-daf1-ec0b-d851-205cbb38a768@kilonet.net>
Message-ID: <b4b556a3-6e4c-b77b-16e7-d2320bbd0dd5@spamtrap.tnetconsulting.net>

On 09/28/2018 11:28 AM, Arthur Krewat wrote:
> Solaris 10 u10:
> 
> beef / # useradd asdf
> beef / # grep asdf /etc/passwd
> asdf:x:504:1::/home/asdf:/bin/sh
> 
> Solaris 11.3:
> medusa# useradd asdf
> medusa# grep asdf /etc/passwd
> asdf:x:65540:10::/export/home/asdf:/usr/bin/bash
> 
> When creating a user on Solaris 11, because it requires you to install a 
> regular user because you can't login directly as root, it creates the 
> home directory in /export/home
> 
> Interesting. To be honest, I did not expect Solaris 10 to use /home as 
> the default.

Strange.

I'd have to play with things to refine my opinion.

I've long thought that Solaris was a moving target and did things 
inconsistently.



-- 
Grant. . . .
unix || die

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

From gtaylor at tnetconsulting.net  Sat Sep 29 05:47:24 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Fri, 28 Sep 2018 13:47:24 -0600
Subject: [TUHS] The origin of /home
In-Reply-To: <bebc352f-daf1-ec0b-d851-205cbb38a768@kilonet.net>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>
 <CAJfiPzztS2jqYWDKCxVfrZ8Sxe9KEtedqwRjY0wMYN2w=aGCNg@mail.gmail.com>
 <fb1dbcce-07ba-c166-d1a0-b59f0ef26486@spamtrap.tnetconsulting.net>
 <bebc352f-daf1-ec0b-d851-205cbb38a768@kilonet.net>
Message-ID: <7b2ef685-ebae-86ea-5332-8e50d2c2a533@spamtrap.tnetconsulting.net>

On 09/28/2018 11:28 AM, Arthur Krewat wrote:
> Solaris 10 u10:
> Solaris 11.3:

Were those fresh installs to test things for this discussion?

Or were they existing installs that you checked?

If they were fresh installs, were they larger kitchen sink type 
installs?  Or minimal installs?



-- 
Grant. . . .
unix || die

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

From cym224 at gmail.com  Sat Sep 29 06:00:29 2018
From: cym224 at gmail.com (Nemo)
Date: Fri, 28 Sep 2018 16:00:29 -0400
Subject: [TUHS] The origin of /home
In-Reply-To: <fb1dbcce-07ba-c166-d1a0-b59f0ef26486@spamtrap.tnetconsulting.net>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>
 <CAJfiPzztS2jqYWDKCxVfrZ8Sxe9KEtedqwRjY0wMYN2w=aGCNg@mail.gmail.com>
 <fb1dbcce-07ba-c166-d1a0-b59f0ef26486@spamtrap.tnetconsulting.net>
Message-ID: <CAJfiPzyUto=7HBYsPh9RGe8xDxnDRszQmYnMpo=7quGQT0B-xg@mail.gmail.com>

On 28/09/2018, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
> On 09/28/2018 10:02 AM, Nemo wrote:
>> This is a bit late but Solaris uses /export/home by default.
>
> I disagree.
>
> Or at least not as such.
>
> Many Solaris systems I've used have put homes in /export/home.  But they
> are /NOT/ supposed to be used /directly/ as the home directory.  The
> intention that they would be NFS exports and that said export would be
> auto mounted to /home.
>
> The /export/home is really the /export/ point, /not/ the location that
> is supposed to be used.

>From https://docs.oracle.com/cd/E26505_01/html/E29492/userconcept-36940.html#userconcept-6
:

A home directory can be located either on the user's local system or
on a remote file server. In either case, by convention the home
directory should be created as /export/home/username. For a large
site, you should store home directories on a server. Use a separate
file system for each /export/homen directory to facilitate backing up
and restoring home directories. For example, /export/home1,
/export/home2.

Regardless of where their home directory is located, users usually
access their home directories through a mount point named
/home/username. When AutoFS is used to mount home directories, you are
not permitted to create any directories under the /home mount point on
any system. The system recognizes the special status of /home when
AutoFS is active.


> --
> Grant. . . .
> unix || die


From krewat at kilonet.net  Sat Sep 29 06:30:43 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Fri, 28 Sep 2018 16:30:43 -0400
Subject: [TUHS] The origin of /home
In-Reply-To: <7b2ef685-ebae-86ea-5332-8e50d2c2a533@spamtrap.tnetconsulting.net>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>
 <CAJfiPzztS2jqYWDKCxVfrZ8Sxe9KEtedqwRjY0wMYN2w=aGCNg@mail.gmail.com>
 <fb1dbcce-07ba-c166-d1a0-b59f0ef26486@spamtrap.tnetconsulting.net>
 <bebc352f-daf1-ec0b-d851-205cbb38a768@kilonet.net>
 <7b2ef685-ebae-86ea-5332-8e50d2c2a533@spamtrap.tnetconsulting.net>
Message-ID: <b6244689-9f85-3af6-efde-304ebe82470f@kilonet.net>



On 9/28/2018 3:47 PM, Grant Taylor via TUHS wrote:
> On 09/28/2018 11:28 AM, Arthur Krewat wrote:
>> Solaris 10 u10:
>> Solaris 11.3:
>
> Were those fresh installs to test things for this discussion?
>
> Or were they existing installs that you checked?
>
> If they were fresh installs, were they larger kitchen sink type 
> installs?  Or minimal installs?

One is my home Solaris server 11.3, the other is a customer's Solaris 10 
install from way back when.

Nothing changes behavior like that from version-to-version of Solaris. 
Solaris 11 as a whole was a big jump in terms of GNU user-land stuff, 
etc, so that behavior was changed, again, probably because as of 11, you 
had to create a regular user during the install.

I just checked Solaris 7 and 8 (x86), which are both "vanilla" installs 
I did to a VMware guest. On both, useradd used /home - an 11.2 guest 
used /export/home






From gtaylor at tnetconsulting.net  Sat Sep 29 07:07:34 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Fri, 28 Sep 2018 15:07:34 -0600
Subject: [TUHS] The origin of /home
In-Reply-To: <CAJfiPzyUto=7HBYsPh9RGe8xDxnDRszQmYnMpo=7quGQT0B-xg@mail.gmail.com>
References: <20180927120854.u8rei%ca6c@bitmessage.ch>
 <CAJfiPzztS2jqYWDKCxVfrZ8Sxe9KEtedqwRjY0wMYN2w=aGCNg@mail.gmail.com>
 <fb1dbcce-07ba-c166-d1a0-b59f0ef26486@spamtrap.tnetconsulting.net>
 <CAJfiPzyUto=7HBYsPh9RGe8xDxnDRszQmYnMpo=7quGQT0B-xg@mail.gmail.com>
Message-ID: <68a3b1e2-41d0-e807-2eb6-eaafdcd47e95@spamtrap.tnetconsulting.net>

On 09/28/2018 02:00 PM, Nemo wrote:
> From 
> https://docs.oracle.com/cd/E26505_01/html/E29492/userconcept-36940.html#userconcept-6 
> :
> 
> A home directory can be located either on the user's local system or on 
> a remote file server. In either case, by convention the home directory 
> should be created as /export/home/username. For a large site, you should 
> store home directories on a server. Use a separate file system for each 
> /export/homen directory to facilitate backing up and restoring home 
> directories. For example, /export/home1, /export/home2.
> 
> Regardless of where their home directory is located, users usually access 
> their home directories through a mount point named /home/username. When 
> AutoFS is used to mount home directories, you are not permitted to create 
> any directories under the /home mount point on any system. The system 
> recognizes the special status of /home when AutoFS is active.

Yep, that jives with what I thought.

"… by convention the home directory should be created as 
/export/home/username … users usually access their home directories 
through a mount point named /home/username …"

Yep, that jives with my experience and my understanding.



-- 
Grant. . . .
unix || die

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

From wkt at tuhs.org  Sat Sep 29 09:04:44 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 29 Sep 2018 09:04:44 +1000
Subject: [TUHS] Original Unix SOSP paper?
Message-ID: <20180928230444.GB17171@minnie.tuhs.org>

All, I just got an e-mail from a TUHS member who would like to lay their
hands on a copy of the original Unix SOSP paper:

  Anyway, I am trying to get my hands on the original 1972/73 paper on The
  UNIX TIME-SHARING SYSTEM that was published at the SOSP ‘73 Proceedings
  of the fourth ACM symposium on operating system principles.

  I do have the 1974 and 1978 reprint papers.   But, I really want the
  1972/73 original.  I see it in the ACM digital library, but the full
  text PDF prints only the abstract.

Does anybody have a scan of the original SOSP paper?

I'd also like a copy of the 1974 reprint in CACM.

Thanks, Warren


From khm at sciops.net  Sat Sep 29 09:24:08 2018
From: khm at sciops.net (Kurt H Maier)
Date: Fri, 28 Sep 2018 16:24:08 -0700
Subject: [TUHS] Original Unix SOSP paper?
In-Reply-To: <20180928230444.GB17171@minnie.tuhs.org>
References: <20180928230444.GB17171@minnie.tuhs.org>
Message-ID: <20180928232408.GB14945@wopr>

On Sat, Sep 29, 2018 at 09:04:44AM +1000, Warren Toomey wrote:
> 
> Does anybody have a scan of the original SOSP paper?

Page 27 was the abstract, and page 28 was ARGOS.  I'm not sure the paper
actually appeared in that publication; it seems it was presented at SOSP
but not published until CACM a year later.  Can someone clarify?

khm


From wkt at tuhs.org  Sat Sep 29 09:24:58 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 29 Sep 2018 09:24:58 +1000
Subject: [TUHS] Original Unix SOSP paper?
In-Reply-To: <20180928230444.GB17171@minnie.tuhs.org>
References: <20180928230444.GB17171@minnie.tuhs.org>
Message-ID: <20180928232458.GA19886@minnie.tuhs.org>

On Sat, Sep 29, 2018 at 09:04:44AM +1000, Warren Toomey wrote:
> Does anybody have a scan of the original SOSP paper?
> I'd also like a copy of the 1974 reprint in CACM.

Hah, I found a copy of the CACM reprint here:
https://www2.cs.duke.edu/courses/cps210/spring16/resources/papers/p365-ritchie.pdf

Cheers, Warren


From beebe at math.utah.edu  Sat Sep 29 09:20:53 2018
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Fri, 28 Sep 2018 17:20:53 -0600
Subject: [TUHS] Original Unix SOSP paper?
In-Reply-To: <20180928230444.GB17171@minnie.tuhs.org>
Message-ID: <CMM.0.96.0.1538176853.beebe@gamma.math.utah.edu>

Warren Toomey <wkt at tuhs.org> asks on Sat, 29 Sep 2018 09:04:44 +1000 for
a copy of the  original 1972/73 paper on The UNIX TIME-SHARING SYSTEM
that was published at the SOSP bProceedings of the fourth ACM
symposium on operating system principles.

The URL in this entry from unix.bib works for me:

@InProceedings{Ritchie:1973:UTSa,
  author =       "Dennis M. Ritchie and Ken Thompson",
  editor =       "{ACM}",
  booktitle =    "Fourth ACM Symposium on Operating Systems Principles,
                 IBM Thomas J. Watson Research Center, Yorktown Heights,
                 New York, October 15-17, 1973",
  title =        "The {UNIX} time-sharing system",
  publisher =    pub-ACM,
  address =      pub-ACM:adr,
  pages =        "??--??",
  year =         "1973",
  bibdate =      "Thu Feb 23 07:01:17 2017",
  bibsource =    "http://www.math.utah.edu/pub/tex/bib/unix.bib",
  URL =          "https://www.bell-labs.com/usr/dmr/www/cacm.html",
  acknowledgement = ack-nhfb,
  remark =       "This electronic edition of this paper is a reprint of
                 the version appearing in The Bell System Technical
                 Journal 57 no. 6, part 2 (July--August 1978). In turn,
                 that was a revised version of an article that appeared
                 in Communications of the ACM, 17, No. 7 (July 1974),
                 pp. 365--375. That article was a revised version of a
                 paper presented at the Fourth ACM Symposium on
                 Operating Systems Principles, IBM Thomas J. Watson
                 Research Center, Yorktown Heights, New York, October
                 15--17, 1973. Most of the differences between versions
                 occur between the C. ACM version and the BSTJ printing;
                 we incorporated updated numbers and material on
                 portability.",
}

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------


From wkt at tuhs.org  Sat Sep 29 09:55:12 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 29 Sep 2018 09:55:12 +1000
Subject: [TUHS] Original Unix SOSP paper?
In-Reply-To: <CMM.0.96.0.1538176853.beebe@gamma.math.utah.edu>
References: <20180928230444.GB17171@minnie.tuhs.org>
 <CMM.0.96.0.1538176853.beebe@gamma.math.utah.edu>
Message-ID: <20180928235512.GB24118@minnie.tuhs.org>

On Fri, Sep 28, 2018 at 05:20:53PM -0600, Nelson H. F. Beebe wrote:
> Warren Toomey <wkt at tuhs.org> asks on Sat, 29 Sep 2018 09:04:44 +1000 for
> a copy of the  original 1972/73 paper on The UNIX TIME-SHARING SYSTEM
> that was published at the SOSP Proceedings of the fourth ACM
> symposium on operating system principles.
> 
> The URL in this entry from unix.bib works for me:

Ah, but:

>   remark =       "This electronic edition of this paper is a reprint of
>                  the version appearing in The Bell System Technical
>                  Journal 57 no. 6, part 2 (July--August 1978). In turn,
>                  that was a revised version of an article that appeared
>                  in Communications of the ACM, 17, No. 7 (July 1974),
>                  pp. 365--375. That article was a revised version of a
>                  paper presented at the Fourth ACM Symposium on
>                  Operating Systems Principles, IBM Thomas J. Watson
>                  Research Center, Yorktown Heights, New York, October
>                  15--17, 1973. Most of the differences between versions
>                  occur between the C. ACM version and the BSTJ printing;
>                  we incorporated updated numbers and material on
>                  portability.",

so not the original SOSP paper or the original 1974 CACM paper :-)

However, it's yet another version of the paper.

I've spent some time tracking down the various "versions" of this paper.
So far, I know of:

+ the mid-1971 draft, available at https://www.tuhs.org/Archive/Distributions/Research/McIlroy_v0/UnixEditionZero-Threshold_OCR.pdf
+ a later version which is in the Nokia Bell Labs archives, which I 
  haven't been able to get my hands on
+ the SOSP presentation, still unclear if there was an actual paper
+ the 1974 CACM paper
+ the version in 6th Edition Unix, available at https://minnie.tuhs.org//cgi-bin/utree.pl?file=V6/usr/doc/unix
+ the 1978 BSTL version cited above

Are there any others that people know about that I've missed?

I would like to do some work on how the content changed over time.
The result would be, for me, an interesting paper to read but somehow
I think the readership base would be limited :-)

Cheers, Warren


From sauer at technologists.com  Sat Sep 29 10:15:38 2018
From: sauer at technologists.com (Charles H. Sauer)
Date: Fri, 28 Sep 2018 19:15:38 -0500
Subject: [TUHS] Original Unix SOSP paper?
In-Reply-To: <20180928235512.GB24118@minnie.tuhs.org>
References: <20180928230444.GB17171@minnie.tuhs.org>
 <CMM.0.96.0.1538176853.beebe@gamma.math.utah.edu>
 <20180928235512.GB24118@minnie.tuhs.org>
Message-ID: <471D7A71-A0FC-4471-BFC4-0263B0D77AD6@technologists.com>

As Kurt has already remarked, the page counts at https://dl.acm.org/citation.cfm?id=800009&picked=prox <https://dl.acm.org/citation.cfm?id=800009&picked=prox> seem all but conclusive that only the abstract was published as part of the '73 SOSP. I have old paper copies of OSR & SOSP stuff in the attic, but I don’t think they start until ’75. Next time I’m looking there, which is probably months or more away, I’ll verify. Charlie

> On Sep 28, 2018, at 6:55 PM, Warren Toomey <wkt at tuhs.org> wrote:
> 
> On Fri, Sep 28, 2018 at 05:20:53PM -0600, Nelson H. F. Beebe wrote:
>> Warren Toomey <wkt at tuhs.org> asks on Sat, 29 Sep 2018 09:04:44 +1000 for
>> a copy of the  original 1972/73 paper on The UNIX TIME-SHARING SYSTEM
>> that was published at the SOSP Proceedings of the fourth ACM
>> symposium on operating system principles.
>> 
>> The URL in this entry from unix.bib works for me:
> 
> Ah, but:
> 
>>  remark =       "This electronic edition of this paper is a reprint of
>>                 the version appearing in The Bell System Technical
>>                 Journal 57 no. 6, part 2 (July--August 1978). In turn,
>>                 that was a revised version of an article that appeared
>>                 in Communications of the ACM, 17, No. 7 (July 1974),
>>                 pp. 365--375. That article was a revised version of a
>>                 paper presented at the Fourth ACM Symposium on
>>                 Operating Systems Principles, IBM Thomas J. Watson
>>                 Research Center, Yorktown Heights, New York, October
>>                 15--17, 1973. Most of the differences between versions
>>                 occur between the C. ACM version and the BSTJ printing;
>>                 we incorporated updated numbers and material on
>>                 portability.",
> 
> so not the original SOSP paper or the original 1974 CACM paper :-)
> 
> However, it's yet another version of the paper.
> 
> I've spent some time tracking down the various "versions" of this paper.
> So far, I know of:
> 
> + the mid-1971 draft, available at https://www.tuhs.org/Archive/Distributions/Research/McIlroy_v0/UnixEditionZero-Threshold_OCR.pdf
> + a later version which is in the Nokia Bell Labs archives, which I 
>  haven't been able to get my hands on
> + the SOSP presentation, still unclear if there was an actual paper
> + the 1974 CACM paper
> + the version in 6th Edition Unix, available at https://minnie.tuhs.org//cgi-bin/utree.pl?file=V6/usr/doc/unix
> + the 1978 BSTL version cited above
> 
> Are there any others that people know about that I've missed?
> 
> I would like to do some work on how the content changed over time.
> The result would be, for me, an interesting paper to read but somehow
> I think the readership base would be limited :-)
> 
> Cheers, Warren

--
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/20180928/b3f8ee92/attachment.html>

From khm at sciops.net  Sat Sep 29 10:48:28 2018
From: khm at sciops.net (Kurt H Maier)
Date: Fri, 28 Sep 2018 17:48:28 -0700
Subject: [TUHS] Original Unix SOSP paper?
In-Reply-To: <20180928235512.GB24118@minnie.tuhs.org>
References: <20180928230444.GB17171@minnie.tuhs.org>
 <CMM.0.96.0.1538176853.beebe@gamma.math.utah.edu>
 <20180928235512.GB24118@minnie.tuhs.org>
Message-ID: <20180929004828.GA41042@wopr>

On Sat, Sep 29, 2018 at 09:55:12AM +1000, Warren Toomey wrote:
> + a later version which is in the Nokia Bell Labs archives, which I 
>   haven't been able to get my hands on

Archive.org has it at https://archive.org/details/bstj-archives but I
collected this specific issue for my own purposes here:
http://sciops.net/information/bstj/

(archive.org's new web interface is ... touch-friendly.)

The paper in question is bstj57-6-1905_text.pdf.

khm


From imp at bsdimp.com  Sat Sep 29 11:44:46 2018
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 28 Sep 2018 19:44:46 -0600
Subject: [TUHS] Original Unix SOSP paper?
In-Reply-To: <20180929004828.GA41042@wopr>
References: <20180928230444.GB17171@minnie.tuhs.org>
 <CMM.0.96.0.1538176853.beebe@gamma.math.utah.edu>
 <20180928235512.GB24118@minnie.tuhs.org> <20180929004828.GA41042@wopr>
Message-ID: <CANCZdfoCrtkwZf=S+fzdw9pLuXNxqTOKqkO-aY36j+RcJ4i=5A@mail.gmail.com>

On Fri, Sep 28, 2018, 6:50 PM Kurt H Maier <khm at sciops.net> wrote:

> On Sat, Sep 29, 2018 at 09:55:12AM +1000, Warren Toomey wrote:
> > + a later version which is in the Nokia Bell Labs archives, which I
> >   haven't been able to get my hands on
>
> Archive.org has it at https://archive.org/details/bstj-archives but I
> collected this specific issue for my own purposes here:
> http://sciops.net/information/bstj/
>
> (archive.org's new web interface is ... touch-friendly.)
>
> The paper in question is bstj57-6-1905_text.pdf.
>

I have a paper copy of the BSTJ in question...

Warner

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

From wkt at tuhs.org  Sat Sep 29 20:11:18 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 29 Sep 2018 20:11:18 +1000
Subject: [TUHS] Original Unix SOSP paper?
In-Reply-To: <20180929004828.GA41042@wopr>
References: <20180928230444.GB17171@minnie.tuhs.org>
 <CMM.0.96.0.1538176853.beebe@gamma.math.utah.edu>
 <20180928235512.GB24118@minnie.tuhs.org>
 <20180929004828.GA41042@wopr>
Message-ID: <20180929101118.GA30784@minnie.tuhs.org>

On Fri, Sep 28, 2018 at 05:48:28PM -0700, Kurt H Maier wrote:
> Archive.org has it at https://archive.org/details/bstj-archives but I
> collected this specific issue for my own purposes here:
> http://sciops.net/information/bstj/
> The paper in question is bstj57-6-1905_text.pdf.

I've also got a mirror of the relevant BSTJ at:
https://www.tuhs.org/Archive/Documentation/Papers/BSTJ/

Cheers, Warren


From wlc at jctaylor.com  Sat Sep 29 20:32:26 2018
From: wlc at jctaylor.com (William Corcoran)
Date: Sat, 29 Sep 2018 10:32:26 +0000
Subject: [TUHS] Original Unix SOSP paper?
In-Reply-To: <20180929101118.GA30784@minnie.tuhs.org>
References: <20180928230444.GB17171@minnie.tuhs.org>
 <CMM.0.96.0.1538176853.beebe@gamma.math.utah.edu>
 <20180928235512.GB24118@minnie.tuhs.org>
 <20180929004828.GA41042@wopr>,<20180929101118.GA30784@minnie.tuhs.org>
Message-ID: <F87AFAB8-38DB-4A4D-8EA9-E21083FF6FD5@jctaylor.com>

Hi Warren,

Thank you for all of your help here!

Truly,

Bill Corcoran



> On Sep 29, 2018, at 6:12 AM, Warren Toomey <wkt at tuhs.org> wrote:
> 
>> On Fri, Sep 28, 2018 at 05:48:28PM -0700, Kurt H Maier wrote:
>> Archive.org has it at https://archive.org/details/bstj-archives but I
>> collected this specific issue for my own purposes here:
>> http://sciops.net/information/bstj/
>> The paper in question is bstj57-6-1905_text.pdf.
> 
> I've also got a mirror of the relevant BSTJ at:
> https://www.tuhs.org/Archive/Documentation/Papers/BSTJ/
> 
> Cheers, Warren


From doug at cs.dartmouth.edu  Sat Sep 29 22:03:56 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sat, 29 Sep 2018 08:03:56 -0400
Subject: [TUHS] Original Unix SOSP paper?
Message-ID: <201809291203.w8TC3u0O057718@tahoe.cs.Dartmouth.EDU>

Warren wrote:
> I would like to do some work on how the content changed over time.
> The result would be, for me, an interesting paper to read but somehow
> I think the readership base would be limited :-)

"Critical editions", as they are known in literary circles,
garner wide respect if not wide readership. Go for it.

Incidentally the earliest diff programs I know about date
from about 1969. One was by Steve Johnson, specifically
for comparing comdecks--compressed assembler source. The
other arose in service of critical editions.

Doug


