The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] My EuroBSDcon talk (preview for commentary)
@ 2019-09-13  3:20 Warner Losh
  2019-09-13  9:03 ` Branden Robinson
                   ` (2 more replies)
  0 siblings, 3 replies; 148+ messages in thread
From: Warner Losh @ 2019-09-13  3:20 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 861 bytes --]

OK. I've shared my slides for the talk.

Some of the family trees are simplified (V7 doesn't have room for all its
ports, for example)
Some of it is a little cheeseball since I'm also trying to be witty and
entertaining (we'll see how that goes).
Please don't share them around until after my talk on the September 20th

I'd like feedback on the bits I got wrong. Or left out. Or if you're in
this and don't want to be, etc.

All the slides after the Questions slide won't be presented and will likely
be deleted.

https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing

Please be kind (but if it sucks, please do tell). I've turned on commenting
on the slides. Probably best if you comment there.

I have a video of me giving this talk, but it's too rough to share...

Thanks for any help you can give me.

Warner

[-- Attachment #2: Type: text/html, Size: 1262 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
  2019-09-13  3:20 [TUHS] My EuroBSDcon talk (preview for commentary) Warner Losh
@ 2019-09-13  9:03 ` Branden Robinson
  2019-09-13 19:47 ` Clem Cole
  2019-09-15 21:46 ` Clem Cole
  2 siblings, 0 replies; 148+ messages in thread
From: Branden Robinson @ 2019-09-13  9:03 UTC (permalink / raw)
  To: Warner Losh; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 2164 bytes --]

Hi Warner,

Just a few minor corrections.

1. slide 21: s/Murrey Hill/Murray Hill/
2. slide 18: s/IOCC/&C/
3. slide 28: s/strippe down/stripped down/; s/IOCC/&C/

Now I know why the domain name is ioccc.org and not iocc.org.  Well-crafted
obfuscated C is nothing if not...unorthodox.

I hadn't even heard of VENIX before--great archeology!  As you lusted for
that OS back in the '80s, I lusted after the Rainbow 100 itself, and found
it cool for the same reasons you did.  The flexibility of the system was
appealing, keeping a bridge to my Z80 origins and the x86 juggernaut.  As
it happened I wound up with a 6809 machine running OS/9, and got Unix-like
exposure without even knowing it (the text editor, T/S Edit, was a vi
clone, and the "word processor", T/S Word, a *roff clone).  And best of
all, that machine taught me how to store multibyte integers correctly.

x86's worst-ever implementation of memory segmentation put me off of
assembly programming for years.  When I finally saw sensible segmentation
combined with hardware memory protection, the universe made sense again.

You have a wealth of great material here and I think you will surprise some
people.

Regards,
Branden

On Fri, Sep 13, 2019 at 1:21 PM Warner Losh <imp@bsdimp.com> wrote:

> OK. I've shared my slides for the talk.
>
> Some of the family trees are simplified (V7 doesn't have room for all its
> ports, for example)
> Some of it is a little cheeseball since I'm also trying to be witty and
> entertaining (we'll see how that goes).
> Please don't share them around until after my talk on the September 20th
>
> I'd like feedback on the bits I got wrong. Or left out. Or if you're in
> this and don't want to be, etc.
>
> All the slides after the Questions slide won't be presented and will
> likely be deleted.
>
>
> https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing
>
> Please be kind (but if it sucks, please do tell). I've turned on
> commenting on the slides. Probably best if you comment there.
>
> I have a video of me giving this talk, but it's too rough to share...
>
> Thanks for any help you can give me.
>
> Warner
>

[-- Attachment #2: Type: text/html, Size: 3839 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
  2019-09-13  3:20 [TUHS] My EuroBSDcon talk (preview for commentary) Warner Losh
  2019-09-13  9:03 ` Branden Robinson
@ 2019-09-13 19:47 ` Clem Cole
  2019-09-13 20:02   ` Clem Cole
  2019-09-14  6:13   ` Wesley Parish
  2019-09-15 21:46 ` Clem Cole
  2 siblings, 2 replies; 148+ messages in thread
From: Clem Cole @ 2019-09-13 19:47 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 6113 bytes --]

slide 4 --  All of HP-UX, Ultrix and Digital UNIX/Tru64 are BSD kernels.
HP-UP and Tru64 support System V calls.

BTW:  DG-UX and Stratus built their own kernels, but used System V command
systems and System Call definitions - which are not listed.

Slide 6 - if you want it I have another picture of the GE system from some
of their literature has a view of all of the components.   Send me email if
you want it.

Slide 8 - Sets out to write version of Fortran came up with B.  Uses B to
write Assembler

Slide 9 - Wrong DEC logo.  Should be the Blue one.  The maroon version does
not show up until the 1990s with Bob Palmer (and has bad memories for some
of us).

Slide 17 - Ken write PDP-11 assembler on PDP-7 in B. , Dennis starts to
rewrite B compiler to output PDP-11 code.

Slide 18 - B begins to become different enough that Dennis starts to call
it nb [new B], eventually deviates enough to become new language

Slide 19 - 4th Edition release outside of the BTL.  Lou Katz becomes 'user
zero'

Slide 20 -- We need to get you the site and group name from Mash.  It was
not in Summit, it was not USG - but was in NJ.  I thought it was Homdel but
I that is purely speculation.
                  Also the role of Columbus team needs to be defined.   Ask
Mary Ann.

Slide 21 -- I'm not going to argue - but I would ask you to add a
disclaimer.   This is what you could reconstruct, but there is some
question of some of the arrows.   Heinz might be able to help, but as
Stienhart and I have said, its believed to be in LA; but no one has tracked
him down as he has been pursuing non-computer interests.

Slide 22 --4th Edition went to Katz that this is wrong, who sometimes reads
this mailing list.  If not, send me a note, I'll reintroduce you.  He might
be able to give you a data.  Check with Warren, my >>memory<< is that some
of userland is still in C although a lot assembler is still there.

Slide 23 -- ??widespread??   -- I'm not sure I would use that. Not even 100
sites yet.     Also there were not "commercial version" this was the first
"commercial license" -- big difference [contact me if you want
explanation].  IIRC fee was 15K per CPU.  Commercial redistribution doesn't
occur until after 7th is released and was a separate license.   I would
add, Mike Lesk's portable C library is starting to be used, but most C
program do their own I/O with read/write

          First real install man page and Dennis build tape installation
system.   Earlier version released as RK05 disk copies.
           Also numerous new peripherals. IIRC Support for the 11/40 starts
here, 4th & 5th needed a 45 class, and earlier used the 20 with the CSS MMU.

Slide 24 -- CMU uses it to teaches OS class.  makes student in class sign a
sub-license.

Slide 25 - missing the first USENIX tapes. which include Harvard and the
like.  Warren and I can probably help a little here.

Slide 26 - new licenses.  Commercial license fees change to 20K for 1st
CPU/5K for each CPU afterward.  CMU buys first commercial license to use
UNIX to make money [after Cole and Klein go on strike].  Case Western
follows suit 6month later.   AT&T agrees for the Universities that they
only had to declare one CPU as commercial and could intermix otherwise and
notifies all the universities that if they were using it for commercial
purposes, then needed a license.

AT&T creates first redistribution license.  Needed at least one $20K
commercial CPU and then $150k for the rights to redistribute.   Originally
$1K per binary CPU.

Slide 27 -- missing Purdue Dual Vax and CMU Mach

Slide 28 - APS had NH which was the model the DEC plate you show.   Maddog
has it now on his Jeep when aps moved to CA (he also has the NH Linux plate
but I don't remember the car -- you can ask him).   I have had the
Massachusetts UNIX plate since 1983 (it's on my model S of course).   ghg
has indiana from around the same time (I think on a pickup).  wnj had the
CA vmunix on his Ferrari, but I don't know if he still has it or what its
on.

Slide 29 - Look in HenrySpencer-TUHS.org -- you'll find tail but not head.

Slide 31 - Job Control can from Europe via MIT.  Jim Kulp wrote it.   Noel
and I can give you the story if you want it.  It was on the PDP-11 there.
 Joy modified csh and added it to 4.1

Slide 32 -- JC was not from UCB.   Joy got it from MIT   -- Dennis create
ENV and it was first distributed in V7.

Slide 33 -- No Bourne supported ENV in the new shell -- see me earlier
email for how all this went down or ask Steve yourself.

Slide 34 -- PCC was included, but the Ritchie Compiler (a.k.a. Typesetter
C) was the default compiler.  You are missing a step BTW -- typesetter C
was released between V6 and V7.   As is the first draft of the White Book.
The new compiler had stdio but targets V6.
Also mpx was part of DataKit support.

Slide 35 --   Not sure that is true.   I thought Microsoft's Xenix ships
before Venix.    Particularly since you made the comment about System III
The original 8086 Xenix was a pure V7 port, with a few additions Gordon
brought with him from Purdue (i.e. ghg hacks).

Slide 52/53/54/55 -- wrong logo (see above)










On Thu, Sep 12, 2019 at 11:21 PM Warner Losh <imp@bsdimp.com> wrote:

> OK. I've shared my slides for the talk.
>
> Some of the family trees are simplified (V7 doesn't have room for all its
> ports, for example)
> Some of it is a little cheeseball since I'm also trying to be witty and
> entertaining (we'll see how that goes).
> Please don't share them around until after my talk on the September 20th
>
> I'd like feedback on the bits I got wrong. Or left out. Or if you're in
> this and don't want to be, etc.
>
> All the slides after the Questions slide won't be presented and will
> likely be deleted.
>
>
> https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing
>
> Please be kind (but if it sucks, please do tell). I've turned on
> commenting on the slides. Probably best if you comment there.
>
> I have a video of me giving this talk, but it's too rough to share...
>
> Thanks for any help you can give me.
>
> Warner
>

[-- Attachment #2: Type: text/html, Size: 12145 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
  2019-09-13 19:47 ` Clem Cole
@ 2019-09-13 20:02   ` Clem Cole
  2019-09-13 20:06     ` Clem Cole
  2019-09-13 20:06     ` Larry McVoy
  2019-09-14  6:13   ` Wesley Parish
  1 sibling, 2 replies; 148+ messages in thread
From: Clem Cole @ 2019-09-13 20:02 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 7352 bytes --]

BTW:  I just thought of something else....  one of the b*tched about the
commercial redistribution license from V7 in 1979, that was not fixed until
the SVR3 licensing the mid-late 1980s  was AT&T's source policy.   As I
said, a commercial source license was $20K for the first CPU and 5K for
each additional one.   Later (System V) it went to $50K for the first and
$10K for each additional.   But what really ticked off the vendors like
DEC, Masscomp, Sun et al, was that each system that sources on was supposed
to one of the 'second CPU licenses' - the binary license was not good
enough.

What most of us did, was make sure any system that was a 'source control'
or 'master' system at any 'site' had a full source license, but we were all
in violation of the source agreement on our personal workstations.  The
argument was the sources on people's machines was ephemeral and not
'stored' there.   But it was definitely contentious.



On Fri, Sep 13, 2019 at 3:47 PM Clem Cole <clemc@ccc.com> wrote:

> slide 4 --  All of HP-UX, Ultrix and Digital UNIX/Tru64 are BSD kernels.
> HP-UP and Tru64 support System V calls.
>
> BTW:  DG-UX and Stratus built their own kernels, but used System V command
> systems and System Call definitions - which are not listed.
>
> Slide 6 - if you want it I have another picture of the GE system from some
> of their literature has a view of all of the components.   Send me email if
> you want it.
>
> Slide 8 - Sets out to write version of Fortran came up with B.  Uses B to
> write Assembler
>
> Slide 9 - Wrong DEC logo.  Should be the Blue one.  The maroon version
> does not show up until the 1990s with Bob Palmer (and has bad memories for
> some of us).
>
> Slide 17 - Ken write PDP-11 assembler on PDP-7 in B. , Dennis starts to
> rewrite B compiler to output PDP-11 code.
>
> Slide 18 - B begins to become different enough that Dennis starts to call
> it nb [new B], eventually deviates enough to become new language
>
> Slide 19 - 4th Edition release outside of the BTL.  Lou Katz becomes 'user
> zero'
>
> Slide 20 -- We need to get you the site and group name from Mash.  It was
> not in Summit, it was not USG - but was in NJ.  I thought it was Homdel but
> I that is purely speculation.
>                   Also the role of Columbus team needs to be defined.
>  Ask Mary Ann.
>
> Slide 21 -- I'm not going to argue - but I would ask you to add a
> disclaimer.   This is what you could reconstruct, but there is some
> question of some of the arrows.   Heinz might be able to help, but as
> Stienhart and I have said, its believed to be in LA; but no one has tracked
> him down as he has been pursuing non-computer interests.
>
> Slide 22 --4th Edition went to Katz that this is wrong, who sometimes
> reads this mailing list.  If not, send me a note, I'll reintroduce you.  He
> might be able to give you a data.  Check with Warren, my >>memory<< is that
> some of userland is still in C although a lot assembler is still there.
>
> Slide 23 -- ??widespread??   -- I'm not sure I would use that. Not even
> 100 sites yet.     Also there were not "commercial version" this was the
> first "commercial license" -- big difference [contact me if you want
> explanation].  IIRC fee was 15K per CPU.  Commercial redistribution doesn't
> occur until after 7th is released and was a separate license.   I would
> add, Mike Lesk's portable C library is starting to be used, but most C
> program do their own I/O with read/write
>
>           First real install man page and Dennis build tape installation
> system.   Earlier version released as RK05 disk copies.
>            Also numerous new peripherals. IIRC Support for the 11/40
> starts here, 4th & 5th needed a 45 class, and earlier used the 20 with the
> CSS MMU.
>
> Slide 24 -- CMU uses it to teaches OS class.  makes student in class sign
> a sub-license.
>
> Slide 25 - missing the first USENIX tapes. which include Harvard and the
> like.  Warren and I can probably help a little here.
>
> Slide 26 - new licenses.  Commercial license fees change to 20K for 1st
> CPU/5K for each CPU afterward.  CMU buys first commercial license to use
> UNIX to make money [after Cole and Klein go on strike].  Case Western
> follows suit 6month later.   AT&T agrees for the Universities that they
> only had to declare one CPU as commercial and could intermix otherwise and
> notifies all the universities that if they were using it for commercial
> purposes, then needed a license.
>
> AT&T creates first redistribution license.  Needed at least one $20K
> commercial CPU and then $150k for the rights to redistribute.   Originally
> $1K per binary CPU.
>
> Slide 27 -- missing Purdue Dual Vax and CMU Mach
>
> Slide 28 - APS had NH which was the model the DEC plate you show.   Maddog
> has it now on his Jeep when aps moved to CA (he also has the NH Linux plate
> but I don't remember the car -- you can ask him).   I have had the
> Massachusetts UNIX plate since 1983 (it's on my model S of course).   ghg
> has indiana from around the same time (I think on a pickup).  wnj had the
> CA vmunix on his Ferrari, but I don't know if he still has it or what its
> on.
>
> Slide 29 - Look in HenrySpencer-TUHS.org -- you'll find tail but not head.
>
> Slide 31 - Job Control can from Europe via MIT.  Jim Kulp wrote it.   Noel
> and I can give you the story if you want it.  It was on the PDP-11 there.
>  Joy modified csh and added it to 4.1
>
> Slide 32 -- JC was not from UCB.   Joy got it from MIT   -- Dennis create
> ENV and it was first distributed in V7.
>
> Slide 33 -- No Bourne supported ENV in the new shell -- see me earlier
> email for how all this went down or ask Steve yourself.
>
> Slide 34 -- PCC was included, but the Ritchie Compiler (a.k.a. Typesetter
> C) was the default compiler.  You are missing a step BTW -- typesetter C
> was released between V6 and V7.   As is the first draft of the White Book.
> The new compiler had stdio but targets V6.
> Also mpx was part of DataKit support.
>
> Slide 35 --   Not sure that is true.   I thought Microsoft's Xenix ships
> before Venix.    Particularly since you made the comment about System III
> The original 8086 Xenix was a pure V7 port, with a few additions Gordon
> brought with him from Purdue (i.e. ghg hacks).
>
> Slide 52/53/54/55 -- wrong logo (see above)
>
>
>
>
>
>
>
>
>
>
> On Thu, Sep 12, 2019 at 11:21 PM Warner Losh <imp@bsdimp.com> wrote:
>
>> OK. I've shared my slides for the talk.
>>
>> Some of the family trees are simplified (V7 doesn't have room for all its
>> ports, for example)
>> Some of it is a little cheeseball since I'm also trying to be witty and
>> entertaining (we'll see how that goes).
>> Please don't share them around until after my talk on the September 20th
>>
>> I'd like feedback on the bits I got wrong. Or left out. Or if you're in
>> this and don't want to be, etc.
>>
>> All the slides after the Questions slide won't be presented and will
>> likely be deleted.
>>
>>
>> https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing
>>
>> Please be kind (but if it sucks, please do tell). I've turned on
>> commenting on the slides. Probably best if you comment there.
>>
>> I have a video of me giving this talk, but it's too rough to share...
>>
>> Thanks for any help you can give me.
>>
>> Warner
>>
>

[-- Attachment #2: Type: text/html, Size: 13922 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
  2019-09-13 20:02   ` Clem Cole
@ 2019-09-13 20:06     ` Clem Cole
  2019-09-13 20:24       ` Jon Steinhart
                         ` (2 more replies)
  2019-09-13 20:06     ` Larry McVoy
  1 sibling, 3 replies; 148+ messages in thread
From: Clem Cole @ 2019-09-13 20:06 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 8029 bytes --]

Another thought -- the first commercial licensee was Rand.   Hired some
former Harvard students who brought UNIX with them.   You probably need to
add things like Rand Ports (a.k.a. named pipes) which came from there.
Also Chesson and Co did the original ArpaNET NCP at University of Ill
with some help from the Rand folks.   That was done on a V6 system ~ 1978

You also need need Ken's famous V6 'patch' tape -- that 'leaked'


On Fri, Sep 13, 2019 at 4:02 PM Clem Cole <clemc@ccc.com> wrote:

> BTW:  I just thought of something else....  one of the b*tched about the
> commercial redistribution license from V7 in 1979, that was not fixed until
> the SVR3 licensing the mid-late 1980s  was AT&T's source policy.   As I
> said, a commercial source license was $20K for the first CPU and 5K for
> each additional one.   Later (System V) it went to $50K for the first and
> $10K for each additional.   But what really ticked off the vendors like
> DEC, Masscomp, Sun et al, was that each system that sources on was supposed
> to one of the 'second CPU licenses' - the binary license was not good
> enough.
>
> What most of us did, was make sure any system that was a 'source control'
> or 'master' system at any 'site' had a full source license, but we were all
> in violation of the source agreement on our personal workstations.  The
> argument was the sources on people's machines was ephemeral and not
> 'stored' there.   But it was definitely contentious.
>
>
>
> On Fri, Sep 13, 2019 at 3:47 PM Clem Cole <clemc@ccc.com> wrote:
>
>> slide 4 --  All of HP-UX, Ultrix and Digital UNIX/Tru64 are BSD kernels.
>> HP-UP and Tru64 support System V calls.
>>
>> BTW:  DG-UX and Stratus built their own kernels, but used System V
>> command systems and System Call definitions - which are not listed.
>>
>> Slide 6 - if you want it I have another picture of the GE system from
>> some of their literature has a view of all of the components.   Send me
>> email if you want it.
>>
>> Slide 8 - Sets out to write version of Fortran came up with B.  Uses B to
>> write Assembler
>>
>> Slide 9 - Wrong DEC logo.  Should be the Blue one.  The maroon version
>> does not show up until the 1990s with Bob Palmer (and has bad memories for
>> some of us).
>>
>> Slide 17 - Ken write PDP-11 assembler on PDP-7 in B. , Dennis starts to
>> rewrite B compiler to output PDP-11 code.
>>
>> Slide 18 - B begins to become different enough that Dennis starts to call
>> it nb [new B], eventually deviates enough to become new language
>>
>> Slide 19 - 4th Edition release outside of the BTL.  Lou Katz
>> becomes 'user zero'
>>
>> Slide 20 -- We need to get you the site and group name from Mash.  It was
>> not in Summit, it was not USG - but was in NJ.  I thought it was Homdel but
>> I that is purely speculation.
>>                   Also the role of Columbus team needs to be defined.
>>  Ask Mary Ann.
>>
>> Slide 21 -- I'm not going to argue - but I would ask you to add a
>> disclaimer.   This is what you could reconstruct, but there is some
>> question of some of the arrows.   Heinz might be able to help, but as
>> Stienhart and I have said, its believed to be in LA; but no one has tracked
>> him down as he has been pursuing non-computer interests.
>>
>> Slide 22 --4th Edition went to Katz that this is wrong, who sometimes
>> reads this mailing list.  If not, send me a note, I'll reintroduce you.  He
>> might be able to give you a data.  Check with Warren, my >>memory<< is that
>> some of userland is still in C although a lot assembler is still there.
>>
>> Slide 23 -- ??widespread??   -- I'm not sure I would use that. Not even
>> 100 sites yet.     Also there were not "commercial version" this was the
>> first "commercial license" -- big difference [contact me if you want
>> explanation].  IIRC fee was 15K per CPU.  Commercial redistribution doesn't
>> occur until after 7th is released and was a separate license.   I would
>> add, Mike Lesk's portable C library is starting to be used, but most C
>> program do their own I/O with read/write
>>
>>           First real install man page and Dennis build tape installation
>> system.   Earlier version released as RK05 disk copies.
>>            Also numerous new peripherals. IIRC Support for the 11/40
>> starts here, 4th & 5th needed a 45 class, and earlier used the 20 with the
>> CSS MMU.
>>
>> Slide 24 -- CMU uses it to teaches OS class.  makes student in class sign
>> a sub-license.
>>
>> Slide 25 - missing the first USENIX tapes. which include Harvard and the
>> like.  Warren and I can probably help a little here.
>>
>> Slide 26 - new licenses.  Commercial license fees change to 20K for 1st
>> CPU/5K for each CPU afterward.  CMU buys first commercial license to use
>> UNIX to make money [after Cole and Klein go on strike].  Case Western
>> follows suit 6month later.   AT&T agrees for the Universities that they
>> only had to declare one CPU as commercial and could intermix otherwise and
>> notifies all the universities that if they were using it for commercial
>> purposes, then needed a license.
>>
>> AT&T creates first redistribution license.  Needed at least one $20K
>> commercial CPU and then $150k for the rights to redistribute.   Originally
>> $1K per binary CPU.
>>
>> Slide 27 -- missing Purdue Dual Vax and CMU Mach
>>
>> Slide 28 - APS had NH which was the model the DEC plate you show.
>>  Maddog has it now on his Jeep when aps moved to CA (he also has the NH
>> Linux plate but I don't remember the car -- you can ask him).   I have had
>> the Massachusetts UNIX plate since 1983 (it's on my model S of course).
>>  ghg has indiana from around the same time (I think on a pickup).  wnj had
>> the CA vmunix on his Ferrari, but I don't know if he still has it or what
>> its on.
>>
>> Slide 29 - Look in HenrySpencer-TUHS.org -- you'll find tail but not head.
>>
>> Slide 31 - Job Control can from Europe via MIT.  Jim Kulp wrote it.
>>  Noel and I can give you the story if you want it.  It was on the PDP-11
>> there.   Joy modified csh and added it to 4.1
>>
>> Slide 32 -- JC was not from UCB.   Joy got it from MIT   -- Dennis create
>> ENV and it was first distributed in V7.
>>
>> Slide 33 -- No Bourne supported ENV in the new shell -- see me earlier
>> email for how all this went down or ask Steve yourself.
>>
>> Slide 34 -- PCC was included, but the Ritchie Compiler (a.k.a. Typesetter
>> C) was the default compiler.  You are missing a step BTW -- typesetter C
>> was released between V6 and V7.   As is the first draft of the White Book.
>> The new compiler had stdio but targets V6.
>> Also mpx was part of DataKit support.
>>
>> Slide 35 --   Not sure that is true.   I thought Microsoft's Xenix ships
>> before Venix.    Particularly since you made the comment about System III
>> The original 8086 Xenix was a pure V7 port, with a few additions Gordon
>> brought with him from Purdue (i.e. ghg hacks).
>>
>> Slide 52/53/54/55 -- wrong logo (see above)
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Sep 12, 2019 at 11:21 PM Warner Losh <imp@bsdimp.com> wrote:
>>
>>> OK. I've shared my slides for the talk.
>>>
>>> Some of the family trees are simplified (V7 doesn't have room for all
>>> its ports, for example)
>>> Some of it is a little cheeseball since I'm also trying to be witty and
>>> entertaining (we'll see how that goes).
>>> Please don't share them around until after my talk on the September 20th
>>>
>>> I'd like feedback on the bits I got wrong. Or left out. Or if you're in
>>> this and don't want to be, etc.
>>>
>>> All the slides after the Questions slide won't be presented and will
>>> likely be deleted.
>>>
>>>
>>> https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing
>>>
>>> Please be kind (but if it sucks, please do tell). I've turned on
>>> commenting on the slides. Probably best if you comment there.
>>>
>>> I have a video of me giving this talk, but it's too rough to share...
>>>
>>> Thanks for any help you can give me.
>>>
>>> Warner
>>>
>>

[-- Attachment #2: Type: text/html, Size: 15066 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
  2019-09-13 20:02   ` Clem Cole
  2019-09-13 20:06     ` Clem Cole
@ 2019-09-13 20:06     ` Larry McVoy
  1 sibling, 0 replies; 148+ messages in thread
From: Larry McVoy @ 2019-09-13 20:06 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

Sun had all their sources on one machine.  Spent many a happy hour there
reading.

On Fri, Sep 13, 2019 at 04:02:30PM -0400, Clem Cole wrote:
> BTW:  I just thought of something else....  one of the b*tched about the
> commercial redistribution license from V7 in 1979, that was not fixed until
> the SVR3 licensing the mid-late 1980s  was AT&T's source policy.   As I
> said, a commercial source license was $20K for the first CPU and 5K for
> each additional one.   Later (System V) it went to $50K for the first and
> $10K for each additional.   But what really ticked off the vendors like
> DEC, Masscomp, Sun et al, was that each system that sources on was supposed
> to one of the 'second CPU licenses' - the binary license was not good
> enough.
> 
> What most of us did, was make sure any system that was a 'source control'
> or 'master' system at any 'site' had a full source license, but we were all
> in violation of the source agreement on our personal workstations.  The
> argument was the sources on people's machines was ephemeral and not
> 'stored' there.   But it was definitely contentious.
> 
> 
> 
> On Fri, Sep 13, 2019 at 3:47 PM Clem Cole <clemc@ccc.com> wrote:
> 
> > slide 4 --  All of HP-UX, Ultrix and Digital UNIX/Tru64 are BSD kernels.
> > HP-UP and Tru64 support System V calls.
> >
> > BTW:  DG-UX and Stratus built their own kernels, but used System V command
> > systems and System Call definitions - which are not listed.
> >
> > Slide 6 - if you want it I have another picture of the GE system from some
> > of their literature has a view of all of the components.   Send me email if
> > you want it.
> >
> > Slide 8 - Sets out to write version of Fortran came up with B.  Uses B to
> > write Assembler
> >
> > Slide 9 - Wrong DEC logo.  Should be the Blue one.  The maroon version
> > does not show up until the 1990s with Bob Palmer (and has bad memories for
> > some of us).
> >
> > Slide 17 - Ken write PDP-11 assembler on PDP-7 in B. , Dennis starts to
> > rewrite B compiler to output PDP-11 code.
> >
> > Slide 18 - B begins to become different enough that Dennis starts to call
> > it nb [new B], eventually deviates enough to become new language
> >
> > Slide 19 - 4th Edition release outside of the BTL.  Lou Katz becomes 'user
> > zero'
> >
> > Slide 20 -- We need to get you the site and group name from Mash.  It was
> > not in Summit, it was not USG - but was in NJ.  I thought it was Homdel but
> > I that is purely speculation.
> >                   Also the role of Columbus team needs to be defined.
> >  Ask Mary Ann.
> >
> > Slide 21 -- I'm not going to argue - but I would ask you to add a
> > disclaimer.   This is what you could reconstruct, but there is some
> > question of some of the arrows.   Heinz might be able to help, but as
> > Stienhart and I have said, its believed to be in LA; but no one has tracked
> > him down as he has been pursuing non-computer interests.
> >
> > Slide 22 --4th Edition went to Katz that this is wrong, who sometimes
> > reads this mailing list.  If not, send me a note, I'll reintroduce you.  He
> > might be able to give you a data.  Check with Warren, my >>memory<< is that
> > some of userland is still in C although a lot assembler is still there.
> >
> > Slide 23 -- ??widespread??   -- I'm not sure I would use that. Not even
> > 100 sites yet.     Also there were not "commercial version" this was the
> > first "commercial license" -- big difference [contact me if you want
> > explanation].  IIRC fee was 15K per CPU.  Commercial redistribution doesn't
> > occur until after 7th is released and was a separate license.   I would
> > add, Mike Lesk's portable C library is starting to be used, but most C
> > program do their own I/O with read/write
> >
> >           First real install man page and Dennis build tape installation
> > system.   Earlier version released as RK05 disk copies.
> >            Also numerous new peripherals. IIRC Support for the 11/40
> > starts here, 4th & 5th needed a 45 class, and earlier used the 20 with the
> > CSS MMU.
> >
> > Slide 24 -- CMU uses it to teaches OS class.  makes student in class sign
> > a sub-license.
> >
> > Slide 25 - missing the first USENIX tapes. which include Harvard and the
> > like.  Warren and I can probably help a little here.
> >
> > Slide 26 - new licenses.  Commercial license fees change to 20K for 1st
> > CPU/5K for each CPU afterward.  CMU buys first commercial license to use
> > UNIX to make money [after Cole and Klein go on strike].  Case Western
> > follows suit 6month later.   AT&T agrees for the Universities that they
> > only had to declare one CPU as commercial and could intermix otherwise and
> > notifies all the universities that if they were using it for commercial
> > purposes, then needed a license.
> >
> > AT&T creates first redistribution license.  Needed at least one $20K
> > commercial CPU and then $150k for the rights to redistribute.   Originally
> > $1K per binary CPU.
> >
> > Slide 27 -- missing Purdue Dual Vax and CMU Mach
> >
> > Slide 28 - APS had NH which was the model the DEC plate you show.   Maddog
> > has it now on his Jeep when aps moved to CA (he also has the NH Linux plate
> > but I don't remember the car -- you can ask him).   I have had the
> > Massachusetts UNIX plate since 1983 (it's on my model S of course).   ghg
> > has indiana from around the same time (I think on a pickup).  wnj had the
> > CA vmunix on his Ferrari, but I don't know if he still has it or what its
> > on.
> >
> > Slide 29 - Look in HenrySpencer-TUHS.org -- you'll find tail but not head.
> >
> > Slide 31 - Job Control can from Europe via MIT.  Jim Kulp wrote it.   Noel
> > and I can give you the story if you want it.  It was on the PDP-11 there.
> >  Joy modified csh and added it to 4.1
> >
> > Slide 32 -- JC was not from UCB.   Joy got it from MIT   -- Dennis create
> > ENV and it was first distributed in V7.
> >
> > Slide 33 -- No Bourne supported ENV in the new shell -- see me earlier
> > email for how all this went down or ask Steve yourself.
> >
> > Slide 34 -- PCC was included, but the Ritchie Compiler (a.k.a. Typesetter
> > C) was the default compiler.  You are missing a step BTW -- typesetter C
> > was released between V6 and V7.   As is the first draft of the White Book.
> > The new compiler had stdio but targets V6.
> > Also mpx was part of DataKit support.
> >
> > Slide 35 --   Not sure that is true.   I thought Microsoft's Xenix ships
> > before Venix.    Particularly since you made the comment about System III
> > The original 8086 Xenix was a pure V7 port, with a few additions Gordon
> > brought with him from Purdue (i.e. ghg hacks).
> >
> > Slide 52/53/54/55 -- wrong logo (see above)
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Sep 12, 2019 at 11:21 PM Warner Losh <imp@bsdimp.com> wrote:
> >
> >> OK. I've shared my slides for the talk.
> >>
> >> Some of the family trees are simplified (V7 doesn't have room for all its
> >> ports, for example)
> >> Some of it is a little cheeseball since I'm also trying to be witty and
> >> entertaining (we'll see how that goes).
> >> Please don't share them around until after my talk on the September 20th
> >>
> >> I'd like feedback on the bits I got wrong. Or left out. Or if you're in
> >> this and don't want to be, etc.
> >>
> >> All the slides after the Questions slide won't be presented and will
> >> likely be deleted.
> >>
> >>
> >> https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing
> >>
> >> Please be kind (but if it sucks, please do tell). I've turned on
> >> commenting on the slides. Probably best if you comment there.
> >>
> >> I have a video of me giving this talk, but it's too rough to share...
> >>
> >> Thanks for any help you can give me.
> >>
> >> Warner
> >>
> >

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
  2019-09-13 20:06     ` Clem Cole
@ 2019-09-13 20:24       ` Jon Steinhart
  2019-09-13 20:43         ` Clem Cole
  2019-09-13 21:31       ` Clem Cole
  2019-09-17 19:18       ` Warner Losh
  2 siblings, 1 reply; 148+ messages in thread
From: Jon Steinhart @ 2019-09-13 20:24 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Not sure about the last bullet on slide 18.  I think that it would be more
correct to say "format" instead of "typeset" since I don't think that the
C/A/T came out until 1972.  I guess it all comes down to whether or not you
consider nroff on an ASR-37 to be typesetting.

Jon

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
  2019-09-13 20:24       ` Jon Steinhart
@ 2019-09-13 20:43         ` Clem Cole
  2019-09-13 20:53           ` Diomidis Spinellis
  0 siblings, 1 reply; 148+ messages in thread
From: Clem Cole @ 2019-09-13 20:43 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]

Jon - Good catch and that is a good reminder.
Warner - You need to add troff and the C/A/T to your timeline.  They were
too important.   What I don't remember, although Doug or Steve might, was
the original troff 4th or 5th edition?  bwk did ditroff, later with the
addition of the APS5.

FWIW: It was for 6th edition and post 1BSD that Tom Ferin did the original
vcat(1) work at UCSF's PDP-11.   It would get spread later to the world as
part of one of the BSDs, but the original emulation of a C/A/T4 with a
plotter support came from Tom, his graphics lab and the earlier work with
the Hershey fonts that CMU and Stanford had done to support the XGP for the
PDP-10s.  But that was super important for why people wanted UNIX early on.


On Fri, Sep 13, 2019 at 4:24 PM Jon Steinhart <jon@fourwinds.com> wrote:

> Not sure about the last bullet on slide 18.  I think that it would be more
> correct to say "format" instead of "typeset" since I don't think that the
> C/A/T came out until 1972.  I guess it all comes down to whether or not you
> consider nroff on an ASR-37 to be typesetting.
>
> Jon
>

[-- Attachment #2: Type: text/html, Size: 1861 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
  2019-09-13 20:43         ` Clem Cole
@ 2019-09-13 20:53           ` Diomidis Spinellis
  2019-09-13 21:45             ` Clem Cole
  0 siblings, 1 reply; 148+ messages in thread
From: Diomidis Spinellis @ 2019-09-13 20:53 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

The Fourth Edition manual was typeset in troff:
https://dspinellis.github.io/unix-v4man/v4man.pdf
https://github.com/dspinellis/unix-v4man

The Third Edition was nroff:
https://dspinellis.github.io/unix-v3man/v3man.pdf
https://github.com/dspinellis/unix-v3man

On 13-Sep-19 23:43, Clem Cole wrote:
> Jon - Good catch and that is a good reminder.
> Warner - You need to add troff and the C/A/T to your timeline.  They 
> were too important.   What I don't remember, although Doug or Steve 
> might, was the original troff 4th or 5th edition?  bwk did 
> ditroff, later with the addition of the APS5.

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
  2019-09-13 20:06     ` Clem Cole
  2019-09-13 20:24       ` Jon Steinhart
@ 2019-09-13 21:31       ` Clem Cole
  2019-09-17 19:29         ` Warner Losh
  2019-09-17 19:18       ` Warner Losh
  2 siblings, 1 reply; 148+ messages in thread
From: Clem Cole @ 2019-09-13 21:31 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 8491 bytes --]

BTW: I just found my PWB 1.0 manual.   The date is May 1977, authors are T.
(Ted) Dolotta, R. (Dick) Haight and E. Piskorik
and it lists the site as 'Piscataway' as the site on the
acknowlegements page.

On Fri, Sep 13, 2019 at 4:06 PM Clem Cole <clemc@ccc.com> wrote:

> Another thought -- the first commercial licensee was Rand.   Hired some
> former Harvard students who brought UNIX with them.   You probably need to
> add things like Rand Ports (a.k.a. named pipes) which came from there.
> Also Chesson and Co did the original ArpaNET NCP at University of Ill
> with some help from the Rand folks.   That was done on a V6 system ~ 1978
>
> You also need need Ken's famous V6 'patch' tape -- that 'leaked'
>
>
> On Fri, Sep 13, 2019 at 4:02 PM Clem Cole <clemc@ccc.com> wrote:
>
>> BTW:  I just thought of something else....  one of the b*tched about the
>> commercial redistribution license from V7 in 1979, that was not fixed until
>> the SVR3 licensing the mid-late 1980s  was AT&T's source policy.   As I
>> said, a commercial source license was $20K for the first CPU and 5K for
>> each additional one.   Later (System V) it went to $50K for the first and
>> $10K for each additional.   But what really ticked off the vendors like
>> DEC, Masscomp, Sun et al, was that each system that sources on was supposed
>> to one of the 'second CPU licenses' - the binary license was not good
>> enough.
>>
>> What most of us did, was make sure any system that was a 'source control'
>> or 'master' system at any 'site' had a full source license, but we were all
>> in violation of the source agreement on our personal workstations.  The
>> argument was the sources on people's machines was ephemeral and not
>> 'stored' there.   But it was definitely contentious.
>>
>>
>>
>> On Fri, Sep 13, 2019 at 3:47 PM Clem Cole <clemc@ccc.com> wrote:
>>
>>> slide 4 --  All of HP-UX, Ultrix and Digital UNIX/Tru64 are BSD
>>> kernels.  HP-UP and Tru64 support System V calls.
>>>
>>> BTW:  DG-UX and Stratus built their own kernels, but used System V
>>> command systems and System Call definitions - which are not listed.
>>>
>>> Slide 6 - if you want it I have another picture of the GE system from
>>> some of their literature has a view of all of the components.   Send me
>>> email if you want it.
>>>
>>> Slide 8 - Sets out to write version of Fortran came up with B.  Uses B
>>> to write Assembler
>>>
>>> Slide 9 - Wrong DEC logo.  Should be the Blue one.  The maroon version
>>> does not show up until the 1990s with Bob Palmer (and has bad memories for
>>> some of us).
>>>
>>> Slide 17 - Ken write PDP-11 assembler on PDP-7 in B. , Dennis starts to
>>> rewrite B compiler to output PDP-11 code.
>>>
>>> Slide 18 - B begins to become different enough that Dennis starts to
>>> call it nb [new B], eventually deviates enough to become new language
>>>
>>> Slide 19 - 4th Edition release outside of the BTL.  Lou Katz
>>> becomes 'user zero'
>>>
>>> Slide 20 -- We need to get you the site and group name from Mash.  It
>>> was not in Summit, it was not USG - but was in NJ.  I thought it was Homdel
>>> but I that is purely speculation.
>>>                   Also the role of Columbus team needs to be defined.
>>>  Ask Mary Ann.
>>>
>>> Slide 21 -- I'm not going to argue - but I would ask you to add a
>>> disclaimer.   This is what you could reconstruct, but there is some
>>> question of some of the arrows.   Heinz might be able to help, but as
>>> Stienhart and I have said, its believed to be in LA; but no one has tracked
>>> him down as he has been pursuing non-computer interests.
>>>
>>> Slide 22 --4th Edition went to Katz that this is wrong, who sometimes
>>> reads this mailing list.  If not, send me a note, I'll reintroduce you.  He
>>> might be able to give you a data.  Check with Warren, my >>memory<< is that
>>> some of userland is still in C although a lot assembler is still there.
>>>
>>> Slide 23 -- ??widespread??   -- I'm not sure I would use that. Not even
>>> 100 sites yet.     Also there were not "commercial version" this was the
>>> first "commercial license" -- big difference [contact me if you want
>>> explanation].  IIRC fee was 15K per CPU.  Commercial redistribution doesn't
>>> occur until after 7th is released and was a separate license.   I would
>>> add, Mike Lesk's portable C library is starting to be used, but most C
>>> program do their own I/O with read/write
>>>
>>>           First real install man page and Dennis build tape installation
>>> system.   Earlier version released as RK05 disk copies.
>>>            Also numerous new peripherals. IIRC Support for the 11/40
>>> starts here, 4th & 5th needed a 45 class, and earlier used the 20 with the
>>> CSS MMU.
>>>
>>> Slide 24 -- CMU uses it to teaches OS class.  makes student in class
>>> sign a sub-license.
>>>
>>> Slide 25 - missing the first USENIX tapes. which include Harvard and the
>>> like.  Warren and I can probably help a little here.
>>>
>>> Slide 26 - new licenses.  Commercial license fees change to 20K for 1st
>>> CPU/5K for each CPU afterward.  CMU buys first commercial license to use
>>> UNIX to make money [after Cole and Klein go on strike].  Case Western
>>> follows suit 6month later.   AT&T agrees for the Universities that they
>>> only had to declare one CPU as commercial and could intermix otherwise and
>>> notifies all the universities that if they were using it for commercial
>>> purposes, then needed a license.
>>>
>>> AT&T creates first redistribution license.  Needed at least one $20K
>>> commercial CPU and then $150k for the rights to redistribute.   Originally
>>> $1K per binary CPU.
>>>
>>> Slide 27 -- missing Purdue Dual Vax and CMU Mach
>>>
>>> Slide 28 - APS had NH which was the model the DEC plate you show.
>>>  Maddog has it now on his Jeep when aps moved to CA (he also has the NH
>>> Linux plate but I don't remember the car -- you can ask him).   I have had
>>> the Massachusetts UNIX plate since 1983 (it's on my model S of course).
>>>  ghg has indiana from around the same time (I think on a pickup).  wnj had
>>> the CA vmunix on his Ferrari, but I don't know if he still has it or what
>>> its on.
>>>
>>> Slide 29 - Look in HenrySpencer-TUHS.org -- you'll find tail but not
>>> head.
>>>
>>> Slide 31 - Job Control can from Europe via MIT.  Jim Kulp wrote it.
>>>  Noel and I can give you the story if you want it.  It was on the PDP-11
>>> there.   Joy modified csh and added it to 4.1
>>>
>>> Slide 32 -- JC was not from UCB.   Joy got it from MIT   -- Dennis
>>> create ENV and it was first distributed in V7.
>>>
>>> Slide 33 -- No Bourne supported ENV in the new shell -- see me earlier
>>> email for how all this went down or ask Steve yourself.
>>>
>>> Slide 34 -- PCC was included, but the Ritchie Compiler (a.k.a.
>>> Typesetter C) was the default compiler.  You are missing a step BTW --
>>> typesetter C was released between V6 and V7.   As is the first draft of the
>>> White Book.  The new compiler had stdio but targets V6.
>>> Also mpx was part of DataKit support.
>>>
>>> Slide 35 --   Not sure that is true.   I thought Microsoft's Xenix ships
>>> before Venix.    Particularly since you made the comment about System III
>>> The original 8086 Xenix was a pure V7 port, with a few additions Gordon
>>> brought with him from Purdue (i.e. ghg hacks).
>>>
>>> Slide 52/53/54/55 -- wrong logo (see above)
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Sep 12, 2019 at 11:21 PM Warner Losh <imp@bsdimp.com> wrote:
>>>
>>>> OK. I've shared my slides for the talk.
>>>>
>>>> Some of the family trees are simplified (V7 doesn't have room for all
>>>> its ports, for example)
>>>> Some of it is a little cheeseball since I'm also trying to be witty and
>>>> entertaining (we'll see how that goes).
>>>> Please don't share them around until after my talk on the September 20th
>>>>
>>>> I'd like feedback on the bits I got wrong. Or left out. Or if you're in
>>>> this and don't want to be, etc.
>>>>
>>>> All the slides after the Questions slide won't be presented and will
>>>> likely be deleted.
>>>>
>>>>
>>>> https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing
>>>>
>>>> Please be kind (but if it sucks, please do tell). I've turned on
>>>> commenting on the slides. Probably best if you comment there.
>>>>
>>>> I have a video of me giving this talk, but it's too rough to share...
>>>>
>>>> Thanks for any help you can give me.
>>>>
>>>> Warner
>>>>
>>>

[-- Attachment #2: Type: text/html, Size: 15795 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
  2019-09-13 20:53           ` Diomidis Spinellis
@ 2019-09-13 21:45             ` Clem Cole
  2019-09-13 22:13               ` [TUHS] earliest Unix roff Warren Toomey
  2019-09-14  7:35               ` [TUHS] My EuroBSDcon talk (preview for commentary) Diomidis Spinellis
  0 siblings, 2 replies; 148+ messages in thread
From: Clem Cole @ 2019-09-13 21:45 UTC (permalink / raw)
  To: Diomidis Spinellis; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 3478 bytes --]

Awesome -- great way to figure it out, although I'm not sure 3rd edition
was nroff, I think it might have been roff.  I think a smart test is to
check to see if those sources used a macro package or not.  If not macro
package, I think that tells us that the likely formatting program was roff.

It does leave us an interesting question, when did the original roff(1)
show up and when did nroff(1).  The original, roff(1), was early, and of
course not until after the original PDP-11/20 port.  But was it as early as
first edition?   roff was the first formatting program.  nroff replaced it
later on, although roff lived through the 6th edition (I do not believe it
is on the v7 tape).

I was under the impression that the order is this ... roff was written for
either v1 or v2 in 1970 or 71; I thought originally by Ken to be similar to
the runoff that ran on the GE systems.   At some point the team recieved
the /C/A/T and Joseph Ossanna wrote a new program to support it,
*a.k.a. *troff,
that was similar to roff but troff was not a superset of the original
program.  nroff was then written after troff came into being to parrot the
behavior of troff using an ASR-37; but I do not know who was the author (it
might have been Ossanna).  But it was a third program, that used the same
macro packages as troff that started to appear for Ossanna's program and
the input language was changed so that a document author could know what
was the output target.

As I said, nroff and roff were in the v6 distribution, although not troff
if I remember it correctly; although troff was part of PWB 1.0.  The
inclusion of both roff and nroff was because some of the Unix
papers/documentation used roff for formatting, not the troff/nroff input
syntax. That said, the PWB man pages have the roff manpage, as well as a
single man page for both nroff and troff with sections later that say
'nroff only' and 'troff only.'

Also I do not remember having any macro packages for roff(1), but their
might have been some, although I just checked the PWB man page and it does
not list a .so command to read in macros, there is no mention of a macro
switch on the command line and in the files section the only external file
it used was the hyphenation tables.

Finally, Ossanna tragically died and some time later the new APS/5 was
obtained. So, bwk wrote a new program yet, that used post processors and
some front end tables, to allow the 'typesetter' portion to work regardless
of the output device (*i.e.* device independent troff or ditroff).   With
the idea only a single program would be needed to be supported.  By this
point nothing in the Research 'releases' required the original roff program
and since it was in assembler, I believe that it was dropped from all
further support.

Clem



On Fri, Sep 13, 2019 at 4:53 PM Diomidis Spinellis <dds@aueb.gr> wrote:

> The Fourth Edition manual was typeset in troff:
> https://dspinellis.github.io/unix-v4man/v4man.pdf
> https://github.com/dspinellis/unix-v4man
>
> The Third Edition was nroff:
> https://dspinellis.github.io/unix-v3man/v3man.pdf
> https://github.com/dspinellis/unix-v3man
>
> On 13-Sep-19 23:43, Clem Cole wrote:
> > Jon - Good catch and that is a good reminder.
> > Warner - You need to add troff and the C/A/T to your timeline.  They
> > were too important.   What I don't remember, although Doug or Steve
> > might, was the original troff 4th or 5th edition?  bwk did
> > ditroff, later with the addition of the APS5.
>

[-- Attachment #2: Type: text/html, Size: 5602 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-13 21:45             ` Clem Cole
@ 2019-09-13 22:13               ` Warren Toomey
  2019-09-13 22:55                 ` Clem Cole
  2019-09-14  7:35               ` [TUHS] My EuroBSDcon talk (preview for commentary) Diomidis Spinellis
  1 sibling, 1 reply; 148+ messages in thread
From: Warren Toomey @ 2019-09-13 22:13 UTC (permalink / raw)
  To: tuhs

On Fri, Sep 13, 2019 at 05:45:51PM -0400, Clem Cole wrote:
>    It does leave us an interesting question, when did the original roff(1)
>    show up and when did nroff(1).  The original, roff(1), was early, and
>    of course not until after the original PDP-11/20 port.  But was it as
>    early as first edition?   roff was the first formatting program.  nroff
>    replaced it later on, although roff lived through the 6th edition (I do
>    not believe it is on the v7 tape).

There was a roff on PDP-7 Unix:

    By the spring of 1971, it was generally agreed that no one had the
    slightest interest in scrapping Unix. Therefore, we transliterated
    the roff text formatter into PDP-11 assembler language, starting from
    the PDP-7 version that had been transliterated from McIlroy’s BCPL
    version on Multics, which had in turn been inspired by J. Saltzer’s
    runoff program on CTSS.

From "The Evolution of the Unix Time-sharing System"

http://www.read.seas.harvard.edu/~kohler/class/aosref/ritchie84evolution.pdf

Cheers, Warren

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-13 22:13               ` [TUHS] earliest Unix roff Warren Toomey
@ 2019-09-13 22:55                 ` Clem Cole
  2019-09-14  2:02                   ` Larry McVoy
  0 siblings, 1 reply; 148+ messages in thread
From: Clem Cole @ 2019-09-13 22:55 UTC (permalink / raw)
  To: Warren Toomey; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]

Thanks.  So we have a date that explains the pdp-11 assembler version - it
was there at v1.

On Fri, Sep 13, 2019 at 6:14 PM Warren Toomey <wkt@tuhs.org> wrote:

> On Fri, Sep 13, 2019 at 05:45:51PM -0400, Clem Cole wrote:
> >    It does leave us an interesting question, when did the original
> roff(1)
> >    show up and when did nroff(1).  The original, roff(1), was early, and
> >    of course not until after the original PDP-11/20 port.  But was it as
> >    early as first edition?   roff was the first formatting program.
> nroff
> >    replaced it later on, although roff lived through the 6th edition (I
> do
> >    not believe it is on the v7 tape).
>
> There was a roff on PDP-7 Unix:
>
>     By the spring of 1971, it was generally agreed that no one had the
>     slightest interest in scrapping Unix. Therefore, we transliterated
>     the roff text formatter into PDP-11 assembler language, starting from
>     the PDP-7 version that had been transliterated from McIlroy’s BCPL
>     version on Multics, which had in turn been inspired by J. Saltzer’s
>     runoff program on CTSS.
>
> From "The Evolution of the Unix Time-sharing System"
>
>
> http://www.read.seas.harvard.edu/~kohler/class/aosref/ritchie84evolution.pdf
>
> Cheers, Warren
>
-- 
Sent from a handheld expect more typos than usual

[-- Attachment #2: Type: text/html, Size: 1917 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-13 22:55                 ` Clem Cole
@ 2019-09-14  2:02                   ` Larry McVoy
  2019-09-14  2:44                     ` Warren Toomey
  0 siblings, 1 reply; 148+ messages in thread
From: Larry McVoy @ 2019-09-14  2:02 UTC (permalink / raw)
  To: Clem Cole; +Cc: tuhs

> >     slightest interest in scrapping Unix. Therefore, we transliterated
> >     the roff text formatter into PDP-11 assembler language, starting from
> >     the PDP-7 version that had been transliterated from McIlroy???s BCPL
> >     version on Multics, which had in turn been inspired by J. Saltzer???s
> >     runoff program on CTSS.

As a *roff guy to the core, to this day, I'd love to see any docs on the 
Multics version and/or the CTSS version.

Roff has some pretty sophisticated stuff (environments come to mind) that
I think 99.9% of the CS world doesn't understand (sort of like my rant
on SCCS, most people didn't look hard enough to get it.  I'm not sure
that I get roff environments to this day but I kinda do).

I'd love to see the docs on that early stuff and see if Joe Ossanna
added in his own magic or was he carrying forward earlier magic.

--lm

P.S.  I love this list for this stuff, I'm an old retired guy that 
wishes he could have helped birth Unix.  Hanging out with the people
who were there is super fun.

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-14  2:02                   ` Larry McVoy
@ 2019-09-14  2:44                     ` Warren Toomey
  2019-09-15  2:56                       ` U'll Be King of the Stars
  2019-09-15 19:27                       ` [TUHS] earliest Unix roff Clem Cole
  0 siblings, 2 replies; 148+ messages in thread
From: Warren Toomey @ 2019-09-14  2:44 UTC (permalink / raw)
  To: Larry McVoy; +Cc: tuhs

On Fri, Sep 13, 2019 at 07:02:40PM -0700, Larry McVoy wrote:
> Roff has some pretty sophisticated stuff (environments come to mind) that
> I think 99.9% of the CS world doesn't understand (sort of like my rant
> on SCCS, most people didn't look hard enough to get it.  I'm not sure
> that I get roff environments to this day but I kinda do).
> 
> I'd love to see the docs on that early stuff and see if Joe Ossanna
> added in his own magic or was he carrying forward earlier magic.

Here's a good page on the history:
https://manpages.bsd.lv/history.html
 
> P.S.  I love this list for this stuff, I'm an old retired guy that 
> wishes he could have helped birth Unix.  Hanging out with the people
> who were there is super fun.

Hell yeah to both!

Cheers, Warren

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
  2019-09-13 19:47 ` Clem Cole
  2019-09-13 20:02   ` Clem Cole
@ 2019-09-14  6:13   ` Wesley Parish
  1 sibling, 0 replies; 148+ messages in thread
From: Wesley Parish @ 2019-09-14  6:13 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

I had the pleasure to play on both a DEC Rainbow and an early Sony PC
(both running MS DOS 2.x though the Rainbow also ran CP/M) in the
early 90s. They could have been described as being only relatively
"IBM clones", as their BIOS did not fully reimplement the IBM PC BIOS.
That was the Phoenix BIOS's achievement.

Consequently Microsoft's Xenix would have come in several different
flavours, according to who the OEM was. I don't know how long this
state of affairs went on for; I do know several computer books dating
from the late 80s I looked at in the early 90s regarded this a
standard, though regrettable, problem.

Do we have any Microsoft Xenix guys on this list? Anyone who'd be able
to fill in these gaps in our knowledge? Or does anyone know anyone
formerly of Microsoft or the original Santa Cruz Operation who we
could ask?

Wesley Parish

On 9/14/19, Clem Cole <clemc@ccc.com> wrote:
<snip>
>
> Slide 35 --   Not sure that is true.   I thought Microsoft's Xenix ships
> before Venix.    Particularly since you made the comment about System III
> The original 8086 Xenix was a pure V7 port, with a few additions Gordon
> brought with him from Purdue (i.e. ghg hacks).
>

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
  2019-09-13 21:45             ` Clem Cole
  2019-09-13 22:13               ` [TUHS] earliest Unix roff Warren Toomey
@ 2019-09-14  7:35               ` Diomidis Spinellis
  1 sibling, 0 replies; 148+ messages in thread
From: Diomidis Spinellis @ 2019-09-14  7:35 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

Correct!  I formatted the Third Edition manual with nroff rather than 
troff, but, as you write, it could have been roff.

Only one man page file contains macro definitions:

https://github.com/dspinellis/unix-history-repo/blob/Research-V3/man/manx/asmt.x#L9

and the man source files also contain the formatted output corresponding 
to that file:

https://github.com/dspinellis/unix-history-repo/blob/Research-V3/man/manx/asmt.cat

Furthermore, this file (and the others in the same directory — manx) 
does not appear in the original Third Edition manual.

So most likely the man pages were formatted with roff, although nroff 
existed and was documented at the time.

https://github.com/dspinellis/unix-history-repo/blob/Research-V3/man/man1/nroff.1

http://bitsavers.trailing-edge.com/pdf/att/unix/3rd_Edition/UNIX_Programmers_Manual_Third_Edition_Feb73.pdf#page=98



On 14-Sep-19 0:45, Clem Cole wrote:
> Awesome -- great way to figure it out, although I'm not sure 3rd edition 
> was nroff, I think it might have been roff.  I think a smart test is to 
> check to see if those sources used a macro package or not.  If not macro 
> package, I think that tells us that the likely formatting program was roff.

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-14  2:44                     ` Warren Toomey
@ 2019-09-15  2:56                       ` U'll Be King of the Stars
  2019-09-15  6:54                         ` arnold
  2019-09-15 19:35                         ` Clem Cole
  2019-09-15 19:27                       ` [TUHS] earliest Unix roff Clem Cole
  1 sibling, 2 replies; 148+ messages in thread
From: U'll Be King of the Stars @ 2019-09-15  2:56 UTC (permalink / raw)
  To: Warren Toomey, Larry McVoy, tuhs

On 14/09/2019 03:44, Warren Toomey wrote:
> On Fri, Sep 13, 2019 at 07:02:40PM -0700, Larry McVoy wrote:
>> Roff has some pretty sophisticated stuff (environments come to mind) that
>> I think 99.9% of the CS world doesn't understand

This thread about *roff echoes something that I have been thinking about 
recently.

I've been wondering whether it is possible and worthwhile to use *roff 
for complex technical documentation.  I've always loved the aesthetic 
that books produced using *roff have but there are other reasons too.

As far as _markup_ is concerned we have DocBook for example.  I am also 
looking into this.  (Also, I understand it's not a typesetting system.)

Getting back to *roff, does anybody know if there is a (hopefully rich) 
repository of macros, or any other resources, for my use case?  (La)TeX 
has this but I'd like to try something else.  What do people think?

Kind regards,

Andrew
-- 
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-15  2:56                       ` U'll Be King of the Stars
@ 2019-09-15  6:54                         ` arnold
  2019-09-15  7:01                           ` Dave Horsfall
                                             ` (2 more replies)
  2019-09-15 19:35                         ` Clem Cole
  1 sibling, 3 replies; 148+ messages in thread
From: arnold @ 2019-09-15  6:54 UTC (permalink / raw)
  To: wkt, ullbeking, tuhs, lm

"U'll Be King of the Stars" <ullbeking@andrewnesbit.org> wrote:

> On 14/09/2019 03:44, Warren Toomey wrote:
> > On Fri, Sep 13, 2019 at 07:02:40PM -0700, Larry McVoy wrote:
> >> Roff has some pretty sophisticated stuff (environments come to mind) that
> >> I think 99.9% of the CS world doesn't understand
>
> This thread about *roff echoes something that I have been thinking about 
> recently.
>
> I've been wondering whether it is possible and worthwhile to use *roff 
> for complex technical documentation.  I've always loved the aesthetic 
> that books produced using *roff have but there are other reasons too.
>
> As far as _markup_ is concerned we have DocBook for example.  I am also 
> looking into this.  (Also, I understand it's not a typesetting system.)

Unless you use a WYSIWYG tool that generates DocBook, you should avoid it.
Your fingers will kill you.  I have written books in troff, DocBook
and Texinfo.  Texinfo is *by far* the superior markup language.

Using Texinfo can generate DocBook which your publisher can turn into PDF.
(I have done this, three times at least.)  But working directly in
DocBook just plain hurts.

> Getting back to *roff, does anybody know if there is a (hopefully rich) 
> repository of macros, or any other resources, for my use case?  (La)TeX 
> has this but I'd like to try something else.  What do people think?

The MM macros are the most capable of the standard sets that are
out there, although possibly the MOM macros distributed with groff
are even more so; I have not investigated fully.

My own wish for the next genie in a lamp that I come across would be
for a texinfo --> troff translator.

Arnold

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-15  6:54                         ` arnold
@ 2019-09-15  7:01                           ` Dave Horsfall
  2019-09-15 16:17                             ` Jon Steinhart
  2019-09-15 19:48                             ` Clem Cole
  2019-09-15  7:32                           ` U'll Be King of the Stars
  2019-09-15 19:37                           ` Clem Cole
  2 siblings, 2 replies; 148+ messages in thread
From: Dave Horsfall @ 2019-09-15  7:01 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Sun, 15 Sep 2019, arnold@skeeve.com wrote:

> The MM macros are the most capable of the standard sets that are out 
> there, although possibly the MOM macros distributed with groff are even 
> more so; I have not investigated fully.

For some reason I prefer the MS macros, probably because I learnt them 
first and I find it difficult to use MM.

-- Dave

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-15  6:54                         ` arnold
  2019-09-15  7:01                           ` Dave Horsfall
@ 2019-09-15  7:32                           ` U'll Be King of the Stars
  2019-09-15  7:46                             ` arnold
  2019-09-15 19:37                           ` Clem Cole
  2 siblings, 1 reply; 148+ messages in thread
From: U'll Be King of the Stars @ 2019-09-15  7:32 UTC (permalink / raw)
  To: arnold, Warren Toomey, The Eunuchs Hysterical Society, Larry McVoy

On 15/09/2019 07:54, arnold@skeeve.com wrote:
> "U'll Be King of the Stars" <ullbeking@andrewnesbit.org> wrote:
>> I've been wondering whether it is possible and worthwhile to use *roff
>> for complex technical documentation.  I've always loved the aesthetic
>> that books produced using *roff have but there are other reasons too.
>>
>> As far as _markup_ is concerned we have DocBook for example.  I am also
>> looking into this.  (Also, I understand it's not a typesetting system.)
> 
> Unless you use a WYSIWYG tool that generates DocBook, you should avoid it.
> Your fingers will kill you.

Oh, I'm not looking for WYSIWIG or even really WYSIMIM.  I'm well used 
to writing in structural markup and presentation markup languages, e.g., 
LaTeX (which I think is extremely complicated, and since I left the 
university environment I do not miss it).

AS for authoring DocBook I was depending on GNU Emacs to do a lot of the 
heavy XML stuff for me.  Wishful thinking perhaps.

> I have written books in troff, DocBook
> and Texinfo.  Texinfo is *by far* the superior markup language.

I've had a feeling that Texinfo has been getting brushed to the side.

Are you suggesting that Info is a good as a rendered documentation 
format?  Or just that Texinfo is good for proto-documents that are to be 
authored in a parseable and meaningful format?

I've been a long-time GNU Emacs user so reading Info files is OK for me. 
  But we've never had a _nice_ Info reader, which is why it didn't take 
off I think.  A lot of people REALLY hate the Info UI.

Moreover it was (is?) very difficult to generate good contents and index 
pages with the official tools that I used at the time.  I started 
working on improving this about 20 years ago but back then it felt as 
though the GNU Info and GNU Emacs projects had other things on their minds.

> Using Texinfo can generate DocBook which your publisher can turn into PDF.
> (I have done this, three times at least.)  But working directly in
> DocBook just plain hurts.

OK, so you are suggesting Texinfo as a prototypical markup language, not 
necessarily something that will end up as Info files?

I have read the Texinfo documentation and I agree that it seemed like a 
rich markup language.

>> Getting back to *roff, does anybody know if there is a (hopefully rich)
>> repository of macros, or any other resources, for my use case?  (La)TeX
>> has this but I'd like to try something else.  What do people think?
> 
> The MM macros are the most capable of the standard sets that are
> out there, although possibly the MOM macros distributed with groff
> are even more so; I have not investigated fully.

Thank you for the heads up.  I never heard of MOM but MM is more familiar.

*I haven't really looked at eqn beyond browsing docs and I'm not sure 
how much I should expect from it.*

TeX is (still?) the king of mathematical expression typesetting.

> My own wish for the next genie in a lamp that I come across would be
> for a texinfo --> troff translator.

Have you looked at Pandoc?  I don't know if it will do this but it's 
worth checking out.

Andrew
-- 
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-15  7:32                           ` U'll Be King of the Stars
@ 2019-09-15  7:46                             ` arnold
  0 siblings, 0 replies; 148+ messages in thread
From: arnold @ 2019-09-15  7:46 UTC (permalink / raw)
  To: wkt, ullbeking, tuhs, lm, arnold

Hi.

"U'll Be King of the Stars" <ullbeking@andrewnesbit.org> wrote:

> AS for authoring DocBook I was depending on GNU Emacs to do a lot of the 
> heavy XML stuff for me.  Wishful thinking perhaps.

Possibly. I use gvim. :-)  And, no, I won't start _that_ discussion.
To each his own, live and let live.

> > I have written books in troff, DocBook
> > and Texinfo.  Texinfo is *by far* the superior markup language.
>
> I've had a feeling that Texinfo has been getting brushed to the side.

It is actively maintained and developed.

> Are you suggesting that Info is a good as a rendered documentation 
> format?  Or just that Texinfo is good for proto-documents that are to be 
> authored in a parseable and meaningful format?

The latter.

> Moreover it was (is?) very difficult to generate good contents and index 
> pages with the official tools that I used at the time.

For _printed_ matter, the current texinfo does fine at table of
contents.  The upcoming version of texinfo (in prerelease now) has
new indexing capabilities that bring it on par with what you see
in commercial publishing: multilevel indexing, as well as "see" and
"see also" entries.

I agree that Info isn't lovely; I prefer to read the generated HTML
from makeinfo, or the PDF from texi2pdf.

> I have read the Texinfo documentation and I agree that it seemed like a 
> rich markup language.

Much of the growth in the markup language has been at my urging
over the years. :-)

> *I haven't really looked at eqn beyond browsing docs and I'm not sure 
> how much I should expect from it.*

eqn is the inspiration for math mode in TeX.  That's very clear,
and Knuth was also aware of tbl.

> > My own wish for the next genie in a lamp that I come across would be
> > for a texinfo --> troff translator.
>
> Have you looked at Pandoc?  I don't know if it will do this but it's 
> worth checking out.

Thanks for that pointer. I'll have to take a look at it.

Arnold

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-15  7:01                           ` Dave Horsfall
@ 2019-09-15 16:17                             ` Jon Steinhart
  2019-09-15 17:23                               ` Ronald Natalie
  2019-09-15 19:48                             ` Clem Cole
  1 sibling, 1 reply; 148+ messages in thread
From: Jon Steinhart @ 2019-09-15 16:17 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Dave Horsfall writes:
> On Sun, 15 Sep 2019, arnold@skeeve.com wrote:
>
> > The MM macros are the most capable of the standard sets that are out 
> > there, although possibly the MOM macros distributed with groff are even 
> > more so; I have not investigated fully.
>
> For some reason I prefer the MS macros, probably because I learnt them 
> first and I find it difficult to use MM.
>
> -- Dave

I am also a MS fan.  Tektronix did their own version of MS that added a ton
of really nice features.  Would be nice if someone could share that since
Tek is long gone and probably doesn't care.

Jon

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-15 16:17                             ` Jon Steinhart
@ 2019-09-15 17:23                               ` Ronald Natalie
  0 siblings, 0 replies; 148+ messages in thread
From: Ronald Natalie @ 2019-09-15 17:23 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society

ROFF is the simplest of the runoff programs but is utterly frozen.

I started with the -ms macro package so I had fondness for it, but switched to -mm over time.     I had done some work (after not being able to pry a version Dennis Mumaugh had written out of the agency) on putting classification marking and formatting in it.    I had restyled it to make the output look like the standard IBM formatting when we were doing UNIX work under contract for IBM.

At Hopkins, we had a small furor when Mike (Michael John) Muuss wrote his own macro package and installed it as tmac.jm (invoked by the -mjm option).   This led to lots of jokes about renaming programs and options after various users.


^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-14  2:44                     ` Warren Toomey
  2019-09-15  2:56                       ` U'll Be King of the Stars
@ 2019-09-15 19:27                       ` Clem Cole
  2019-09-15 19:31                         ` Jon Steinhart
  1 sibling, 1 reply; 148+ messages in thread
From: Clem Cole @ 2019-09-15 19:27 UTC (permalink / raw)
  To: Warren Toomey; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]

Warren,

On Fri, Sep 13, 2019 at 10:44 PM Warren Toomey <wkt@tuhs.org> wrote:

>
> Here's a good page on the history:
> https://manpages.bsd.lv/history.html

Excellent - thanks for the pointer.   This shows nroff before troff.
 FWIW: I guess I was miss informed, but I had been under the impression
that was the other way around.  i.e. nroff was done to be compliant with
the new troff, replacing roff, although the suggestion here is that he
wrote it add macros to roff.  I'll note that either way, the dates are all
possible of course because the U/L case ASR 37 was introduced 1968 so by
the early 1970's they would have been around the labs.

[-- Attachment #2: Type: text/html, Size: 1225 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-15 19:27                       ` [TUHS] earliest Unix roff Clem Cole
@ 2019-09-15 19:31                         ` Jon Steinhart
  0 siblings, 0 replies; 148+ messages in thread
From: Jon Steinhart @ 2019-09-15 19:31 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Clem Cole writes:
> Excellent - thanks for the pointer.   This shows nroff before troff.
>  FWIW: I guess I was miss informed, but I had been under the impression
> that was the other way around.  i.e. nroff was done to be compliant with
> the new troff, replacing roff, although the suggestion here is that he
> wrote it add macros to roff.  I'll note that either way, the dates are all
> possible of course because the U/L case ASR 37 was introduced 1968 so by
> the early 1970's they would have been around the labs.

Yes, we had ASR 37s, used one myself.  Not only did the do upper and lower
case, but they also did Greek and math characters, had bracket building
characters, and so on.  Biggest problem was line noise since these were
mostly on dial-up.  One could be having a nice day and all of a sudden a
burst of line noise would trigger a shift-out and everything would be
gibberish.

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-15  2:56                       ` U'll Be King of the Stars
  2019-09-15  6:54                         ` arnold
@ 2019-09-15 19:35                         ` Clem Cole
  2019-09-15 20:49                           ` U'll Be King of the Stars
  1 sibling, 1 reply; 148+ messages in thread
From: Clem Cole @ 2019-09-15 19:35 UTC (permalink / raw)
  To: U'll Be King of the Stars; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]

On Sat, Sep 14, 2019 at 11:03 PM U'll Be King of the Stars <
ullbeking@andrewnesbit.org> wrote:

>
> I've been wondering whether it is possible and worthwhile to use *roff
> for complex technical documentation.  I've always loved the aesthetic
> that books produced using *roff have but there are other reasons too.
>
Ditto.  The books that used roff can look clean and within a series are
usually consistent, but what I've like is that they are different.
The Prentiss-Hall series and the ORA books both were produced using troff
and different versions of ms, but the results are different.

One of my complained with LaTex books is they all seem to look the same.


> Getting back to *roff, does anybody know if there is a (hopefully rich)
> repository of macros, or any other resources, for my use case?
>
I've never seen one.   As far as I knew it, publishers sometimes seeded
authors.  ORA used the Masscomp/Tektronix derived version of ms (-mS) that
Steve Talbot created (and Rick LeFaivre originally created from the
original Lesk V7 set).   Rich Steven's has his own additions to the version
of ms that came with groff which I have also seen.

[-- Attachment #2: Type: text/html, Size: 2314 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-15  6:54                         ` arnold
  2019-09-15  7:01                           ` Dave Horsfall
  2019-09-15  7:32                           ` U'll Be King of the Stars
@ 2019-09-15 19:37                           ` Clem Cole
  2019-09-16  5:52                             ` arnold
  2 siblings, 1 reply; 148+ messages in thread
From: Clem Cole @ 2019-09-15 19:37 UTC (permalink / raw)
  To: Aharon Robbins; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 308 bytes --]

On Sun, Sep 15, 2019 at 2:55 AM <arnold@skeeve.com> wrote:

> Texinfo is *by far* the superior markup language.
>
I'll take your work for it, but my complaint is it requires emacs to use as
the pager on my screen.  If you live in emacs, that makes sense; but most
people, even in the GNU/Linux world, don't.

[-- Attachment #2: Type: text/html, Size: 794 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-15  7:01                           ` Dave Horsfall
  2019-09-15 16:17                             ` Jon Steinhart
@ 2019-09-15 19:48                             ` Clem Cole
  2019-09-15 21:16                               ` Dave Horsfall
  1 sibling, 1 reply; 148+ messages in thread
From: Clem Cole @ 2019-09-15 19:48 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]

I learn runoff from the IBM and the TOPS, then PUB then Scribe before I saw
the nroff/troff family.
I have fond memories of using Scribe (which was sort of the model for the
LaTex macros when it got tied up in the legal entanglements of CMU).   So
UNIX was what I had and became adept at it.

Like Larry, it's still my goto today and even prefer to Word for anything
over a single page.

On Sun, Sep 15, 2019 at 3:01 AM Dave Horsfall <dave@horsfall.org> wrote:

> For some reason I prefer the MS macros, probably because I learnt them
> first and I find it difficult to use MM.
>
The order I learned them was -mm {PWB}, -ms {V7}, -man {V7}, -ms {Tek}, -me
{UCB}, -mS {MSCP}, -man {UCB version}.   I feel into -ms with a couple of
macros from -mS (.Li/Le for lists which were similar to MM's) for big
documents, and the UCB -man for really simple things.   It becomes a 'less
is more' sort of thing - -mm and too complicated and I was not writing BTL
tech memos, and after I did not my thesis, I did not need Eric's work
(which was perfect for a UCB thesis).

[-- Attachment #2: Type: text/html, Size: 1815 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-15 19:35                         ` Clem Cole
@ 2019-09-15 20:49                           ` U'll Be King of the Stars
  2019-09-16  6:20                             ` arnold
  0 siblings, 1 reply; 148+ messages in thread
From: U'll Be King of the Stars @ 2019-09-15 20:49 UTC (permalink / raw)
  To: Clem Cole, The Eunuchs Hysterical Society

On 15/09/2019 20:35, Clem Cole wrote:
> 
> 
> On Sat, Sep 14, 2019 at 11:03 PM U'll Be King of the Stars 
> <ullbeking@andrewnesbit.org <mailto:ullbeking@andrewnesbit.org>> wrote:
> 
> 
>     I've been wondering whether it is possible and worthwhile to use *roff
>     for complex technical documentation.  I've always loved the aesthetic
>     that books produced using *roff have but there are other reasons too.
> 
> Ditto.  The books that used roff can look clean and within a series are 
> usually consistent, but what I've like is that they are different.

Yes, they look clean but different to each other.

I'm guessing that the reason might be that it is easier to exercise 
*roff's capabilities than it is to push LaTeX to get good results 
without spending a huge amount of time.

> The Prentiss-Hall series and the ORA books both were produced using 
> troff and different versions of ms, but the results are different.

I wonder if Prentice-Hall and O'Reilly & Associates might be willing to 
share their *roff macro sets in an open source way.

> One of my complained with LaTex books is they all seem to look the same.

Don't they ever?!  It has gotten to the point that Computer Modern 
actually makes me feel *fatigued* when I encounter it when reading, say, 
a mathematics monograph.

On the other hand it's the perfect typeface for résumés and CV's for 
computer scientists.  Like a secret handshake.

Perhaps the reason that the CM typeface is so common is that changing 
typefaces in LaTeX is complicated and difficult so authors leave it 
alone.  At least this has been my experience.

>     Getting back to *roff, does anybody know if there is a (hopefully rich)
>     repository of macros, or any other resources, for my use case?
> 
> I've never seen one.   As far as I knew it, publishers sometimes seeded 
> authors.  ORA used the Masscomp/Tektronix derived version of ms (-mS) 
> that Steve Talbot created (and Rick LeFaivre originally created from the 
> original Lesk V7 set).   Rich Steven's has his own additions to the 
> version of ms that came with groff which I have also seen.

This is fascinating insider information, and it leads me full circle to 
several reasons why I want to try to use *roff in the first place:

1.  Do you think there is any chance of obtaining these macro packages? 
Either from authors who haven't passed away, or from the publishing 
houses themselves?

2.  I get the impression that writing a macro package or editing an 
existing is relatively straightforward.  Would you agree?

     Or, at least, that it makes some kind of sense.  I could never make 
head or tail of LaTeX's macro extensions.  I certainly didn't want to 
spend my life trying to figure it out.

     I still remember the sinking feeling in my stomach when I realized 
that the five (or so) books that make up the de facto canon of LaTeX 
user documentation (published by Addison-Wesley) are thousands of pages 
in total.  I did not want to engage with that.

I have no particular intention to speak ill of LaTeX.  Rather, it is my 
only point of reference for publishing-grade typesetting and 
unfortunately I don't have fond memories of it.

Kind regards,

Andrew
-- 
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-15 19:48                             ` Clem Cole
@ 2019-09-15 21:16                               ` Dave Horsfall
  0 siblings, 0 replies; 148+ messages in thread
From: Dave Horsfall @ 2019-09-15 21:16 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 828 bytes --]

On Sun, 15 Sep 2019, Clem Cole wrote:

> The order I learned them was -mm {PWB}, -ms {V7}, -man {V7}, -ms {Tek}, 
> -me {UCB}, -mS {MSCP}, -man {UCB version}.   I feel into -ms with a 
> couple of macros from -mS (.Li/Le for lists which were similar to MM's) 
> for big documents, and the UCB -man for really simple things.   It 
> becomes a 'less is more' sort of thing - -mm and too complicated and I 
> was not writing BTL tech memos, and after I did not my thesis, I did not 
> need Eric's work (which was perfect for a UCB thesis).

For me it was ROFF (V5), -man (V6), -ms (V6).  These days I don't need 
markup any more; the most complicated things I write are letters using 
TextEdit on the Mac, and C/Perl/etc with VI :-)

Actually on the odd occasion I need markup it's "groff -ms -Tps" on
the FreeBSD box.

-- Dave

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
  2019-09-13  3:20 [TUHS] My EuroBSDcon talk (preview for commentary) Warner Losh
  2019-09-13  9:03 ` Branden Robinson
  2019-09-13 19:47 ` Clem Cole
@ 2019-09-15 21:46 ` Clem Cole
  2019-09-15 23:25   ` Bakul Shah
                     ` (2 more replies)
  2 siblings, 3 replies; 148+ messages in thread
From: Clem Cole @ 2019-09-15 21:46 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 3562 bytes --]

Funny the things you think about at 3 in the AM.

There are two other things missing from Warner's timeline that I think are
important.  A little about the clones and also about the commercial efforts
(which turns out to be related as one might expect).


The first UNIX clone that I know about was a V6 version by Whitesmiths,
called Idris, I want to say in 1977/78.   I believe that Michel's Gien's
Pascal clone that he talked about a year later started out as V6, but
morphed to V7 before he was done (and then later morphed again to become
Chorus in a C++ rewrote).  Mike Malcolm's Thoth (which "Thucks" by the way,
my wife threw out my tee-shirt years ago;-) was a pseudo V6 clone.   I
don't think he tried to recompile V6 code, like he would with his later QNX
efforts (and he wrote it in B, not C), but the model was V6 and he had seen
and/or run V6 at Waterloo.

By the time of V7, the clones do start showing up. Minux which everyone
agreed was original, as well as Mark William's Coherent, which in the end
AT&T backed off. But as Dennis said at the time something to the effect,
that it was not clear they had directly used AT&T sources to build it, as
much as the authors clearly had *seen/had access to UNIX operating and used
it to build Coherent, plus they probably had seen the UNIX sources* at some
point (this was important later when AT&T would make 'Trade Secret' claims).

Idris is interesting in that when Plauger built it, he did get in trouble
at the UDel USENIX when he tried to 'hawk it' and basically was booed (how
he did was as much of a problem as that fact that he did it).  But by that
point, there was another commercial UNIX available.   What's interesting is
that there was not an official V6 redistribution license like there was for
V7; so I'm not 100% sure I know how it was done and I would love to
enlightened.

I know this much of the story.

As I mentioned before the first commercial user of UNIX was Rand
Corporation in LA.  Al Arms of AT&T legal wrote the original $15K/CPU
license for them.   I don't know how many of those licenses were made
available, but I've always been under the impression it was under 10.  Like
a lot of people at the time, this was when the 'glass tty' was just showing
up in force and Rand updated/wrote a version of ed(1) called the rand(1)
editor [IIRC, its still available as the 'grand editor' from Dave Yost].

Shortly thereafter, Peter Weiner and Heinz would create a company in Santa
Monica called, Interactive Systems Corp (ISC) and they provided v6 and copy
of the Rand editor for some commercial folks (FYI - ISC would later do the
original 386/UNIX port for AT&T, IBM and Intel but that's a different
story, and eventually Sun would buy them years later).   In fact, one of
the things the folks at ISC did at the beginning was that they had worked
with Perkin-Elmer and created a version of PE's 'Fox' terminal with
modified ROMs that ran part of the Rand Editor in it [the Fox has a
Motorola 6800 processor in it.  CMU had a lot of the standard ones because
they were $750 in 1978 which was very inexpensive].   Anyway, what would
eventually become the 68000 development team in Austin (Les Crudele, Nick
Trudenick, Tom Grunner et al) used the ISC system and those modified Foxes
as their development system.

What I don't know is how that license worked.   I think what happened was
ISC was selling 'support.'   Motorola (or one of their customers) got a
commercial license from AT&T and then got a support license from ISC with
their additions.  But frankly, I don't know.

>

[-- Attachment #2: Type: text/html, Size: 5402 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
  2019-09-15 21:46 ` Clem Cole
@ 2019-09-15 23:25   ` Bakul Shah
  2019-09-15 23:35     ` Clem cole
  2019-09-16  1:42     ` Warner Losh
  2019-09-16  1:31   ` [TUHS] " William Pechter
  2019-09-16  3:36   ` Theodore Y. Ts'o
  2 siblings, 2 replies; 148+ messages in thread
From: Bakul Shah @ 2019-09-15 23:25 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

On Sun, 15 Sep 2019 17:46:42 -0400 Clem Cole <clemc@ccc.com> wrote:
>
> The first UNIX clone that I know about was a V6 version by Whitesmiths,
> called Idris, I want to say in 1977/78.   I believe that Michel's Gien's
> Pascal clone that he talked about a year later started out as V6, but
> morphed to V7 before he was done (and then later morphed again to become
> Chorus in a C++ rewrote).  Mike Malcolm's Thoth (which "Thucks" by the way,
> my wife threw out my tee-shirt years ago;-) was a pseudo V6 clone.   I

Acc. to a paper[1] by Cheriton, Malcom and Melen did the
original small run time executive called Thoth. Cheriton
rewrote it to form the kernel of the system described in the
Feb 1979 CACM article. It used memory mapping, swapping. etc.
They also added a filesystem.

Thoth could not have been a clone of v6.  It used message
passing. More RPC than pipes. And it had "teams", where a
"team" is roughly the same as a Unix process (separate address
space) and a Thoth "process" was a thread in that address
space.  root was "*" (instead of "/") and current dir was "@"
(instead ".").  A bigger difference was that it had *nodes* or
files and any file can have sub nodes.  There was no
separation between files and directories.

It was an interesting system and a lot of different things
were tried in it. In 1980-81 timeframe AMD forked off a
separate company called AMC to build microcomputers. They
chose Thoth.  I almost worked there but in the end decided I'd
rather do unix and joined Fortune and soon after AMD came to
its senses and shut AMC down.

[1] https://cs.uwaterloo.ca/research/tr/1979/CS-79-19.pdf

> As I mentioned before the first commercial user of UNIX was Rand
> Corporation in LA.  Al Arms of AT&T legal wrote the original $15K/CPU
> license for them.   I don't know how many of those licenses were made
> available, but I've always been under the impression it was under 10.  Like
> a lot of people at the time, this was when the 'glass tty' was just showing
> up in force and Rand updated/wrote a version of ed(1) called the rand(1)
> editor [IIRC, its still available as the 'grand editor' from Dave Yost].

The Rand editor e had nothing in common with ed(1).  e
descended from NED, a 2D editor, invented by Ned Irons in 1967
and described in "A CRT editing system" CACM Jan 1972.

The "Grand editor", derived from e19 is long gone. Even Dave
gave up on it long ago.  Though you can find a separate
version on the 'Net, also derived from e19.  e with its
multiple windows was a joy to use on a 60 line Ann Arbor
Ambassador terminal. I use acme because it too is a tiling
editor like e. It has some goodies not in e but overall e
was a better experience.

http://www.bitsavers.org/pdf/rand/R-2176-ARPA_The_CRT_Text_Editor_NED_Dec77.pdf

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
  2019-09-15 23:25   ` Bakul Shah
@ 2019-09-15 23:35     ` Clem cole
  2019-09-16  1:42     ` Warner Losh
  1 sibling, 0 replies; 148+ messages in thread
From: Clem cole @ 2019-09-15 23:35 UTC (permalink / raw)
  To: Bakul Shah; +Cc: The Eunuchs Hysterical Society

I’m very aware it was message passing.  I’ve run it.  I’ve spoken to mike about it.  They definitely had seen v6.  But as I said I’m not so sure it was a clone.  Again they used B which was popular at Waterloo at the time.


Thanks for the update on the relationship between Ned and rand’s e.  I had thought they used Ed as part of it.   I saw Dave earlier this summer btw and he said he still gets asked about it.  Although he’s working a new hw architecture to fill his days. 

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

> On Sep 15, 2019, at 7:25 PM, Bakul Shah <bakul@bitblocks.com> wrote:
> 
>> On Sun, 15 Sep 2019 17:46:42 -0400 Clem Cole <clemc@ccc.com> wrote:
>> 
>> The first UNIX clone that I know about was a V6 version by Whitesmiths,
>> called Idris, I want to say in 1977/78.   I believe that Michel's Gien's
>> Pascal clone that he talked about a year later started out as V6, but
>> morphed to V7 before he was done (and then later morphed again to become
>> Chorus in a C++ rewrote).  Mike Malcolm's Thoth (which "Thucks" by the way,
>> my wife threw out my tee-shirt years ago;-) was a pseudo V6 clone.   I
> 
> Acc. to a paper[1] by Cheriton, Malcom and Melen did the
> original small run time executive called Thoth. Cheriton
> rewrote it to form the kernel of the system described in the
> Feb 1979 CACM article. It used memory mapping, swapping. etc.
> They also added a filesystem.
> 
> Thoth could not have been a clone of v6.  It used message
> passing. More RPC than pipes. And it had "teams", where a
> "team" is roughly the same as a Unix process (separate address
> space) and a Thoth "process" was a thread in that address
> space.  root was "*" (instead of "/") and current dir was "@"
> (instead ".").  A bigger difference was that it had *nodes* or
> files and any file can have sub nodes.  There was no
> separation between files and directories.
> 
> It was an interesting system and a lot of different things
> were tried in it. In 1980-81 timeframe AMD forked off a
> separate company called AMC to build microcomputers. They
> chose Thoth.  I almost worked there but in the end decided I'd
> rather do unix and joined Fortune and soon after AMD came to
> its senses and shut AMC down.
> 
> [1] https://cs.uwaterloo.ca/research/tr/1979/CS-79-19.pdf
> 
>> As I mentioned before the first commercial user of UNIX was Rand
>> Corporation in LA.  Al Arms of AT&T legal wrote the original $15K/CPU
>> license for them.   I don't know how many of those licenses were made
>> available, but I've always been under the impression it was under 10.  Like
>> a lot of people at the time, this was when the 'glass tty' was just showing
>> up in force and Rand updated/wrote a version of ed(1) called the rand(1)
>> editor [IIRC, its still available as the 'grand editor' from Dave Yost].
> 
> The Rand editor e had nothing in common with ed(1).  e
> descended from NED, a 2D editor, invented by Ned Irons in 1967
> and described in "A CRT editing system" CACM Jan 1972.
> 
> The "Grand editor", derived from e19 is long gone. Even Dave
> gave up on it long ago.  Though you can find a separate
> version on the 'Net, also derived from e19.  e with its
> multiple windows was a joy to use on a 60 line Ann Arbor
> Ambassador terminal. I use acme because it too is a tiling
> editor like e. It has some goodies not in e but overall e
> was a better experience.
> 
> http://www.bitsavers.org/pdf/rand/R-2176-ARPA_The_CRT_Text_Editor_NED_Dec77.pdf

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
  2019-09-15 21:46 ` Clem Cole
  2019-09-15 23:25   ` Bakul Shah
@ 2019-09-16  1:31   ` William Pechter
  2019-09-16  1:48     ` Clem cole
  2019-09-16  2:24     ` Dave Horsfall
  2019-09-16  3:36   ` Theodore Y. Ts'o
  2 siblings, 2 replies; 148+ messages in thread
From: William Pechter @ 2019-09-16  1:31 UTC (permalink / raw)
  To: tuhs


On 9/15/19 5:46 PM, Clem Cole wrote:
> Funny the things you think about at 3 in the AM.
>
> Idris is interesting in that when Plauger built it, he did get in 
> trouble at the UDel USENIX when he tried to 'hawk it' and basically 
> was booed (how he did was as much of a problem as that fact that he 
> did it).  But by that point, there was another commercial UNIX 
> available.   What's interesting is that there was not an official V6 
> redistribution license like there was for V7; so I'm not 100% sure I 
> know how it was done and I would love to enlightened.
>
Interesting... I was at Concurrent messing around with a couple of 
truckloads of 7350 boxes they were trashing.  They were still being 
built (or supported) by Concurrent in 87 or so (I think that's when the 
Masscomp merger happened)... They were an 8mhz 68000 running either 
Uniplus+ (Sys III) or Idris (IIRC) or MicroXelos System V (which I think 
is a rebadged Uniplus SysV renamed to match the Concurrent 3200 Xelos 
systems).

They used them internal around '83 when they went to a Rand Editor and  
some *Roff based formatting for their office automation.  The motto for 
the IT move to desktop Unix was "Paper Free in '83."

Soon PC's and laser printers killed any hope of "paper free" as the 
staff spent way too much time chosing fonts for BS memos.

Here's some info on the very slow 68k I ran a newsfeed on: 
http://www.1000bit.it/ad/bro/perkin/PerkinElmer7350.pdf

> I know this much of the story.
>
> As I mentioned before the first commercial user of UNIX was Rand 
> Corporation in LA.  Al Arms of AT&T legal wrote the original $15K/CPU 
> license for them.   I don't know how many of those licenses were made 
> available, but I've always been under the impression it was under 10.  
> Like a lot of people at the time, this was when the 'glass tty' was 
> just showing up in force and Rand updated/wrote a version of ed(1) 
> called the rand(1) editor [IIRC, its still available as the 'grand 
> editor' from Dave Yost].
>
Perkin-Elmer had a port of the Rand Editor "E" which worked on both the 
block mode and text terminals and they were using this for their office 
automation stuff internal on the desktops until they went Windows and 
Microsoft around 86 or so.

I rescued a bunch of the trash bound 7350's and set up a small Cnews 
relay around Monmouth and Ocean counties in NJ.  For a while I upgraded 
to an AT&T6300 with Xenix-86 on it which outran the 6 or 8 mhz 68k in 
the Perkin-Elmer box.

Cheap RLL disks and higher speed serial ports were to obsolete 
everything below a 386 for the news feed so I upgraded it.

One of the great things about the editor on the box was the Rand Editor 
version allowed block copy of column data -- which I could only do on my 
CP/M box under Wordstar.

I kept the boxes around until a Trenton Computer Festival.  When I 
couldn't unload them in the 90-91 time frame I used the free dumpsters 
there to finish the destruction that Concurrent had planned.

I wiped and reused the ton of Uniplus disks I had at the time as scratch 
floppies.  I wish I had a copy left for historical reasons.  I kept the 
full manual set until I had a full *BSD 4.2,4.3 set and a full SysV set 
so I dumped the Idris and SysIII stuff.

My original degree was history and I never found an old computer or doc 
I didn't try to save.


Bill



-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-gmail.com  http://xkcd.com/705/


^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
  2019-09-15 23:25   ` Bakul Shah
  2019-09-15 23:35     ` Clem cole
@ 2019-09-16  1:42     ` Warner Losh
  2019-09-16  1:52       ` Clem cole
  1 sibling, 1 reply; 148+ messages in thread
From: Warner Losh @ 2019-09-16  1:42 UTC (permalink / raw)
  To: Bakul Shah; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 3143 bytes --]

On Mon, Sep 16, 2019, 12:25 AM Bakul Shah <bakul@bitblocks.com> wrote:

> On Sun, 15 Sep 2019 17:46:42 -0400 Clem Cole <clemc@ccc.com> wrote:
> >
> > The first UNIX clone that I know about was a V6 version by Whitesmiths,
> > called Idris, I want to say in 1977/78.   I believe that Michel's Gien's
> > Pascal clone that he talked about a year later started out as V6, but
> > morphed to V7 before he was done (and then later morphed again to become
> > Chorus in a C++ rewrote).  Mike Malcolm's Thoth (which "Thucks" by the
> way,
> > my wife threw out my tee-shirt years ago;-) was a pseudo V6 clone.   I
>
> Acc. to a paper[1] by Cheriton, Malcom and Melen did the
> original small run time executive called Thoth. Cheriton
> rewrote it to form the kernel of the system described in the
> Feb 1979 CACM article. It used memory mapping, swapping. etc.
> They also added a filesystem.
>


Cataloguing all the clones was out of scope for my talk... there are a huge
number that are known, and many more that aren't...

I likely could do a whole talk on just that...

Warner


Thoth could not have been a clone of v6.  It used message
> passing. More RPC than pipes. And it had "teams", where a
> "team" is roughly the same as a Unix process (separate address
> space) and a Thoth "process" was a thread in that address
> space.  root was "*" (instead of "/") and current dir was "@"
> (instead ".").  A bigger difference was that it had *nodes* or
> files and any file can have sub nodes.  There was no
> separation between files and directories.
>
> It was an interesting system and a lot of different things
> were tried in it. In 1980-81 timeframe AMD forked off a
> separate company called AMC to build microcomputers. They
> chose Thoth.  I almost worked there but in the end decided I'd
> rather do unix and joined Fortune and soon after AMD came to
> its senses and shut AMC down.
>
> [1] https://cs.uwaterloo.ca/research/tr/1979/CS-79-19.pdf
>
> > As I mentioned before the first commercial user of UNIX was Rand
> > Corporation in LA.  Al Arms of AT&T legal wrote the original $15K/CPU
> > license for them.   I don't know how many of those licenses were made
> > available, but I've always been under the impression it was under 10.
> Like
> > a lot of people at the time, this was when the 'glass tty' was just
> showing
> > up in force and Rand updated/wrote a version of ed(1) called the rand(1)
> > editor [IIRC, its still available as the 'grand editor' from Dave Yost].
>
> The Rand editor e had nothing in common with ed(1).  e
> descended from NED, a 2D editor, invented by Ned Irons in 1967
> and described in "A CRT editing system" CACM Jan 1972.
>
> The "Grand editor", derived from e19 is long gone. Even Dave
> gave up on it long ago.  Though you can find a separate
> version on the 'Net, also derived from e19.  e with its
> multiple windows was a joy to use on a 60 line Ann Arbor
> Ambassador terminal. I use acme because it too is a tiling
> editor like e. It has some goodies not in e but overall e
> was a better experience.
>
>
> http://www.bitsavers.org/pdf/rand/R-2176-ARPA_The_CRT_Text_Editor_NED_Dec77.pdf
>

[-- Attachment #2: Type: text/html, Size: 4496 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
  2019-09-16  1:31   ` [TUHS] " William Pechter
@ 2019-09-16  1:48     ` Clem cole
  2019-09-16  2:24     ` Dave Horsfall
  1 sibling, 0 replies; 148+ messages in thread
From: Clem cole @ 2019-09-16  1:48 UTC (permalink / raw)
  To: pechter; +Cc: tuhs

Becareful.  The Idris name was also used later by someone else for a 68000 system a few years after the Whitesmiths demise and they had stopped trying to sell there clone.   I do not believe the two products were in any way related.  

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

> On Sep 15, 2019, at 9:31 PM, William Pechter <pechter@gmail.com> wrote:
> 
> 
>> On 9/15/19 5:46 PM, Clem Cole wrote:
>> Funny the things you think about at 3 in the AM.
>> 
>> Idris is interesting in that when Plauger built it, he did get in trouble at the UDel USENIX when he tried to 'hawk it' and basically was booed (how he did was as much of a problem as that fact that he did it).  But by that point, there was another commercial UNIX available.   What's interesting is that there was not an official V6 redistribution license like there was for V7; so I'm not 100% sure I know how it was done and I would love to enlightened.
>> 
> Interesting... I was at Concurrent messing around with a couple of truckloads of 7350 boxes they were trashing.  They were still being built (or supported) by Concurrent in 87 or so (I think that's when the Masscomp merger happened)... They were an 8mhz 68000 running either Uniplus+ (Sys III) or Idris (IIRC) or MicroXelos System V (which I think is a rebadged Uniplus SysV renamed to match the Concurrent 3200 Xelos systems).
> 
> They used them internal around '83 when they went to a Rand Editor and  some *Roff based formatting for their office automation.  The motto for the IT move to desktop Unix was "Paper Free in '83."
> 
> Soon PC's and laser printers killed any hope of "paper free" as the staff spent way too much time chosing fonts for BS memos.
> 
> Here's some info on the very slow 68k I ran a newsfeed on: http://www.1000bit.it/ad/bro/perkin/PerkinElmer7350.pdf
> 
>> I know this much of the story.
>> 
>> As I mentioned before the first commercial user of UNIX was Rand Corporation in LA.  Al Arms of AT&T legal wrote the original $15K/CPU license for them.   I don't know how many of those licenses were made available, but I've always been under the impression it was under 10.  Like a lot of people at the time, this was when the 'glass tty' was just showing up in force and Rand updated/wrote a version of ed(1) called the rand(1) editor [IIRC, its still available as the 'grand editor' from Dave Yost].
>> 
> Perkin-Elmer had a port of the Rand Editor "E" which worked on both the block mode and text terminals and they were using this for their office automation stuff internal on the desktops until they went Windows and Microsoft around 86 or so.
> 
> I rescued a bunch of the trash bound 7350's and set up a small Cnews relay around Monmouth and Ocean counties in NJ.  For a while I upgraded to an AT&T6300 with Xenix-86 on it which outran the 6 or 8 mhz 68k in the Perkin-Elmer box.
> 
> Cheap RLL disks and higher speed serial ports were to obsolete everything below a 386 for the news feed so I upgraded it.
> 
> One of the great things about the editor on the box was the Rand Editor version allowed block copy of column data -- which I could only do on my CP/M box under Wordstar.
> 
> I kept the boxes around until a Trenton Computer Festival.  When I couldn't unload them in the 90-91 time frame I used the free dumpsters there to finish the destruction that Concurrent had planned.
> 
> I wiped and reused the ton of Uniplus disks I had at the time as scratch floppies.  I wish I had a copy left for historical reasons.  I kept the full manual set until I had a full *BSD 4.2,4.3 set and a full SysV set so I dumped the Idris and SysIII stuff.
> 
> My original degree was history and I never found an old computer or doc I didn't try to save.
> 
> 
> Bill
> 
> 
> 
> -- 
> Digital had it then.  Don't you wish you could buy it now!
> pechter-at-gmail.com  http://xkcd.com/705/
> 

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
  2019-09-16  1:42     ` Warner Losh
@ 2019-09-16  1:52       ` Clem cole
  2019-09-16  2:05         ` George Michaelson
  0 siblings, 1 reply; 148+ messages in thread
From: Clem cole @ 2019-09-16  1:52 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 3682 bytes --]

Fair enough.  But the original v6 Whitesmiths Idris was important and should be part of your v6 slide.    It establishes that some people were beginning to take a commercial version of Unix seriously even if AT&T was not allowed too.  

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

> On Sep 15, 2019, at 9:42 PM, Warner Losh <imp@bsdimp.com> wrote:
> 
> 
> 
>> On Mon, Sep 16, 2019, 12:25 AM Bakul Shah <bakul@bitblocks.com> wrote:
>> On Sun, 15 Sep 2019 17:46:42 -0400 Clem Cole <clemc@ccc.com> wrote:
>> >
>> > The first UNIX clone that I know about was a V6 version by Whitesmiths,
>> > called Idris, I want to say in 1977/78.   I believe that Michel's Gien's
>> > Pascal clone that he talked about a year later started out as V6, but
>> > morphed to V7 before he was done (and then later morphed again to become
>> > Chorus in a C++ rewrote).  Mike Malcolm's Thoth (which "Thucks" by the way,
>> > my wife threw out my tee-shirt years ago;-) was a pseudo V6 clone.   I
>> 
>> Acc. to a paper[1] by Cheriton, Malcom and Melen did the
>> original small run time executive called Thoth. Cheriton
>> rewrote it to form the kernel of the system described in the
>> Feb 1979 CACM article. It used memory mapping, swapping. etc.
>> They also added a filesystem.
> 
> 
> 
> Cataloguing all the clones was out of scope for my talk... there are a huge number that are known, and many more that aren't...
> 
> I likely could do a whole talk on just that...
> 
> Warner 
> 
> 
>> Thoth could not have been a clone of v6.  It used message
>> passing. More RPC than pipes. And it had "teams", where a
>> "team" is roughly the same as a Unix process (separate address
>> space) and a Thoth "process" was a thread in that address
>> space.  root was "*" (instead of "/") and current dir was "@"
>> (instead ".").  A bigger difference was that it had *nodes* or
>> files and any file can have sub nodes.  There was no
>> separation between files and directories.
>> 
>> It was an interesting system and a lot of different things
>> were tried in it. In 1980-81 timeframe AMD forked off a
>> separate company called AMC to build microcomputers. They
>> chose Thoth.  I almost worked there but in the end decided I'd
>> rather do unix and joined Fortune and soon after AMD came to
>> its senses and shut AMC down.
>> 
>> [1] https://cs.uwaterloo.ca/research/tr/1979/CS-79-19.pdf
>> 
>> > As I mentioned before the first commercial user of UNIX was Rand
>> > Corporation in LA.  Al Arms of AT&T legal wrote the original $15K/CPU
>> > license for them.   I don't know how many of those licenses were made
>> > available, but I've always been under the impression it was under 10.  Like
>> > a lot of people at the time, this was when the 'glass tty' was just showing
>> > up in force and Rand updated/wrote a version of ed(1) called the rand(1)
>> > editor [IIRC, its still available as the 'grand editor' from Dave Yost].
>> 
>> The Rand editor e had nothing in common with ed(1).  e
>> descended from NED, a 2D editor, invented by Ned Irons in 1967
>> and described in "A CRT editing system" CACM Jan 1972.
>> 
>> The "Grand editor", derived from e19 is long gone. Even Dave
>> gave up on it long ago.  Though you can find a separate
>> version on the 'Net, also derived from e19.  e with its
>> multiple windows was a joy to use on a 60 line Ann Arbor
>> Ambassador terminal. I use acme because it too is a tiling
>> editor like e. It has some goodies not in e but overall e
>> was a better experience.
>> 
>> http://www.bitsavers.org/pdf/rand/R-2176-ARPA_The_CRT_Text_Editor_NED_Dec77.pdf

[-- Attachment #2: Type: text/html, Size: 5128 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
  2019-09-16  1:52       ` Clem cole
@ 2019-09-16  2:05         ` George Michaelson
  2019-09-16  2:37           ` Bakul Shah
  0 siblings, 1 reply; 148+ messages in thread
From: George Michaelson @ 2019-09-16  2:05 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

The "block copy in an editor" thing is something which has intrigued
me for years. poor old ed/ex/vi just couldn't do it, and for the life
of me, I could not understand why this was "deprecated" by the people
writing that family of editors. I seem to recall the various
lightweight emacs which proceeded GNU had it, in some cases, and GNU
had it. (Goslings emacs?)

It was pretty much "you could do this with awk or sed" or "I wrote a
SPITBAL program to do that" for most things. -As if columnar state, or
a region of a screen was not something it even made sense to pick up
into a buffer and put down somewhere else.

Later on I theorised that the internal edit sequence log structure
might make this quite hard to conceptualise and implement. But, I
think its also possible the editor authors in question just didn't see
a use value for this up-front.

I think anyone who used WordStar or a half-duplex terminal saw a
potential use for this almost immediately. And, the people using the
early newspaper edit terminals almost certainly had a use for it
because even at low-charcount they routinely seemed to work in
newspaper columns, and so a "story" was about columnar paragraph
structured data.

Similarly the 'repeat this sequence of commands' thing which emacs
had, as a "start keystroke" <do things> "end keystroke" and then @run
that thing. Yes you could @run VI buffers, but you had to program them
into a state, you couldn't tell the editor to "watch what you did, and
re-do it on successive lines"

I also suspect, that "do the thing you just did" and "block copy" were
a bit low: people who did these kind of things were not clever. Clever
people held the state of the lines in their head, and were mentally
writing the ed/ex/vi or Teco sequences to change the letters in a
line. Dumb people like me were thinking of editing as "cut the words
out with rounded -end scissors and ask mummy for the clag gluepaste"

Many fine hours were spent doing rote edits to fix post-formatted
NROFF and RUNOFF text by me. Dumb, but doable.

(runoff on the Dec-10 was good. I am glad I'd done it, it made the
transition to nroff far easier. I didn't realize it was a cross-port
from CTSS)

-G

On Mon, Sep 16, 2019 at 11:52 AM Clem cole <clemc@ccc.com> wrote:
>
> Fair enough.  But the original v6 Whitesmiths Idris was important and should be part of your v6 slide.    It establishes that some people were beginning to take a commercial version of Unix seriously even if AT&T was not allowed too.
>
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
>
> On Sep 15, 2019, at 9:42 PM, Warner Losh <imp@bsdimp.com> wrote:
>
>
>
> On Mon, Sep 16, 2019, 12:25 AM Bakul Shah <bakul@bitblocks.com> wrote:
>>
>> On Sun, 15 Sep 2019 17:46:42 -0400 Clem Cole <clemc@ccc.com> wrote:
>> >
>> > The first UNIX clone that I know about was a V6 version by Whitesmiths,
>> > called Idris, I want to say in 1977/78.   I believe that Michel's Gien's
>> > Pascal clone that he talked about a year later started out as V6, but
>> > morphed to V7 before he was done (and then later morphed again to become
>> > Chorus in a C++ rewrote).  Mike Malcolm's Thoth (which "Thucks" by the way,
>> > my wife threw out my tee-shirt years ago;-) was a pseudo V6 clone.   I
>>
>> Acc. to a paper[1] by Cheriton, Malcom and Melen did the
>> original small run time executive called Thoth. Cheriton
>> rewrote it to form the kernel of the system described in the
>> Feb 1979 CACM article. It used memory mapping, swapping. etc.
>> They also added a filesystem.
>
>
>
> Cataloguing all the clones was out of scope for my talk... there are a huge number that are known, and many more that aren't...
>
> I likely could do a whole talk on just that...
>
> Warner
>
>
>> Thoth could not have been a clone of v6.  It used message
>> passing. More RPC than pipes. And it had "teams", where a
>> "team" is roughly the same as a Unix process (separate address
>> space) and a Thoth "process" was a thread in that address
>> space.  root was "*" (instead of "/") and current dir was "@"
>> (instead ".").  A bigger difference was that it had *nodes* or
>> files and any file can have sub nodes.  There was no
>> separation between files and directories.
>>
>> It was an interesting system and a lot of different things
>> were tried in it. In 1980-81 timeframe AMD forked off a
>> separate company called AMC to build microcomputers. They
>> chose Thoth.  I almost worked there but in the end decided I'd
>> rather do unix and joined Fortune and soon after AMD came to
>> its senses and shut AMC down.
>>
>> [1] https://cs.uwaterloo.ca/research/tr/1979/CS-79-19.pdf
>>
>> > As I mentioned before the first commercial user of UNIX was Rand
>> > Corporation in LA.  Al Arms of AT&T legal wrote the original $15K/CPU
>> > license for them.   I don't know how many of those licenses were made
>> > available, but I've always been under the impression it was under 10.  Like
>> > a lot of people at the time, this was when the 'glass tty' was just showing
>> > up in force and Rand updated/wrote a version of ed(1) called the rand(1)
>> > editor [IIRC, its still available as the 'grand editor' from Dave Yost].
>>
>> The Rand editor e had nothing in common with ed(1).  e
>> descended from NED, a 2D editor, invented by Ned Irons in 1967
>> and described in "A CRT editing system" CACM Jan 1972.
>>
>> The "Grand editor", derived from e19 is long gone. Even Dave
>> gave up on it long ago.  Though you can find a separate
>> version on the 'Net, also derived from e19.  e with its
>> multiple windows was a joy to use on a 60 line Ann Arbor
>> Ambassador terminal. I use acme because it too is a tiling
>> editor like e. It has some goodies not in e but overall e
>> was a better experience.
>>
>> http://www.bitsavers.org/pdf/rand/R-2176-ARPA_The_CRT_Text_Editor_NED_Dec77.pdf

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
  2019-09-16  1:31   ` [TUHS] " William Pechter
  2019-09-16  1:48     ` Clem cole
@ 2019-09-16  2:24     ` Dave Horsfall
  2019-09-16  2:31       ` Toby Thain
  1 sibling, 1 reply; 148+ messages in thread
From: Dave Horsfall @ 2019-09-16  2:24 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

On Sun, 15 Sep 2019, William Pechter wrote:

> They used them internal around '83 when they went to a Rand Editor and  
> some *Roff based formatting for their office automation.  The motto for 
> the IT move to desktop Unix was "Paper Free in '83."
>
> Soon PC's and laser printers killed any hope of "paper free" as the 
> staff spent way too much time chosing fonts for BS memos.

There was a saying many years ago, from someone whom I've long forgotten: 
"I'll believe in the paper-less office when I see the paper-less toilet".

-- Dave

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
  2019-09-16  2:24     ` Dave Horsfall
@ 2019-09-16  2:31       ` Toby Thain
  0 siblings, 0 replies; 148+ messages in thread
From: Toby Thain @ 2019-09-16  2:31 UTC (permalink / raw)
  To: Dave Horsfall, The Eunuchs Hysterical Society

On 2019-09-15 10:24 p.m., Dave Horsfall wrote:
> On Sun, 15 Sep 2019, William Pechter wrote:
> 
>> They used them internal around '83 when they went to a Rand Editor
>> and  some *Roff based formatting for their office automation.  The
>> motto for the IT move to desktop Unix was "Paper Free in '83."
>>
>> Soon PC's and laser printers killed any hope of "paper free" as the
>> staff spent way too much time chosing fonts for BS memos.
> 
> There was a saying many years ago, from someone whom I've long
> forgotten: "I'll believe in the paper-less office when I see the
> paper-less toilet".

I am forced to observe that not only are paperless toilets quite common
outside North America, they're also more hygienic...

--Toby


> 
> -- Dave


^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
  2019-09-16  2:05         ` George Michaelson
@ 2019-09-16  2:37           ` Bakul Shah
  2019-09-16  3:29             ` [TUHS] INed/Rand Editor/Ned [was " Charles H. Sauer
  0 siblings, 1 reply; 148+ messages in thread
From: Bakul Shah @ 2019-09-16  2:37 UTC (permalink / raw)
  To: George Michaelson; +Cc: The Eunuchs Hysterical Society

On Mon, 16 Sep 2019 12:05:24 +1000 George Michaelson <ggm@algebras.org> wrote:
> The "block copy in an editor" thing is something which has intrigued
> me for years. poor old ed/ex/vi just couldn't do it, and for the life
> of me, I could not understand why this was "deprecated" by the people
> writing that family of editors. I seem to recall the various
> lightweight emacs which proceeded GNU had it, in some cases, and GNU
> had it. (Goslings emacs?)

I think this is because vi grew out of ex which grew out of
ed, all of which were "line" editors, while the Rand Editor
(and the original NED) assumed a quarter plane model. e had
commands such as box (to draw a box), blank (or was it cut?)
to wipe out all nonblank chars from a rectangle, replace,
overlay (nonblank chars from the copy buffer overwrote data),
underlay (nonblank chars from the copy buffer didn't overwrite
nonblank chars) and so on. It even had justfy, fill and center
commands. It was basically an editor for producing documents
in monspaced fonts!

^ permalink raw reply	[flat|nested] 148+ messages in thread

* [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary)
  2019-09-16  2:37           ` Bakul Shah
@ 2019-09-16  3:29             ` Charles H. Sauer
  2019-09-16 14:53               ` Clem Cole
  0 siblings, 1 reply; 148+ messages in thread
From: Charles H. Sauer @ 2019-09-16  3:29 UTC (permalink / raw)
  To: Bakul Shah; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 2126 bytes --]

The first Unix I used was PC/ix on an XT. I don’t know it even had vi, but it had INed, which I assume was the ISC evolution of NED & Rand Editor. (I think I first started using vi on Xenix on an AT before I got my own RT??)

Anyway, I had been very productive with half-duplex editing on 3270 on CMS up to that point, and INed seemed very natural to me.

Totally unrelated to Unix, when I came to IBM Austin from Yorktown, real 3270s were scarce/shared. I got a DisplayWriter with a 3270 card and emulator in my office. That was better than a real 3270 to my tastes, even with the 8” diskettes. 3270 emulation on PC was ok, but not as good as the real thing, certainly not as good as the DW emulation. 

> On Sep 15, 2019, at 9:37 PM, Bakul Shah <bakul@bitblocks.com> wrote:
> 
> On Mon, 16 Sep 2019 12:05:24 +1000 George Michaelson <ggm@algebras.org> wrote:
>> The "block copy in an editor" thing is something which has intrigued
>> me for years. poor old ed/ex/vi just couldn't do it, and for the life
>> of me, I could not understand why this was "deprecated" by the people
>> writing that family of editors. I seem to recall the various
>> lightweight emacs which proceeded GNU had it, in some cases, and GNU
>> had it. (Goslings emacs?)
> 
> I think this is because vi grew out of ex which grew out of
> ed, all of which were "line" editors, while the Rand Editor
> (and the original NED) assumed a quarter plane model. e had
> commands such as box (to draw a box), blank (or was it cut?)
> to wipe out all nonblank chars from a rectangle, replace,
> overlay (nonblank chars from the copy buffer overwrote data),
> underlay (nonblank chars from the copy buffer didn't overwrite
> nonblank chars) and so on. It even had justfy, fill and center
> commands. It was basically an editor for producing documents
> in monspaced fonts!

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


[-- Attachment #2: Type: text/html, Size: 4044 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
  2019-09-15 21:46 ` Clem Cole
  2019-09-15 23:25   ` Bakul Shah
  2019-09-16  1:31   ` [TUHS] " William Pechter
@ 2019-09-16  3:36   ` Theodore Y. Ts'o
  2 siblings, 0 replies; 148+ messages in thread
From: Theodore Y. Ts'o @ 2019-09-16  3:36 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

On Sun, Sep 15, 2019 at 05:46:42PM -0400, Clem Cole wrote:
> By the time of V7, the clones do start showing up. Minux which everyone
> agreed was original, as well as Mark William's Coherent, which in the end
> AT&T backed off. But as Dennis said at the time something to the effect,
> that it was not clear they had directly used AT&T sources to build it, as
> much as the authors clearly had *seen/had access to UNIX operating and used
> it to build Coherent, plus they probably had seen the UNIX sources* at some
> point (this was important later when AT&T would make 'Trade Secret' claims).

One really interesting anecdote about the "Trade Secret" claims, is
that the MIT Unix license never had the "methods and concepts" clause
in it.  The MIT Administration/Lawyers considered in unconscionable
the brains of MIT students might get encumbered by AT&T, and outright
rejected that clause.  Apparently MIT had a lot more clout (and
probably alumni in high places at AT&T), so MIT was able to make the
"no methods and concepts" clause stick.  For each new version of Unix
from AT&T, this issue would come up, and eventually, the Unix license
would get included in Grant contracts where AT&T really, really wanted
MIT to do research in some area, and apparently MIT had enough
leverage to get successive Unix license updates, all without the
infamous "methods and concepts" clause.

At one point, even though MIT had the necessary licenses so it could
be allowed to receive Ultrix or OSF/1 sources, AT&T's licensing
division refused to confirm (or deny) whether or not MIT had a valid
Unix source license, and so this caused problems for MIT to be able to
get an official version of Ultrix or OSF/1 sources.  No matter, MIT
had even more alumni and connections which Digital, so when a tape was
eventually installed in Project Athena's AFS cell, it was apparently
an active source tree from some engineering directory, completely with
core dumps and editor backup files....

So while I have looked at BSD 4.3 sources when I was a student systems
programmer, I have it on good authority from people who were staff
members on Project Athena at the time, that my brain was not owned by
AT&T due to that nasty "methods and concepts" clause --- because the
MIT Unix source license didn't have that nonsense.

    	 		       	    	 - Ted

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-15 19:37                           ` Clem Cole
@ 2019-09-16  5:52                             ` arnold
  2019-09-16 12:10                               ` Clem Cole
  0 siblings, 1 reply; 148+ messages in thread
From: arnold @ 2019-09-16  5:52 UTC (permalink / raw)
  To: clemc, arnold; +Cc: tuhs

Clem Cole <clemc@ccc.com> wrote:

> On Sun, Sep 15, 2019 at 2:55 AM <arnold@skeeve.com> wrote:
>
> > Texinfo is *by far* the superior markup language.
> >
> I'll take your work for it, but my complaint is it requires emacs to use as
> the pager on my screen.  If you live in emacs, that makes sense; but most
> people, even in the GNU/Linux world, don't.

Not true at all.  I don't use Emacs, never have, and likely never will.

I use the standalone Info reader (named info) if I want to look at the
Info output.  But as I mentioned already, I usually look at the Texinfo
documentation I'm working on via PDF or HTML.

And gvim has very nice syntax highlighting for Texinfo input files.

Arnold

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-15 20:49                           ` U'll Be King of the Stars
@ 2019-09-16  6:20                             ` arnold
  2019-09-16 12:13                               ` Clem Cole
  2019-09-17  0:10                               ` [TUHS] O'Reilly groff macros (was: earliest Unix roff) Greg 'groggy' Lehey
  0 siblings, 2 replies; 148+ messages in thread
From: arnold @ 2019-09-16  6:20 UTC (permalink / raw)
  To: ullbeking, tuhs, clemc

"U'll Be King of the Stars" <ullbeking@andrewnesbit.org> wrote:

> This is fascinating insider information, and it leads me full circle to 
> several reasons why I want to try to use *roff in the first place:
>
> 1.  Do you think there is any chance of obtaining these macro packages? 
> Either from authors who haven't passed away, or from the publishing 
> houses themselves?

O'Reilly probably would. I can ask someone there, if there's serious
interest here.  They haven't used troff for book production for well
over a decade.

I'm not sure that Prentice-Hall had its own macros. Rather, the
books from Bell Labs were all set on the same research Unix systems.

> 2.  I get the impression that writing a macro package or editing an 
> existing is relatively straightforward.  Would you agree?

Possibly straightforward, but very much like working in assembly
language.  The commands and escape sequences (in standard troff) are
all very short, and thus cryptic, and the extra levels of backslashes
needed inside macro bodies don't help.

GNU troff has additional features that probably help a lot; my experience
has been in grunging around in traditional packages.

My two cents,

Arnodl

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16  5:52                             ` arnold
@ 2019-09-16 12:10                               ` Clem Cole
  2019-09-16 12:26                                 ` Lars Brinkhoff
                                                   ` (4 more replies)
  0 siblings, 5 replies; 148+ messages in thread
From: Clem Cole @ 2019-09-16 12:10 UTC (permalink / raw)
  To: Aharon Robbins; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 594 bytes --]

On Mon, Sep 16, 2019 at 1:52 AM <arnold@skeeve.com> wrote:

> I use the standalone Info reader (named info) if I want to look at the
> Info output.
>
Fair enough, but be careful, while I admit I have not looked in a while,
info(gnu) relies on emacs keybindings and a number of very emacs'ish things.
Every time I have tried to deal with it, I have unprogram my fingers and
reset them to emacs.

If it would have used more(1) [or even less(1)] then I would not be as
annoyed.
Unix had fine tools [man(1), more(1), et al] and rms and friends felt the
need to replace them with ITS-like programs.

[-- Attachment #2: Type: text/html, Size: 1538 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16  6:20                             ` arnold
@ 2019-09-16 12:13                               ` Clem Cole
  2019-09-16 12:34                                 ` arnold
  2019-09-16 14:52                                 ` Larry McVoy
  2019-09-17  0:10                               ` [TUHS] O'Reilly groff macros (was: earliest Unix roff) Greg 'groggy' Lehey
  1 sibling, 2 replies; 148+ messages in thread
From: Clem Cole @ 2019-09-16 12:13 UTC (permalink / raw)
  To: Aharon Robbins; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

On Mon, Sep 16, 2019 at 2:21 AM <arnold@skeeve.com> wrote:

> I'm not sure that Prentice-Hall had its own macros. Rather, the
> books from Bell Labs were all set on the same research Unix systems.
>
That's might be true for bwk's and Pike's stuff, but not Rich Steven's or
Comer's books.   I know for fact that Rich had a set of macro's (based
originally on -ms) and a set of integrated makefiles to build his texts.  I
was under the impression he passed them to a number of people, not just
people like me.

[-- Attachment #2: Type: text/html, Size: 1030 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 12:10                               ` Clem Cole
@ 2019-09-16 12:26                                 ` Lars Brinkhoff
  2019-09-16 13:42                                   ` Clem Cole
  2019-09-16 13:13                                 ` Chet Ramey
                                                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 148+ messages in thread
From: Lars Brinkhoff @ 2019-09-16 12:26 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

Clem Cole wrote:
> Unix had fine tools [man(1), more(1), et al] and rms and friends felt
> the need to replace them with ITS-like programs.

Emacs and Info are rather blatantly are not anywhere near the Unix
philosophy.  (Maybe they can be useful anyway.)

However, please note that more(1) also was inspired by, almost copied
from, ITS.  Certainly the prompt --More-- is.

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 12:13                               ` Clem Cole
@ 2019-09-16 12:34                                 ` arnold
  2019-09-16 14:52                                 ` Larry McVoy
  1 sibling, 0 replies; 148+ messages in thread
From: arnold @ 2019-09-16 12:34 UTC (permalink / raw)
  To: clemc, arnold; +Cc: tuhs

Clem Cole <clemc@ccc.com> wrote:

> On Mon, Sep 16, 2019 at 2:21 AM <arnold@skeeve.com> wrote:
>
> > I'm not sure that Prentice-Hall had its own macros. Rather, the
> > books from Bell Labs were all set on the same research Unix systems.
> >
> That's might be true for bwk's and Pike's stuff, but not Rich Steven's or
> Comer's books.   I know for fact that Rich had a set of macro's (based
> originally on -ms) and a set of integrated makefiles to build his texts.  I
> was under the impression he passed them to a number of people, not just
> people like me.

Don't know, but you could try http://www.unixnetworkprogramming.com/contact.html
for the Unix Network Programming book which was updated after Richard
Stevens passed away.

Arnold

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 12:10                               ` Clem Cole
  2019-09-16 12:26                                 ` Lars Brinkhoff
@ 2019-09-16 13:13                                 ` Chet Ramey
  2019-09-16 14:51                                 ` Larry McVoy
                                                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 148+ messages in thread
From: Chet Ramey @ 2019-09-16 13:13 UTC (permalink / raw)
  To: Clem Cole, Aharon Robbins; +Cc: The Eunuchs Hysterical Society

On 9/16/19 8:10 AM, Clem Cole wrote:

>     I use the standalone Info reader (named info) if I want to look at the
>     Info output. 
> 
> Fair enough, but be careful, while I admit I have not looked in a while,
> info(gnu) relies on emacs keybindings and a number of very emacs'ish things.
> Every time I have tried to deal with it, I have unprogram my fingers and
> reset them to emacs.
> 
> If it would have used more(1) [or even less(1)] then I would not be as annoyed.

It seems to me that the strength of info (the file format and program) is
the navigation of a menu-driven hierarchical document containing what are
essentially selectable links between sections. Something like more or less
is poorly suited to take advantage of those features.

You need a way to position the cursor with more flexibility than more gives
you.

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 12:26                                 ` Lars Brinkhoff
@ 2019-09-16 13:42                                   ` Clem Cole
  2019-09-16 14:54                                     ` Larry McVoy
                                                       ` (2 more replies)
  0 siblings, 3 replies; 148+ messages in thread
From: Clem Cole @ 2019-09-16 13:42 UTC (permalink / raw)
  To: Lars Brinkhoff; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 2183 bytes --]

On Mon, Sep 16, 2019 at 8:26 AM Lars Brinkhoff <lars@nocrew.org> wrote:

> However, please note that more(1) also was inspired by, almost copied
> from, ITS.  Certainly the prompt --More-- is.
>

Absolutely.  A friend of mine/fellow UCB grad student, Eric Shienbrood,
wrote it.  He was a MIT undergrad. And Eric happily said it was modeled
from ITS.
And before, Eric wrote it, UNIX lacked anything like it.   Which to me is
fine, t*aking an idea from another system to add a new feature that is
lacking.*

What irks me is the blatant force-feeding of any system to the users, be it
ITS, UNIX or Windows into another.   It's ok to offer an alternative
interface, but when the system has a mechanism, your tools need to be *socially
compliant* with it, not try to make 'those users become like me.'
 Frankly, that is a pretty arrogant behavior. Yes, I know the argument is
two fold.  GNU is not UNIX and we wrote it (he who has the gold, gets to
rule).

BTW:  If it makes you feel better, I've been fighting this attitude at a
number of places, particularly Intel, for years.   For instance, our dev
tools folks wrote their own Installer 'because it was easier for them and
they could use it everywhere').   That's a no-no.  If you have Windows
product, you must use Microsoft's installer, if you have a Mac, you use
what Apple gives you, if you have VMS, you used the (wretched) setld, or in
this case, for Linux its rpm/yum et al.; etc.     But they had their own
'installer group' and it was easier for >>them<< than for the users.

I think the rule of 'least astonishment' is what needs to be the high order
bit when building tools for people.   Again, offering emacs (or any other
ITS tool) is fine, but when the new tool is installed on Windows/UNIX/Mac
et.. it needs to behave itself with the rest of the system, particularly if
there is already a mechanism in place to do a support function.

Simply, I would not mind info(gnu) and texinfo(gnu) if there was a way to
created man pages (or Windows / Mac help).  But having a man page that
basically says, see figure one
<https://www.dourish.com/goodies/see-figure-1.html> is not cool.

my 2 cents from a grumpy old guy....
Clem

[-- Attachment #2: Type: text/html, Size: 4208 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 12:10                               ` Clem Cole
  2019-09-16 12:26                                 ` Lars Brinkhoff
  2019-09-16 13:13                                 ` Chet Ramey
@ 2019-09-16 14:51                                 ` Larry McVoy
  2019-09-16 14:57                                   ` Clem Cole
  2019-09-17  7:53                                   ` arnold
  2019-09-16 21:42                                 ` Dave Horsfall
  2019-10-05 19:44                                 ` Michael Parson
  4 siblings, 2 replies; 148+ messages in thread
From: Larry McVoy @ 2019-09-16 14:51 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

On Mon, Sep 16, 2019 at 08:10:48AM -0400, Clem Cole wrote:
> On Mon, Sep 16, 2019 at 1:52 AM <arnold@skeeve.com> wrote:
> 
> > I use the standalone Info reader (named info) if I want to look at the
> > Info output.
> >
> Fair enough, but be careful, while I admit I have not looked in a while,
> info(gnu) relies on emacs keybindings and a number of very emacs'ish things.
> Every time I have tried to deal with it, I have unprogram my fingers and
> reset them to emacs.
> 
> If it would have used more(1) [or even less(1)] then I would not be as
> annoyed.
> Unix had fine tools [man(1), more(1), et al] and rms and friends felt the
> need to replace them with ITS-like programs.

I hate texinfo and friends.  I get why it is better than man, but man was
good enough, more than good enough, and the GNU project took everything
it could find and destroyed the man pages.

If you have something like perl that needs a zillion sub pages, info
makes sense.  For just a man page, info is horrible.

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 12:13                               ` Clem Cole
  2019-09-16 12:34                                 ` arnold
@ 2019-09-16 14:52                                 ` Larry McVoy
  1 sibling, 0 replies; 148+ messages in thread
From: Larry McVoy @ 2019-09-16 14:52 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

On Mon, Sep 16, 2019 at 08:13:55AM -0400, Clem Cole wrote:
> On Mon, Sep 16, 2019 at 2:21 AM <arnold@skeeve.com> wrote:
> 
> > I'm not sure that Prentice-Hall had its own macros. Rather, the
> > books from Bell Labs were all set on the same research Unix systems.
> >
> That's might be true for bwk's and Pike's stuff, but not Rich Steven's or
> Comer's books.   I know for fact that Rich had a set of macro's (based
> originally on -ms) and a set of integrated makefiles to build his texts.  I
> was under the impression he passed them to a number of people, not just
> people like me.

I don't have them but he and I had many discussions about troff, tbl,
pic, etc.  We had a shared love for pic.

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary)
  2019-09-16  3:29             ` [TUHS] INed/Rand Editor/Ned [was " Charles H. Sauer
@ 2019-09-16 14:53               ` Clem Cole
  2019-09-16 16:16                 ` Warner Losh
  0 siblings, 1 reply; 148+ messages in thread
From: Clem Cole @ 2019-09-16 14:53 UTC (permalink / raw)
  To: Charles H. Sauer; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 268 bytes --]

On Sun, Sep 15, 2019 at 11:37 PM Charles H. Sauer <sauer@technologists.com>
wrote:

> The first Unix I used was PC/ix on an XT. I don’t know it even had vi, but
> it had INed, which I assume was the ISC evolution of NED & Rand Editor.
>
Yes, that is correct.

[-- Attachment #2: Type: text/html, Size: 790 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 13:42                                   ` Clem Cole
@ 2019-09-16 14:54                                     ` Larry McVoy
  2019-09-16 16:09                                     ` Paul Winalski
  2019-09-16 22:05                                     ` Dave Horsfall
  2 siblings, 0 replies; 148+ messages in thread
From: Larry McVoy @ 2019-09-16 14:54 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

Holy smokes, Clem, you are me and I am you.  I couldn't agree more with 
this post, especially 'least astonishment'.

On Mon, Sep 16, 2019 at 09:42:56AM -0400, Clem Cole wrote:
> What irks me is the blatant force-feeding of any system to the users, be it
> ITS, UNIX or Windows into another.   It's ok to offer an alternative
> interface, but when the system has a mechanism, your tools need to be *socially
> compliant* with it, not try to make 'those users become like me.'
>  Frankly, that is a pretty arrogant behavior. Yes, I know the argument is
> two fold.  GNU is not UNIX and we wrote it (he who has the gold, gets to
> rule).
> 
> BTW:  If it makes you feel better, I've been fighting this attitude at a
> number of places, particularly Intel, for years.   For instance, our dev
> tools folks wrote their own Installer 'because it was easier for them and
> they could use it everywhere').   That's a no-no.  If you have Windows
> product, you must use Microsoft's installer, if you have a Mac, you use
> what Apple gives you, if you have VMS, you used the (wretched) setld, or in
> this case, for Linux its rpm/yum et al.; etc.     But they had their own
> 'installer group' and it was easier for >>them<< than for the users.
> 
> I think the rule of 'least astonishment' is what needs to be the high order
> bit when building tools for people.   Again, offering emacs (or any other
> ITS tool) is fine, but when the new tool is installed on Windows/UNIX/Mac
> et.. it needs to behave itself with the rest of the system, particularly if
> there is already a mechanism in place to do a support function.
> 
> Simply, I would not mind info(gnu) and texinfo(gnu) if there was a way to
> created man pages (or Windows / Mac help).  But having a man page that
> basically says, see figure one
> <https://www.dourish.com/goodies/see-figure-1.html> is not cool.
> 
> my 2 cents from a grumpy old guy....
> Clem

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 14:51                                 ` Larry McVoy
@ 2019-09-16 14:57                                   ` Clem Cole
  2019-09-16 15:14                                     ` Richard Salz
  2019-09-16 22:35                                     ` Dave Horsfall
  2019-09-17  7:53                                   ` arnold
  1 sibling, 2 replies; 148+ messages in thread
From: Clem Cole @ 2019-09-16 14:57 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 696 bytes --]

On Mon, Sep 16, 2019 at 10:51 AM Larry McVoy <lm@mcvoy.com> wrote:

> I hate texinfo and friends.  I get why it is better than man, but man was
> good enough, more than good enough, and the GNU project took everything
> it could find and destroyed the man pages.
>
Amen, bro.   As I said, it was not 'social compliant' which was really a
not very nice thing to do.   It's arrogant to say in effect "your way is
wrong, I'm going to try to kill it off."


>
> If you have something like perl that needs a zillion sub pages, info
> makes sense.  For just a man page, info is horrible.

I'm not even sure, I like that, to be honest. I'm 'old school' enough to
rather use a book from ORA or the like.

[-- Attachment #2: Type: text/html, Size: 1693 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 14:57                                   ` Clem Cole
@ 2019-09-16 15:14                                     ` Richard Salz
  2019-09-16 15:48                                       ` Ronald Natalie
                                                         ` (3 more replies)
  2019-09-16 22:35                                     ` Dave Horsfall
  1 sibling, 4 replies; 148+ messages in thread
From: Richard Salz @ 2019-09-16 15:14 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 312 bytes --]

Is it any surprise that the early GNU effort was really trying to recreate
ITS?  Can you really blame them?  I'm grateful that they made `info` be a
standalone program.  Putting the concept of "cursor position" into the
existing pagers (more/less/etc) and doing jump/xref/back would be more than
a stretch, IMO.

[-- Attachment #2: Type: text/html, Size: 370 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 15:14                                     ` Richard Salz
@ 2019-09-16 15:48                                       ` Ronald Natalie
  2019-09-16 16:10                                       ` Larry McVoy
                                                         ` (2 subsequent siblings)
  3 siblings, 0 replies; 148+ messages in thread
From: Ronald Natalie @ 2019-09-16 15:48 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society



> On Sep 16, 2019, at 11:14 AM, Richard Salz <rich.salz@gmail.com> wrote:
> 
> Is it any surprise that the early GNU effort was really trying to recreate ITS?  Can you really blame them?  I'm grateful that they made `info` be a standalone program.  Putting the concept of "cursor position" into the existing pagers (more/less/etc) and doing jump/xref/back would be more than a stretch, IMO.
> 

Having been an early UNIX Emacs adoptee (I never really learned VI, if there was no emacs, I just used ed.    A tendency that my employees always found amusing), I could never tolerate INFO in any of its forms (either ITS or on UNIX).
It was far too cumbersome for the features it claimed to add to the mix.

As for formatters, my biggest gripe with many of them is that I should not be able to tell what the formatter is by looking at the output.   This is where Tex fails.    It’s ugly style always seems to telegraph through.   The only thing that is worse is those odd little bumps on the top of pic-framed tbl output.   

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 13:42                                   ` Clem Cole
  2019-09-16 14:54                                     ` Larry McVoy
@ 2019-09-16 16:09                                     ` Paul Winalski
  2019-09-16 22:05                                     ` Dave Horsfall
  2 siblings, 0 replies; 148+ messages in thread
From: Paul Winalski @ 2019-09-16 16:09 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

On 9/16/19, Clem Cole <clemc@ccc.com> wrote:
> On Mon, Sep 16, 2019 at 8:26 AM Lars Brinkhoff <lars@nocrew.org> wrote:
>
> What irks me is the blatant force-feeding of any system to the users, be it
> ITS, UNIX or Windows into another.   It's ok to offer an alternative
> interface, but when the system has a mechanism, your tools need to be
> *socially
> compliant* with it, not try to make 'those users become like me.'
>  Frankly, that is a pretty arrogant behavior. Yes, I know the argument is
> two fold.  GNU is not UNIX and we wrote it (he who has the gold, gets to
> rule).

Amen to that!  As the old saying goes, "when in Rome, do as the Romans
do".  On UNIX, tools are expected to send output to stdout.  On
Windows, users expect text selection and ^C/^V copy-and-paste to work.
On VMS, you use the CLI interface to parse the command line.  And so
on.  The principle of least astonishment should always be foremost in
user interaction design.

> BTW:  If it makes you feel better, I've been fighting this attitude at a
> number of places, particularly Intel, for years.   For instance, our dev
> tools folks wrote their own Installer 'because it was easier for them and
> they could use it everywhere').   That's a no-no.  If you have Windows
> product, you must use Microsoft's installer, if you have a Mac, you use
> what Apple gives you, if you have VMS, you used the (wretched) setld, or in
> this case, for Linux its rpm/yum et al.; etc.     But they had their own
> 'installer group' and it was easier for >>them<< than for the users.

I used to work in that organization.  The installer situation is one
of the worst cases of not-invented-here syndrome that I've ever seen.
Or maybe it was just empire building by some ambitious manager.  The
"it's easier for us and we can use it everywhere" argument is pure BS.
Any savings that they got from having the a common code base for the
installer was wiped out by all the extra development effort needed to
track the release-to-release changes that the various platforms made
to their software deployment setup.  Their installer was always a step
or two behind the curve, late in supporting new platform features, and
full of subtle bugs and mis-implemented edge conditions.  It wasn't
really "easier for them" in the long run after all.  It was a
maintenance nightmare.

-Paul W.

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 15:14                                     ` Richard Salz
  2019-09-16 15:48                                       ` Ronald Natalie
@ 2019-09-16 16:10                                       ` Larry McVoy
  2019-09-16 16:16                                         ` Jon Steinhart
  2019-09-17 11:20                                         ` Thomas Paulsen
  2019-09-16 19:13                                       ` Steffen Nurpmeso
  2019-09-16 19:31                                       ` Bakul Shah
  3 siblings, 2 replies; 148+ messages in thread
From: Larry McVoy @ 2019-09-16 16:10 UTC (permalink / raw)
  To: Richard Salz; +Cc: The Eunuchs Hysterical Society

On Mon, Sep 16, 2019 at 11:14:25AM -0400, Richard Salz wrote:
> Is it any surprise that the early GNU effort was really trying to recreate
> ITS?  Can you really blame them?  I'm grateful that they made `info` be a
> standalone program.  Putting the concept of "cursor position" into the
> existing pagers (more/less/etc) and doing jump/xref/back would be more than
> a stretch, IMO.

It's what Clem said.  You should acclimate yourself to your environment.
Pushing info into man environment is a lot like being an immigrant and
wanting to bring your laws into your new homeland.  That isn't a thing
and shouldn't be a thing.  Doesn't matter that people think ITS is better,
they are in Unix.  If you think ITS is better, go live there.

When in Rome....

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 16:10                                       ` Larry McVoy
@ 2019-09-16 16:16                                         ` Jon Steinhart
  2019-09-16 16:26                                           ` Larry McVoy
  2019-09-17 11:20                                         ` Thomas Paulsen
  1 sibling, 1 reply; 148+ messages in thread
From: Jon Steinhart @ 2019-09-16 16:16 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Larry McVoy writes:
> On Mon, Sep 16, 2019 at 11:14:25AM -0400, Richard Salz wrote:
> > Is it any surprise that the early GNU effort was really trying to recreate
> > ITS?  Can you really blame them?  I'm grateful that they made `info` be a
> > standalone program.  Putting the concept of "cursor position" into the
> > existing pagers (more/less/etc) and doing jump/xref/back would be more than
> > a stretch, IMO.
>
> It's what Clem said.  You should acclimate yourself to your environment.
> Pushing info into man environment is a lot like being an immigrant and
> wanting to bring your laws into your new homeland.  That isn't a thing
> and shouldn't be a thing.  Doesn't matter that people think ITS is better,
> they are in Unix.  If you think ITS is better, go live there.
>
> When in Rome....

Well, in the shameless department, I can quote from my book:

	Mucking up the ecosystem into which you release code does not
	add value. Many developers behave as if they’re stereotypical
	Americans vacationing in another country, or for that matter my
	father-in-law visiting — the “I just came to your place, so do
	things my way” attitude.

	For example, UNIX systems have a command that displays manual pages
	for programs. You can type man foo and it’ll show you the page
	for the foo command. There’s also a convention that really complex
	commands, such as yacc , have both a manual page and a longer, more
	in-depth document that describes the program in more detail. When
	the GNU project (which I’ll discuss shortly) added commands to
	UNIX, it used its own texinfo system for manuals, which wasn’t
	compatible with the man system. The result was that users would have
	to try both the man and info commands to find documentation. Even
	if, as some believe, the GNU approach was superior, any possible
	benefits were outweighed by the UNIX community’s huge loss of
	productivity that resulted from the fragmented ecosystem.

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary)
  2019-09-16 14:53               ` Clem Cole
@ 2019-09-16 16:16                 ` Warner Losh
  2019-09-16 20:21                   ` G. Branden Robinson
  2019-10-09  0:38                   ` Lyndon Nerenberg
  0 siblings, 2 replies; 148+ messages in thread
From: Warner Losh @ 2019-09-16 16:16 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 604 bytes --]

On Mon, Sep 16, 2019, 3:53 PM Clem Cole <clemc@ccc.com> wrote:

>
>
> On Sun, Sep 15, 2019 at 11:37 PM Charles H. Sauer <sauer@technologists.com>
> wrote:
>
>> The first Unix I used was PC/ix on an XT. I don’t know it even had vi,
>> but it had INed, which I assume was the ISC evolution of NED & Rand Editor.
>>
> Yes, that is correct.
>

Venix had vi. At least 2.0 pulled that in from Berkeley...

I got to look at the source to a few other editors of the era. All has the
terminal codes hard coded into them... it was common to do that before
things like termcap...

Warner

>

[-- Attachment #2: Type: text/html, Size: 1714 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 16:16                                         ` Jon Steinhart
@ 2019-09-16 16:26                                           ` Larry McVoy
  2019-09-16 16:31                                             ` Richard Salz
  0 siblings, 1 reply; 148+ messages in thread
From: Larry McVoy @ 2019-09-16 16:26 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society

+1

On Mon, Sep 16, 2019 at 09:16:03AM -0700, Jon Steinhart wrote:
> Larry McVoy writes:
> > On Mon, Sep 16, 2019 at 11:14:25AM -0400, Richard Salz wrote:
> > > Is it any surprise that the early GNU effort was really trying to recreate
> > > ITS?  Can you really blame them?  I'm grateful that they made `info` be a
> > > standalone program.  Putting the concept of "cursor position" into the
> > > existing pagers (more/less/etc) and doing jump/xref/back would be more than
> > > a stretch, IMO.
> >
> > It's what Clem said.  You should acclimate yourself to your environment.
> > Pushing info into man environment is a lot like being an immigrant and
> > wanting to bring your laws into your new homeland.  That isn't a thing
> > and shouldn't be a thing.  Doesn't matter that people think ITS is better,
> > they are in Unix.  If you think ITS is better, go live there.
> >
> > When in Rome....
> 
> Well, in the shameless department, I can quote from my book:
> 
> 	Mucking up the ecosystem into which you release code does not
> 	add value. Many developers behave as if they???re stereotypical
> 	Americans vacationing in another country, or for that matter my
> 	father-in-law visiting ??? the ???I just came to your place, so do
> 	things my way??? attitude.
> 
> 	For example, UNIX systems have a command that displays manual pages
> 	for programs. You can type man foo and it???ll show you the page
> 	for the foo command. There???s also a convention that really complex
> 	commands, such as yacc , have both a manual page and a longer, more
> 	in-depth document that describes the program in more detail. When
> 	the GNU project (which I???ll discuss shortly) added commands to
> 	UNIX, it used its own texinfo system for manuals, which wasn???t
> 	compatible with the man system. The result was that users would have
> 	to try both the man and info commands to find documentation. Even
> 	if, as some believe, the GNU approach was superior, any possible
> 	benefits were outweighed by the UNIX community???s huge loss of
> 	productivity that resulted from the fragmented ecosystem.

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 16:26                                           ` Larry McVoy
@ 2019-09-16 16:31                                             ` Richard Salz
  2019-09-16 16:45                                               ` Larry McVoy
  2019-09-16 17:00                                               ` Clem Cole
  0 siblings, 2 replies; 148+ messages in thread
From: Richard Salz @ 2019-09-16 16:31 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 158 bytes --]

I don't think it's totally GNU's fault that it became Linux.  They weren't
trying to be tourists in Rome, they were trying to create a new city of
their own.

[-- Attachment #2: Type: text/html, Size: 229 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 16:31                                             ` Richard Salz
@ 2019-09-16 16:45                                               ` Larry McVoy
  2019-09-16 17:19                                                 ` KatolaZ
  2019-09-16 17:24                                                 ` Clem Cole
  2019-09-16 17:00                                               ` Clem Cole
  1 sibling, 2 replies; 148+ messages in thread
From: Larry McVoy @ 2019-09-16 16:45 UTC (permalink / raw)
  To: Richard Salz; +Cc: The Eunuchs Hysterical Society

On Mon, Sep 16, 2019 at 12:31:13PM -0400, Richard Salz wrote:
> I don't think it's totally GNU's fault that it became Linux.  They weren't
> trying to be tourists in Rome, they were trying to create a new city of
> their own.

Yeah, except they didn't create their own city, they pooped all over a
different one.  There is no defense for what they did.  If they did the
right thing they would have created a markup language that could have
produced info files and man files.

It's not that hard, I wrote something called webroff that took -ms
format input and produced a website complete with the navigation tree,
it defaulted to showing you a page (each .NH) at time but it also had
a site map where you could see the entire document as a single page,
or each major section (.NH 1) as a page.

For more than a decade this was BitMover's home page.  I can't tell
you how many sales calls I've been on and I've seen the entire web
site printed out on the manager's desk.

The reality is there was absolutely no need for a new format for
info files, they could have parsed man input and produced info 
files and that's what they should have done.

Those who defend the choice of info over man just aren't real Unix
people.  And that's fine, Unix isn't the only choice, they can go
run some other OS and be happy.  But it's just rude to thrust info
into a Unix system.  And lame because they could have parsed man
pages into info docs and then they are adopting the Unix way of
doing things and actually adding value.

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 16:31                                             ` Richard Salz
  2019-09-16 16:45                                               ` Larry McVoy
@ 2019-09-16 17:00                                               ` Clem Cole
  1 sibling, 0 replies; 148+ messages in thread
From: Clem Cole @ 2019-09-16 17:00 UTC (permalink / raw)
  To: Richard Salz; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1565 bytes --]

I note that it wasn't "GNI" it was GNU or he would have started with LISP.

The fact is rms started by wanting to hack/rewrite Gosling EMACS as it had
been released and some of the other C versions were at the same time a
little less open to him as a starting point.  Since it was not in LISP, he
needed to write a C Compiler (which I still think is the #1 positive thing
from the Gnu project and in the end, I believe that it was others that
really made the compiler the success, not rms other than he tirelessly
championed it).  The reality is that the Gnu team quick set out  to rewrite
the UNIX tools and used Trix (a UNIX clone) as the original OS. Hurd did
not come until later and in the Linux became the kernel it lived upon (as
Jon says, it's Internet/Linux not Gnu/Linux).

Sorry, IMO, rms tried to 'pee on Unix to make it smell like ITS' - not
surprising as you say.  But pretty darned arrogant none-the less. The
results makes using many of the tools "astonishing" to everyone else.

+1 to Jon's comments.

"Even if, as some believe, the GNU approach was superior, any possible benefits
were outweighed by the UNIX community’s huge loss of productivity that
resulted from the fragmented ecosystem."

Amen brother Jon, and this week's free will offering will be sponsoring ....

On Mon, Sep 16, 2019 at 12:31 PM Richard Salz <rich.salz@gmail.com> wrote:

> I don't think it's totally GNU's fault that it became Linux.  They weren't
> trying to be tourists in Rome, they were trying to create a new city of
> their own.
>

[-- Attachment #2: Type: text/html, Size: 3299 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 16:45                                               ` Larry McVoy
@ 2019-09-16 17:19                                                 ` KatolaZ
  2019-09-16 17:24                                                   ` Larry McVoy
                                                                     ` (2 more replies)
  2019-09-16 17:24                                                 ` Clem Cole
  1 sibling, 3 replies; 148+ messages in thread
From: KatolaZ @ 2019-09-16 17:19 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 2010 bytes --]

On Mon, Sep 16, 2019 at 09:45:02AM -0700, Larry McVoy wrote:

[cut]

> 
> Those who defend the choice of info over man just aren't real Unix
> people.  And that's fine, Unix isn't the only choice, they can go
> run some other OS and be happy.  But it's just rude to thrust info
> into a Unix system.  And lame because they could have parsed man
> pages into info docs and then they are adopting the Unix way of
> doing things and actually adding value.

Sorry, but I totally don't see the point here. The problem is not the
technology, but the adopters. I personally don't like info at all, and
still swear whenever a software comes without a proper manpage, but
info has not been shovelled down your throat (or anybody else's, for
that matter). The adopters have decided that info was fine for their
use case. They could have written manpages and send patches over, and
in many cases they didn't.

There is plenty of software coming from the GNU project that has
comprehensive and clear manpages (just to cite a single example,
bash(1) comes with manpages, and no info doc). At the same time, there
is tons of "Unix" software around that comes without any documentation
*at all*, or with scant text files covering the bare basics.

Unfortunately this trend is only getting worse, and we have far too
many notaable examples here, not all of them coming from the GNU
project, or from the "ITS tradition", whatever it means for you.

I agree that whoever does not produce a readily usable documentaion
for their software has not really understood much of the Unix
philosophy. But that's not at all a matter of formats, rather of
culture.

Then, if you just want to vomit on info, or you prefer to use info as
another excuse to vomit on the GNU project, well go ahead. But the
actual issue is elsewhere (the lack of respect for the users, and the
tendency to hide stuff under the carpet), and has not been introduced
by the GNU project, at all.

My2Cents

Enzo Nicosia

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 17:19                                                 ` KatolaZ
@ 2019-09-16 17:24                                                   ` Larry McVoy
  2019-09-16 17:32                                                     ` Jon Steinhart
  2019-09-16 17:35                                                     ` Clem Cole
  2019-09-16 17:37                                                   ` Jon Steinhart
  2019-09-16 18:04                                                   ` [TUHS] " Chet Ramey
  2 siblings, 2 replies; 148+ messages in thread
From: Larry McVoy @ 2019-09-16 17:24 UTC (permalink / raw)
  To: KatolaZ; +Cc: The Eunuchs Hysterical Society

On Mon, Sep 16, 2019 at 07:19:05PM +0200, KatolaZ wrote:
> On Mon, Sep 16, 2019 at 09:45:02AM -0700, Larry McVoy wrote:
> 
> [cut]
> 
> > 
> > Those who defend the choice of info over man just aren't real Unix
> > people.  And that's fine, Unix isn't the only choice, they can go
> > run some other OS and be happy.  But it's just rude to thrust info
> > into a Unix system.  And lame because they could have parsed man
> > pages into info docs and then they are adopting the Unix way of
> > doing things and actually adding value.
> 
> Sorry, but I totally don't see the point here. 

Jon put it well, the point is people expect to be able to say 

	man foo

and have that work.  Until GNU came along, that's the way it was.
GNU pushed a different system into the mix.

The secondary point is they could have *added* to Unix by making a
man2info command, I know they could have because I've done something
similar, parsing man or -ms pages is trivial.

GNU choose not to do that and I can't begin to express how wrong 
that was.  GNU is not Unix for sure.

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 16:45                                               ` Larry McVoy
  2019-09-16 17:19                                                 ` KatolaZ
@ 2019-09-16 17:24                                                 ` Clem Cole
  1 sibling, 0 replies; 148+ messages in thread
From: Clem Cole @ 2019-09-16 17:24 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 2417 bytes --]

On Mon, Sep 16, 2019 at 12:45 PM Larry McVoy <lm@mcvoy.com> wrote:

> Yeah, except they didn't create their own city, they pooped all over a
> different one.

peed *vs.* pooped -  one is marking territory while the other is destroying
it.
It is interesting that both analogs work here, however.

There is no defense for what they did.  If they did the
> right thing they would have created a markup language that could have
> produced info files and man files.
>
+1 and that's why it is even more difficult to understand.   Being polite
and 'fitting in' would really not been any harder than being like Jon's
father-in-law.


> ....
> Those who defend the choice of info over man just aren't real Unix people.

I'd maybe say it as they don't want to be real Unix people and fit it with
the rest.



> And that's fine, Unix isn't the only choice, they can go
> run some other OS and be happy.

Frankly, trying to turn a Lisp Machine into a "Unix box" would have been as
much of sin, in my eyes. Hey, I'm thrilled to see rms and his friends can
build and purchase as many LMI box as he would like (But I do observe, the
'technically superior system,' in the end, wasn't very economical).   I
really don't mind bringing things over (like more, or job control, or
command/filename completion that all came from other systems).  That is
really adding value to the new system (UNIX in this case).


But it's just rude to thrust info
> into a Unix system.  And lame because they could have parsed man
> pages into info docs and then they are adopting the Unix way of
> doing things and actually adding value.

touché

As Larry and Jon have said better than I, it was the seemly effect of trying
to replace man with info that I just don't understand.     As Larry has
said if they had made a way go from texinfo to man, even if it had been a
little rough on the edges, I might have grumbled, but I would have tried to
use it.  The truth is today, like many other Unix hacker I know, if I am
offered a new tool but using it means that I am being led down a path to use
info/texinfo, I rethink if I want to use that new tool or not.   It's a big
turn off for me to want to learn to use such a tool since I know the
authors have made no attempt to integrate it into a traditional UNIX
workflow if they have not built proper man pages, much less written
traditional docs.

[-- Attachment #2: Type: text/html, Size: 5465 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 17:24                                                   ` Larry McVoy
@ 2019-09-16 17:32                                                     ` Jon Steinhart
  2019-09-16 17:35                                                     ` Clem Cole
  1 sibling, 0 replies; 148+ messages in thread
From: Jon Steinhart @ 2019-09-16 17:32 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Larry McVoy writes:
> On Mon, Sep 16, 2019 at 07:19:05PM +0200, KatolaZ wrote:
> > On Mon, Sep 16, 2019 at 09:45:02AM -0700, Larry McVoy wrote:
> > 
> > [cut]
> > 
> > > 
> > > Those who defend the choice of info over man just aren't real Unix
> > > people.  And that's fine, Unix isn't the only choice, they can go
> > > run some other OS and be happy.  But it's just rude to thrust info
> > > into a Unix system.  And lame because they could have parsed man
> > > pages into info docs and then they are adopting the Unix way of
> > > doing things and actually adding value.
> > 
> > Sorry, but I totally don't see the point here. 
>
> Jon put it well, the point is people expect to be able to say 
>
> 	man foo
>
> and have that work.  Until GNU came along, that's the way it was.
> GNU pushed a different system into the mix.
>
> The secondary point is they could have *added* to Unix by making a
> man2info command, I know they could have because I've done something
> similar, parsing man or -ms pages is trivial.
>
> GNU choose not to do that and I can't begin to express how wrong 
> that was.  GNU is not Unix for sure.

So I'm not really trying to be all that shameless, it's just that I've already
written down my opinions on this sort of stuff and don't need to retype it all.
From a section entitled "The Value Proposition":

	There's an overarching question that you should keep in mind when
	working on a project: "Am I adding value?" I'm not talking about
	the intrinsic value of accomplishing some task here; I'm talking
	about increasing productivity.

	If you're programming for a living, you need to meet whatever goals
	your employer has set. But, of course, there's more than one way
	to meet those goals. You could just do what you need to do to get
	by. Or, you could put a little thought into things that might not
	have occurred to management.  For example, you might realize that
	your code would be useful in another project and structure it so
	it's easily reusable. Or, you might sense that you were tasked to
	implement a special case of a more general problem and solve that
	general problem instead, paving the way for future enhancements.
	Of course, you should talk about this with management so that
	they're not surprised.

	You can add value to yourself by making sure that you're proficient
	in a variety of technologies. Side projects are a common way to
	get experience; it's equivalent to doing homework but more fun.

	One classic way in which people attempt to add value is by
	creating tools. This is trickier than it seems because sometimes
	adding value for yourself reduces value for others. People often
	create new tools because some feature that they think they need
	is missing from existing ones. A good example is the make utility
	(invented by Stuart Feldman at Bell Labs in 1976), which is used to
	build large software packages. As time went on, new features were
	needed. Some of these were added to make, but in many other cases,
	people created well-intentioned but incompatible new utilities
	that performed similar functions. (For example, I consulted for
	a company once that wrote their own solely because they didn't
	bother to completely read the make documentation and were unaware
	that it would do exactly what they needed.) Now there's make,
	cmake, dmake, imake, pick-a-letter-make, and other programs that
	all do similar things in incompatible ways. The result is that
	practitioners like you need to learn multiple tools in each category.
	It makes everyone's life harder, not easier. It doesn't add
	value—it detracts. Figure 15-1 sums up the situation nicely.
	[ Figure 15-1 is the xkcd how standards proliferate cartoon ]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 17:24                                                   ` Larry McVoy
  2019-09-16 17:32                                                     ` Jon Steinhart
@ 2019-09-16 17:35                                                     ` Clem Cole
  1 sibling, 0 replies; 148+ messages in thread
From: Clem Cole @ 2019-09-16 17:35 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 639 bytes --]

On Mon, Sep 16, 2019 at 1:24 PM Larry McVoy <lm@mcvoy.com> wrote:

> The secondary point is they could have *added* to Unix by making a
> man2info command
>

Exactly!!!!   That's what Eric did when he wrote more(ucb) -  he *added to
Unix*.   The funny part was that USG thought more(ucb) was a good idea and
then wrote their own, pg(att); which was just as arrogant as the info
behavior from the Gnu folks!!!   Later, Less(internet) replaced more, but
only as a superset, building on the foundation and eventually USB chose to
ship more also as so many people wanted it.

As I said yesterday, standing on the shoulders, not on their toes.

[-- Attachment #2: Type: text/html, Size: 1437 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 17:19                                                 ` KatolaZ
  2019-09-16 17:24                                                   ` Larry McVoy
@ 2019-09-16 17:37                                                   ` Jon Steinhart
  2019-09-16 18:09                                                     ` [TUHS] [OT] " KatolaZ
  2019-09-16 18:04                                                   ` [TUHS] " Chet Ramey
  2 siblings, 1 reply; 148+ messages in thread
From: Jon Steinhart @ 2019-09-16 17:37 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

KatolaZ writes:
> Sorry, but I totally don't see the point here. The problem is not the
> technology, but the adopters. I personally don't like info at all, and
> still swear whenever a software comes without a proper manpage, but
> info has not been shovelled down your throat (or anybody else's, for
> that matter). The adopters have decided that info was fine for their
> use case. They could have written manpages and send patches over, and
> in many cases they didn't.
>
> There is plenty of software coming from the GNU project that has
> comprehensive and clear manpages (just to cite a single example,
> bash(1) comes with manpages, and no info doc). At the same time, there
> is tons of "Unix" software around that comes without any documentation
> *at all*, or with scant text files covering the bare basics.
>
> Unfortunately this trend is only getting worse, and we have far too
> many notaable examples here, not all of them coming from the GNU
> project, or from the "ITS tradition", whatever it means for you.
>
> I agree that whoever does not produce a readily usable documentaion
> for their software has not really understood much of the Unix
> philosophy. But that's not at all a matter of formats, rather of
> culture.
>
> Then, if you just want to vomit on info, or you prefer to use info as
> another excuse to vomit on the GNU project, well go ahead. But the
> actual issue is elsewhere (the lack of respect for the users, and the
> tendency to hide stuff under the carpet), and has not been introduced
> by the GNU project, at all.
>
> My2Cents
>
> Enzo Nicosia

It seems to me that you're missing the point here.  It's not a question of
whether or not GNU programs have good documentation.  It's the fact that
GNU made it hard to find documentation because they took one pile and split
it into two with no guide to what was in each pile.  It's not that their
documentation was good or bad, it's that they made it hard to find any
documentation.

Maybe it's because I'm a child of the 60s, but I'm with Arlo Guthrie on this
one (from Alice's Restaurant): "And we decided that one big pile is better
than two little piles, and rather than bring that one up we decided to throw
ours down."

Jon

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 17:19                                                 ` KatolaZ
  2019-09-16 17:24                                                   ` Larry McVoy
  2019-09-16 17:37                                                   ` Jon Steinhart
@ 2019-09-16 18:04                                                   ` Chet Ramey
  2019-09-16 18:19                                                     ` KatolaZ
  2019-09-16 23:24                                                     ` Dave Horsfall
  2 siblings, 2 replies; 148+ messages in thread
From: Chet Ramey @ 2019-09-16 18:04 UTC (permalink / raw)
  To: KatolaZ, Larry McVoy; +Cc: The Eunuchs Hysterical Society


[-- Attachment #1.1: Type: text/plain, Size: 483 bytes --]

On 9/16/19 1:19 PM, KatolaZ wrote:

> There is plenty of software coming from the GNU project that has
> comprehensive and clear manpages (just to cite a single example,
> bash(1) comes with manpages, and no info doc). 

Bash comes with both a large man page and an extensive info doc.

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* [TUHS] [OT] Re:  earliest Unix roff
  2019-09-16 17:37                                                   ` Jon Steinhart
@ 2019-09-16 18:09                                                     ` KatolaZ
  2019-09-16 18:19                                                       ` Jon Steinhart
  0 siblings, 1 reply; 148+ messages in thread
From: KatolaZ @ 2019-09-16 18:09 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 2688 bytes --]

On Mon, Sep 16, 2019 at 10:37:03AM -0700, Jon Steinhart wrote:

[cut]

> 
> It seems to me that you're missing the point here.  It's not a question of
> whether or not GNU programs have good documentation.  It's the fact that
> GNU made it hard to find documentation because they took one pile and split
> it into two with no guide to what was in each pile.  It's not that their
> documentation was good or bad, it's that they made it hard to find any
> documentation.
> 
> Maybe it's because I'm a child of the 60s, but I'm with Arlo Guthrie on this
> one (from Alice's Restaurant): "And we decided that one big pile is better
> than two little piles, and rather than bring that one up we decided to throw
> ours down."
>

Dear Jon, I am a child of the 70s, so I know the drill ;)

What I am saying is that the vast majority of the software from the
GNU project actually has a good-quality manpage acoompanying it. And
it also has the same documentation in info format. Hence I see no
point in vomiting on info (which I mostly dislike anyway, as I said),
as on any other document format, as long as the same information is
made available via manpages as well, as it is the case for most of the
software present in current Unix systems, wherever it comes from. The
split caused by the introduction of info has mainly been cured by the
community, maybe too late, but still.

We can discuss whether the split was necessary or "right" in the first
instance, as we could discuss whether it was good or not for cat(1) to
leave Murray Hill in 1979 with no options and come back from Berkley
with a source code doubled in size and 9 options in 1982. We could do
that, but perhaps we shouldn't get too partisan, since the history of
Unix is not a simple single-threaded and linear one, as the many
insightful contributions posted in this ML show. It's a continuum,
where it is difficult to find any single element which is totally
right or totally wrong.

I honestly see more danger in the recent trend that avoids
documentation altogether, except for a scant README.md file at the top
of the sources. There is an entire generation of developers who see
little value in producing (and using) online documentation, where by
online I mean manpage-like or info-like docs. For the simple reason
that the main way in which documentation is produced and distributed
has changed a lot in the last 25 years. Now it's all about googling
the right words, unfortunately.

We can keep blaming RMS, info, or the GNU project, but indeed blaming
them for the Web would be a bit too much ;)

And this is perhaps becoming OT anyway.

HND

Enzo Nicosia



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] [OT] Re:  earliest Unix roff
  2019-09-16 18:09                                                     ` [TUHS] [OT] " KatolaZ
@ 2019-09-16 18:19                                                       ` Jon Steinhart
  0 siblings, 0 replies; 148+ messages in thread
From: Jon Steinhart @ 2019-09-16 18:19 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

KatolaZ writes:
> Dear Jon, I am a child of the 70s, so I know the drill ;)
>
> What I am saying is that the vast majority of the software from the
> GNU project actually has a good-quality manpage acoompanying it. And
> it also has the same documentation in info format. Hence I see no
> point in vomiting on info (which I mostly dislike anyway, as I said),
> as on any other document format, as long as the same information is
> made available via manpages as well, as it is the case for most of the
> software present in current Unix systems, wherever it comes from. The
> split caused by the introduction of info has mainly been cured by the
> community, maybe too late, but still.
>
> We can discuss whether the split was necessary or "right" in the first
> instance, as we could discuss whether it was good or not for cat(1) to
> leave Murray Hill in 1979 with no options and come back from Berkley
> with a source code doubled in size and 9 options in 1982. We could do
> that, but perhaps we shouldn't get too partisan, since the history of
> Unix is not a simple single-threaded and linear one, as the many
> insightful contributions posted in this ML show. It's a continuum,
> where it is difficult to find any single element which is totally
> right or totally wrong.
>
> I honestly see more danger in the recent trend that avoids
> documentation altogether, except for a scant README.md file at the top
> of the sources. There is an entire generation of developers who see
> little value in producing (and using) online documentation, where by
> online I mean manpage-like or info-like docs. For the simple reason
> that the main way in which documentation is produced and distributed
> has changed a lot in the last 25 years. Now it's all about googling
> the right words, unfortunately.
>
> We can keep blaming RMS, info, or the GNU project, but indeed blaming
> them for the Web would be a bit too much ;)
>
> And this is perhaps becoming OT anyway.
>
> HND
>
> Enzo Nicosia

Well, maybe we're just violently agreeing.  Again, while I think that
info is klunky-feeling, my issue is the ecosystem fragmentation.

I think that it's not our place to discuss cat as Rob is on the list
and he owns that :-)

I do agree that the utter lack of any documentation is a bigger problem.
Or worse, the document that says how to download, build, and install a
package without ever saying what it does or how to use it.

I'm not blaming RMS or GNU, I'm just using them as examples of a way of
doing things that I don't like.  I certainly don't blame them for the web.
Please let's not get started on that!

Jon

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 18:04                                                   ` [TUHS] " Chet Ramey
@ 2019-09-16 18:19                                                     ` KatolaZ
  2019-09-16 23:24                                                     ` Dave Horsfall
  1 sibling, 0 replies; 148+ messages in thread
From: KatolaZ @ 2019-09-16 18:19 UTC (permalink / raw)
  To: Chet Ramey; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 493 bytes --]

On Mon, Sep 16, 2019 at 02:04:00PM -0400, Chet Ramey wrote:
> On 9/16/19 1:19 PM, KatolaZ wrote:
> 
> > There is plenty of software coming from the GNU project that has
> > comprehensive and clear manpages (just to cite a single example,
> > bash(1) comes with manpages, and no info doc). 
> 
> Bash comes with both a large man page and an extensive info doc.
> 

Yep, sorry! I meant "and not only an info doc". And they are both of
very good quality, IMHO.

HND

Enzo Nicosia

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 15:14                                     ` Richard Salz
  2019-09-16 15:48                                       ` Ronald Natalie
  2019-09-16 16:10                                       ` Larry McVoy
@ 2019-09-16 19:13                                       ` Steffen Nurpmeso
  2019-09-16 19:31                                       ` Bakul Shah
  3 siblings, 0 replies; 148+ messages in thread
From: Steffen Nurpmeso @ 2019-09-16 19:13 UTC (permalink / raw)
  To: Richard Salz; +Cc: The Eunuchs Hysterical Society

Richard Salz wrote in <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc5\
8A@mail.gmail.com>:
 |Is it any surprise that the early GNU effort was really trying to recreate \
 |ITS?  Can you really blame them?  I'm grateful that they made `info` \
 |be a standalone program.  Putting the concept of "cursor 
 |position" into the existing pagers (more/less/etc) and doing jump/xref/b\
 |ack would be more than a stretch, IMO.

So that is actually not true, really.

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 15:14                                     ` Richard Salz
                                                         ` (2 preceding siblings ...)
  2019-09-16 19:13                                       ` Steffen Nurpmeso
@ 2019-09-16 19:31                                       ` Bakul Shah
  3 siblings, 0 replies; 148+ messages in thread
From: Bakul Shah @ 2019-09-16 19:31 UTC (permalink / raw)
  To: Richard Salz; +Cc: The Eunuchs Hysterical Society

The way Rob solved the problem in acme(1) is much nicer.
Right click on |open(2)| and its man page opens up in a
new window. You can do the same on any manpage mentioned
in the SEE ALSO section or anywhere else and you can see
their man page without any side-effect on the original
window. He didn't throw out any old documentation but
added a a new tool to make navigation easier (and it is
more general in that you can define right click actions).

There was already cursor positioning available in vi. It
would not have been a real stretch to hack in acme like
support in less or vi (clumsier without a mouse but still).
In fact tag support in vi already did something like it
with ^] and ^^ for jump/back.


> On Sep 16, 2019, at 8:14 AM, Richard Salz <rich.salz@gmail.com> wrote:
> 
> Is it any surprise that the early GNU effort was really trying to recreate ITS?  Can you really blame them?  I'm grateful that they made `info` be a standalone program.  Putting the concept of "cursor position" into the existing pagers (more/less/etc) and doing jump/xref/back would be more than a stretch, IMO.
> 


^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary)
  2019-09-16 16:16                 ` Warner Losh
@ 2019-09-16 20:21                   ` G. Branden Robinson
  2019-09-16 20:47                     ` Jon Steinhart
  2019-09-17 11:46                     ` [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview " Theodore Y. Ts'o
  2019-10-09  0:38                   ` Lyndon Nerenberg
  1 sibling, 2 replies; 148+ messages in thread
From: G. Branden Robinson @ 2019-09-16 20:21 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 669 bytes --]

At 2019-09-16T17:16:12+0100, Warner Losh wrote:
> I got to look at the source to a few other editors of the era. All has
> the terminal codes hard coded into them... it was common to do that
> before things like termcap...

It's still common today.  Everything the developer cares to think about,
let alone test on, interprets EMCA-48 SGR escape sequences.  My favorite
recent example is "spectre-meltdown-checker", which has such edifying
lines as:

        _info_nol "> \033[46m\033[30mSTATUS:\033[0m "

Why write something portable when you can be "close to the metal"?  :-/

I gently steer people to better ways when the occasion presents itself.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary)
  2019-09-16 20:21                   ` G. Branden Robinson
@ 2019-09-16 20:47                     ` Jon Steinhart
  2019-09-16 22:33                       ` George Michaelson
  2019-09-16 22:48                       ` [TUHS] better ways and termcap vs. terminfo " G. Branden Robinson
  2019-09-17 11:46                     ` [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview " Theodore Y. Ts'o
  1 sibling, 2 replies; 148+ messages in thread
From: Jon Steinhart @ 2019-09-16 20:47 UTC (permalink / raw)
  To: tuhs

G. Branden Robinson writes:
>
> At 2019-09-16T17:16:12+0100, Warner Losh wrote:
> > I got to look at the source to a few other editors of the era. All has
> > the terminal codes hard coded into them... it was common to do that
> > before things like termcap...
>
> It's still common today.  Everything the developer cares to think about,
> let alone test on, interprets EMCA-48 SGR escape sequences.  My favorite
> recent example is "spectre-meltdown-checker", which has such edifying
> lines as:
>
>         _info_nol "> \033[46m\033[30mSTATUS:\033[0m "
>
> Why write something portable when you can be "close to the metal"?  :-/
>
> I gently steer people to better ways when the occasion presents itself.
>
> Regards,
> Branden

We can have an interesting discussion of the definition of "better ways".
I see termcap as a great solution for the days in which there was little
standardization.  But it's probably pretty hard to find a non-conforming
terminal nowadays so I think that it's better to avoid obfuscation.  Were
it me I would have a comment that referenced the page and section number
in the standard.

Since we like debating the merits of old technology, somebody can kick off
a termcap versus terminfo discussion :-)

Jon

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 12:10                               ` Clem Cole
                                                   ` (2 preceding siblings ...)
  2019-09-16 14:51                                 ` Larry McVoy
@ 2019-09-16 21:42                                 ` Dave Horsfall
  2019-09-16 21:48                                   ` Larry McVoy
  2019-09-17  0:16                                   ` Greg 'groggy' Lehey
  2019-10-05 19:44                                 ` Michael Parson
  4 siblings, 2 replies; 148+ messages in thread
From: Dave Horsfall @ 2019-09-16 21:42 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]

On Mon, 16 Sep 2019, Clem Cole wrote:

> Fair enough, but be careful, while I admit I have not looked in a while, 
> info(gnu) relies on emacs keybindings and a number of very 
> emacs'ish things. Every time I have tried to deal with it, I have 
> unprogram my fingers and reset them to emacs.

Yep, which is why I like "info" as much as I like EMACS i.e. not at all.

What exactly is wrong with the manpage format?  It tells you everything 
you need to know, and tells you where to find further information.

-- Dave

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 21:42                                 ` Dave Horsfall
@ 2019-09-16 21:48                                   ` Larry McVoy
  2019-09-16 21:54                                     ` Jon Steinhart
  2019-09-17  0:16                                   ` Greg 'groggy' Lehey
  1 sibling, 1 reply; 148+ messages in thread
From: Larry McVoy @ 2019-09-16 21:48 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

On Tue, Sep 17, 2019 at 07:42:28AM +1000, Dave Horsfall wrote:
> On Mon, 16 Sep 2019, Clem Cole wrote:
> 
> >Fair enough, but be careful, while I admit I have not looked in a while,
> >info(gnu) relies on emacs keybindings and a number of very
> >emacs'ish??things. Every time I have tried to deal with it, I have
> >unprogram my fingers and reset them to emacs.
> 
> Yep, which is why I like "info" as much as I like EMACS i.e. not at all.
> 
> What exactly is wrong with the manpage format?  It tells you everything you
> need to know, and tells you where to find further information.

I think, someone correct me if I'm wrong, the info stuff was designed
to handle larger, more complex stuff, with a table of contents, etc.
Something like perl could fit in one info doc but the perl man page is
not a thing, it's just a series of pointers to more man pages.

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 21:48                                   ` Larry McVoy
@ 2019-09-16 21:54                                     ` Jon Steinhart
  2019-09-16 21:59                                       ` Larry McVoy
  2019-09-16 22:10                                       ` Bakul Shah
  0 siblings, 2 replies; 148+ messages in thread
From: Jon Steinhart @ 2019-09-16 21:54 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Larry McVoy writes:
>
> I think, someone correct me if I'm wrong, the info stuff was designed
> to handle larger, more complex stuff, with a table of contents, etc.
> Something like perl could fit in one info doc but the perl man page is
> not a thing, it's just a series of pointers to more man pages.

Can't answer you directly on this one, but I prefer the old system of
having man pages and separate documents for longer things.  I still
have old notebooks full of papers on lex, yacc, and so on.

One of the problems with using info for something like perl is that it
doesn't have a useful organization.  There's a difference to me between
a reference manual and a user's guide.  Most of the stuff referenced by
the main perl page is user's guide stuff to me, it's not a reference.

Probably someone knows more than me about all this.  I have always been
under the impression that one read the user's guide to learn about
complicated stuff.  The manual pages were there so that you could find
the right options when you forgot.  Putting every detail about a complex
program into a manual page doesn't feel right to me.

Jon

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 21:54                                     ` Jon Steinhart
@ 2019-09-16 21:59                                       ` Larry McVoy
  2019-09-17  5:07                                         ` Lars Brinkhoff
  2019-09-16 22:10                                       ` Bakul Shah
  1 sibling, 1 reply; 148+ messages in thread
From: Larry McVoy @ 2019-09-16 21:59 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society

On Mon, Sep 16, 2019 at 02:54:49PM -0700, Jon Steinhart wrote:
> Larry McVoy writes:
> >
> > I think, someone correct me if I'm wrong, the info stuff was designed
> > to handle larger, more complex stuff, with a table of contents, etc.
> > Something like perl could fit in one info doc but the perl man page is
> > not a thing, it's just a series of pointers to more man pages.
> 
> Can't answer you directly on this one, but I prefer the old system of
> having man pages and separate documents for longer things.  I still
> have old notebooks full of papers on lex, yacc, and so on.
> 
> One of the problems with using info for something like perl is that it
> doesn't have a useful organization.  

We are 100% on the same page.  My complaint about wikis is it is impossible
to find anything without a search engine.  I like tables of contents and
indices.

My comment on the info stuff was just my understand of why it came to be.

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 13:42                                   ` Clem Cole
  2019-09-16 14:54                                     ` Larry McVoy
  2019-09-16 16:09                                     ` Paul Winalski
@ 2019-09-16 22:05                                     ` Dave Horsfall
  2019-09-16 22:33                                       ` reed
                                                         ` (2 more replies)
  2 siblings, 3 replies; 148+ messages in thread
From: Dave Horsfall @ 2019-09-16 22:05 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 600 bytes --]

