[TUHS] My EuroBSDcon talk (preview for commentary)

[TUHS] My EuroBSDcon talk (preview for commentary)

[Warner Losh]

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

Re: [TUHS] My EuroBSDcon talk (preview for commentary)

[Branden Robinson]

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

Re: [TUHS] My EuroBSDcon talk (preview for commentary)

[Clem Cole]

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

Re: [TUHS] My EuroBSDcon talk (preview for commentary)

[Clem Cole]

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

Re: [TUHS] My EuroBSDcon talk (preview for commentary)

[Clem Cole]

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

Re: [TUHS] My EuroBSDcon talk (preview for commentary)

[Jon Steinhart]

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

Re: [TUHS] My EuroBSDcon talk (preview for commentary)

[Clem Cole]

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

Re: [TUHS] My EuroBSDcon talk (preview for commentary)

[Diomidis Spinellis]

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.

Re: [TUHS] My EuroBSDcon talk (preview for commentary)

[Clem Cole]

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

Re: [TUHS] earliest Unix roff

[Warren Toomey]

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

Re: [TUHS] earliest Unix roff

[Clem Cole]

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

Re: [TUHS] earliest Unix roff

[Larry McVoy]

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

Re: [TUHS] earliest Unix roff

[Warren Toomey]

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

Re: [TUHS] earliest Unix roff