On Mon, 16 Sep 2019, Clem Cole wrote:

> >       However, please note that more(1) also was inspired by, almost 
> >       copied from, ITS.  Certainly the prompt --More-- is.
> 
> Absolutely.  A friend of mine/fellow UCB grad student, Eric Shienbrood, 
> wrote it.  He was a MIT undergrad. And Eric happily said it was modeled 
> from ITS. And before, Eric wrote it, UNIX lacked anything like it.  
>  Which to me is fine, taking an idea from another system to add a new 
> feature that is lacking.

Am I the only one who remembers the old "pg" program?  It seems to have
disappeared.

-- Dave

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 21:54                                     ` Jon Steinhart
  2019-09-16 21:59                                       ` Larry McVoy
@ 2019-09-16 22:10                                       ` Bakul Shah
  1 sibling, 0 replies; 148+ messages in thread
From: Bakul Shah @ 2019-09-16 22:10 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society

On Mon, 16 Sep 2019 14:54:49 -0700 Jon Steinhart <jon@fourwinds.com> wrote:
> Larry McVoy writes:
> >
> > I think, someone correct me if I'm wrong, the info stuff was designed
> > to handle larger, more complex stuff, with a table of contents, etc.
> > Something like perl could fit in one info doc but the perl man page is
> > not a thing, it's just a series of pointers to more man pages.
>
> Can't answer you directly on this one, but I prefer the old system of
> having man pages and separate documents for longer things.  I still
> have old notebooks full of papers on lex, yacc, and so on.
>
> One of the problems with using info for something like perl is that it
> doesn't have a useful organization.  There's a difference to me between
> a reference manual and a user's guide.  Most of the stuff referenced by
> the main perl page is user's guide stuff to me, it's not a reference.
>
> Probably someone knows more than me about all this.  I have always been
> under the impression that one read the user's guide to learn about
> complicated stuff.  The manual pages were there so that you could find
> the right options when you forgot.  Putting every detail about a complex
> program into a manual page doesn't feel right to me.

A typical manpage had just the right length. Reading man pages
and experimenting is how I initially learned all about unix
commands.

Keeping a manpage short also limited what you as the
implementer would be tempted to add to the command. Manpages
work best for programs that follow the unix mantra of do one
thing and do it well. But not for kitchensink programs.  When
you need a multipage reference manual (for *experts*) with a
TOC and program to "navigate", you're much more likely to give
into the temptation of adding more features than partition
functionality into separate programs that work well together.
Not to mention it is harder to get something right that has
many more features.

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary)
  2019-09-16 20:47                     ` Jon Steinhart