[U'll Be King of the Stars]

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

Re: [TUHS] earliest Unix roff

[arnold]

"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

Re: [TUHS] earliest Unix roff

[Dave Horsfall]

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

Re: [TUHS] earliest Unix roff

[Jon Steinhart]

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

Re: [TUHS] earliest Unix roff

[Ronald Natalie]

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.

Re: [TUHS] earliest Unix roff

[Clem Cole]

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

Re: [TUHS] earliest Unix roff

[Dave Horsfall]

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

Re: [TUHS] earliest Unix roff

[U'll Be King of the Stars]

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

Re: [TUHS] earliest Unix roff

[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

Re: [TUHS] earliest Unix roff

[Clem Cole]

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

Re: [TUHS] earliest Unix roff

[arnold]

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

Re: [TUHS] earliest Unix roff

[Clem Cole]

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

Re: [TUHS] earliest Unix roff

[Lars Brinkhoff]

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.

Re: [TUHS] earliest Unix roff

[Clem Cole]

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

Re: [TUHS] earliest Unix roff

[Larry McVoy]

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 

Re: [TUHS] earliest Unix roff

[Paul Winalski]

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.

Re: [TUHS] earliest Unix roff

[Dave Horsfall]

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

Re: [TUHS] earliest Unix roff

[reed]

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

Re: [TUHS] earliest Unix roff

[Dave Horsfall]

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

Re: [TUHS] earliest Unix roff

[Nemo Nusquam]

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.

Re: [TUHS] earliest Unix roff

[Arthur Krewat]

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.

Re: [TUHS] earliest Unix roff

[Thomas Paulsen]

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.

Re: [TUHS] earliest Unix roff

[Clem Cole]

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

Re: [TUHS] earliest Unix roff

[Chet Ramey]

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/

Re: [TUHS] earliest Unix roff

[Larry McVoy]

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.

Re: [TUHS] earliest Unix roff

[Clem Cole]

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

Re: [TUHS] earliest Unix roff

[Richard Salz]

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

Re: [TUHS] earliest Unix roff

[Ronald Natalie]

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

Re: [TUHS] earliest Unix roff

[Larry McVoy]

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

Re: [TUHS] earliest Unix roff

[Jon Steinhart]

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.

Re: [TUHS] earliest Unix roff

[Larry McVoy]

+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 

Re: [TUHS] earliest Unix roff

[Richard Salz]

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

Re: [TUHS] earliest Unix roff

[Larry McVoy]

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.

Re: [TUHS] earliest Unix roff

[KatolaZ]

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

Re: [TUHS] earliest Unix roff

[Larry McVoy]

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.

Re: [TUHS] earliest Unix roff

[Jon Steinhart]

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 ]

Re: [TUHS] earliest Unix roff

[Clem Cole]

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

Re: [TUHS] earliest Unix roff

[Jon Steinhart]

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

[TUHS] [OT] Re: earliest Unix roff

[KatolaZ]

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

Re: [TUHS] [OT] Re: earliest Unix roff

[Jon Steinhart]

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

Re: [TUHS] earliest Unix roff

[Chet Ramey]

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

Re: [TUHS] earliest Unix roff

[KatolaZ]

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

Re: [TUHS] earliest Unix roff

[Dave Horsfall]

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

Re: [TUHS] earliest Unix roff

[Clem Cole]

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

Re: [TUHS] earliest Unix roff

[Clem Cole]

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

Re: [TUHS] earliest Unix roff

[Thomas Paulsen]

 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.

Re: [TUHS] earliest Unix roff

[Steffen Nurpmeso]

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)

Re: [TUHS] earliest Unix roff

[Bakul Shah]

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

Re: [TUHS] earliest Unix roff

[Dave Horsfall]

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

Re: [TUHS] earliest Unix roff

[arnold]

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.

Re: [TUHS] earliest Unix roff

[Clem Cole]

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

Re: [TUHS] earliest Unix roff

[arnold]

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

Re: [TUHS] earliest Unix roff

[Christopher Browne]

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

Re: [TUHS] earliest Unix roff

[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

Re: [TUHS] earliest Unix roff

[Warner Losh]

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

Re: [TUHS] earliest Unix roff

[Adam Thornton]

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

Re: [TUHS] earliest Unix roff

[Dave Horsfall]

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

Re: [TUHS] earliest Unix roff

[Larry McVoy]

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.

Re: [TUHS] earliest Unix roff

[Jon Steinhart]

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

Re: [TUHS] earliest Unix roff

[Larry McVoy]

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.

Re: [TUHS] earliest Unix roff

[Lars Brinkhoff]

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.

Re: [TUHS] earliest Unix roff

[Bakul Shah]

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.

Re: [TUHS] earliest Unix roff

[Greg 'groggy' Lehey]

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

Re: [TUHS] earliest Unix roff

[Jon Steinhart]

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?

Re: [TUHS] earliest Unix roff

[David]

> 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

Re: [TUHS] earliest Unix roff

[Michael Parson]

(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

Re: [TUHS] earliest Unix roff

[Clem Cole]

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

Re: [TUHS] earliest Unix roff

[U'll Be King of the Stars]

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

Re: [TUHS] earliest Unix roff

[arnold]

"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

Re: [TUHS] earliest Unix roff

[Clem Cole]

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

Re: [TUHS] earliest Unix roff

[arnold]

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

Re: [TUHS] earliest Unix roff

[Larry McVoy]

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.

[TUHS] O'Reilly groff macros (was: earliest Unix roff)

[Greg 'groggy' Lehey]

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

Re: [TUHS] O'Reilly groff macros (was: earliest Unix roff)

[Clem Cole]

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

Re: [TUHS] O'Reilly groff macros

[U'll Be King of the Stars]

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

Re: [TUHS] O'Reilly groff macros

[Clem Cole]

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

Re: [TUHS] O'Reilly groff macros

[Greg 'groggy' Lehey]

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

Re: [TUHS] O'Reilly groff macros

[Clem cole]

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

Re: [TUHS] earliest Unix roff

[Clem Cole]

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

Re: [TUHS] earliest Unix roff

[Jon Steinhart]

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.

Re: [TUHS] My EuroBSDcon talk (preview for commentary)

[Diomidis Spinellis]

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.

Re: [TUHS] My EuroBSDcon talk (preview for commentary)

[Clem Cole]

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

Re: [TUHS] My EuroBSDcon talk (preview for commentary)

[Warner Losh]

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

Re: [TUHS] My EuroBSDcon talk (preview for commentary)

[Clem Cole]

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

Re: [TUHS] My EuroBSDcon talk (preview for commentary)

[Warner Losh]

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

Re: [TUHS] My EuroBSDcon talk (preview for commentary)

[Clem Cole]

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

Re: [TUHS] My EuroBSDcon talk (preview for commentary)

[Larry McVoy]

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 

Re: [TUHS] My EuroBSDcon talk (preview for commentary)

[Wesley Parish]

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

Re: [TUHS] My EuroBSDcon talk (preview for commentary)

[Clem Cole]

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

Re: [TUHS] My EuroBSDcon talk (preview for commentary)

[Bakul Shah]

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

Re: [TUHS] My EuroBSDcon talk (preview for commentary)

[Clem cole]

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

Re: [TUHS] My EuroBSDcon talk (preview for commentary)

[Warner Losh]

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

Re: [TUHS] My EuroBSDcon talk (preview for commentary)

[Clem cole]

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

Re: [TUHS] My EuroBSDcon talk (preview for commentary)

[George Michaelson]

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

Re: [TUHS] My EuroBSDcon talk (preview for commentary)

[Bakul Shah]

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!

[TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary)

[Charles H. Sauer]

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

Re: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary)

[Clem Cole]

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

Re: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary)

[Warner Losh]

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

Re: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary)

[G. Branden Robinson]

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

Re: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary)

[Jon Steinhart]

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

Re: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary)