@ 2019-09-16 22:33                       ` George Michaelson
  2019-09-16 23:14                         ` G. Branden Robinson
  2019-10-09  1:10                         ` Lyndon Nerenberg
  2019-09-16 22:48                       ` [TUHS] better ways and termcap vs. terminfo " G. Branden Robinson
  1 sibling, 2 replies; 148+ messages in thread
From: George Michaelson @ 2019-09-16 22:33 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society

On Tue, Sep 17, 2019 at 6:47 AM Jon Steinhart <jon@fourwinds.com> wrote:
>
> Since we like debating the merits of old technology, somebody can kick off
> a termcap versus terminfo discussion :-)
>

Felt like of-its-time NIH. Since the codes to drive an ADM5 were the
same in either source, and since the intent was the same, it was just
a giant *why* for me.

I didn't get why binary file either. If the cost of reading the
termcap DB was a significant hit on your program, I think you just
proved you were a robot and would be defeated by a captcha. Having to
compile things is a drag.

It was probably a side effect of the sequence of universities and
institutions I worked at (York, Leeds, York, UCL, CSIRO, UQ) that they
were almost exclusively v7->32V->BSD->SunOS shops and so the emergence
of SYSV was basically occluded to me, and so SYSV-isms (with the
exception of RFS and the pre-gnu getopt() which leaked into UUCP
newsgroups I read somehow).