[George Michaelson]

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*

Re: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary)

[G. Branden Robinson]

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

Re: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary)

[Lyndon Nerenberg]

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

Re: [TUHS] better ways and termcap vs. terminfo for commentary)

[G. Branden Robinson]

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

Re: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary)

[Theodore Y. Ts'o]

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

Re: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary)

[G. Branden Robinson]

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

Re: [TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary)

[Lyndon Nerenberg]

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

Re: [TUHS] My EuroBSDcon talk (preview for commentary)

[William Pechter]

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/

Re: [TUHS] My EuroBSDcon talk (preview for commentary)

[Clem cole]

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

Re: [TUHS] My EuroBSDcon talk (preview for commentary)

[Dave Horsfall]

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

Re: [TUHS] My EuroBSDcon talk (preview for commentary)

[Toby Thain]

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

Re: [TUHS] My EuroBSDcon talk (preview for commentary)

[Theodore Y. Ts'o]

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

Re: [TUHS] [OT] Re: earliest Unix roff

[Norman Wilson]

KatolaZ:
> 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 needn't discuss that (though of course there are opinions and
mine are the correct ones), but in the interest of historic accuracy,
I should point out by 1979 (V7) cat had developed a single option -u
to turn off stdio buffering.

Sometime before 1984 or so, that option was removed, and cat was
simplified to just
	while ((n = read(fd, buf, sizeof(buf))) > 0)
		write(1, buf, n)
(error checking elided for clarity)
which worked just fine for the rest of the life of the Research
system.

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.

Norman Wilson
Toronto ON
(Three cats, no options)

Re: [TUHS] [OT] Re: earliest Unix roff

[Nemo Nusquam]

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

N.

> Norman Wilson
> Toronto ON
> (Three cats, no options)

Re: [TUHS] [OT] Re: earliest Unix roff

[Larry McVoy]

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

Re: [TUHS] [OT] Re: earliest Unix roff

[Arthur Krewat]

Serious question:

Which is better, creating a whole new binary to put in /usr/bin to do a 
single task, or add a flag to cat?

Which is better, a proliferation of binaries w/standalone source code, 
or a single code tree that can handle slightly different tasks and save 
space?

:)

art k.

PS: Using argv[0] (as in a symbolic link) to alter a program's behavior 
instead of using flags is cheating on the above test.




On 9/19/2019 4:18 PM, Larry McVoy 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
>

Re: [TUHS] [OT] Re: earliest Unix roff

[Jon Steinhart]

Arthur Krewat writes:
> Serious question:
>
> Which is better, creating a whole new binary to put in /usr/bin to do a 
> single task, or add a flag to cat?
>
> Which is better, a proliferation of binaries w/standalone source code, 
> or a single code tree that can handle slightly different tasks and save 
> space?
>
> :)
>
> art k.
>
> PS: Using argv[0] (as in a symbolic link) to alter a program's behavior 
> instead of using flags is cheating on the above test.