Terminfo just didn't feel very *relevant*

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 22:05                                     ` Dave Horsfall
@ 2019-09-16 22:33                                       ` reed
  2019-09-17  0:11                                         ` Dave Horsfall
  2019-09-17  0:02                                       ` Nemo Nusquam
  2019-09-17  0:46                                       ` Clem Cole
  2 siblings, 1 reply; 148+ messages in thread
From: reed @ 2019-09-16 22:33 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

> Am I the only one who remembers the old "pg" program?  It seems to have
> disappeared.

I see two different pg. One in the 32V sources and the other first 
Usenix delaware collection. (Both in TUHS archives)

Another pager "cr3" is in 1BSD collection (which was replaced by 
Halbert's more in 3BSD).

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 14:57                                   ` Clem Cole
  2019-09-16 15:14                                     ` Richard Salz
@ 2019-09-16 22:35                                     ` Dave Horsfall
  1 sibling, 0 replies; 148+ messages in thread
From: Dave Horsfall @ 2019-09-16 22:35 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 439 bytes --]

On Mon, 16 Sep 2019, Clem Cole wrote:

> >       If you have something like perl that needs a zillion sub pages, 
> >       info makes sense.  For just a man page, info is horrible.
> 
> I'm not even sure, I like that, to be honest. I'm 'old school' enough to 
> rather use a book from ORA or the like. 

Or use www.perltutorial.org which is a good resource; I often get stuck
on the finer points of Perl, such as the OO stuff.

-- Dave

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] better ways and termcap vs. terminfo for commentary)
  2019-09-16 20:47                     ` Jon Steinhart
  2019-09-16 22:33                       ` George Michaelson
@ 2019-09-16 22:48                       ` G. Branden Robinson
  1 sibling, 0 replies; 148+ messages in thread
From: G. Branden Robinson @ 2019-09-16 22:48 UTC (permalink / raw)
  To: tuhs


[-- Attachment #1.1: Type: text/plain, Size: 3253 bytes --]

At 2019-09-16T13:47:27-0700, Jon Steinhart wrote:
> G. Branden Robinson writes:
> >         _info_nol "> \033[46m\033[30mSTATUS:\033[0m "
> >
> > Why write something portable when you can be "close to the metal"?  :-/
> >
> > I gently steer people to better ways when the occasion presents itself.
[...]
> 
> We can have an interesting discussion of the definition of "better ways".

Here I think we have a layering violation.  Why on earth would a CPU
microarchitectural flaw detector need to know or care about the details
terminal control sequences?

_Anything_ that provides an abstraction of the terminal is an
improvement on the above.

> I see termcap as a great solution for the days in which there was
> little standardization.

Setting aside the specificity of "termcap", sure.  Something was needed
to gather up the absurd efflorescence of implementation details among
hardware terminals and present programmers (and users struggling to
interact with the system) something simpler and more intention-oriented.

You want "bold, if the device can do it", not a giant switch statement
encompassing '\033[1m', '\033ya', '\033yA', '\033<', '\2331m', '\033[1m'
with a parameter after it, '\033[7m', \033[=15F', ...

And if the device _can't_ do bold, you want to be able to decide for
yourself whether you don't care if the boldness is left out, or be able
to query that interface layer about it and program your own fallback
(use indentation, full capitalization, an "IMPORTANT:" prefix, etc.) in
the event the capability is absent.

> But it's probably pretty hard to find a non-conforming terminal
> nowadays so I think that it's better to avoid obfuscation.

I've attached an example of the sort of thing I do.  It has a lot of
comments, so is inappropriate for inlining on a list full of Unix
grognards.  ;-)

> Were it me I would have a comment that referenced the page and section
> number in the standard.

This is a good idea, but its benefit can be limited for ISO standards,
which are often paywalled.  In this case the controlling standard is
ISO 6429.  Fortunately it's largely parallel to ECMA-48 which is freely
available.  In this case you want ECMA-48, pp. 61-63[1].

> Since we like debating the merits of old technology, somebody can kick
> off a termcap versus terminfo discussion :-)

terminfo is better than termcap in the same way that Fortran 77 is
better than Microsoft BASIC for 8-bit microcomputers--identifier length.

Fortran 77, 6 characters.
MS BASIC, 2.
termcap, 2.
terminfo, 5.

Of course, that argument could be turned around rather precisely for
those who prize "terseness".

I reckon one of the reasons that function names in the Unix kernel were
allowed to grow as long as they did--while still being limited to 6
characters for linkage reasons--was because the precious space of 1-
and 2-letter external identifiers was held sacrosanct for user programs.

There but for that grace would 'swtch()' have gone as 'sw()', and
'creat()' as 'cr()', perhaps.

No such considerations availed in the namespace for executable programs.
;-)

Regards,
Branden

[1] https://www.ecma-international.org/publications/files/ECMA-ST/Ecma-048.pdf


[-- Attachment #1.2: example.sh --]
[-- Type: application/x-sh, Size: 2029 bytes --]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary)
  2019-09-16 22:33                       ` George Michaelson
@ 2019-09-16 23:14                         ` G. Branden Robinson
  2019-10-09  1:10                         ` Lyndon Nerenberg
  1 sibling, 0 replies; 148+ messages in thread
From: G. Branden Robinson @ 2019-09-16 23:14 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 3445 bytes --]

At 2019-09-17T08:33:29+1000, George Michaelson wrote:
> On Tue, Sep 17, 2019 at 6:47 AM Jon Steinhart <jon@fourwinds.com> wrote:
> >
> > Since we like debating the merits of old technology, somebody can kick off
> > a termcap versus terminfo discussion :-)
> >
> 
> Felt like of-its-time NIH.

I certainly would not defend USG on those grounds.  Many poor decisions
seem to have been taken in the name of attempting to gain a commercial
advantage, or of an effort to present the industry with a fait accompli
that you just HAD to go along with and therefore HAD to fork over a
license fee.

This is only my impression from reading histories and retrospectives; I
came of age just as the Unix wars were winding down and Microsoft showed
that they were the most competitive at being anti-competitive.

> Since the codes to drive an ADM5 were the same in either source, and
> since the intent was the same, it was just a giant *why* for me.

For me, the mnemonic value of the capability names is important, though
terminfo didn't leverage that advantage nearly as much as they could and
should have.  5 characters was better than 2 but still too short.  And
in many cases they just reused the termcap capability names as-is, e.g.,
'am', 'll'.

But one example is enough to point up the advantage.  By what name do
you look up the "bold" capability?  In terminfo, it's called...'bold'.

In termcap, what's your bet?  'bd'?  Nope.  'bo'?  Nope.

'md'.

> I didn't get why binary file either. If the cost of reading the
> termcap DB was a significant hit on your program, I think you just
> proved you were a robot and would be defeated by a captcha. Having to
> compile things is a drag.

This is an implementation detail that _should_ have been transparent to
the user.  No one should have needed to care what the on-disk or
in-memory representation of the terminal capability list was.

But...it was the '80s.  My guess is that encapsulation to that degree
smacked of object-orientation, possibly, and therefore was always going
to be a performance disaster, the same way no one was ever going to need
more than 640KiB or how microkernels were always going to be slow at
context-switching.

Or maybe it just came down to lazy implementation.

> It was probably a side effect of the sequence of universities and
> institutions I worked at (York, Leeds, York, UCL, CSIRO, UQ) that they
> were almost exclusively v7->32V->BSD->SunOS shops and so the emergence
> of SYSV was basically occluded to me, and so SYSV-isms (with the
> exception of RFS and the pre-gnu getopt() which leaked into UUCP
> newsgroups I read somehow).
> 
> Terminfo just didn't feel very *relevant*

Yes--what good ideas AT&T commercial Unix had, they seemed determined to
ensure people never found out about except via capture of standards
bodies followed by mandatory licensing.  To me this would explain the
reasoning behind the Sun/AT&T corrupt bargain that led to Solaris (of
which Larry has written here).  People were enthusiastic about SunOS.
Obviously the thing to do with such an enthusiastic user base is buy
access to it and force them to eat whatever you feed them.  They will
remin your thralls and sing your praises for free, because all
consumer preferences are ultimately mindless questions of fashion.

Worked brilliantly, didn't it?

It can.  If you're Steve Jobs.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 18:04                                                   ` [TUHS] " Chet Ramey
  2019-09-16 18:19                                                     ` KatolaZ
@ 2019-09-16 23:24                                                     ` Dave Horsfall
  1 sibling, 0 replies; 148+ messages in thread
From: Dave Horsfall @ 2019-09-16 23:24 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Mon, 16 Sep 2019, Chet Ramey wrote:

> Bash comes with both a large man page and an extensive info doc.

On my (obsolete) FreeBSD box:

     aneurin% man bash | wc -l
 	5947

Now there's a manpage that should have been split up...

On the same box:

     aneurin% man zsh | wc -l
 	 346

That's because it's got sub-pages, each describing a particular feature
(I've been using ZSH for years).

-- Dave

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 22:05                                     ` Dave Horsfall
  2019-09-16 22:33                                       ` reed
@ 2019-09-17  0:02                                       ` Nemo Nusquam
  2019-09-17  0:21                                         ` Arthur Krewat
  2019-09-17 11:12                                         ` Thomas Paulsen
  2019-09-17  0:46                                       ` Clem Cole
  2 siblings, 2 replies; 148+ messages in thread
From: Nemo Nusquam @ 2019-09-17  0:02 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

On 09/16/19 18:05, Dave Horsfall wrote:
> Am I the only one who remembers the old "pg" program? It seems to have
> disappeared.

Still ships with Solaris (in /usr/bin).

N.

^ permalink raw reply	[flat|nested] 148+ messages in thread

* [TUHS] O'Reilly groff macros (was:  earliest Unix roff)
  2019-09-16  6:20                             ` arnold
  2019-09-16 12:13                               ` Clem Cole
@ 2019-09-17  0:10                               ` Greg 'groggy' Lehey
  2019-09-17  0:51                                 ` Clem Cole
  1 sibling, 1 reply; 148+ messages in thread
From: Greg 'groggy' Lehey @ 2019-09-17  0:10 UTC (permalink / raw)
  To: arnold; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 1274 bytes --]

On Monday, 16 September 2019 at  0:20:46 -0600, arnold@skeeve.com wrote:
>> 1.  Do you think there is any chance of obtaining these macro packages?
>> Either from authors who haven't passed away, or from the publishing
>> houses themselves?
>
> O'Reilly probably would. I can ask someone there, if there's serious
> interest here.  They haven't used troff for book production for well
> over a decade.

The O'Reilly macro package was derived from the macros described in
Dougherty and O'Reilly "UNIX Text Processing" (Hayden 1988).  I
received a copy round 1993 for my book "Porting UNIX Software" (didn't
we shout in those days?), and when we released the book under Creative
Commons in 2005 or so, the macros were released with it.  It's
available online as
http://www.lemis.com/grog/Documentation/PUS/tmac.Gbignuts.G

In passing I should mention that they required me to use those
macros.  At the time I wanted to use TeX, but they were "unwilling".
I used groff, and I've never used TeX since: a dead baby duck.

Greg
--
Sent from my desktop computer.
Finger grog@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 22:33                                       ` reed
@ 2019-09-17  0:11                                         ` Dave Horsfall
  0 siblings, 0 replies; 148+ messages in thread
From: Dave Horsfall @ 2019-09-17  0:11 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Mon, 16 Sep 2019, reed@reedmedia.net wrote:

>> Am I the only one who remembers the old "pg" program?  It seems to have 
>> disappeared.
>
> I see two different pg. One in the 32V sources and the other first 
> Usenix delaware collection. (Both in TUHS archives)

We never ran 32V; our Vaxen - called "vaxa" and "vaxb" - ran VMS...  I was 
only in charge of the Unix PDP-11/40s sprinkled around the place (and the 
odd /34 and /23).

-- Dave

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 21:42                                 ` Dave Horsfall
  2019-09-16 21:48                                   ` Larry McVoy
@ 2019-09-17  0:16                                   ` Greg 'groggy' Lehey
  2019-09-17  0:31                                     ` Jon Steinhart
  2019-09-17 12:20                                     ` David
  1 sibling, 2 replies; 148+ messages in thread
From: Greg 'groggy' Lehey @ 2019-09-17  0:16 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]

On Tuesday, 17 September 2019 at  7:42:28 +1000, Dave Horsfall wrote:
> On Mon, 16 Sep 2019, Clem Cole wrote:
>
>> Fair enough, but be careful, while I admit I have not looked in a while,
>> info(gnu) relies on emacs keybindings and a number of very
>> emacs'ish things. Every time I have tried to deal with it, I have
>> unprogram my fingers and reset them to emacs.
>
> Yep, which is why I like "info" as much as I like EMACS i.e. not at
> all.

Maybe I've missed something, but I'm in the intermediate camp.  Emacs
is in my fingertips, and I wouldn't want to live without it, but I'd
far rather see info go away.  In some ways it anticipated HTML, but I
find navigation particularly painful.

> What exactly is wrong with the manpage format?

It's linear.

> It tells you everything you need to know, and tells you where to
> find further information.

Yes, but you need to follow the link manually.  Theoretically a good
HTML document would be better, but it's nice to have a linear form
that you can search.

For an extreme case of man pages, look at something like mplayer(1) or
mpv(1):

  $ man mplayer|wc -l
     9435
  $ man mpv|wc -l
     13939

That doesn't make them easy to read.

Greg
--
Sent from my desktop computer.
Finger grog@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-17  0:02                                       ` Nemo Nusquam
@ 2019-09-17  0:21                                         ` Arthur Krewat
  2019-09-17 11:12                                         ` Thomas Paulsen
  1 sibling, 0 replies; 148+ messages in thread
From: Arthur Krewat @ 2019-09-17  0:21 UTC (permalink / raw)
  To: tuhs

On 9/16/2019 8:02 PM, Nemo Nusquam wrote:
> On 09/16/19 18:05, Dave Horsfall wrote:
>> Am I the only one who remembers the old "pg" program? It seems to have
>> disappeared.
>
> Still ships with Solaris (in /usr/bin).

Now you've gone and said a bad word... ;)

art k.


^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-17  0:16                                   ` Greg 'groggy' Lehey
@ 2019-09-17  0:31                                     ` Jon Steinhart
  2019-09-17 12:20                                     ` David
  1 sibling, 0 replies; 148+ messages in thread
From: Jon Steinhart @ 2019-09-17  0:31 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Greg 'groggy' Lehey writes:
>
> Yes, but you need to follow the link manually.  Theoretically a good
> HTML document would be better, but it's nice to have a linear form
> that you can search.

Isn't "good HTML document" an oxymoron?

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 22:05                                     ` Dave Horsfall
  2019-09-16 22:33                                       ` reed
  2019-09-17  0:02                                       ` Nemo Nusquam
@ 2019-09-17  0:46                                       ` Clem Cole
  2 siblings, 0 replies; 148+ messages in thread
From: Clem Cole @ 2019-09-17  0:46 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 987 bytes --]

The USG pg program was created after UCB released more.  Btw this was
before vi or csh was distributed.  But too many BTL folks had seen BSD
during there OYOC year and either demanded it or had brought what was in
effect 2BSD back with them.

On Mon, Sep 16, 2019 at 6:06 PM Dave Horsfall <dave@horsfall.org> wrote:

> On Mon, 16 Sep 2019, Clem Cole wrote:
>
> > >       However, please note that more(1) also was inspired by, almost
> > >       copied from, ITS.  Certainly the prompt --More-- is.
> >
> > Absolutely.  A friend of mine/fellow UCB grad student, Eric Shienbrood,
> > wrote it.  He was a MIT undergrad. And Eric happily said it was modeled
> > from ITS. And before, Eric wrote it, UNIX lacked anything like it.
> >  Which to me is fine, taking an idea from another system to add a new
> > feature that is lacking.
>
> Am I the only one who remembers the old "pg" program?  It seems to have
> disappeared.
>
> -- Dave

-- 
Sent from a handheld expect more typos than usual

[-- Attachment #2: Type: text/html, Size: 1453 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] O'Reilly groff macros (was:  earliest Unix roff)
  2019-09-17  0:10                               ` [TUHS] O'Reilly groff macros (was: earliest Unix roff) Greg 'groggy' Lehey