I would argue the first.  In the case of current linux cat, I would make a
separate utility to number lines, a separate utility to squeeze out repeated
empty blank lines, a separate utility to show non printing characters that
might have an option to select the characters that would encompass -T.  All of
these are useful utilities by themselves.  Someone using a particular combo of
options a lot can always write their own scripts or use aliases.  That's the
beauty of composability.

Jon

Re: [TUHS] [OT] Re: earliest Unix roff

[Steve Nickolas]

On Thu, 19 Sep 2019, Arthur Krewat wrote:

> Serious question:
>
> Which is better, creating a whole new binary to put in /usr/bin to do a 
> single task, or add a flag to cat?
>
> Which is better, a proliferation of binaries w/standalone source code, or a 
> single code tree that can handle slightly different tasks and save space?
>
> :)
>
> art k.

I would argue that the more "Unix" way to do it is have the multiple 
binaries.  One job, one tool, and chain them together to make bigger 
tools.

-uso.

Re: [TUHS] [OT] Re: earliest Unix roff

[Larry McVoy]

On Thu, Sep 19, 2019 at 05:46:13PM -0400, Steve Nickolas wrote:
> On Thu, 19 Sep 2019, Arthur Krewat wrote:
> 
> >Serious question:
> >
> >Which is better, creating a whole new binary to put in /usr/bin to do a
> >single task, or add a flag to cat?
> >
> >Which is better, a proliferation of binaries w/standalone source code, or
> >a single code tree that can handle slightly different tasks and save
> >space?
> >
> >:)
> >
> >art k.
> 
> I would argue that the more "Unix" way to do it is have the multiple
> binaries.  One job, one tool, and chain them together to make bigger tools.

That worked when we were running on 64K machines.  Modern machines do
a lot more and the problem space is not always a pipeline.

You aren't going to write a web server by spawning 

	cat | encrypt | http_servlet

That doesn't scale.  At all.

Re: [TUHS] [OT] Re: earliest Unix roff

[Rob Pike]

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

This was my fault, and it happened because I confronted DMR about the -u
flag for cat. He said it was there because it seemed important that cat be
writable in stdio, which was new at the time. I agreed but said the point
had been made and avoiding unnecessary flags was a higher goal. So cat was
simplified to do what it said, no more and no less, with read and write and
no nonsense.

-rob




On Fri, Sep 20, 2019 at 4:51 AM Norman Wilson <norman@oclsc.org> wrote:

> KatolaZ:
> > 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 needn't discuss that (though of course there are opinions and
> mine are the correct ones), but in the interest of historic accuracy,
> I should point out by 1979 (V7) cat had developed a single option -u
> to turn off stdio buffering.
>
> Sometime before 1984 or so, that option was removed, and cat was
> simplified to just
>         while ((n = read(fd, buf, sizeof(buf))) > 0)
>                 write(1, buf, n)
> (error checking elided for clarity)
> which worked just fine for the rest of the life of the Research
> system.
>
> 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.
>
> Norman Wilson
> Toronto ON
> (Three cats, no options)
>

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

Re: [TUHS] [OT] Re: earliest Unix roff

[Norman Wilson]

Arthur Krewat:

  Which is better, creating a whole new binary to put in /usr/bin to do a 
  single task, or add a flag to cat?

  Which is better, a proliferation of binaries w/standalone source code, 
  or a single code tree that can handle slightly different tasks and save 
  space?

======

Which is simpler to write correctly, to debug, and to maintain:
a simple program that does a single task, or a huge single program
with lots of tasks mashed together?

Which is easier to understand and use, individual programs each
with a few options specialized to a particular task, or a monolith
with many more options some of which apply only to one task or
another, others to all?

What are you trying to optimize for?  The speed with which
programmers can churn out yet another featureful utility full
of bugs and corner cases, or the ease with which the end-user
can figure out what tool to use and how to use it?

Norman Wilson
Toronto ON