@ 2019-09-17  0:51                                 ` Clem Cole
  2019-09-17  0:54                                   ` [TUHS] O'Reilly groff macros U'll Be King of the Stars
  0 siblings, 1 reply; 148+ messages in thread
From: Clem Cole @ 2019-09-17  0:51 UTC (permalink / raw)
  To: Greg 'groggy' Lehey; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 1603 bytes --]

FYI Which Dale and Tim used at Masscomp  4 years earlier.  That book was
originally modeled from Janet Eagans style guide which I still have.

On Mon, Sep 16, 2019 at 8:11 PM Greg 'groggy' Lehey <grog@lemis.com> wrote:

> On Monday, 16 September 2019 at  0:20:46 -0600, arnold@skeeve.com wrote:
> >> 1.  Do you think there is any chance of obtaining these macro packages?
> >> Either from authors who haven't passed away, or from the publishing
> >> houses themselves?
> >
> > O'Reilly probably would. I can ask someone there, if there's serious
> > interest here.  They haven't used troff for book production for well
> > over a decade.
>
> The O'Reilly macro package was derived from the macros described in
> Dougherty and O'Reilly "UNIX Text Processing" (Hayden 1988).  I
> received a copy round 1993 for my book "Porting UNIX Software" (didn't
> we shout in those days?), and when we released the book under Creative
> Commons in 2005 or so, the macros were released with it.  It's
> available online as
> http://www.lemis.com/grog/Documentation/PUS/tmac.Gbignuts.G
>
> In passing I should mention that they required me to use those
> macros.  At the time I wanted to use TeX, but they were "unwilling".
> I used groff, and I've never used TeX since: a dead baby duck.
>
> Greg
> --
> Sent from my desktop computer.
> Finger grog@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
>
-- 
Sent from a handheld expect more typos than usual

[-- Attachment #2: Type: text/html, Size: 2451 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] O'Reilly groff macros
  2019-09-17  0:51                                 ` Clem Cole
@ 2019-09-17  0:54                                   ` U'll Be King of the Stars
  2019-09-17  1:03                                     ` Clem Cole
  2019-09-17  1:41                                     ` Greg 'groggy' Lehey
  0 siblings, 2 replies; 148+ messages in thread
From: U'll Be King of the Stars @ 2019-09-17  0:54 UTC (permalink / raw)
  To: Clem Cole, Greg 'groggy' Lehey, arnold, tuhs

On 17/09/2019 01:51, Clem Cole wrote:
> FYI Which Dale and Tim used at Masscomp  4 years earlier.  That book was 
> originally modeled from Janet Eagans style guide which I still have.

I LOVE style guides.  I have a bit of a thing for them.

Was the Eagans guide published?  (Andrew shuffles off to Amazon.)

Andrew
-- 
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] O'Reilly groff macros
  2019-09-17  0:54                                   ` [TUHS] O'Reilly groff macros U'll Be King of the Stars
@ 2019-09-17  1:03                                     ` Clem Cole
  2019-09-17  1:41                                     ` Greg 'groggy' Lehey
  1 sibling, 0 replies; 148+ messages in thread
From: Clem Cole @ 2019-09-17  1:03 UTC (permalink / raw)
  To: U'll Be King of the Stars; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 785 bytes --]

No. It was given to all the Masscomp writers and of course all of Tims at
the beginning since we were his primary client in those days.  He had not
yet done the X11 books which was what made Tim’s business.

On Mon, Sep 16, 2019 at 8:54 PM U'll Be King of the Stars <
ullbeking@andrewnesbit.org> wrote:

> On 17/09/2019 01:51, Clem Cole wrote:
> > FYI Which Dale and Tim used at Masscomp  4 years earlier.  That book was
> > originally modeled from Janet Eagans style guide which I still have.
>
> I LOVE style guides.  I have a bit of a thing for them.
>
> Was the Eagans guide published?  (Andrew shuffles off to Amazon.)
>
> Andrew
> --
> OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9
>
-- 
Sent from a handheld expect more typos than usual

[-- Attachment #2: Type: text/html, Size: 1188 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] O'Reilly groff macros
  2019-09-17  0:54                                   ` [TUHS] O'Reilly groff macros U'll Be King of the Stars
  2019-09-17  1:03                                     ` Clem Cole
@ 2019-09-17  1:41                                     ` Greg 'groggy' Lehey
  2019-09-17  1:58                                       ` Clem cole
  1 sibling, 1 reply; 148+ messages in thread
From: Greg 'groggy' Lehey @ 2019-09-17  1:41 UTC (permalink / raw)
  To: U'll Be King of the Stars; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 896 bytes --]

On Tuesday, 17 September 2019 at  1:54:21 +0100, U'll Be King of the Stars wrote:
> On 17/09/2019 01:51, Clem Cole wrote:
>> FYI Which Dale and Tim used at Masscomp  4 years earlier.  That book was
>> originally modeled from Janet Eagans style guide which I still have.
>
> I LOVE style guides.  I have a bit of a thing for them.
>
> Was the Eagans guide published?  (Andrew shuffles off to Amazon.)

I didn't get it when I signed up with O'Reilly.  Instead they pointed
me at the Chicago Manual of Style, which got me interested in the idea
of style as well.  It's fascinating how much the individual guides
differ.

Greg
--
Sent from my desktop computer.
Finger grog@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] O'Reilly groff macros
  2019-09-17  1:41                                     ` Greg 'groggy' Lehey
@ 2019-09-17  1:58                                       ` Clem cole
  0 siblings, 0 replies; 148+ messages in thread
From: Clem cole @ 2019-09-17  1:58 UTC (permalink / raw)
  To: Greg 'groggy' Lehey; +Cc: tuhs

If I was not clear, Janet’s document was for Masscomp.  But the a number of Ora folks all had it like Talbot, Dale, Tim and Cindy     

After the merger ( I had left by then as had Janet) a large number of Janet’s original team followed Tim and became his original core in Cambridge.  

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

> On Sep 16, 2019, at 9:41 PM, Greg 'groggy' Lehey <grog@lemis.com> wrote:
> 
>> On Tuesday, 17 September 2019 at  1:54:21 +0100, U'll Be King of the Stars wrote:
>>> On 17/09/2019 01:51, Clem Cole wrote:
>>> FYI Which Dale and Tim used at Masscomp  4 years earlier.  That book was
>>> originally modeled from Janet Eagans style guide which I still have.
>> 
>> I LOVE style guides.  I have a bit of a thing for them.
>> 
>> Was the Eagans guide published?  (Andrew shuffles off to Amazon.)
> 
> I didn't get it when I signed up with O'Reilly.  Instead they pointed
> me at the Chicago Manual of Style, which got me interested in the idea
> of style as well.  It's fascinating how much the individual guides
> differ.
> 
> Greg
> --
> Sent from my desktop computer.
> Finger grog@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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 21:59                                       ` Larry McVoy
@ 2019-09-17  5:07                                         ` Lars Brinkhoff
  0 siblings, 0 replies; 148+ messages in thread
From: Lars Brinkhoff @ 2019-09-17  5:07 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

Larry McVoy wrote:
> My comment on the info stuff was just my understand of why it came to be.

Probably no one knows any more.

Quick history recap:

- First there was the old plain text INFO which was more like Unix' man.
- Then there was the new hypertext INFO built on EMACS.
- GNU info copied ITS' INFO.

When I ask ITS people about this old plain text INFO, they don't even
remember it.

I think it's reasonable to assume they thought the new hypertext format
with links was more intriguing technology than plain text files.

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 14:51                                 ` Larry McVoy
  2019-09-16 14:57                                   ` Clem Cole
@ 2019-09-17  7:53                                   ` arnold
  2019-09-17 14:21                                     ` Clem Cole
  2019-09-17 15:58                                     ` Christopher Browne
  1 sibling, 2 replies; 148+ messages in thread
From: arnold @ 2019-09-17  7:53 UTC (permalink / raw)
  To: lm, clemc; +Cc: tuhs

It is like clockwork.

Whenever I say something about Texinfo *as a markup language* for use
in *writing books*, the discussion inevitably degenerates into a hate
rant against Info and RMS's (failed) attempt to replace man pages.
Totally missing the point too.

This is a trend on TUHS.  The same discussions, the same rants, often
the same misinformation, over and over and over again.

I start to wonder if I should continue to subscribe.

Arnold

Larry McVoy <lm@mcvoy.com> wrote:

> On Mon, Sep 16, 2019 at 08:10:48AM -0400, Clem Cole wrote:
> > On Mon, Sep 16, 2019 at 1:52 AM <arnold@skeeve.com> wrote:
> > 
> > > I use the standalone Info reader (named info) if I want to look at the
> > > Info output.
> > >
> > Fair enough, but be careful, while I admit I have not looked in a while,
> > info(gnu) relies on emacs keybindings and a number of very emacs'ish things.
> > Every time I have tried to deal with it, I have unprogram my fingers and
> > reset them to emacs.
> > 
> > If it would have used more(1) [or even less(1)] then I would not be as
> > annoyed.
> > Unix had fine tools [man(1), more(1), et al] and rms and friends felt the
> > need to replace them with ITS-like programs.
>
> I hate texinfo and friends.  I get why it is better than man, but man was
> good enough, more than good enough, and the GNU project took everything
> it could find and destroyed the man pages.
>
> If you have something like perl that needs a zillion sub pages, info
> makes sense.  For just a man page, info is horrible.

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-17  0:02                                       ` Nemo Nusquam
  2019-09-17  0:21                                         ` Arthur Krewat
@ 2019-09-17 11:12                                         ` Thomas Paulsen
  1 sibling, 0 replies; 148+ messages in thread
From: Thomas Paulsen @ 2019-09-17 11:12 UTC (permalink / raw)
  To: Nemo Nusquam; +Cc: tuhs



Nemo Nusquam wrote:
> On 09/16/19 18:05, Dave Horsfall wrote:
> > Am I the only one who remembers the old "pg" program? It seems
> to have disappeared.
>
> Still ships with Solaris (in /usr/bin).
the sources can be found at Jorg Schillings sourceforge site.



^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 16:10                                       ` Larry McVoy
  2019-09-16 16:16                                         ` Jon Steinhart
@ 2019-09-17 11:20                                         ` Thomas Paulsen
  1 sibling, 0 replies; 148+ messages in thread
From: Thomas Paulsen @ 2019-09-17 11:20 UTC (permalink / raw)
  To: Larry McVoy; +Cc: tuhs


 Larry McVoy <lm@mcvoy.com> wrote:
>
> It's what Clem said.  You should acclimate yourself to your environment.
> Pushing info into man environment is a lot like being an immigrant and
> wanting to bring your laws into your new homeland.  That isn't a thing
> and shouldn't be a thing.  Doesn't matter that people think ITS is better,
> they are in Unix.  If you think ITS is better, go live there.
> When in Rome....
>
info failed (as well as texinfo). Hardly anybody using it, beside notorious emacs maniacs like me.  Rome doesn't like it.



^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary)
  2019-09-16 20:21                   ` G. Branden Robinson
  2019-09-16 20:47                     ` Jon Steinhart
@ 2019-09-17 11:46                     ` Theodore Y. Ts'o
  2019-09-17 12:52                       ` G. Branden Robinson
  1 sibling, 1 reply; 148+ messages in thread
From: Theodore Y. Ts'o @ 2019-09-17 11:46 UTC (permalink / raw)
  To: G. Branden Robinson; +Cc: tuhs

On Tue, Sep 17, 2019 at 06:21:56AM +1000, G. Branden Robinson wrote:
> It's still common today.  Everything the developer cares to think about,
> let alone test on, interprets EMCA-48 SGR escape sequences.  My favorite
> recent example is "spectre-meltdown-checker", which has such edifying
> lines as:
> 
>         _info_nol "> \033[46m\033[30mSTATUS:\033[0m "
> 
> Why write something portable when you can be "close to the metal"?  :-/

To be fair, spectre-multdown-checker is a shell script, and while you
can use tput, that's not super-portable (some versions take termcap
names, some take terminfo names, and the only thing that has been
standardized is "init", "clear", and "reset"), and said script was
designed to work on Linux and *BSD systems.

					- Ted

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-17  0:16                                   ` Greg 'groggy' Lehey
  2019-09-17  0:31                                     ` Jon Steinhart
@ 2019-09-17 12:20                                     ` David
  1 sibling, 0 replies; 148+ messages in thread
From: David @ 2019-09-17 12:20 UTC (permalink / raw)
  To: Greg 'groggy' Lehey; +Cc: The Eunuchs Hysterical Society


> On Sep 16, 2019, at 5:16 PM, Greg 'groggy' Lehey <grog@lemis.com> wrote:
> 
> For an extreme case of man pages, look at something like mplayer(1) or
> mpv(1):
> 
>  $ man mplayer|wc -l
>     9435
>  $ man mpv|wc -l
>     13939
> 
Those aren’t man pages, they are novellas.

	David


^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary)
  2019-09-17 11:46                     ` [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview " Theodore Y. Ts'o
@ 2019-09-17 12:52                       ` G. Branden Robinson
  0 siblings, 0 replies; 148+ messages in thread
From: G. Branden Robinson @ 2019-09-17 12:52 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 1329 bytes --]

At 2019-09-17T07:46:02-0400, Theodore Y. Ts'o wrote:
> To be fair, spectre-multdown-checker is a shell script, and while you
> can use tput, that's not super-portable (some versions take termcap
> names, some take terminfo names, and the only thing that has been
> standardized is "init", "clear", and "reset"),

Now that you mention it I do remember Thomas Dickey saying that at some
point.

> and said script was designed to work on Linux and *BSD systems.

In that case I'd query tput through a function that got defined
differently based on the output of uname, or tput's own version string
output if it could be coaxed into giving me one (Dickey's ncurses tput
supports -V for this purpose; I don't know about the BSDs).

The thrust is to get that egregious noise out of the output strings as
written in the source file so as to preserve their human-readability.

Better this:
	echo "${fg_black}${bg_cyan}STATUS:${normal}"
Than:
	echo "\033[30m\033[43mSTATUS\033[m"

...in which am I more likely to notice typos?  Given an editor that
lexically analyzes your shell script[1], which is more likely to
integrate well with a spell-checker?

Regards,
Branden

[1] Okay, so that turns out to be nearly impossible, at least if you
want to recognize every possible construct[2].

[2] https://hal.archives-ouvertes.fr/hal-01890044/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-17  7:53                                   ` arnold
@ 2019-09-17 14:21                                     ` Clem Cole
  2019-09-17 15:03                                       ` arnold
  2019-09-17 15:58                                     ` Christopher Browne
  1 sibling, 1 reply; 148+ messages in thread
From: Clem Cole @ 2019-09-17 14:21 UTC (permalink / raw)
  To: Aharon Robbins; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 2330 bytes --]

Fair enough.  Mei culpa from one of those that was vocal.  That said, maybe
a trick is to stay away from texinfo/info and the man page discussion on
this list since its a hot button that causes much trama for some with a
more traditional UNIX view.

Please don't leave, your voice is important and I generally agree with you
and always like to hear you out.  But even if I do not agree, I still want
to listen.  You have come to your conclusions in a different manner than
some of us, and where each of us puts the MSB tends to color our views.
Diversity of opinion is a good thing.

Respectfully,
Clem
ᐧ

On Tue, Sep 17, 2019 at 3:53 AM <arnold@skeeve.com> wrote:

> It is like clockwork.
>
> Whenever I say something about Texinfo *as a markup language* for use
> in *writing books*, the discussion inevitably degenerates into a hate
> rant against Info and RMS's (failed) attempt to replace man pages.
> Totally missing the point too.
>
> This is a trend on TUHS.  The same discussions, the same rants, often
> the same misinformation, over and over and over again.
>
> I start to wonder if I should continue to subscribe.
>
> Arnold
>
> Larry McVoy <lm@mcvoy.com> wrote:
>
> > On Mon, Sep 16, 2019 at 08:10:48AM -0400, Clem Cole wrote:
> > > On Mon, Sep 16, 2019 at 1:52 AM <arnold@skeeve.com> wrote:
> > >
> > > > I use the standalone Info reader (named info) if I want to look at
> the
> > > > Info output.
> > > >
> > > Fair enough, but be careful, while I admit I have not looked in a
> while,
> > > info(gnu) relies on emacs keybindings and a number of very emacs'ish
> things.
> > > Every time I have tried to deal with it, I have unprogram my fingers
> and
> > > reset them to emacs.
> > >
> > > If it would have used more(1) [or even less(1)] then I would not be as
> > > annoyed.
> > > Unix had fine tools [man(1), more(1), et al] and rms and friends felt
> the
> > > need to replace them with ITS-like programs.
> >
> > I hate texinfo and friends.  I get why it is better than man, but man was
> > good enough, more than good enough, and the GNU project took everything
> > it could find and destroyed the man pages.
> >
> > If you have something like perl that needs a zillion sub pages, info
> > makes sense.  For just a man page, info is horrible.
>

[-- Attachment #2: Type: text/html, Size: 3490 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-17 14:21                                     ` Clem Cole
@ 2019-09-17 15:03                                       ` arnold
  0 siblings, 0 replies; 148+ messages in thread
From: arnold @ 2019-09-17 15:03 UTC (permalink / raw)
  To: clemc, arnold; +Cc: tuhs

Yes, I think the next time anyone says anything about markup languages,
I'll just use private mail.

Thanks,

Arnold

Clem Cole <clemc@ccc.com> wrote:

> Fair enough.  Mei culpa from one of those that was vocal.  That said, maybe
> a trick is to stay away from texinfo/info and the man page discussion on
> this list since its a hot button that causes much trama for some with a
> more traditional UNIX view.
>
> Please don't leave, your voice is important and I generally agree with you
> and always like to hear you out.  But even if I do not agree, I still want
> to listen.  You have come to your conclusions in a different manner than
> some of us, and where each of us puts the MSB tends to color our views.
> Diversity of opinion is a good thing.
>
> Respectfully,
> Clem
> ᐧ
>
> On Tue, Sep 17, 2019 at 3:53 AM <arnold@skeeve.com> wrote:
>
> > It is like clockwork.
> >
> > Whenever I say something about Texinfo *as a markup language* for use
> > in *writing books*, the discussion inevitably degenerates into a hate
> > rant against Info and RMS's (failed) attempt to replace man pages.
> > Totally missing the point too.
> >
> > This is a trend on TUHS.  The same discussions, the same rants, often
> > the same misinformation, over and over and over again.
> >
> > I start to wonder if I should continue to subscribe.
> >
> > Arnold
> >
> > Larry McVoy <lm@mcvoy.com> wrote:
> >
> > > On Mon, Sep 16, 2019 at 08:10:48AM -0400, Clem Cole wrote:
> > > > On Mon, Sep 16, 2019 at 1:52 AM <arnold@skeeve.com> wrote:
> > > >
> > > > > I use the standalone Info reader (named info) if I want to look at
> > the
> > > > > Info output.
> > > > >
> > > > Fair enough, but be careful, while I admit I have not looked in a
> > while,
> > > > info(gnu) relies on emacs keybindings and a number of very emacs'ish
> > things.
> > > > Every time I have tried to deal with it, I have unprogram my fingers
> > and
> > > > reset them to emacs.
> > > >
> > > > If it would have used more(1) [or even less(1)] then I would not be as
> > > > annoyed.
> > > > Unix had fine tools [man(1), more(1), et al] and rms and friends felt
> > the
> > > > need to replace them with ITS-like programs.
> > >
> > > I hate texinfo and friends.  I get why it is better than man, but man was
> > > good enough, more than good enough, and the GNU project took everything
> > > it could find and destroyed the man pages.
> > >
> > > If you have something like perl that needs a zillion sub pages, info
> > > makes sense.  For just a man page, info is horrible.
> >

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-17  7:53                                   ` arnold
  2019-09-17 14:21                                     ` Clem Cole
@ 2019-09-17 15:58                                     ` Christopher Browne
  2019-09-17 18:15                                       ` arnold
  1 sibling, 1 reply; 148+ messages in thread
From: Christopher Browne @ 2019-09-17 15:58 UTC (permalink / raw)
  To: arnold, The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1962 bytes --]

On Tue, Sep 17, 2019, 3:54 AM <arnold@skeeve.com> wrote:

> It is like clockwork.
>
> Whenever I say something about Texinfo *as a markup language* for use
> in *writing books*, the discussion inevitably degenerates into a hate
> rant against Info and RMS's (failed) attempt to replace man pages.
> Totally missing the point too.
>

Yeah, that is a pain in the neck.

I had the other reaction to this...

I have been managing my web presence via DocBook SGML for a goodly long
time.  It is, as mentioned upthread, pretty wordy what with all the verbose
tagging.

It would be worth something to be able to edit it in TeXinfo form, with the
lesser amount of tagging required.  (And I'd kinda like to get off of
DocBook/SGML one of these days as the toolset is clearly mouldering away
pretty badly.)

So my reaction to your comments was to look into the usability of
TeXinfo...  I did a wee experiment yesterday, attempting to use docbook2x
to get to something else.  Alas, it seems to want to use xsltproc on the
XML form, and the transformation to XML is apparently a separate pain in
the neck.  I thought I accomplished it, but the XSLT for generating TeXinfo
throws up on it, so there must be more to the matter.  I'll take a further
poke at it later; thank you for offering a bit of inspiration on possible
approaches to change.

I know I can turn DocBook into s-expressions, and then write some
transformation in CL after that; it would be nice if there were something
already written.

For sophisticated material, TeXinfo is of use, notwithstanding notions to
make everything into brief man pages.

Bashing RMS for wanting things from ITS (and probably Multics too) (as I
see elsewhere in the thread) is unnecessarily unkind.  A dogmatic attitude
of "must be short man pages" shifts us to a different Procrustean bed that
fails in a different set of cases.  I for one was kinda hoping for Project
Xanadu someday, to throw a different perspective on that.

>

[-- Attachment #2: Type: text/html, Size: 2867 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-17 15:58                                     ` Christopher Browne
@ 2019-09-17 18:15                                       ` arnold
  2019-09-17 18:32                                         ` Warner Losh
  2019-09-18  0:42                                         ` Adam Thornton
  0 siblings, 2 replies; 148+ messages in thread
From: arnold @ 2019-09-17 18:15 UTC (permalink / raw)
  To: tuhs, cbbrowne, arnold

Hi.

Christopher Browne <cbbrowne@gmail.com> wrote:
> I had the other reaction to this...
>
> I have been managing my web presence via DocBook SGML for a goodly long
> time.  It is, as mentioned upthread, pretty wordy what with all the verbose
> tagging.
>
> It would be worth something to be able to edit it in TeXinfo form, with the
> lesser amount of tagging required.  (And I'd kinda like to get off of
> DocBook/SGML one of these days as the toolset is clearly mouldering away
> pretty badly.)

Looks like pandoc will go from DocBook to Texinfo.

Me, I'd probably write a giant awk script to do the grunt work. :-)

> For sophisticated material, TeXinfo is of use, notwithstanding notions to
> make everything into brief man pages.

As I've been saying, I use it for books.

Good luck,

Arnold

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-17 18:15                                       ` arnold
@ 2019-09-17 18:32                                         ` Warner Losh
  2019-09-18  0:42                                         ` Adam Thornton
  1 sibling, 0 replies; 148+ messages in thread
From: Warner Losh @ 2019-09-17 18:32 UTC (permalink / raw)
  To: Arnold Robbins; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 832 bytes --]

On Tue, Sep 17, 2019 at 12:16 PM <arnold@skeeve.com> wrote:

> Hi.
>
> Christopher Browne <cbbrowne@gmail.com> wrote:
> > I had the other reaction to this...
> >
> > I have been managing my web presence via DocBook SGML for a goodly long
> > time.  It is, as mentioned upthread, pretty wordy what with all the
> verbose
> > tagging.
> >
> > It would be worth something to be able to edit it in TeXinfo form, with
> the
> > lesser amount of tagging required.  (And I'd kinda like to get off of
> > DocBook/SGML one of these days as the toolset is clearly mouldering away
> > pretty badly.)
>
> Looks like pandoc will go from DocBook to Texinfo.
>
> Me, I'd probably write a giant awk script to do the grunt work. :-)
>

FreeBSD likely is moving out DocBook stuff to markdown. Docbook is too hard
to find people to work on :(

Warner

[-- Attachment #2: Type: text/html, Size: 1334 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
  2019-09-13 20:06     ` Clem Cole
  2019-09-13 20:24       ` Jon Steinhart
  2019-09-13 21:31       ` Clem Cole
@ 2019-09-17 19:18       ` Warner Losh
  2019-09-17 20:13         ` Clem Cole
  2 siblings, 1 reply; 148+ messages in thread
From: Warner Losh @ 2019-09-17 19:18 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 9081 bytes --]

On Fri, Sep 13, 2019 at 2:07 PM Clem Cole <clemc@ccc.com> wrote:

> Another thought -- the first commercial licensee was Rand.   Hired some
> former Harvard students who brought UNIX with them.   You probably need to
> add things like Rand Ports (a.k.a. named pipes) which came from there.
> Also Chesson and Co did the original ArpaNET NCP at University of Ill
> with some help from the Rand folks.   That was done on a V6 system ~ 1978
>

When I worked at The Wollongong Group they were quite specific that they
had their license from V6 days, that it was a one-off that has unusually
favorable terms, and that it was the first licensee. But that may be the
first license to redistribute, rather than the first commercial user to be
licensed...  I think for an expanded version of my talk, I'd include the
other details, since there's both the NCP work and some TCP work with v7 in
our archive these days. I'll add a bullet point for these things. V6/V7 is
the time that derivatives and add-ons really start to appear in relative
abundance.

You also need need Ken's famous V6 'patch' tape -- that 'leaked'
>

I'll see if I can work that in.. Is that the famous '50 patches' or is that
something else?

On Fri, Sep 13, 2019 at 4:02 PM Clem Cole <clemc@ccc.com> wrote:
>
>> BTW:  I just thought of something else....  one of the b*tched about the
>> commercial redistribution license from V7 in 1979, that was not fixed until
>> the SVR3 licensing the mid-late 1980s  was AT&T's source policy.   As I
>> said, a commercial source license was $20K for the first CPU and 5K for
>> each additional one.   Later (System V) it went to $50K for the first and
>> $10K for each additional.   But what really ticked off the vendors like
>> DEC, Masscomp, Sun et al, was that each system that sources on was supposed
>> to one of the 'second CPU licenses' - the binary license was not good
>> enough.
>>
>> What most of us did, was make sure any system that was a 'source control'
>> or 'master' system at any 'site' had a full source license, but we were all
>> in violation of the source agreement on our personal workstations.  The
>> argument was the sources on people's machines was ephemeral and not
>> 'stored' there.   But it was definitely contentious.
>>
>
Yea, I think that all these details are (a) interesting but (b) not quite
right for this talk...

Warner


> On Fri, Sep 13, 2019 at 3:47 PM Clem Cole <clemc@ccc.com> wrote:
>>
>>> slide 4 --  All of HP-UX, Ultrix and Digital UNIX/Tru64 are BSD
>>> kernels.  HP-UP and Tru64 support System V calls.
>>>
>>> BTW:  DG-UX and Stratus built their own kernels, but used System V
>>> command systems and System Call definitions - which are not listed.
>>>
>>> Slide 6 - if you want it I have another picture of the GE system from
>>> some of their literature has a view of all of the components.   Send me
>>> email if you want it.
>>>
>>> Slide 8 - Sets out to write version of Fortran came up with B.  Uses B
>>> to write Assembler
>>>
>>> Slide 9 - Wrong DEC logo.  Should be the Blue one.  The maroon version
>>> does not show up until the 1990s with Bob Palmer (and has bad memories for
>>> some of us).
>>>
>>> Slide 17 - Ken write PDP-11 assembler on PDP-7 in B. , Dennis starts to
>>> rewrite B compiler to output PDP-11 code.
>>>
>>> Slide 18 - B begins to become different enough that Dennis starts to
>>> call it nb [new B], eventually deviates enough to become new language
>>>
>>> Slide 19 - 4th Edition release outside of the BTL.  Lou Katz
>>> becomes 'user zero'
>>>
>>> Slide 20 -- We need to get you the site and group name from Mash.  It
>>> was not in Summit, it was not USG - but was in NJ.  I thought it was Homdel
>>> but I that is purely speculation.
>>>                   Also the role of Columbus team needs to be defined.
>>>  Ask Mary Ann.
>>>
>>> Slide 21 -- I'm not going to argue - but I would ask you to add a
>>> disclaimer.   This is what you could reconstruct, but there is some
>>> question of some of the arrows.   Heinz might be able to help, but as
>>> Stienhart and I have said, its believed to be in LA; but no one has tracked
>>> him down as he has been pursuing non-computer interests.
>>>
>>> Slide 22 --4th Edition went to Katz that this is wrong, who sometimes
>>> reads this mailing list.  If not, send me a note, I'll reintroduce you.  He
>>> might be able to give you a data.  Check with Warren, my >>memory<< is that
>>> some of userland is still in C although a lot assembler is still there.
>>>
>>> Slide 23 -- ??widespread??   -- I'm not sure I would use that. Not even
>>> 100 sites yet.     Also there were not "commercial version" this was the
>>> first "commercial license" -- big difference [contact me if you want
>>> explanation].  IIRC fee was 15K per CPU.  Commercial redistribution doesn't
>>> occur until after 7th is released and was a separate license.   I would
>>> add, Mike Lesk's portable C library is starting to be used, but most C
>>> program do their own I/O with read/write
>>>
>>>           First real install man page and Dennis build tape installation
>>> system.   Earlier version released as RK05 disk copies.
>>>            Also numerous new peripherals. IIRC Support for the 11/40
>>> starts here, 4th & 5th needed a 45 class, and earlier used the 20 with the
>>> CSS MMU.
>>>
>>> Slide 24 -- CMU uses it to teaches OS class.  makes student in class
>>> sign a sub-license.
>>>
>>> Slide 25 - missing the first USENIX tapes. which include Harvard and the
>>> like.  Warren and I can probably help a little here.
>>>
>>> Slide 26 - new licenses.  Commercial license fees change to 20K for 1st
>>> CPU/5K for each CPU afterward.  CMU buys first commercial license to use
>>> UNIX to make money [after Cole and Klein go on strike].  Case Western
>>> follows suit 6month later.   AT&T agrees for the Universities that they
>>> only had to declare one CPU as commercial and could intermix otherwise and
>>> notifies all the universities that if they were using it for commercial
>>> purposes, then needed a license.
>>>
>>> AT&T creates first redistribution license.  Needed at least one $20K
>>> commercial CPU and then $150k for the rights to redistribute.   Originally
>>> $1K per binary CPU.
>>>
>>> Slide 27 -- missing Purdue Dual Vax and CMU Mach
>>>
>>> Slide 28 - APS had NH which was the model the DEC plate you show.
>>>  Maddog has it now on his Jeep when aps moved to CA (he also has the NH
>>> Linux plate but I don't remember the car -- you can ask him).   I have had
>>> the Massachusetts UNIX plate since 1983 (it's on my model S of course).
>>>  ghg has indiana from around the same time (I think on a pickup).  wnj had
>>> the CA vmunix on his Ferrari, but I don't know if he still has it or what
>>> its on.
>>>
>>> Slide 29 - Look in HenrySpencer-TUHS.org -- you'll find tail but not
>>> head.
>>>
>>> Slide 31 - Job Control can from Europe via MIT.  Jim Kulp wrote it.
>>>  Noel and I can give you the story if you want it.  It was on the PDP-11
>>> there.   Joy modified csh and added it to 4.1
>>>
>>> Slide 32 -- JC was not from UCB.   Joy got it from MIT   -- Dennis
>>> create ENV and it was first distributed in V7.
>>>
>>> Slide 33 -- No Bourne supported ENV in the new shell -- see me earlier
>>> email for how all this went down or ask Steve yourself.
>>>
>>> Slide 34 -- PCC was included, but the Ritchie Compiler (a.k.a.
>>> Typesetter C) was the default compiler.  You are missing a step BTW --
>>> typesetter C was released between V6 and V7.   As is the first draft of the
>>> White Book.  The new compiler had stdio but targets V6.
>>> Also mpx was part of DataKit support.
>>>
>>> Slide 35 --   Not sure that is true.   I thought Microsoft's Xenix ships
>>> before Venix.    Particularly since you made the comment about System III
>>> The original 8086 Xenix was a pure V7 port, with a few additions Gordon
>>> brought with him from Purdue (i.e. ghg hacks).
>>>
>>> Slide 52/53/54/55 -- wrong logo (see above)
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Sep 12, 2019 at 11:21 PM Warner Losh <imp@bsdimp.com> wrote:
>>>
>>>> OK. I've shared my slides for the talk.
>>>>
>>>> Some of the family trees are simplified (V7 doesn't have room for all
>>>> its ports, for example)
>>>> Some of it is a little cheeseball since I'm also trying to be witty and
>>>> entertaining (we'll see how that goes).
>>>> Please don't share them around until after my talk on the September 20th
>>>>
>>>> I'd like feedback on the bits I got wrong. Or left out. Or if you're in
>>>> this and don't want to be, etc.
>>>>
>>>> All the slides after the Questions slide won't be presented and will
>>>> likely be deleted.
>>>>
>>>>
>>>> https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing
>>>>
>>>> Please be kind (but if it sucks, please do tell). I've turned on
>>>> commenting on the slides. Probably best if you comment there.
>>>>
>>>> I have a video of me giving this talk, but it's too rough to share...
>>>>
>>>> Thanks for any help you can give me.
>>>>
>>>> Warner
>>>>
>>>

[-- Attachment #2: Type: text/html, Size: 16561 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
  2019-09-13 21:31       ` Clem Cole
@ 2019-09-17 19:29         ` Warner Losh
  2019-09-17 20:17           ` Clem Cole
  0 siblings, 1 reply; 148+ messages in thread
From: Warner Losh @ 2019-09-17 19:29 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 9422 bytes --]

On Fri, Sep 13, 2019 at 3:31 PM Clem Cole <clemc@ccc.com> wrote:

> BTW: I just found my PWB 1.0 manual.   The date is May 1977, authors are
> T. (Ted) Dolotta, R. (Dick) Haight and E. Piskorik
> and it lists the site as 'Piscataway' as the site on the
> acknowlegements page.
>

Yes. That's the first release of PWB. However, they took delivery of their
first PDP-11 in 1973, which is when the PWB efforts began as part of the
BIS or BISP business unit (I have conflicting sources on the exact name).

After my talk is complete, I'd planned on going back and trying to piece
together release timelines as well, since although efforts happened
starting in 73, releases, as such, don't seem to start for another couple
of years. I suspect that when the number of groups being supported was
small, the overhead of a formal release cycle likely wasn't worth the
benefits (but have no documentation from the early days to prove that).

Warner


> On Fri, Sep 13, 2019 at 4:06 PM Clem Cole <clemc@ccc.com> wrote:
>
>> Another thought -- the first commercial licensee was Rand.   Hired some
>> former Harvard students who brought UNIX with them.   You probably need to
>> add things like Rand Ports (a.k.a. named pipes) which came from there.
>> Also Chesson and Co did the original ArpaNET NCP at University of Ill
>> with some help from the Rand folks.   That was done on a V6 system ~ 1978
>>
>> You also need need Ken's famous V6 'patch' tape -- that 'leaked'
>>
>>
>> On Fri, Sep 13, 2019 at 4:02 PM Clem Cole <clemc@ccc.com> wrote:
>>
>>> BTW:  I just thought of something else....  one of the b*tched about the
>>> commercial redistribution license from V7 in 1979, that was not fixed until
>>> the SVR3 licensing the mid-late 1980s  was AT&T's source policy.   As I
>>> said, a commercial source license was $20K for the first CPU and 5K for
>>> each additional one.   Later (System V) it went to $50K for the first and
>>> $10K for each additional.   But what really ticked off the vendors like
>>> DEC, Masscomp, Sun et al, was that each system that sources on was supposed
>>> to one of the 'second CPU licenses' - the binary license was not good
>>> enough.
>>>
>>> What most of us did, was make sure any system that was a 'source
>>> control' or 'master' system at any 'site' had a full source license, but we
>>> were all in violation of the source agreement on our personal
>>> workstations.  The argument was the sources on people's machines was
>>> ephemeral and not 'stored' there.   But it was definitely contentious.
>>>
>>>
>>>
>>> On Fri, Sep 13, 2019 at 3:47 PM Clem Cole <clemc@ccc.com> wrote:
>>>
>>>> slide 4 --  All of HP-UX, Ultrix and Digital UNIX/Tru64 are BSD
>>>> kernels.  HP-UP and Tru64 support System V calls.
>>>>
>>>> BTW:  DG-UX and Stratus built their own kernels, but used System V
>>>> command systems and System Call definitions - which are not listed.
>>>>
>>>> Slide 6 - if you want it I have another picture of the GE system from
>>>> some of their literature has a view of all of the components.   Send me
>>>> email if you want it.
>>>>
>>>> Slide 8 - Sets out to write version of Fortran came up with B.  Uses B
>>>> to write Assembler
>>>>
>>>> Slide 9 - Wrong DEC logo.  Should be the Blue one.  The maroon version
>>>> does not show up until the 1990s with Bob Palmer (and has bad memories for
>>>> some of us).
>>>>
>>>> Slide 17 - Ken write PDP-11 assembler on PDP-7 in B. , Dennis starts to
>>>> rewrite B compiler to output PDP-11 code.
>>>>
>>>> Slide 18 - B begins to become different enough that Dennis starts to
>>>> call it nb [new B], eventually deviates enough to become new language
>>>>
>>>> Slide 19 - 4th Edition release outside of the BTL.  Lou Katz
>>>> becomes 'user zero'
>>>>
>>>> Slide 20 -- We need to get you the site and group name from Mash.  It
>>>> was not in Summit, it was not USG - but was in NJ.  I thought it was Homdel
>>>> but I that is purely speculation.
>>>>                   Also the role of Columbus team needs to be defined.
>>>>  Ask Mary Ann.
>>>>
>>>> Slide 21 -- I'm not going to argue - but I would ask you to add a
>>>> disclaimer.   This is what you could reconstruct, but there is some
>>>> question of some of the arrows.   Heinz might be able to help, but as
>>>> Stienhart and I have said, its believed to be in LA; but no one has tracked
>>>> him down as he has been pursuing non-computer interests.
>>>>
>>>> Slide 22 --4th Edition went to Katz that this is wrong, who sometimes
>>>> reads this mailing list.  If not, send me a note, I'll reintroduce you.  He
>>>> might be able to give you a data.  Check with Warren, my >>memory<< is that
>>>> some of userland is still in C although a lot assembler is still there.
>>>>
>>>> Slide 23 -- ??widespread??   -- I'm not sure I would use that. Not even
>>>> 100 sites yet.     Also there were not "commercial version" this was the
>>>> first "commercial license" -- big difference [contact me if you want
>>>> explanation].  IIRC fee was 15K per CPU.  Commercial redistribution doesn't
>>>> occur until after 7th is released and was a separate license.   I would
>>>> add, Mike Lesk's portable C library is starting to be used, but most C
>>>> program do their own I/O with read/write
>>>>
>>>>           First real install man page and Dennis build tape
>>>> installation system.   Earlier version released as RK05 disk copies.
>>>>            Also numerous new peripherals. IIRC Support for the 11/40
>>>> starts here, 4th & 5th needed a 45 class, and earlier used the 20 with the
>>>> CSS MMU.
>>>>
>>>> Slide 24 -- CMU uses it to teaches OS class.  makes student in class
>>>> sign a sub-license.
>>>>
>>>> Slide 25 - missing the first USENIX tapes. which include Harvard and
>>>> the like.  Warren and I can probably help a little here.
>>>>
>>>> Slide 26 - new licenses.  Commercial license fees change to 20K for 1st
>>>> CPU/5K for each CPU afterward.  CMU buys first commercial license to use
>>>> UNIX to make money [after Cole and Klein go on strike].  Case Western
>>>> follows suit 6month later.   AT&T agrees for the Universities that they
>>>> only had to declare one CPU as commercial and could intermix otherwise and
>>>> notifies all the universities that if they were using it for commercial
>>>> purposes, then needed a license.
>>>>
>>>> AT&T creates first redistribution license.  Needed at least one $20K
>>>> commercial CPU and then $150k for the rights to redistribute.   Originally
>>>> $1K per binary CPU.
>>>>
>>>> Slide 27 -- missing Purdue Dual Vax and CMU Mach
>>>>
>>>> Slide 28 - APS had NH which was the model the DEC plate you show.
>>>>  Maddog has it now on his Jeep when aps moved to CA (he also has the NH
>>>> Linux plate but I don't remember the car -- you can ask him).   I have had
>>>> the Massachusetts UNIX plate since 1983 (it's on my model S of course).
>>>>  ghg has indiana from around the same time (I think on a pickup).  wnj had
>>>> the CA vmunix on his Ferrari, but I don't know if he still has it or what
>>>> its on.
>>>>
>>>> Slide 29 - Look in HenrySpencer-TUHS.org -- you'll find tail but not
>>>> head.
>>>>
>>>> Slide 31 - Job Control can from Europe via MIT.  Jim Kulp wrote it.
>>>>  Noel and I can give you the story if you want it.  It was on the PDP-11
>>>> there.   Joy modified csh and added it to 4.1
>>>>
>>>> Slide 32 -- JC was not from UCB.   Joy got it from MIT   -- Dennis
>>>> create ENV and it was first distributed in V7.
>>>>
>>>> Slide 33 -- No Bourne supported ENV in the new shell -- see me earlier
>>>> email for how all this went down or ask Steve yourself.
>>>>
>>>> Slide 34 -- PCC was included, but the Ritchie Compiler (a.k.a.
>>>> Typesetter C) was the default compiler.  You are missing a step BTW --
>>>> typesetter C was released between V6 and V7.   As is the first draft of the
>>>> White Book.  The new compiler had stdio but targets V6.
>>>> Also mpx was part of DataKit support.
>>>>
>>>> Slide 35 --   Not sure that is true.   I thought Microsoft's Xenix
>>>> ships before Venix.    Particularly since you made the comment about System
>>>> III
>>>> The original 8086 Xenix was a pure V7 port, with a few additions Gordon
>>>> brought with him from Purdue (i.e. ghg hacks).
>>>>
>>>> Slide 52/53/54/55 -- wrong logo (see above)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Sep 12, 2019 at 11:21 PM Warner Losh <imp@bsdimp.com> wrote:
>>>>
>>>>> OK. I've shared my slides for the talk.
>>>>>
>>>>> Some of the family trees are simplified (V7 doesn't have room for all
>>>>> its ports, for example)
>>>>> Some of it is a little cheeseball since I'm also trying to be witty
>>>>> and entertaining (we'll see how that goes).
>>>>> Please don't share them around until after my talk on the September
>>>>> 20th
>>>>>
>>>>> I'd like feedback on the bits I got wrong. Or left out. Or if you're
>>>>> in this and don't want to be, etc.
>>>>>
>>>>> All the slides after the Questions slide won't be presented and will
>>>>> likely be deleted.
>>>>>
>>>>>
>>>>> https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing
>>>>>
>>>>> Please be kind (but if it sucks, please do tell). I've turned on
>>>>> commenting on the slides. Probably best if you comment there.
>>>>>
>>>>> I have a video of me giving this talk, but it's too rough to share...
>>>>>
>>>>> Thanks for any help you can give me.
>>>>>
>>>>> Warner
>>>>>
>>>>

[-- Attachment #2: Type: text/html, Size: 15396 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
  2019-09-17 19:18       ` Warner Losh
@ 2019-09-17 20:13         ` Clem Cole
  0 siblings, 0 replies; 148+ messages in thread
From: Clem Cole @ 2019-09-17 20:13 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 838 bytes --]

On Tue, Sep 17, 2019 at 3:18 PM Warner Losh <imp@bsdimp.com> wrote:

>
> When I worked at The Wollongong Group they were quite specific that they
> had their license from V6 days, that it was a one-off that has unusually
> favorable terms, and that it was the first licensee. But that may be the
> first license to redistribute, rather than the first commercial user to be
> licensed...
>
Possible - as I said ISC might have something also.  But V7 was the first
generally available redistrbution license.  It might have had a few tunable
things, but generally it was what everyone had.  The per CPU terms was set
thinking a computer cost $150K-500K, not $1-2K.




>
>
> I'll see if I can work that in.. Is that the famous '50 patches' or is
> that something else?
>
Yes - the patch tape or 50 changes.


> ᐧ

[-- Attachment #2: Type: text/html, Size: 2907 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
  2019-09-17 19:29         ` Warner Losh
@ 2019-09-17 20:17           ` Clem Cole
  0 siblings, 0 replies; 148+ messages in thread
From: Clem Cole @ 2019-09-17 20:17 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 569 bytes --]

On Tue, Sep 17, 2019 at 3:29 PM Warner Losh <imp@bsdimp.com> wrote:

> Yes. That's the first release of PWB. However, they took delivery of their
> first PDP-11 in 1973, which is when the PWB efforts began
>
Hmmm... I'd believe the efforts start then, but the idea if going outside
of that group was later.
Mashey is the person to ask.  Send me email off line and I'll introduce you.




> as part of the BIS or BISP business unit (I have conflicting sources on
> the exact name).
>
Yeah that sounds like something I remember.  Ask Mash.




> ᐧ

[-- Attachment #2: Type: text/html, Size: 2767 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-17 18:15                                       ` arnold
  2019-09-17 18:32                                         ` Warner Losh
@ 2019-09-18  0:42                                         ` Adam Thornton
  1 sibling, 0 replies; 148+ messages in thread
From: Adam Thornton @ 2019-09-18  0:42 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]

I always rather liked the IBM Bookmaster flavor of GML.  I wrote some
good-looking (and perhaps even useful) things in it.

Adam

On Tue, Sep 17, 2019 at 11:16 AM <arnold@skeeve.com> wrote:

> Hi.
>
> Christopher Browne <cbbrowne@gmail.com> wrote:
> > I had the other reaction to this...
> >
> > I have been managing my web presence via DocBook SGML for a goodly long
> > time.  It is, as mentioned upthread, pretty wordy what with all the
> verbose
> > tagging.
> >
> > It would be worth something to be able to edit it in TeXinfo form, with
> the
> > lesser amount of tagging required.  (And I'd kinda like to get off of
> > DocBook/SGML one of these days as the toolset is clearly mouldering away
> > pretty badly.)
>
> Looks like pandoc will go from DocBook to Texinfo.
>
> Me, I'd probably write a giant awk script to do the grunt work. :-)
>
> > For sophisticated material, TeXinfo is of use, notwithstanding notions to
> > make everything into brief man pages.
>
> As I've been saying, I use it for books.
>
> Good luck,
>
> Arnold
>

[-- Attachment #2: Type: text/html, Size: 1549 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-16 12:10                               ` Clem Cole
                                                   ` (3 preceding siblings ...)
  2019-09-16 21:42                                 ` Dave Horsfall
@ 2019-10-05 19:44                                 ` Michael Parson
  4 siblings, 0 replies; 148+ messages in thread
From: Michael Parson @ 2019-10-05 19:44 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

(pardon the reply on an oldish thread, I've not read this group in a
while)

On Mon, 16 Sep 2019, Clem Cole wrote:
> On Mon, Sep 16, 2019 at 1:52 AM <arnold@skeeve.com> wrote:
>
>> I use the standalone Info reader (named info) if I want to look at the
>> Info output.
>>
> Fair enough, but be careful, while I admit I have not looked in a while,
> info(gnu) relies on emacs keybindings and a number of very emacs'ish things.
> Every time I have tried to deal with it, I have unprogram my fingers and
> reset them to emacs.
>
> If it would have used more(1) [or even less(1)] then I would not be as
> annoyed.
> Unix had fine tools [man(1), more(1), et al] and rms and friends felt the
> need to replace them with ITS-like programs.

A few years ago, I was introduced to pinfo[0] for reading info pages, it's
more like using the lynx browser to read info docs rather than the emacs
keybindings.

-- 
Michael Parson
Pflugerville, TX
KF5LGQ

[0] http://pinfo.sourceforge.net

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary)
  2019-09-16 16:16                 ` Warner Losh
  2019-09-16 20:21                   ` G. Branden Robinson
@ 2019-10-09  0:38                   ` Lyndon Nerenberg
  1 sibling, 0 replies; 148+ messages in thread
From: Lyndon Nerenberg @ 2019-10-09  0:38 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Warner Losh writes:

> Venix had vi. At least 2.0 pulled that in from Berkeley...

But they built it with '#define SMALL' or whatever the #ifdef was for
the 16-bit version.  I was working at a court reporting company at the
time, and we had just introduced the court reporters to UNIX for editing,
proofing, and typesetting the transcripts.  Within a few weeks they were
blowing through the limits of the 16-bit-restricted Venix vi.  I ended up
bootlegging the vi source from a friend so we could compile an un-
restricted address space binary for them to use.

This same bunch of reporters, within a couple of months, were writing
their own awk scripts to look for transcription errors, and their own
troff macros to typeset the final product in client-specific formats.

When I first arrived there they were using Convergent NGEN workstations
to transcribe the tapes.  In well under a year we had replaced those
with a Convergent MiniFrame and moved the entire workflow over to
vi/awk/troff spitting out Postscript, most of the tools for which
the reporters wrote themselves.

Today, when I listen to all our "technical support" people at work
whine about how they can't log in to XXX (because they didn't run
ssh-add), it sets my hair on fire.  I would so love to put them in
the Waybac Machine and let the old gang school them in "learn to do
your fscking job!"

Sorry, what were we talking about ... ?

--lyndon

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary)
  2019-09-16 22:33                       ` George Michaelson
  2019-09-16 23:14                         ` G. Branden Robinson
@ 2019-10-09  1:10                         ` Lyndon Nerenberg
  1 sibling, 0 replies; 148+ messages in thread
From: Lyndon Nerenberg @ 2019-10-09  1:10 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[Sorry, coming to this thread very late ...]

George Michaelson writes:

> Terminfo just didn't feel very *relevant*

In the sense that we no longer stare down collections of Ann Arbor
Ambassador's with their endless combinations of screen configurations,
or just dealing with adm3a vs. xl83 vs. vtXX0, sure.

But terminfo (or cap) is still relevant to me every day in a couple
of ways, even though my $TERM is almost always 'xterm'.

Lots of terminals have internal memory buffers that curses can take
advantage of.  The most common case is to have a cursor-oriented
application (vi, less, systat) grab on to one of those buffers and
use it while they run, and then restore the original terminal screen
when they exit.  This preserves the shell session context around
the editor/whatever session.  Sometimes this is useful.  Sometimes
it is not.

I happen to dislike that behaviour.  When I'm churning through a
sequence of commands and get to the point where I need to look up
something obscure in the manpage, there's nothing more frustrating
than running 'man foo', finding the section of the manpage that
describes exactly what I need to do, pressing 'q' to exit the pager,
and watching said pager erase the very information I was looking for
just to redraw the screen back to the point where I originally became
lost :-P

terminfo saves me[1] from that behaviour.  The decision about how,
when, or if to use those memory buffers is part of the terminfo
definition for the $TERM I'm using.  So I can customize the inter-
action between xterm and less by writing my own 'xterm' terminfo
definition that doesn't do the memory buffer dance.  POSIX even
defines interfaces such as $TERMINFO and tic(1) that ensure I can
portably push my own 'xterm' definitions around to all the systems
I work on.

But of course, *everybody* knows the entire universe lives in an
ANSI terminal now, so why bother with curses?

This is the same logic that *knows* that nobody in the universe
customizes the colours they use in their terminal sessions, so
they can feel free to make up whatever colour mappings they want.
Don't like it?  Then set our app-specific configuration settings,
or environment variables, or both.  Because, why should we pay
attention to the terminal attribute mappings that have been in
terminfo/curses for how many decades?

--lyndon

[1] OpenBSD is very annoying about this. On every (every!) other
    UNIX variant I use, I can upload and compile my custom
    terminfo 'xterm' definition and It Just Works.  Not OpenBSD ...

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-20 13:41     ` Steffen Nurpmeso
@ 2019-09-20 15:03       ` Steffen Nurpmeso
  0 siblings, 0 replies; 148+ messages in thread
From: Steffen Nurpmeso @ 2019-09-20 15:03 UTC (permalink / raw)
  To: John P. Linderman; +Cc: The Eunuchs Hysterical Society

Steffen Nurpmeso wrote in <20190920134137.DXBTo%steffen@sdaoden.eu>:
 |John P. Linderman wrote in <CAC0cEp-CVPb-OhcDHKfbj5nMoiYjkAOEZnEOf4Sv5Zr\
 |zTnDKTg@mail.gmail.com>:
 ...
 ||There is a place for a concise description of each command, and a \
 ||separate \
 ||place for tutorials and conference papers.
 ...
 |Also, easy it is to concisely document that -n chooses a numeric
 |sort, and -r reverses the result order, but 
 |
 |   -b addr, --bcc=..
 |          Send a blind carbon copy to recipient addr.
 |
 |can result in dead-end or otherwise misunderstood situations
 |unless you really know that particular manual is stripped down,
 |and the reference manual makes this
 ...

And i want to clarify that we talk about a program which does not
behave the way a user would normally expect, where normally is
that the mail is sent to all recipients.
In an academic or a lab environment you can ask someone, or go
over and say "Hi Ken" or "Hi Kurt", "your program misbehaves".
But in the wild people will simply start to mistrust a program, or
stop using it right away.  In 99 percent you will not even get
a bug report or hear just about anything.  (Except maybe for the
most popular and widely used programs.)  And then all the work,
the blood sweat and tears have been for nothing.

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-19 20:38   ` John P. Linderman
@ 2019-09-20 13:41     ` Steffen Nurpmeso
  2019-09-20 15:03       ` Steffen Nurpmeso
  0 siblings, 1 reply; 148+ messages in thread
From: Steffen Nurpmeso @ 2019-09-20 13:41 UTC (permalink / raw)
  To: John P. Linderman; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 5605 bytes --]

John P. Linderman wrote in <CAC0cEp-CVPb-OhcDHKfbj5nMoiYjkAOEZnEOf4Sv5Zr\
zTnDKTg@mail.gmail.com>:
 |In the early 70's, Marc Rochkind recommended re-reading the entire \
 |UNIX manual yearly. Back then, it was doable. Now it is probably growing \
 |faster than I can read.

It is however astonishing by how much even the POSIX standard
changes, as a lowest common denominator.  The IETF produces an
overwhelming amount of drafts and RFCs, which need to or should be
adhered to, affecting functionality and documentation.  So much
more time would be needed, for so many things.

 |There is a place for a concise description of each command, and a separate \
 |place for tutorials and conference papers.

Unfortunately not except in FreeBSD and NetBSD, which carry some
in /usr/share/doc, like the BSD mail manual.  You need to find it
here, and i wonder how many of those who have grown up in the
Linux world would find them at all.  (Or even do a search.)
They are not really updated in addition.  Though FreeBSD added
a clang entry, the time when developers invented ideas and
implementations, and documented those under /usr/share/doc are
over even there.  This is really sad.  Infrequently and getting
rarer i reread those, for example "Rethinking /dev and devices in
the UNIX kernel" about the introduction of devfs, which i still
find great.

It is great to hear you who is responsible that the "load of
options reached 17 in v9", whereas i maintain a fork of the
program which causes "old UNIX hands [to] groan at the monstrous
headers that come from latter-day mailers and at the fatness of
their manuals" (citing A Research UNIX Reader).

To offer a solution i could add another layer in between -h output
and full reference manual, and create a heavily minimized version
of the manual, renaming that one to -reference.1 maybe, and
prominently mention the reference.
Also, easy it is to concisely document that -n chooses a numeric
sort, and -r reverses the result order, but 

   -b addr, --bcc=..
          Send a blind carbon copy to recipient addr.

can result in dead-end or otherwise misunderstood situations
unless you really know that particular manual is stripped down,
and the reference manual makes this

   -b addr, --bcc=..
          Send a blind carbon copy to recipient addr, if the set[268]ting of
          expandaddr[408], one of the INTERNAL VARIABLES[29], allows; the
          ‘shquote’ expandaddr[408] flag is supported.  The option may be
          used multiple times.  Also see the section On sending mail, and
          non-interactive mode[7].

(Here, expandaddr has not been invented by me.)
But if you have the reference a bit present in your head, then

  #?0|kent:nail$ .obj/s-nail -h|grep -- -b
         [:-a attachment:] [:-b bcc-addr:] [:-c cc-addr:]
  . -b, -c, -r, -T, to-addr: ex@am.ple or '(Lovely) Ex <am@p.le>'

should also be sufficient.  Blasting the concise complexity of
a mathematical formula,

   -a file[=input-charset[#output-charset]], --attach=..
          Attach file to the message (for compose mode opportunities refer
          to ~@[317] and ~^[319]).

needs to backed as

   -a file[=input-charset[#output-charset]], --attach=..
          Attach file to the message (for compose mode opportunities refer
          to ~@[317] and ~^[319]).  Filename transformations[26] (also see
          file[193]) will be performed, except that shell variables are not
          expanded.  Shall file not be accessible but contain a ‘=’ charac‐
          ter, then anything before the last ‘=’ will be used as the file‐
          name, anything thereafter as a character set specification.

          If an input character set is specified, but no output character
          set, then the given input character set is fixed as-is, and no
          conversion will be applied; giving the empty string or the special
          string hyphen-minus ‘-’ will be treated as if ttycharset[590] has
          been specified (the default).

          If an output character set has also been given then the conversion
          will be performed exactly as specified and on-the-fly, not consid‐
          ering the file type and content.  As an exception the empty string
          or hyphen-minus ‘-’, select the default conversion algorithm (see
          Character sets[14]): no conversion is performed on-the-fly, file
          and its contents will be MIME-classified (HTML mail and MIME
          attachments[9], The mime.types files[35]); Only this mode is sup‐
          ported without support for character set conversions
          (features[411] does not mention ‘+iconv’).

for people to get at least enough of the picture to use the
option.  (Note the actual algorithm is documented somewhere else.)

  #?0|kent:nail$ .obj/s-nail -h|grep -- '-a '
           [:-a attachment:] [:-b bcc-addr:] [:-c cc-addr:]
  . -a attachment[=input-charset[#output-charset]]

But normally, all you say is "-a file" and the thing is fine
by default without just doing anything at all.  That is how it
should be.

Dear John P. Linderman, be warned that the above output of -b is
new, it was "-[bcrT]:" before, for which to understand regular
expressions or file patterns are implied.  I have given you credit
for the change.

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

[-- Attachment #2: Original message content --]
[-- Type: message/rfc822, Size: 16687 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 6093 bytes --]

In the early 70's, Marc Rochkind recommended re-reading the entire UNIX
manual yearly. Back then, it was doable. Now it is probably growing faster
than I can read.

There is a place for a *concise* description of each command, and a
separate place for tutorials and conference papers.

On Thu, Sep 19, 2019 at 3:44 PM Steffen Nurpmeso <steffen@sdaoden.eu> wrote:

> Norman Wilson wrote in <1568916649.17313.for-standards-violators@oclsc.org
> >:
>  |Larry McVoy:
>  |
>  |  If you have something like perl that needs a zillion sub pages, info
>  |  makes sense.  For just a man page, info is horrible.
>  |
>  |=====
>  |
>  |This pokes me in one of my longest-standing complaints:
>  |
>  |Manual entries, as printed by man and once upon a time in
>  |the Programmers' Manual Volume 1, should be concise references.
>  |They are not a place for tutorials or long-winded descriptions
>  |or even long lists of hundreds of options (let alone descriptions
>  |of why the developer thinks this is the neatest thing since
>  |sliced bread and what bread he had in his sandwiches that day).
>  |
>  |For many programs, one or two pages of concise reference is
>  |all the documentation that's needed; no one needs a ten-page
>  |tutorial on how to use cat or rm or ls, for example.  But some
>  |programs really do deserve a longer treatment, either a tutorial
>  |or an extended reference with more detail or both.  Those belong
>  |in separate documents, and are why the Programmers' Manual had
>  |a second volume.
>  |
>  |Nowadays people think nothing of writing 68-page-long manual
>  |entries (real example from something I'm working with right now)
>  |that are long, chatty lists of options or configuration-file
>  |directives with tutorial information interspersed.  The result
>  |makes the developer feel good--look at all the documentation
>  |I've written!!--but it's useless for someone trying to figure
>  |out how to write a configuration file for the first time, and
>  |not so great even for someone trying to edit an existing one.
>  |
>  |Even the Research system didn't always get this right; some
>
> I totally disagree with you.  Whereas i even admire McIlroy's
> "concise", and really love reading Plan9 manual pages, and that
> not only because one can imagine _who_ put their fingers on those,
> i think manual pages should enable people to work with a program.
> And not only intellectual elite, the absolute top of the pops
> gathered together in this cave and grooving with a pict, but
> "everybody" to the extend possible.
>
> If i would have a lot of money in spare i could hire teams of
> three people each which rotate through the develop / test
> / documentation cycle, and around each others work.  But that is
> not how it goes here, you add a feature and write down the docs,
> you extend one and patch in doc where you think it belongs, yet
> get infos from someone and patch in doc to clarify something.  You
> do all that short on time, and finally you have a rag rug.
>
> So what you would need then is time to step back, let time pass,
> come back with fresh eyes, reread the entire documentation once,
> reflect, and work it all over.
>
> Add the complications of not being a native speaker.
> For some projects, add many translations done by volunteers, which
> you leave behind if you adhere to this work cycle.  (But do not if
> you just patch up.)
>
> You could of course split the manual into several subsections, but
> which one to split, which not.  Duplicate several, for example
> command line options, which can initiate complicate tasks, which
> need a lengthy text to become understandable?
>
> Who is going to do all that work?  Who is the one who will spend
> the time and strength necessary to keep all the individual parts
> in sync?  For example, this week (at least the latter commit) on
> FreeBSD the ZFS filesystem, thus a crucial part of the
> infrastructure of FreeBSD (no Hammer or BTRFS support), the
> i guess second largest free software environment, with quite some
> people getting paid for working on the code base, was extended (i
> do not use ZFS), but even the help string of the managing tool was
> not updated until a follow up commit several days later fixed
> that!
>
> So for me this is not feasible.  I have the manual, and i have the
> help string output for -h / --help, and a longer (long option) one
> with --long-help.  If you want a quick shot, use -h.  If you need
> documentation, use the manual.
>
>   #?0|kent:mk$ man -l ../nail.1|wc -l
>   troff: <standard input>:14382: name expected (got '\c'): treated as
> missing
>   8172
>
> Without TOC and anchors.
> bug in groff mdoc macros in 1.22.3, by the way (.Lk i guessed).
>
>   #?0|kent:mk$ mdoc ../nail.1|wc -l
>   8307
>
> With TOC and hundreds of internal and external anchors.
>
>   #?0|kent:mk$ /tmp/y/s-nail -h|wc -l
>   24
>   #?0|kent:mk$ /tmp/y/s-nail --long-help|wc -l
>   57
>
>  |manual entries ran on and on and on when what was really
>  |needed was a concise list of something and a longer accompanying
>  |document.  (The Tenth Edition manual was much better about
>  |that, mostly because of all the work Doug put in.  I doubt
>  |there has ever been a better editor for technical text than
>  |Doug.)  But it's far worse now in most systems, because
>  |there's rarely any editor at all; the manuals are just an
>  |accreted clump.
>  |
>  |And that's a shame, though I have no suggestions on how
>  |to fix it.
>
> I do not know either.  The car industry has the many pictures but
> no content (for people who spend money), a repair manual for
> underpaid mechanics, and detailed spare part foils for those
> people working in the dusty spare parts depot.  That at least
> thirty years ago when i snuffled into that industry.
>
>  |Norman Wilson
>  |Toronto ON
>  --End of <1568916649.17313.for-standards-violators@oclsc.org>
>
> --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)
>

[-- Attachment #2.1.2: Type: text/html, Size: 7304 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-19 22:42 ` Rob Pike
@ 2019-09-19 22:55   ` Bakul Shah
  0 siblings, 0 replies; 148+ messages in thread
From: Bakul Shah @ 2019-09-19 22:55 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Re: more/less/p

At Fortune Systems Dave Yost added page mode to the tty driver
when his serial io optimizations made scrolling at 9600
blazing fast.  He also added an ioctl for page size.  By
setting it to something smaller than the tty number of rows
you can see some context as well.  This worked pretty well.

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-19 18:42 Norman Wilson
@ 2019-09-19 22:42 ` Rob Pike
  2019-09-19 22:55   ` Bakul Shah
  0 siblings, 1 reply; 148+ messages in thread
From: Rob Pike @ 2019-09-19 22:42 UTC (permalink / raw)
  To: Norman Wilson; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 4721 bytes --]

Here is the complete Plan 9 man page for p:

% 9 man p


     P(1)                                                         P(1)


     NAME

          p - paginate


     SYNOPSIS

          p [ -number ] [ file ... ]


     DESCRIPTION

          P copies its standard input, or the named files if given, to

          its standard output, stopping at the end of every 22nd line,

          and between files, to wait for a newline from the user.  The

          option sets the number of lines on a page.


          While waiting for a newline, p interprets the commands:


          !    Pass the rest of the line to the shell as a command.


          q    Quit.


     SOURCE

          /usr/local/plan9/src/cmd/p.c


     Page 1                       Plan 9             (printed 9/20/19)



On Fri, Sep 20, 2019 at 4:43 AM Norman Wilson <norman@oclsc.org> wrote:

> Clem Cole:
>
>   Exactly!!!!   That's what Eric did when he wrote more(ucb) -  he *added
> to
>   Unix*.   The funny part was that USG thought more(ucb) was a good idea
> and
>   then wrote their own, pg(att); which was just as arrogant as the info
>   behavior from the Gnu folks!!!
>
> ======
>
> And others wrote their own too, of course.  The one I know
> best is p(1), written by Rob Pike in the late 1970s at the
> University of Toronto.  I encountered at Caltech on the
> system Rob had set up before leaving for Bell Labs (and
> which I cared for and hacked on for the next four years
> before following him).  By the time I reached BTL it was
> a normal part of the Research system; I believe it's in
> all of the Eighth, Ninth, and Tenth Edition manuals.
>
> p is interesting because it's so much lighter-weight, and
> because it has rather a different interior design:
>
> Rather than doing termcappy things, p just prints 22 lines
> (or the number specified in an option), then doesn't print
> the newline after the 22nd line.  Hit return and it will
> print the next 22 lines, and so on.  The resulting text just
> flows up the glass-tty screen without any fuss, cbreak, or
> anything.  (I believe the first version predated V7 and
> therefore cbreak.)
>
> Why 22 lines instead of 24, the common height of glass ttys
> back then?  Partly because that means you keep a line or two
> of context when advancing pages, making reading simpler.
> But also because in those days, a standard page destined for
> a printer (e.g. from pr or nroff, and therefore from man) was
> 66 lines long.  22 evenly divides 66, so man something | p
> never gives you a screen spanning pages.
>
> p was able to back up: type - (and return) instead of just
> return, and it reprints the previous 22-line page; -- (return)
> the 22 lines before that; and so on.  This was implemented
> in an interesting and clever way: a wrapper around the standard
> I/O library which kept a circular buffer of some fixed number
> of characters (8KiB in early versions, I think), and a new
> call that, in effect, backed up the file pointer by one character
> and returned the character just backed over.  That made it easy
> to back over the previous N lines: just make that call until
> you've seen N newlines, then discard the newline you've just
> backed over, and you're at the beginning the first line you want
> to reprint.
>
> As I vaguely recall, more was able to back up, but only when
> reading from a real file, not a pipeline.  p could do (limited
> but sufficient) backup from a pipeline too.
>
> As a creature of its pre-window-system era, you could also type
> !command when p paused as well.
>
> I remember being quite interested in that wrapper as a
> possible library for use in other things, though I never
> found a use for it.
>
> I also remember a wonderful Elements-of-Programming-Style
> adventure with Rob's code.  I discovered it had a bug under some
> specific case when read returned less than a full bufferful.
> I read the code carefully and couldn't see what was wrong.
> So I wrote my own replacement for the problematic subroutine
> from scratch, tested it carefully in corner cases, then with
> listings of Rob's code and mine side-by-side walked through
> each with the problem case and found the bug.
>
> I still carry my own version of p (rewritten from scratch mainly
> to make it more portable--Rob's code was old enough to be too
> clever in some details) wherever I go; ironically, even back to
> U of T where I have been on and off for the past 30 years.
> more and less and pg and the like are certainly useful programs;
> for various reasons they're not to my taste, but I don't scorn
> them.  But I can't help being particular fond of p because it
> taught me a few things about programming too.
>
> Norman Wilson
> Toronto ON
>

[-- Attachment #2: Type: text/html, Size: 14866 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-19 18:10 Norman Wilson
  2019-09-19 18:37 ` Clem Cole
  2019-09-19 19:44 ` Steffen Nurpmeso
@ 2019-09-19 20:53 ` Bakul Shah
  2 siblings, 0 replies; 148+ messages in thread
From: Bakul Shah @ 2019-09-19 20:53 UTC (permalink / raw)
  To: Norman Wilson; +Cc: tuhs

On Sep 19, 2019, at 11:10 AM, Norman Wilson <norman@oclsc.org> wrote:
> 
> This pokes me in one of my longest-standing complaints:
> 
> Manual entries, as printed by man and once upon a time in
> the Programmers' Manual Volume 1, should be concise references.
> They are not a place for tutorials or long-winded descriptions
> or even long lists of hundreds of options (let alone descriptions
> of why the developer thinks this is the neatest thing since
> sliced bread and what bread he had in his sandwiches that day).
> 
> For many programs, one or two pages of concise reference is
> all the documentation that's needed; no one needs a ten-page
> tutorial on how to use cat or rm or ls, for example.  But some
> programs really do deserve a longer treatment, either a tutorial
> or an extended reference with more detail or both.  Those belong
> in separate documents, and are why the Programmers' Manual had
> a second volume.
> 
> Nowadays people think nothing of writing 68-page-long manual
> entries (real example from something I'm working with right now)
> that are long, chatty lists of options or configuration-file
> directives with tutorial information interspersed.  The result
> makes the developer feel good--look at all the documentation
> I've written!!--but it's useless for someone trying to figure
> out how to write a configuration file for the first time, and
> not so great even for someone trying to edit an existing one.
> 
> Even the Research system didn't always get this right; some
> manual entries ran on and on and on when what was really
> needed was a concise list of something and a longer accompanying
> document.  (The Tenth Edition manual was much better about
> that, mostly because of all the work Doug put in.  I doubt
> there has ever been a better editor for technical text than
> Doug.)  But it's far worse now in most systems, because
> there's rarely any editor at all; the manuals are just an
> accreted clump.
> 
> And that's a shame, though I have no suggestions on how
> to fix it.

Agree 100%. But I think what we are really complaining about
is more recent program design & interface. Why do programs
have so many options. Why is their functionality partitioned
better.


^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-19 20:18   ` Larry McVoy
@ 2019-09-19 20:42     ` Andy Kosela
  0 siblings, 0 replies; 148+ messages in thread
From: Andy Kosela @ 2019-09-19 20:42 UTC (permalink / raw)
  To: Larry McVoy; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 569 bytes --]

On Thursday, September 19, 2019, Larry McVoy <lm@mcvoy.com> wrote:

> On Thu, Sep 19, 2019 at 03:00:16PM -0400, Nemo Nusquam wrote:
> > On 09/19/19 14:50, Norman Wilson wrote (in part):
> > >So it's true that BSD added needless (in my humble but correct
> > >opinion) options, but not that it had none before they touched it.
> > >Unless all those other programs were stuffed into cat in an earlier
> > >Berkeley system, but I don't think they were.
> >
> > Who said "Cat came back from Berkeley waving flags."?
>
> Rob Pike
>

 http://harmful.cat-v.org/cat-v/

--Andy

[-- Attachment #2: Type: text/html, Size: 912 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-19 19:44 ` Steffen Nurpmeso
@ 2019-09-19 20:38   ` John P. Linderman
  2019-09-20 13:41     ` Steffen Nurpmeso
  0 siblings, 1 reply; 148+ messages in thread
From: John P. Linderman @ 2019-09-19 20:38 UTC (permalink / raw)
  To: Steffen Nurpmeso; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 6093 bytes --]

In the early 70's, Marc Rochkind recommended re-reading the entire UNIX
manual yearly. Back then, it was doable. Now it is probably growing faster
than I can read.

There is a place for a *concise* description of each command, and a
separate place for tutorials and conference papers.

On Thu, Sep 19, 2019 at 3:44 PM Steffen Nurpmeso <steffen@sdaoden.eu> wrote:

> Norman Wilson wrote in <1568916649.17313.for-standards-violators@oclsc.org
> >:
>  |Larry McVoy:
>  |
>  |  If you have something like perl that needs a zillion sub pages, info
>  |  makes sense.  For just a man page, info is horrible.
>  |
>  |=====
>  |
>  |This pokes me in one of my longest-standing complaints:
>  |
>  |Manual entries, as printed by man and once upon a time in
>  |the Programmers' Manual Volume 1, should be concise references.
>  |They are not a place for tutorials or long-winded descriptions
>  |or even long lists of hundreds of options (let alone descriptions
>  |of why the developer thinks this is the neatest thing since
>  |sliced bread and what bread he had in his sandwiches that day).
>  |
>  |For many programs, one or two pages of concise reference is
>  |all the documentation that's needed; no one needs a ten-page
>  |tutorial on how to use cat or rm or ls, for example.  But some
>  |programs really do deserve a longer treatment, either a tutorial
>  |or an extended reference with more detail or both.  Those belong
>  |in separate documents, and are why the Programmers' Manual had
>  |a second volume.
>  |
>  |Nowadays people think nothing of writing 68-page-long manual
>  |entries (real example from something I'm working with right now)
>  |that are long, chatty lists of options or configuration-file
>  |directives with tutorial information interspersed.  The result
>  |makes the developer feel good--look at all the documentation
>  |I've written!!--but it's useless for someone trying to figure
>  |out how to write a configuration file for the first time, and
>  |not so great even for someone trying to edit an existing one.
>  |
>  |Even the Research system didn't always get this right; some
>
> I totally disagree with you.  Whereas i even admire McIlroy's
> "concise", and really love reading Plan9 manual pages, and that
> not only because one can imagine _who_ put their fingers on those,
> i think manual pages should enable people to work with a program.
> And not only intellectual elite, the absolute top of the pops
> gathered together in this cave and grooving with a pict, but
> "everybody" to the extend possible.
>
> If i would have a lot of money in spare i could hire teams of
> three people each which rotate through the develop / test
> / documentation cycle, and around each others work.  But that is
> not how it goes here, you add a feature and write down the docs,
> you extend one and patch in doc where you think it belongs, yet
> get infos from someone and patch in doc to clarify something.  You
> do all that short on time, and finally you have a rag rug.
>
> So what you would need then is time to step back, let time pass,
> come back with fresh eyes, reread the entire documentation once,
> reflect, and work it all over.
>
> Add the complications of not being a native speaker.
> For some projects, add many translations done by volunteers, which
> you leave behind if you adhere to this work cycle.  (But do not if
> you just patch up.)
>
> You could of course split the manual into several subsections, but
> which one to split, which not.  Duplicate several, for example
> command line options, which can initiate complicate tasks, which
> need a lengthy text to become understandable?
>
> Who is going to do all that work?  Who is the one who will spend
> the time and strength necessary to keep all the individual parts
> in sync?  For example, this week (at least the latter commit) on
> FreeBSD the ZFS filesystem, thus a crucial part of the
> infrastructure of FreeBSD (no Hammer or BTRFS support), the
> i guess second largest free software environment, with quite some
> people getting paid for working on the code base, was extended (i
> do not use ZFS), but even the help string of the managing tool was
> not updated until a follow up commit several days later fixed
> that!
>
> So for me this is not feasible.  I have the manual, and i have the
> help string output for -h / --help, and a longer (long option) one
> with --long-help.  If you want a quick shot, use -h.  If you need
> documentation, use the manual.
>
>   #?0|kent:mk$ man -l ../nail.1|wc -l
>   troff: <standard input>:14382: name expected (got '\c'): treated as
> missing
>   8172
>
> Without TOC and anchors.
> bug in groff mdoc macros in 1.22.3, by the way (.Lk i guessed).
>
>   #?0|kent:mk$ mdoc ../nail.1|wc -l
>   8307
>
> With TOC and hundreds of internal and external anchors.
>
>   #?0|kent:mk$ /tmp/y/s-nail -h|wc -l
>   24
>   #?0|kent:mk$ /tmp/y/s-nail --long-help|wc -l
>   57
>
>  |manual entries ran on and on and on when what was really
>  |needed was a concise list of something and a longer accompanying
>  |document.  (The Tenth Edition manual was much better about
>  |that, mostly because of all the work Doug put in.  I doubt
>  |there has ever been a better editor for technical text than
>  |Doug.)  But it's far worse now in most systems, because
>  |there's rarely any editor at all; the manuals are just an
>  |accreted clump.
>  |
>  |And that's a shame, though I have no suggestions on how
>  |to fix it.
>
> I do not know either.  The car industry has the many pictures but
> no content (for people who spend money), a repair manual for
> underpaid mechanics, and detailed spare part foils for those
> people working in the dusty spare parts depot.  That at least
> thirty years ago when i snuffled into that industry.
>
>  |Norman Wilson
>  |Toronto ON
>  --End of <1568916649.17313.for-standards-violators@oclsc.org>
>
> --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)
>

[-- Attachment #2: Type: text/html, Size: 7304 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-19 18:10 Norman Wilson
  2019-09-19 18:37 ` Clem Cole
@ 2019-09-19 19:44 ` Steffen Nurpmeso
  2019-09-19 20:38   ` John P. Linderman
  2019-09-19 20:53 ` Bakul Shah
  2 siblings, 1 reply; 148+ messages in thread
From: Steffen Nurpmeso @ 2019-09-19 19:44 UTC (permalink / raw)
  To: Norman Wilson; +Cc: tuhs

Norman Wilson wrote in <1568916649.17313.for-standards-violators@oclsc.org>:
 |Larry McVoy:
 |
 |  If you have something like perl that needs a zillion sub pages, info
 |  makes sense.  For just a man page, info is horrible.
 |
 |=====
 |
 |This pokes me in one of my longest-standing complaints:
 |
 |Manual entries, as printed by man and once upon a time in
 |the Programmers' Manual Volume 1, should be concise references.
 |They are not a place for tutorials or long-winded descriptions
 |or even long lists of hundreds of options (let alone descriptions
 |of why the developer thinks this is the neatest thing since
 |sliced bread and what bread he had in his sandwiches that day).
 |
 |For many programs, one or two pages of concise reference is
 |all the documentation that's needed; no one needs a ten-page
 |tutorial on how to use cat or rm or ls, for example.  But some
 |programs really do deserve a longer treatment, either a tutorial
 |or an extended reference with more detail or both.  Those belong
 |in separate documents, and are why the Programmers' Manual had
 |a second volume.
 |
 |Nowadays people think nothing of writing 68-page-long manual
 |entries (real example from something I'm working with right now)
 |that are long, chatty lists of options or configuration-file
 |directives with tutorial information interspersed.  The result
 |makes the developer feel good--look at all the documentation
 |I've written!!--but it's useless for someone trying to figure
 |out how to write a configuration file for the first time, and
 |not so great even for someone trying to edit an existing one.
 |
 |Even the Research system didn't always get this right; some

I totally disagree with you.  Whereas i even admire McIlroy's
"concise", and really love reading Plan9 manual pages, and that
not only because one can imagine _who_ put their fingers on those,
i think manual pages should enable people to work with a program.
And not only intellectual elite, the absolute top of the pops
gathered together in this cave and grooving with a pict, but
"everybody" to the extend possible.

If i would have a lot of money in spare i could hire teams of
three people each which rotate through the develop / test
/ documentation cycle, and around each others work.  But that is
not how it goes here, you add a feature and write down the docs,
you extend one and patch in doc where you think it belongs, yet
get infos from someone and patch in doc to clarify something.  You
do all that short on time, and finally you have a rag rug.

So what you would need then is time to step back, let time pass,
come back with fresh eyes, reread the entire documentation once,
reflect, and work it all over.

Add the complications of not being a native speaker.
For some projects, add many translations done by volunteers, which
you leave behind if you adhere to this work cycle.  (But do not if
you just patch up.)

You could of course split the manual into several subsections, but
which one to split, which not.  Duplicate several, for example
command line options, which can initiate complicate tasks, which
need a lengthy text to become understandable?

Who is going to do all that work?  Who is the one who will spend
the time and strength necessary to keep all the individual parts
in sync?  For example, this week (at least the latter commit) on
FreeBSD the ZFS filesystem, thus a crucial part of the
infrastructure of FreeBSD (no Hammer or BTRFS support), the
i guess second largest free software environment, with quite some
people getting paid for working on the code base, was extended (i
do not use ZFS), but even the help string of the managing tool was
not updated until a follow up commit several days later fixed
that!

So for me this is not feasible.  I have the manual, and i have the
help string output for -h / --help, and a longer (long option) one
with --long-help.  If you want a quick shot, use -h.  If you need
documentation, use the manual.

  #?0|kent:mk$ man -l ../nail.1|wc -l
  troff: <standard input>:14382: name expected (got '\c'): treated as missing
  8172

Without TOC and anchors.
bug in groff mdoc macros in 1.22.3, by the way (.Lk i guessed).

  #?0|kent:mk$ mdoc ../nail.1|wc -l
  8307

With TOC and hundreds of internal and external anchors.

  #?0|kent:mk$ /tmp/y/s-nail -h|wc -l
  24
  #?0|kent:mk$ /tmp/y/s-nail --long-help|wc -l
  57

 |manual entries ran on and on and on when what was really
 |needed was a concise list of something and a longer accompanying
 |document.  (The Tenth Edition manual was much better about
 |that, mostly because of all the work Doug put in.  I doubt
 |there has ever been a better editor for technical text than
 |Doug.)  But it's far worse now in most systems, because
 |there's rarely any editor at all; the manuals are just an
 |accreted clump.
 |
 |And that's a shame, though I have no suggestions on how
 |to fix it.

I do not know either.  The car industry has the many pictures but
no content (for people who spend money), a repair manual for
underpaid mechanics, and detailed spare part foils for those
people working in the dusty spare parts depot.  That at least
thirty years ago when i snuffled into that industry.

 |Norman Wilson
 |Toronto ON
 --End of <1568916649.17313.for-standards-violators@oclsc.org>

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-19 18:37 ` Clem Cole
@ 2019-09-19 18:44   ` Jon Steinhart
  0 siblings, 0 replies; 148+ messages in thread
From: Jon Steinhart @ 2019-09-19 18:44 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Clem Cole writes:
>
> On Thu, Sep 19, 2019 at 2:11 PM Norman Wilson <norman@oclsc.org> wrote:
>
> > Manual entries, as printed by man and once upon a time in
> > the Programmers' Manual Volume 1, should be concise references.
> > They are not a place for tutorials or long-winded descriptions
> > or even long lists of hundreds of options (let alone descriptions
> > of why the developer thinks this is the neatest thing since
> > sliced bread and what bread he had in his sandwiches that day).
> >
> > For many programs, one or two pages of concise reference is
> > all the documentation that's needed; no one needs a ten-page
> > tutorial on how to use cat or rm or ls, for example.  But some
> > programs really do deserve a longer treatment, either a tutorial
> > or an extended reference with more detail or both.  Those belong
> > in separate documents, and are why the Programmers' Manual had
> > a second volume.
> >
> > Nowadays people think nothing of writing 68-page-long manual
> > entries (real example from something I'm working with right now)
> > that are long, chatty lists of options or configuration-file
> > directives with tutorial information interspersed.  The result
> > makes the developer feel good--look at all the documentation
> > I've written!!--but it's useless for someone trying to figure
> > out how to write a configuration file for the first time, and
> > not so great even for someone trying to edit an existing one.
> >
> > Even the Research system didn't always get this right; some
> > manual entries ran on and on and on when what was really
> > needed was a concise list of something and a longer accompanying
> > document.  (The Tenth Edition manual was much better about
> > that, mostly because of all the work Doug put in.  I doubt
> > there has ever been a better editor for technical text than
> > Doug.)  But it's far worse now in most systems, because
> > there's rarely any editor at all; the manuals are just an
> > accreted clump.
> >
> > And that's a shame, though I have no suggestions on how
> > to fix it.
> >
> > +1

This is sort of my late in life mission.  Here's a description of a session
that I've proposed for an upcoming conference.

	Once upon a time there was Budweiser. Then, along came craft beer
	which started a movement. Now, one can find a whole range of
	offerings from craft cheese to artisanal baking soda. Hard to find
	is craft programming. What’s called "programming technology" today
	seems to be the art of minimizing the damage that can be done by
	monkeys at keyboards. Since we can no longer purchase even a
	toothpick that doesn’t contain a processor and a blue LED, we depend
	on code. How can we revive the art of programming? How do we foster
	the creation of good code instead of spending energy minimizing the
	damage that can be done by bad code? Our lives depend on it.

My two cents is that craft programmers know how to write good documentation.
Probably one of the things that made BTL so wonderful was the breadth of
knowledge that people had.  Ken was recently telling me about Lee McMahon who
was a classically trained monk in addition to writing qsort for V3.

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
@ 2019-09-19 18:42 Norman Wilson
  2019-09-19 22:42 ` Rob Pike
  0 siblings, 1 reply; 148+ messages in thread
From: Norman Wilson @ 2019-09-19 18:42 UTC (permalink / raw)
  To: tuhs

Clem Cole:

  Exactly!!!!   That's what Eric did when he wrote more(ucb) -  he *added to
  Unix*.   The funny part was that USG thought more(ucb) was a good idea and
  then wrote their own, pg(att); which was just as arrogant as the info
  behavior from the Gnu folks!!!

======

And others wrote their own too, of course.  The one I know
best is p(1), written by Rob Pike in the late 1970s at the
University of Toronto.  I encountered at Caltech on the
system Rob had set up before leaving for Bell Labs (and
which I cared for and hacked on for the next four years
before following him).  By the time I reached BTL it was
a normal part of the Research system; I believe it's in
all of the Eighth, Ninth, and Tenth Edition manuals.

p is interesting because it's so much lighter-weight, and
because it has rather a different interior design:

Rather than doing termcappy things, p just prints 22 lines
(or the number specified in an option), then doesn't print
the newline after the 22nd line.  Hit return and it will
print the next 22 lines, and so on.  The resulting text just
flows up the glass-tty screen without any fuss, cbreak, or
anything.  (I believe the first version predated V7 and
therefore cbreak.)

Why 22 lines instead of 24, the common height of glass ttys
back then?  Partly because that means you keep a line or two
of context when advancing pages, making reading simpler.
But also because in those days, a standard page destined for
a printer (e.g. from pr or nroff, and therefore from man) was
66 lines long.  22 evenly divides 66, so man something | p
never gives you a screen spanning pages.

p was able to back up: type - (and return) instead of just
return, and it reprints the previous 22-line page; -- (return)
the 22 lines before that; and so on.  This was implemented
in an interesting and clever way: a wrapper around the standard
I/O library which kept a circular buffer of some fixed number
of characters (8KiB in early versions, I think), and a new
call that, in effect, backed up the file pointer by one character
and returned the character just backed over.  That made it easy
to back over the previous N lines: just make that call until
you've seen N newlines, then discard the newline you've just
backed over, and you're at the beginning the first line you want
to reprint.

As I vaguely recall, more was able to back up, but only when
reading from a real file, not a pipeline.  p could do (limited
but sufficient) backup from a pipeline too.

As a creature of its pre-window-system era, you could also type
!command when p paused as well.

I remember being quite interested in that wrapper as a
possible library for use in other things, though I never
found a use for it.

I also remember a wonderful Elements-of-Programming-Style
adventure with Rob's code.  I discovered it had a bug under some
specific case when read returned less than a full bufferful.
I read the code carefully and couldn't see what was wrong.
So I wrote my own replacement for the problematic subroutine
from scratch, tested it carefully in corner cases, then with
listings of Rob's code and mine side-by-side walked through
each with the problem case and found the bug.

I still carry my own version of p (rewritten from scratch mainly
to make it more portable--Rob's code was old enough to be too
clever in some details) wherever I go; ironically, even back to
U of T where I have been on and off for the past 30 years.
more and less and pg and the like are certainly useful programs;
for various reasons they're not to my taste, but I don't scorn
them.  But I can't help being particular fond of p because it
taught me a few things about programming too.

Norman Wilson
Toronto ON

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-19 18:10 Norman Wilson
@ 2019-09-19 18:37 ` Clem Cole
  2019-09-19 18:44   ` Jon Steinhart
  2019-09-19 19:44 ` Steffen Nurpmeso
  2019-09-19 20:53 ` Bakul Shah
  2 siblings, 1 reply; 148+ messages in thread
From: Clem Cole @ 2019-09-19 18:37 UTC (permalink / raw)
  To: Norman Wilson; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]

On Thu, Sep 19, 2019 at 2:11 PM Norman Wilson <norman@oclsc.org> wrote:

> Manual entries, as printed by man and once upon a time in
> the Programmers' Manual Volume 1, should be concise references.
> They are not a place for tutorials or long-winded descriptions
> or even long lists of hundreds of options (let alone descriptions
> of why the developer thinks this is the neatest thing since
> sliced bread and what bread he had in his sandwiches that day).
>
> For many programs, one or two pages of concise reference is
> all the documentation that's needed; no one needs a ten-page
> tutorial on how to use cat or rm or ls, for example.  But some
> programs really do deserve a longer treatment, either a tutorial
> or an extended reference with more detail or both.  Those belong
> in separate documents, and are why the Programmers' Manual had
> a second volume.
>
> Nowadays people think nothing of writing 68-page-long manual
> entries (real example from something I'm working with right now)
> that are long, chatty lists of options or configuration-file
> directives with tutorial information interspersed.  The result
> makes the developer feel good--look at all the documentation
> I've written!!--but it's useless for someone trying to figure
> out how to write a configuration file for the first time, and
> not so great even for someone trying to edit an existing one.
>
> Even the Research system didn't always get this right; some
> manual entries ran on and on and on when what was really
> needed was a concise list of something and a longer accompanying
> document.  (The Tenth Edition manual was much better about
> that, mostly because of all the work Doug put in.  I doubt
> there has ever been a better editor for technical text than
> Doug.)  But it's far worse now in most systems, because
> there's rarely any editor at all; the manuals are just an
> accreted clump.
>
> And that's a shame, though I have no suggestions on how
> to fix it.
>
> +1

[-- Attachment #2: Type: text/html, Size: 2608 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
@ 2019-09-19 18:10 Norman Wilson
  2019-09-19 18:37 ` Clem Cole
                   ` (2 more replies)
  0 siblings, 3 replies; 148+ messages in thread
From: Norman Wilson @ 2019-09-19 18:10 UTC (permalink / raw)
  To: tuhs

Larry McVoy:

  If you have something like perl that needs a zillion sub pages, info
  makes sense.  For just a man page, info is horrible.

=====

This pokes me in one of my longest-standing complaints:

Manual entries, as printed by man and once upon a time in
the Programmers' Manual Volume 1, should be concise references.
They are not a place for tutorials or long-winded descriptions
or even long lists of hundreds of options (let alone descriptions
of why the developer thinks this is the neatest thing since
sliced bread and what bread he had in his sandwiches that day).

For many programs, one or two pages of concise reference is
all the documentation that's needed; no one needs a ten-page
tutorial on how to use cat or rm or ls, for example.  But some
programs really do deserve a longer treatment, either a tutorial
or an extended reference with more detail or both.  Those belong
in separate documents, and are why the Programmers' Manual had
a second volume.

Nowadays people think nothing of writing 68-page-long manual
entries (real example from something I'm working with right now)
that are long, chatty lists of options or configuration-file
directives with tutorial information interspersed.  The result
makes the developer feel good--look at all the documentation
I've written!!--but it's useless for someone trying to figure
out how to write a configuration file for the first time, and
not so great even for someone trying to edit an existing one.

Even the Research system didn't always get this right; some
manual entries ran on and on and on when what was really
needed was a concise list of something and a longer accompanying
document.  (The Tenth Edition manual was much better about
that, mostly because of all the work Doug put in.  I doubt
there has ever been a better editor for technical text than
Doug.)  But it's far worse now in most systems, because
there's rarely any editor at all; the manuals are just an
accreted clump.

And that's a shame, though I have no suggestions on how
to fix it.

Norman Wilson
Toronto ON

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-17  1:33         ` Larry McVoy
@ 2019-09-17 22:39           ` Dave Horsfall
  0 siblings, 0 replies; 148+ messages in thread
From: Dave Horsfall @ 2019-09-17 22:39 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Mon, 16 Sep 2019, Larry McVoy wrote:

> In retrospect having / be roots home is a super bad idea but I think it 
> was fairly common practice, /root became a thing as idiots like me 
> messed things up :)

After my similar fsckup, I made /etc root's home directory (it was much 
easier to recover, and was available at boot time).

-- Dave

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-17  1:17     ` Larry McVoy
  2019-09-17  1:26       ` Clem cole
@ 2019-09-17  1:57       ` Bakul Shah
  1 sibling, 0 replies; 148+ messages in thread
From: Bakul Shah @ 2019-09-17  1:57 UTC (permalink / raw)
  To: tuhs

On Mon, 16 Sep 2019 18:17:52 -0700 Larry McVoy <lm@mcvoy.com> wrote:
> On Mon, Sep 16, 2019 at 09:11:17PM -0400, Arthur Krewat wrote:
> > On 9/16/2019 8:20 PM, Steve Johnson wrote:
> > >One day I had been furiously editing a long program file for about an hour
> > >and a half when I was called away to lunch, and, being hungry, didn't save
> > >my file.?? When I got back to the terminal an hour later, I discovered two
> > >things -- the system had crashed, and our cat had decided that the pile of
> > >paper
> > >on the floor made a great litter box.?? After a few choice words, I sighed
> > >and picked up my highliter...
> > 
> > This should be engraved on a plaque somewhere. Only because I had almost th
> e
> > same thing happen to me, without the cat though. I had a printout of a
> > "mail" program I had written on TOPS-10 at high school. I had to retype the
> > entire thing after the file got corrupted.
>
> I think we have all been there.  Something always goes wrong.  I wrote 
> a paper about how to restore a Masscomp because I did rm -rf . in /.
> I believe we had roots home as / because /usr was a different partition.
> Clem, did Masscomp make roots home / or was that us?  Anyway, I did a
> cd something
> and somehow deleted the something and then did rm -rf .
> Much fun was had, I was up all night putting things back together.
> This was probably around 1984 or 1985, I was pretty green.

I may have mentioned restoring root directory using peek/poke
commands of a primitive boot loader.  Right before Comdex
(fall 1981) someone accidentally wiped out the root dir.  IIRC
we had just two systems that actually worked. The other person
was copying the floppy to the second system when something
went wrong.  The backup didn't work. And this was a Comdex
special filesystem (with demos for the show painstakingly put
together and no time to recreate it all from scratch). I
happened to remember inode & block numbers of the first few
things so I fixed up the root dir enough for the system to
come up & run fsck. Luckily very little was lost and we were
able to repair the demos and run them at Comdex!

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-17  1:26       ` Clem cole
  2019-09-17  1:33         ` Larry McVoy
@ 2019-09-17  1:36         ` Richard Salz
  1 sibling, 0 replies; 148+ messages in thread
From: Richard Salz @ 2019-09-17  1:36 UTC (permalink / raw)
  To: Clem cole; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 296 bytes --]

We've all been there.  I won a Unix "most egregious use of Unix tools"
award from Usenix for this small script
   trap 'ls | wc' 1 2 3 15
   echo Reflex test. Type control-c
   ls | wc
   rm *

Because I also did "rm * .o"

I still have the ugly little warthog, anatomically correct, on my desk.

[-- Attachment #2: Type: text/html, Size: 473 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-17  1:26       ` Clem cole
@ 2019-09-17  1:33         ` Larry McVoy
  2019-09-17 22:39           ` Dave Horsfall
  2019-09-17  1:36         ` Richard Salz
  1 sibling, 1 reply; 148+ messages in thread
From: Larry McVoy @ 2019-09-17  1:33 UTC (permalink / raw)
  To: Clem cole; +Cc: tuhs

In retrospect having / be roots home is a super bad idea but I think it
was fairly common practice, /root became a thing as idiots like me 
messed things up :)

On Mon, Sep 16, 2019 at 09:26:34PM -0400, Clem cole wrote:
> I???ve forgotten but it could have been early on. Having /root as the super users home directory was on later systems. I thought Masscomp did that but I might be thinking Stellar by then.  
> 
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
> 
> > On Sep 16, 2019, at 9:17 PM, Larry McVoy <lm@mcvoy.com> wrote:
> > 
> >> On Mon, Sep 16, 2019 at 09:11:17PM -0400, Arthur Krewat wrote:
> >>> On 9/16/2019 8:20 PM, Steve Johnson wrote:
> >>> One day I had been furiously editing a long program file for about an hour
> >>> and a half when I was called away to lunch, and, being hungry, didn't save
> >>> my file.?? When I got back to the terminal an hour later, I discovered two
> >>> things -- the system had crashed, and our cat had decided that the pile of
> >>> paper
> >>> on the floor made a great litter box.?? After a few choice words, I sighed
> >>> and picked up my highliter...
> >> 
> >> This should be engraved on a plaque somewhere. Only because I had almost the
> >> same thing happen to me, without the cat though. I had a printout of a
> >> "mail" program I had written on TOPS-10 at high school. I had to retype the
> >> entire thing after the file got corrupted.
> > 
> > I think we have all been there.  Something always goes wrong.  I wrote 
> > a paper about how to restore a Masscomp because I did rm -rf . in /.
> > I believe we had roots home as / because /usr was a different partition.
> > Clem, did Masscomp make roots home / or was that us?  Anyway, I did a
> > cd something
> > and somehow deleted the something and then did rm -rf .
> > Much fun was had, I was up all night putting things back together.
> > This was probably around 1984 or 1985, I was pretty green.

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

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-17  1:17     ` Larry McVoy
@ 2019-09-17  1:26       ` Clem cole
  2019-09-17  1:33         ` Larry McVoy
  2019-09-17  1:36         ` Richard Salz
  2019-09-17  1:57       ` Bakul Shah
  1 sibling, 2 replies; 148+ messages in thread
From: Clem cole @ 2019-09-17  1:26 UTC (permalink / raw)
  To: Larry McVoy; +Cc: tuhs

I’ve forgotten but it could have been early on. Having /root as the super users home directory was on later systems. I thought Masscomp did that but I might be thinking Stellar by then.  

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

> On Sep 16, 2019, at 9:17 PM, Larry McVoy <lm@mcvoy.com> wrote:
> 
>> On Mon, Sep 16, 2019 at 09:11:17PM -0400, Arthur Krewat wrote:
>>> On 9/16/2019 8:20 PM, Steve Johnson wrote:
>>> One day I had been furiously editing a long program file for about an hour
>>> and a half when I was called away to lunch, and, being hungry, didn't save
>>> my file.?? When I got back to the terminal an hour later, I discovered two
>>> things -- the system had crashed, and our cat had decided that the pile of
>>> paper
>>> on the floor made a great litter box.?? After a few choice words, I sighed
>>> and picked up my highliter...
>> 
>> This should be engraved on a plaque somewhere. Only because I had almost the
>> same thing happen to me, without the cat though. I had a printout of a
>> "mail" program I had written on TOPS-10 at high school. I had to retype the
>> entire thing after the file got corrupted.
> 
> I think we have all been there.  Something always goes wrong.  I wrote 
> a paper about how to restore a Masscomp because I did rm -rf . in /.
> I believe we had roots home as / because /usr was a different partition.
> Clem, did Masscomp make roots home / or was that us?  Anyway, I did a
> cd something
> and somehow deleted the something and then did rm -rf .
> Much fun was had, I was up all night putting things back together.
> This was probably around 1984 or 1985, I was pretty green.

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-17  0:20 ` Steve Johnson
  2019-09-17  1:11   ` Arthur Krewat
@ 2019-09-17  1:19   ` Bakul Shah
  1 sibling, 0 replies; 148+ messages in thread
From: Bakul Shah @ 2019-09-17  1:19 UTC (permalink / raw)
  To: Steve Johnson; +Cc: tuhs, Doug McIlroy

[-- Attachment #1: Type: text/plain, Size: 550 bytes --]

The one time you didn't want any cat output....

> On Sep 16, 2019, at 5:20 PM, Steve Johnson <scj@yaccman.com> wrote:
> 
> One day I had been furiously editing a long program file for about an hour and a half when I was called away to lunch, and, being hungry, didn't save
> my file.  When I got back to the terminal an hour later, I discovered two things -- the system had crashed, and our cat had decided that the pile of paper
> on the floor made a great litter box.  After a few choice words, I sighed and picked up my highliter...
> 


[-- Attachment #2: Type: text/html, Size: 2083 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-17  1:11   ` Arthur Krewat
@ 2019-09-17  1:17     ` Larry McVoy
  2019-09-17  1:26       ` Clem cole
  2019-09-17  1:57       ` Bakul Shah
  0 siblings, 2 replies; 148+ messages in thread
From: Larry McVoy @ 2019-09-17  1:17 UTC (permalink / raw)
  To: Arthur Krewat; +Cc: tuhs

On Mon, Sep 16, 2019 at 09:11:17PM -0400, Arthur Krewat wrote:
> On 9/16/2019 8:20 PM, Steve Johnson wrote:
> >One day I had been furiously editing a long program file for about an hour
> >and a half when I was called away to lunch, and, being hungry, didn't save
> >my file.?? When I got back to the terminal an hour later, I discovered two
> >things -- the system had crashed, and our cat had decided that the pile of
> >paper
> >on the floor made a great litter box.?? After a few choice words, I sighed
> >and picked up my highliter...
> 
> This should be engraved on a plaque somewhere. Only because I had almost the
> same thing happen to me, without the cat though. I had a printout of a
> "mail" program I had written on TOPS-10 at high school. I had to retype the
> entire thing after the file got corrupted.

I think we have all been there.  Something always goes wrong.  I wrote 
a paper about how to restore a Masscomp because I did rm -rf . in /.
I believe we had roots home as / because /usr was a different partition.
Clem, did Masscomp make roots home / or was that us?  Anyway, I did a
cd something
and somehow deleted the something and then did rm -rf .
Much fun was had, I was up all night putting things back together.
This was probably around 1984 or 1985, I was pretty green.

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-17  0:20 ` Steve Johnson
@ 2019-09-17  1:11   ` Arthur Krewat
  2019-09-17  1:17     ` Larry McVoy
  2019-09-17  1:19   ` Bakul Shah
  1 sibling, 1 reply; 148+ messages in thread
From: Arthur Krewat @ 2019-09-17  1:11 UTC (permalink / raw)
  To: tuhs

On 9/16/2019 8:20 PM, Steve Johnson wrote:
> One day I had been furiously editing a long program file for about an 
> hour and a half when I was called away to lunch, and, being hungry, 
> didn't save
> my file.  When I got back to the terminal an hour later, I discovered 
> two things -- the system had crashed, and our cat had decided that the 
> pile of paper
> on the floor made a great litter box.  After a few choice words, I 
> sighed and picked up my highliter...

This should be engraved on a plaque somewhere. Only because I had almost 
the same thing happen to me, without the cat though. I had a printout of a
"mail" program I had written on TOPS-10 at high school. I had to retype 
the entire thing after the file got corrupted.

Yay MACRO-10

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-15 22:07 Doug McIlroy
@ 2019-09-17  0:20 ` Steve Johnson
  2019-09-17  1:11   ` Arthur Krewat
  2019-09-17  1:19   ` Bakul Shah
  0 siblings, 2 replies; 148+ messages in thread
From: Steve Johnson @ 2019-09-17  0:20 UTC (permalink / raw)
  To: Doug McIlroy, tuhs

[-- Attachment #1: Type: text/plain, Size: 2570 bytes --]


Dennis had a model 37 on his sunporch for years.  The innards were
nearly all mechanical -- cams and levers, etc.  And as the years went
by, wear and tear made the thing shake when it was being used.  
From time to time, it would shake so much that a space would be added
into whatever you were typing.

I think Dennis finally retired it after he typed the command "rm
*.o"  (a common command in those days of small discs), and got the
respnse ".o not found"

The model37 used fan-fold paper, that we got by the box.  It was an
art to arrange the paper flow so that the output didn't pile up inside
the box of blank paper,
but rather ended up in a pile on the floor.

In this era, Unix would, from time to time, crash unexpectedly,
causing you to lose all the edits you hadn't written out yet.  The
drill in that case was to
gather up the paper with all your typing on it, and, with a
highlighter, highlight the stuff you needed to retype when the system
came up.

One day I had been furiously editing a long program file for about an
hour and a half when I was called away to lunch, and, being hungry,
didn't save
my file.  When I got back to the terminal an hour later, I discovered
two things -- the system had crashed, and our cat had decided that the
pile of paper
on the floor made a great litter box.  After a few choice words, I
sighed and picked up my highliter...

Steve

----- Original Message -----
From: "Doug McIlroy" <doug@cs.dartmouth.edu>
To:<tuhs@tuhs.org>
Cc:
Sent:Sun, 15 Sep 2019 18:07:11 -0400
Subject:Re: [TUHS] earliest Unix roff

 > Excellent - thanks for the pointer. This shows nroff before troff.
 > FWIW: I guess I was miss informed, but I had been under the
impression
 > that was the other way around. i.e. nroff was done to be compliant
with
 > the new troff, replacing roff, although the suggestion here is that
he
 > wrote it add macros to roff. I'll note that either way, the dates
are all
 > possible of course because the U/L case ASR 37 was introduced 1968
so by
 > the early 1970's they would have been around the labs.

 nroff was in v2; troff appeared in v4, which incidentally was
 typeset in troff.

 Because of Joe Ossanna's role in designing the model 37, we
 had 37's in the Labs and even in our homes right from the
 start of production. But when they went obsolete, they were
 a chore to get rid of. As Labs property, they had to be
 returned; and picking them up was nobody's priority.
 Andy Hall had one on his back porch for a year.

 Doug



[-- Attachment #2: Type: text/html, Size: 3423 bytes --]

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
@ 2019-09-15 22:07 Doug McIlroy
  2019-09-17  0:20 ` Steve Johnson
  0 siblings, 1 reply; 148+ messages in thread
From: Doug McIlroy @ 2019-09-15 22:07 UTC (permalink / raw)
  To: tuhs

> Excellent - thanks for the pointer.   This shows nroff before troff.
>  FWIW: I guess I was miss informed, but I had been under the impression
> that was the other way around.  i.e. nroff was done to be compliant with
> the new troff, replacing roff, although the suggestion here is that he
> wrote it add macros to roff.  I'll note that either way, the dates are all
> possible of course because the U/L case ASR 37 was introduced 1968 so by
> the early 1970's they would have been around the labs.

nroff was in v2; troff appeared in v4, which incidentally was
typeset in troff.

Because of Joe Ossanna's role in designing the model 37, we
had 37's in the Labs and even in our homes right from the
start of production. But when they went obsolete, they were
a chore to get rid of. As Labs property, they had to be
returned; and picking them up was nobody's priority.
Andy Hall had one on his back porch for a year.

Doug

^ permalink raw reply	[flat|nested] 148+ messages in thread

* Re: [TUHS] earliest Unix roff
@ 2019-09-15  2:45 Doug McIlroy
  0 siblings, 0 replies; 148+ messages in thread
From: Doug McIlroy @ 2019-09-15  2:45 UTC (permalink / raw)
  To: tuhs

> I'd love to see the docs on that early stuff and see if Joe Ossanna
> added in his own magic or was he carrying forward earlier magic.

Here are scans of non-unix roff in 1971: https://www.cs.dartmouth.edu/~doug/roff71/roff71
I also have 1969, but it's bedtime and that will have to wait.

Relative numbers (+n), roman numerals, .ti, top and bottom margin settings,
.po, running titles, tab settings, hyphenation and footnotes were not in
Saltzer's runoff. Most other features were. 

Doug

^ permalink raw reply	[flat|nested] 148+ messages in thread

end of thread, other threads:[~2019-10-09  1:10 UTC | newest]

Thread overview: 148+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-13  3:20 [TUHS] My EuroBSDcon talk (preview for commentary) Warner Losh
2019-09-13  9:03 ` Branden Robinson
2019-09-13 19:47 ` Clem Cole
2019-09-13 20:02   ` Clem Cole
2019-09-13 20:06     ` Clem Cole
2019-09-13 20:24       ` Jon Steinhart
2019-09-13 20:43         ` Clem Cole
2019-09-13 20:53           ` Diomidis Spinellis
2019-09-13 21:45             ` Clem Cole
2019-09-13 22:13               ` [TUHS] earliest Unix roff Warren Toomey
2019-09-13 22:55                 ` Clem Cole
2019-09-14  2:02                   ` Larry McVoy
2019-09-14  2:44                     ` Warren Toomey
2019-09-15  2:56                       ` U'll Be King of the Stars
2019-09-15  6:54                         ` arnold
2019-09-15  7:01                           ` Dave Horsfall
2019-09-15 16:17                             ` Jon Steinhart
2019-09-15 17:23                               ` Ronald Natalie
2019-09-15 19:48                             ` Clem Cole
2019-09-15 21:16                               ` Dave Horsfall
2019-09-15  7:32                           ` U'll Be King of the Stars
2019-09-15  7:46                             ` arnold
2019-09-15 19:37                           ` Clem Cole
2019-09-16  5:52                             ` arnold
2019-09-16 12:10                               ` Clem Cole
2019-09-16 12:26                                 ` Lars Brinkhoff
2019-09-16 13:42                                   ` Clem Cole
2019-09-16 14:54                                     ` Larry McVoy
2019-09-16 16:09                                     ` Paul Winalski
2019-09-16 22:05                                     ` Dave Horsfall
2019-09-16 22:33                                       ` reed
2019-09-17  0:11                                         ` Dave Horsfall
2019-09-17  0:02                                       ` Nemo Nusquam
2019-09-17  0:21                                         ` Arthur Krewat
2019-09-17 11:12                                         ` Thomas Paulsen
2019-09-17  0:46                                       ` Clem Cole
2019-09-16 13:13                                 ` Chet Ramey
2019-09-16 14:51                                 ` Larry McVoy
2019-09-16 14:57                                   ` Clem Cole
2019-09-16 15:14                                     ` Richard Salz
2019-09-16 15:48                                       ` Ronald Natalie
2019-09-16 16:10                                       ` Larry McVoy
2019-09-16 16:16                                         ` Jon Steinhart
2019-09-16 16:26                                           ` Larry McVoy
2019-09-16 16:31                                             ` Richard Salz
2019-09-16 16:45                                               ` Larry McVoy
2019-09-16 17:19                                                 ` KatolaZ
2019-09-16 17:24                                                   ` Larry McVoy
2019-09-16 17:32                                                     ` Jon Steinhart
2019-09-16 17:35                                                     ` Clem Cole
2019-09-16 17:37                                                   ` Jon Steinhart
2019-09-16 18:09                                                     ` [TUHS] [OT] " KatolaZ
2019-09-16 18:19                                                       ` Jon Steinhart
2019-09-16 18:04                                                   ` [TUHS] " Chet Ramey
2019-09-16 18:19                                                     ` KatolaZ
2019-09-16 23:24                                                     ` Dave Horsfall
2019-09-16 17:24                                                 ` Clem Cole
2019-09-16 17:00                                               ` Clem Cole
2019-09-17 11:20                                         ` Thomas Paulsen
2019-09-16 19:13                                       ` Steffen Nurpmeso
2019-09-16 19:31                                       ` Bakul Shah
2019-09-16 22:35                                     ` Dave Horsfall
2019-09-17  7:53                                   ` arnold
2019-09-17 14:21                                     ` Clem Cole
2019-09-17 15:03                                       ` arnold
2019-09-17 15:58                                     ` Christopher Browne
2019-09-17 18:15                                       ` arnold
2019-09-17 18:32                                         ` Warner Losh
2019-09-18  0:42                                         ` Adam Thornton
2019-09-16 21:42                                 ` Dave Horsfall
2019-09-16 21:48                                   ` Larry McVoy
2019-09-16 21:54                                     ` Jon Steinhart
2019-09-16 21:59                                       ` Larry McVoy
2019-09-17  5:07                                         ` Lars Brinkhoff
2019-09-16 22:10                                       ` Bakul Shah
2019-09-17  0:16                                   ` Greg 'groggy' Lehey
2019-09-17  0:31                                     ` Jon Steinhart
2019-09-17 12:20                                     ` David
2019-10-05 19:44                                 ` Michael Parson
2019-09-15 19:35                         ` Clem Cole
2019-09-15 20:49                           ` U'll Be King of the Stars
2019-09-16  6:20                             ` arnold
2019-09-16 12:13                               ` Clem Cole
2019-09-16 12:34                                 ` arnold
2019-09-16 14:52                                 ` Larry McVoy
2019-09-17  0:10                               ` [TUHS] O'Reilly groff macros (was: earliest Unix roff) Greg 'groggy' Lehey
2019-09-17  0:51                                 ` Clem Cole
2019-09-17  0:54                                   ` [TUHS] O'Reilly groff macros U'll Be King of the Stars
2019-09-17  1:03                                     ` Clem Cole
2019-09-17  1:41                                     ` Greg 'groggy' Lehey
2019-09-17  1:58                                       ` Clem cole
2019-09-15 19:27                       ` [TUHS] earliest Unix roff Clem Cole
2019-09-15 19:31                         ` Jon Steinhart
2019-09-14  7:35               ` [TUHS] My EuroBSDcon talk (preview for commentary) Diomidis Spinellis
2019-09-13 21:31       ` Clem Cole
2019-09-17 19:29         ` Warner Losh
2019-09-17 20:17           ` Clem Cole
2019-09-17 19:18       ` Warner Losh
2019-09-17 20:13         ` Clem Cole
2019-09-13 20:06     ` Larry McVoy
2019-09-14  6:13   ` Wesley Parish
2019-09-15 21:46 ` Clem Cole
2019-09-15 23:25   ` Bakul Shah
2019-09-15 23:35     ` Clem cole
2019-09-16  1:42     ` Warner Losh
2019-09-16  1:52       ` Clem cole
2019-09-16  2:05         ` George Michaelson
2019-09-16  2:37           ` Bakul Shah
2019-09-16  3:29             ` [TUHS] INed/Rand Editor/Ned [was " Charles H. Sauer
2019-09-16 14:53               ` Clem Cole
2019-09-16 16:16                 ` Warner Losh
2019-09-16 20:21                   ` G. Branden Robinson
2019-09-16 20:47                     ` Jon Steinhart
2019-09-16 22:33                       ` George Michaelson
2019-09-16 23:14                         ` G. Branden Robinson
2019-10-09  1:10                         ` Lyndon Nerenberg
2019-09-16 22:48                       ` [TUHS] better ways and termcap vs. terminfo " G. Branden Robinson
2019-09-17 11:46                     ` [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview " Theodore Y. Ts'o
2019-09-17 12:52                       ` G. Branden Robinson
2019-10-09  0:38                   ` Lyndon Nerenberg
2019-09-16  1:31   ` [TUHS] " William Pechter
2019-09-16  1:48     ` Clem cole
2019-09-16  2:24     ` Dave Horsfall
2019-09-16  2:31       ` Toby Thain
2019-09-16  3:36   ` Theodore Y. Ts'o
2019-09-15  2:45 [TUHS] earliest Unix roff Doug McIlroy
2019-09-15 22:07 Doug McIlroy
2019-09-17  0:20 ` Steve Johnson
2019-09-17  1:11   ` Arthur Krewat
2019-09-17  1:17     ` Larry McVoy
2019-09-17  1:26       ` Clem cole
2019-09-17  1:33         ` Larry McVoy
2019-09-17 22:39           ` Dave Horsfall
2019-09-17  1:36         ` Richard Salz
2019-09-17  1:57       ` Bakul Shah
2019-09-17  1:19   ` Bakul Shah
2019-09-19 18:10 Norman Wilson
2019-09-19 18:37 ` Clem Cole
2019-09-19 18:44   ` Jon Steinhart
2019-09-19 19:44 ` Steffen Nurpmeso
2019-09-19 20:38   ` John P. Linderman
2019-09-20 13:41     ` Steffen Nurpmeso
2019-09-20 15:03       ` Steffen Nurpmeso
2019-09-19 20:53 ` Bakul Shah
2019-09-19 18:42 Norman Wilson
2019-09-19 22:42 ` Rob Pike
2019-09-19 22:55   ` Bakul Shah
2019-09-19 18:50 [TUHS] [OT] " Norman Wilson
2019-09-19 19:00 ` Nemo Nusquam
2019-09-19 20:18   ` Larry McVoy
2019-09-19 20:42     ` [TUHS] " Andy Kosela

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).