From jnc at mercury.lcs.mit.edu  Tue May  1 01:05:32 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 30 Apr 2018 11:05:32 -0400 (EDT)
Subject: [TUHS] /dev/drum
Message-ID: <20180430150532.4B67218C09C@mercury.lcs.mit.edu>

    > From: Johnny Billquist

    > This is where I disagree. The problem is that the chunks in the PDP-11
    > do not describe things from a zero offset, while a segment do. Only
    > chunk 0 is describing addresses from a 0 offset. And exactly which chunk
    > is selected is based on the virtual address, and nothing else.

Well, you have something of a point, but... it depends on how you look at it.
If you think of a PDP-11 address as holding two concatenated fields (3 bits of
'segment' and 13 bits of 'offset within segment'), not so much.

IIRC there are other segmented machines that do things this way - I can't
recall the details of any off the top of my head. (Well, there the KA10/KI10,
with their writeable/write-protected 'chunks', but that's a bit of a
degenerate case. I'm sure there is some segmented machine that works that way,
but I can't recall it.)

BTW, this reminds me of another key differentiator between paging and
segments, which is that paging was originally _invisible_ to the user (except
for setting the total size of the process), whereas segmentation is explicitly
visible to the user.

I think there is at least one PDP-11 OS which makes the 'chunks' visible to
the user - MERT (and speaking of which, I need to get back on my project of
trying to track down source/documentation for it).


    > Demand paging really is a separate thing from virtual memory. It's a
    > very bad thing to try and conflate the two.

Really? I always worked on the basis that the two terms were synonyms - but
I'm very open to the possibility that there is a use to having them have
distinct meanings.

I see a definition of 'virtual memory' below, but what would you use for
'paging'?

Now that I think about it, there are actually _three_ concepts: 'virtual
memory', as you define it; what I will call 'non-residence' - i.e. a process
can run without _all_ of its virtual memory being present in physical memory;
and 'paging' - which I would define as 'use fixed-size blocks'. (The third is
more of an engineering thing, rather than high-level architecture, since it
means you never have to 'shuffle' core, as systems that used variable-sized
things seem to.)

'Non-residence' is actually orthogonal to 'paging'; I can imagine a paging
system which didn't support non-residence, and vice versa (either swapping
the entire virtual address space, or doing it a segment at a time if the
system has segments).

    > There is nothing about virtual memory that says that you do not have to
    > have all of your virtual memory mapped to physical memory when the
    > process is running.

True.

    > Virtual memory is just *virtual* memory. It's not "real" or physical in
    > the sense that it has a dedicated location in physical memory, which
    > would be the same for all processes talking about that memory
    > address. Instead, each process has its own memory, which might be mapped
    > somewhere in physical memory, but it might also not be.

OK so far.

    > each process would have to be aware of all the other processes that use
    > memory, and make sure that no two processes try to use the same memory,
    > or chaos ensues.

There's also the System 360 approach, where processes share a single address
space (physical memory - no virtual memory on them!), but it uses protection
keys on memory 'chunks' (not sure of the correct IBM term) to ensure that one
process can't tromp on another's memory.


    >> a memory management device for the PDP-11 which provided 'real' paging,
    >> the KT11-B?

    > have never read any technical details. Interesting read.

Yes, we were lucky to be able to retrieve detailed info on it! A PDP-11/20
sold on eBay with a fairly complete set of KT11-B documentation, and allegedly
a "KT11-B" as well, but alas, it turned out to 'only' be an RK11-C. Not that
RK11-C's aren't cool, but on the 'cool scale' they are like 3, whereas a
KT11-B would have been, like, 17! :-) Still, we managed to get the KT11-B
'manual' (such as it is) and prints online.

I'd love to find out equivalent detail for the KT11-A, but I've never seen
anything on it. (And I've appealed before for the KS11, which an early PDP-11
Unix apparently used, but no joy.)


    > But how do you then view modern architectures which have different sized
    > pages? Are they no longer pages then?

Actually, there is precedent for that. The original Multics hardware, the
GE-645, supported two page sizes. That was dropped in later machines (the
Honeywell 6000's) since it was decided that the extra complexity wasn't worth
it.

I don't have any problem with several different page sizes, _if it makes
engineering sense to support them_. (I assume that the rationale for their
re-introduction is that in the age of 64-bit machines, page tables for very
large 'chunks' can be very large if pages of ~1K or so are used, or something
like.)

It does make real memory allocation (one of the advantages of paging) more
difficult, since there would now be small and large page frames. Although I
suppose it wouldn't be hard to coalesce them, if there are only two sizes, and
one's a small power-of-2 multiple of the other - like 'fragments' in the
Berkeley Fast File System for BSD4.2.

I have a query, though - how does a system with two page sizes know which to
use? On Multics (and probably on the x86), it's a per-segment attribute. But
on a system with a large, flat address space, how does the system know which
parts of it are using small pages, and which large?

      Noel


From paul.winalski at gmail.com  Tue May  1 02:43:50 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Mon, 30 Apr 2018 12:43:50 -0400
Subject: [TUHS] /dev/drum
In-Reply-To: <20180430150532.4B67218C09C@mercury.lcs.mit.edu>
References: <20180430150532.4B67218C09C@mercury.lcs.mit.edu>
Message-ID: <CABH=_VQcDma-wamSK8+ncMRq0UQYY4Py8Dte4vOJm7XQf75qXg@mail.gmail.com>

On 4/30/18, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>
> There's also the System 360 approach, where processes share a single
> address
> space (physical memory - no virtual memory on them!), but it uses
> protection
> keys on memory 'chunks' (not sure of the correct IBM term) to ensure that
> one
> process can't tromp on another's memory.

IBM always used the term "storage" rather than "memory".  The Storage
Protection feature for System/360 was optional on some models, and
provided a 4-bit protection key for each 2048-byte block (IBM's term)
of physical storage, allowing for up to 15 processes to be executing
simultaneously (key value 0 disabled storage protection).

The System/370 operating systems DOS/VS, OS/VS1, and OS/VS2 SVS all
had a single, demand-paged virtual address space, usually a few times
larger than the physical memory.  For DOS/VS the virtual address space
was partitioned into a space (mapped virtual=physical address)
starting at address 0 for the OS, then up to five user program
partitions.  Programs were linked to run in one of these partitions.
OS/VS1 (successor to OS/360 MFT) also had a single virtual address
space, but it had more partitions and the program loader could
dynamically relocate applications to run in any of the partitions.
OS/VS2 SVS (first successor to OS/360 MVT) had a single virtual
address space, but dynamically allocated partitions as needed.  OS/VS2
MVS had processes in the modern OS sense--each executing program got
its own virtual address space.

-Paul W.


From bqt at update.uu.se  Tue May  1 07:41:04 2018
From: bqt at update.uu.se (Johnny Billquist)
Date: Mon, 30 Apr 2018 23:41:04 +0200
Subject: [TUHS] /dev/drum
In-Reply-To: <20180430150532.4B67218C09C@mercury.lcs.mit.edu>
References: <20180430150532.4B67218C09C@mercury.lcs.mit.edu>
Message-ID: <91f53deb-a0b4-52a7-6b2e-20023570eddc@update.uu.se>

On 2018-04-30 17:05, Noel Chiappa wrote:
>      > From: Johnny Billquist
> 
>      > This is where I disagree. The problem is that the chunks in the PDP-11
>      > do not describe things from a zero offset, while a segment do. Only
>      > chunk 0 is describing addresses from a 0 offset. And exactly which chunk
>      > is selected is based on the virtual address, and nothing else.
> 
> Well, you have something of a point, but... it depends on how you look at it.
> If you think of a PDP-11 address as holding two concatenated fields (3 bits of
> 'segment' and 13 bits of 'offset within segment'), not so much.

Err... That would be a pretty ugly way to look at the world. Not to 
mention that one segment silently slides over into the next one if it's 
more than 8K. No, I think I prefer to not try to look at the world that 
way. :-)

> IIRC there are other segmented machines that do things this way - I can't
> recall the details of any off the top of my head. (Well, there the KA10/KI10,
> with their writeable/write-protected 'chunks', but that's a bit of a
> degenerate case. I'm sure there is some segmented machine that works that way,
> but I can't recall it.)

The KA/KI without the Twenex pager pretty much only had two segments, 
unless I remember wrong. It was the low segment and the high segment. 
Well, ok, that also implied that it was based on the virtual address, 
but these two segments were definitely treated as two separate spaces, 
that were never concatenated.

> BTW, this reminds me of another key differentiator between paging and
> segments, which is that paging was originally _invisible_ to the user (except
> for setting the total size of the process), whereas segmentation is explicitly
> visible to the user.

Good point.
Well, wouldn't you say that the "chunks" on a PDP-11 are invisible to 
the user? Unless you are the kernel of course. Or run without protection.

> I think there is at least one PDP-11 OS which makes the 'chunks' visible to
> the user - MERT (and speaking of which, I need to get back on my project of
> trying to track down source/documentation for it).

Don't know that system. But you could just argue that RT-11 also makes 
it all visible as well. Any OS which don't give you proper protection 
will allow you to play with all hardware, no matter how it appears.

>      > Demand paging really is a separate thing from virtual memory. It's a
>      > very bad thing to try and conflate the two.
> 
> Really? I always worked on the basis that the two terms were synonyms - but
> I'm very open to the possibility that there is a use to having them have
> distinct meanings.

*Demand* paging is definitely a separate concept from virtual memory.

OSes like RSX, RSTS/E, or Unix, on PDP-11s do give you virtual memory. 
However, none of them implement demand paging. The PDP-11 can, as you 
noted, also support demand paging, but there is little need for such an 
advanced mechanism on that machine, for several reasons.

When I first read about demand paging, it was in the context of VMS, and 
the simplicitly, elegance, and efficiency of it really impressed me.

Starting execution of an image in VMS really just meant that the OS read 
in the executable image meta information, which gave things like what 
memory addressed were defined. VMS created the page table, and marked 
every page as invalid, and then it started executing in the process. The 
first thing that would happen would of course be that you got a page 
fault by trying to fetch the instruction at the first address of the 
program. VMS immediately suspends execution until it have read in that 
page from the binary, marks that page as now having a valid translation, 
and then resumes execution. Of course, most likely you'll have a whole 
storm of page faults almost immediately after a process starts 
executing, but after a while, you'll be in a sort of balance where you 
mostly run without any more page faults.
(I would assume Unix does it the same way on modern machines.)

Very different than in RSX, for example, where the OS first makes sure 
all required virtual memory have valid translations before the process 
is allowed to execute.

> I see a definition of 'virtual memory' below, but what would you use for
> 'paging'?

"Paging" is a bit of an unclear term for me here. It might be referring 
to the reading in of a page at a page fault, which would be a demand 
paging situation, the paging out of individual pages as a demand paged 
system requires pages to fulfill needs of a different process, or it 
might mean the reading in or writing out of all pages of a process, in 
which case it would be close to a synonym with "swapping". So, in which 
way do you mean "paging"?

> Now that I think about it, there are actually _three_ concepts: 'virtual
> memory', as you define it; what I will call 'non-residence' - i.e. a process
> can run without _all_ of its virtual memory being present in physical memory;
> and 'paging' - which I would define as 'use fixed-size blocks'. (The third is
> more of an engineering thing, rather than high-level architecture, since it
> means you never have to 'shuffle' core, as systems that used variable-sized
> things seem to.)
> 
> 'Non-residence' is actually orthogonal to 'paging'; I can imagine a paging
> system which didn't support non-residence, and vice versa (either swapping
> the entire virtual address space, or doing it a segment at a time if the
> system has segments).

Yeah. And non-residence, as you call it, is what demand paging is.
Pages are brought into physical memory on demand.

The definition you use for paging here is an interesting point. Not sure 
how much of a thing it would be, but it might be a thing sometimes as 
well. But then we get into the question I asked further down, how do you 
then deal with when you have different sized pages on a system?
But "paging" just meaning "fixed size pages" is certainly a distinction 
you can make. I think I wouldn't find much use for it, but that don't 
mean others might not, or that it wouldn't be a possible classification.

>      > each process would have to be aware of all the other processes that use
>      > memory, and make sure that no two processes try to use the same memory,
>      > or chaos ensues.
> 
> There's also the System 360 approach, where processes share a single address
> space (physical memory - no virtual memory on them!), but it uses protection
> keys on memory 'chunks' (not sure of the correct IBM term) to ensure that one
> process can't tromp on another's memory.

Oh. There is no real connection between virtual memory and memory 
protection. One can exist with or without the other.

>      >> a memory management device for the PDP-11 which provided 'real' paging,
>      >> the KT11-B?
> 
>      > have never read any technical details. Interesting read.
> 
> Yes, we were lucky to be able to retrieve detailed info on it! A PDP-11/20
> sold on eBay with a fairly complete set of KT11-B documentation, and allegedly
> a "KT11-B" as well, but alas, it turned out to 'only' be an RK11-C. Not that
> RK11-C's aren't cool, but on the 'cool scale' they are like 3, whereas a
> KT11-B would have been, like, 17! :-) Still, we managed to get the KT11-B
> 'manual' (such as it is) and prints online.

Really cool. Thanks for sharing.

> I'd love to find out equivalent detail for the KT11-A, but I've never seen
> anything on it. (And I've appealed before for the KS11, which an early PDP-11
> Unix apparently used, but no joy.)

Might have been just some internal early attempt that never got out of DEC?

>      > But how do you then view modern architectures which have different sized
>      > pages? Are they no longer pages then?
> 
> Actually, there is precedent for that. The original Multics hardware, the
> GE-645, supported two page sizes. That was dropped in later machines (the
> Honeywell 6000's) since it was decided that the extra complexity wasn't worth
> it.
> 
> I don't have any problem with several different page sizes, _if it makes
> engineering sense to support them_. (I assume that the rationale for their
> re-introduction is that in the age of 64-bit machines, page tables for very
> large 'chunks' can be very large if pages of ~1K or so are used, or something
> like.)
> 
> It does make real memory allocation (one of the advantages of paging) more
> difficult, since there would now be small and large page frames. Although I
> suppose it wouldn't be hard to coalesce them, if there are only two sizes, and
> one's a small power-of-2 multiple of the other - like 'fragments' in the
> Berkeley Fast File System for BSD4.2.

So, would you then say that such machines do not have pages, but have 
segments?
Or where do you draw the line? Is it some function of how many different 
sized pages there can be before you would call it segments? ;-)

But yes, it can make life more complex. But somewhere, this is all just 
math, and computers are usually pretty good with that.

> I have a query, though - how does a system with two page sizes know which to
> use? On Multics (and probably on the x86), it's a per-segment attribute. But
> on a system with a large, flat address space, how does the system know which
> parts of it are using small pages, and which large?

Beats me. I always just assumed it would be related to the virtual 
address. Some part of the address space use small pages, some other part 
uses large. But I have not ever cared to actually find out.
Just as some machines had I/O spaced mapped to several addresses, so 
that you could hit things cached or uncached, and possibly read/write 
different sized data efficiently without lots of fiddling.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From charles.unix.pro at gmail.com  Thu May  3 12:54:40 2018
From: charles.unix.pro at gmail.com (Charles Anthony)
Date: Wed, 2 May 2018 19:54:40 -0700
Subject: [TUHS] /dev/drum
In-Reply-To: <20180430150532.4B67218C09C@mercury.lcs.mit.edu>
References: <20180430150532.4B67218C09C@mercury.lcs.mit.edu>
Message-ID: <CANV78LQfjBLCDmf9rFBYajqhmqS3u0akpJQfoHnQzQ_VJsJ_+Q@mail.gmail.com>

On Mon, Apr 30, 2018 at 8:05 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Johnny Billquist
>
>
>     > But how do you then view modern architectures which have different
> sized
>     > pages? Are they no longer pages then?
>
> Actually, there is precedent for that. The original Multics hardware, the
> GE-645, supported two page sizes. That was dropped in later machines (the
> Honeywell 6000's) since it was decided that the extra complexity wasn't
> worth
> it.
>
>
7 page sizes. AL39, page 40:

 PTWAM.ADDR
The 18 high-order bits of the 24-bit absolute main memory address of
the page. The hardware ignores low-order bits of this page address
according to page size based on the following:

Page size in words    ADDR bits ignored
    64             none
   128              17
   256            16-17
   512            15-17
  1024            14-17
  2048            13-17
  4096            12-17


I am unsure of exactly which model supported this, but somewhere in the
evolution from 645 to DPS8-M.

-- Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180502/5578b62a/attachment.html>

From jnc at mercury.lcs.mit.edu  Thu May  3 21:39:56 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu,  3 May 2018 07:39:56 -0400 (EDT)
Subject: [TUHS] /dev/drum
Message-ID: <20180503113956.EFE4F18C08A@mercury.lcs.mit.edu>

    > That would be a pretty ugly way to look at the world.

'Beauty is in the eye of the beholder', and all that! :-)

    > Not to mention that one segment silently slides over into the next one
    > if it's more than 8K.

Again, precedent; IIRC, on the GE-645 Multics, segments were limited to 2^N-1 pages,
precisely because otherwise incrementing an inter-segment pointer could march off
the end of one, and into the next! (The -645 was implemented as a 'bag on the side'
of the non-segmented -635, so things like this were somewhat inevitable.)


    > wouldn't you say that the "chunks" on a PDP-11 are invisible to the
    > user? Unless you are the kernel of course. Or run without protection.

No, in MERT 'segments' (called that) were a basic system primitive, which
users had access to. (Very cool system! I really need to get moving on trying
to recover that...)


    > *Demand* paging is definitely a separate concept from virtual memory.

Hmmm. I understand your definitions, and like breaking things up into 'virtual
addressing' (which I prefer as the term, see below), 'non-residence' or
'demand loaded', and 'paging' (breaking into smallish, equal-sized chunks),
but the problem with using "virtual memory" as a term for the first is that to
most people, that term already has a meaning - the combination of all three.

(I have painful memories of this sort of thing - the term 'locator' was
invented after we gave up trying to convince people one could have a network
architecture in which not all packets contained addresses. That caused a major
'does not compute' fault in most people's brains! And 'locator' has since been
perverted from its original definition. But I digress.)


    > There is no real connection between virtual memory and memory
    > protection. One can exist with or without the other.

Virtual addressing and memory protection; yes, no connection. (Although the
former will often give you the latter - if process A can't see, or name, 
process B's memory, it can't damage it.)


    > Might have been just some internal early attempt that never got out of DEC?

Could be; something similar seems to have happened to the 'RK11-B':

  http://gunkies.org/wiki/RK11_disk_controller


    >> I don't have any problem with several different page sizes, _if it
    >> engineering sense to support them_.

    > So, would you then say that such machines do not have pages, but have 
    > segments?
    > Or where do you draw the line? Is it some function of how many different 
    > sized pages there can be before you would call it segments? ;-)

No, the number doesn't make a difference (to me). I'm trying to work out what
the key difference is; in part, it's that segments are first-class objects
which are visible to the user; paging is almost always hidden under the
sheets.

But not always; some OS's allow processes to share pages, or to map file pages
into address spaces, etc. Which does make it complex to separate the two..

     Noel


From bqt at update.uu.se  Fri May  4 07:22:32 2018
From: bqt at update.uu.se (Johnny Billquist)
Date: Thu, 3 May 2018 23:22:32 +0200
Subject: [TUHS] /dev/drum
In-Reply-To: <20180503113956.EFE4F18C08A@mercury.lcs.mit.edu>
References: <20180503113956.EFE4F18C08A@mercury.lcs.mit.edu>
Message-ID: <0ce4a7c8-9ced-4e06-46c3-f5f9816bbfcc@update.uu.se>

On 2018-05-03 13:39, Noel Chiappa wrote:
>      > That would be a pretty ugly way to look at the world.
> 
> 'Beauty is in the eye of the beholder', and all that! :-)

That is true... Still, would you consider such a view anything close to 
nice, usable or a good reflection of the hardware? :-)

>      > Not to mention that one segment silently slides over into the next one
>      > if it's more than 8K.
> 
> Again, precedent; IIRC, on the GE-645 Multics, segments were limited to 2^N-1 pages,
> precisely because otherwise incrementing an inter-segment pointer could march off
> the end of one, and into the next! (The -645 was implemented as a 'bag on the side'
> of the non-segmented -635, so things like this were somewhat inevitable.)

Right. But such a limitation does not exist on the PDP-11. You in fact 
normally do have several "chunks" concatenated, so that you have your 
linear virtual address space.

>      > wouldn't you say that the "chunks" on a PDP-11 are invisible to the
>      > user? Unless you are the kernel of course. Or run without protection.
> 
> No, in MERT 'segments' (called that) were a basic system primitive, which
> users had access to. (Very cool system! I really need to get moving on trying
> to recover that...)

But you say that MERT ran with memory protection and users not directly 
able to access the MMU? In such case then, the hardware is not really 
visible, but the OS gives you some construct which can easily be mapped 
on to the hardware.

Or else I am missing something you are saying.

The PLAS directives that were mentioned earlier, which various DEC OSes 
implemented, could be said to reflect segments. In the same way you 
could say that mmap() under Unix gives you a segment. But that is not a 
strict reflection of the hardware.

>      > *Demand* paging is definitely a separate concept from virtual memory.
> 
> Hmmm. I understand your definitions, and like breaking things up into 'virtual
> addressing' (which I prefer as the term, see below), 'non-residence' or
> 'demand loaded', and 'paging' (breaking into smallish, equal-sized chunks),
> but the problem with using "virtual memory" as a term for the first is that to
> most people, that term already has a meaning - the combination of all three.

It's actually not my definition. Demand paging is a term that have been 
used for this for the last 40 years, and is not something there is much 
contention about. I must admit that I'm rather surprised if the term 
really is unknown to you.
Locate any good text on operating system concepts, and you should find 
demand paging properly described. (Or go to Wikipedia, even though there 
is some disdain around it here, it does contain a bunch of information 
and references that are not all useless.)

Virtual memory usually have been equally uncontroversial, but there it 
has started to change in the last 10 years or so. I guess it's partly a 
result of the monoculture we now face, where you have lots of people who 
have never seen or used anything but x86 and Linux, if they have done 
anything close to the memory management. And that in addition with more 
and more people without proper CS educations fooling around in this 
area, and having a somewhat incomplete understanding of the concepts.

>      > There is no real connection between virtual memory and memory
>      > protection. One can exist with or without the other.
> 
> Virtual addressing and memory protection; yes, no connection. (Although the
> former will often give you the latter - if process A can't see, or name,
> process B's memory, it can't damage it.)

Right. Separation of memory can be seen as a form of memory protection 
as well. But that is really just a side effect of not even having the 
ability to refer to the memory, and is not explicitly any form of 
protection.
(Hello, virtual memory once more...)

>      > Might have been just some internal early attempt that never got out of DEC?
> 
> Could be; something similar seems to have happened to the 'RK11-B':
> 
>    http://gunkies.org/wiki/RK11_disk_controller

Which also begs the question - was there also a RK11-A?

>      >> I don't have any problem with several different page sizes, _if it
>      >> engineering sense to support them_.
> 
>      > So, would you then say that such machines do not have pages, but have
>      > segments?
>      > Or where do you draw the line? Is it some function of how many different
>      > sized pages there can be before you would call it segments? ;-)
> 
> No, the number doesn't make a difference (to me). I'm trying to work out what
> the key difference is; in part, it's that segments are first-class objects
> which are visible to the user; paging is almost always hidden under the
> sheets.
> 
> But not always; some OS's allow processes to share pages, or to map file pages
> into address spaces, etc. Which does make it complex to separate the two..

And the "chunks" on a PDP-11, running Unix, RSX or RSTS/E, or something 
similar is also totally invisible. You can expand memory, or even 
through mechanisms as shared memory and PLAS directives have your memory 
space mapping different "objects", but the MMU page registers details 
are totally invisible to you there.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From jnc at mercury.lcs.mit.edu  Sat May  5 23:06:53 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat,  5 May 2018 09:06:53 -0400 (EDT)
Subject: [TUHS] /dev/drum
Message-ID: <20180505130653.8D85618C079@mercury.lcs.mit.edu>

    > From: Johnny Billquist

    >> in MERT 'segments' (called that) were a basic system primitive, which
    >> users had access to.

    > the OS gives you some construct which can easily be mapped on to the
    > hardware.

Right. "A logical segment is a piece of contiguous memory, 32 to 32K 16-bit
words long ... Associated with each segment are an internal segment
identifiern and an optional global name." So it's clear how that maps onto the
PDP-11 memory management hardware - and a MERT 'segment' might use more than
one 'chunk'.


    >> I understand your definitions, and like breaking things up into
    >> 'virtual addressing' (which I prefer as the term, see below),
    >> 'non-residence' or 'demand loaded', and 'paging' (breaking into
    >> smallish, equal-sized chunks), but the problem with using "virtual
    >> memory" as a term for the first is that to most people, that term
    >> already has a meaning - the combination of all three.

Actually, after some research, it turns out to be only the first two. But I
digress...

    > It's actually not my definition. Demand paging is a term that have been
    > used for this for the last 40 years, and is not something there is much
    > contention about.

I wasn't talking about "demand paging", but rather your use of the term
"virtual memory":

    >>> Virtual memory is just *virtual* memory. It's not "real" or physical
    >>> in the sense that it has a dedicated location in physical memory
    >>> ... Instead, each process has its own memory, which might be mapped
    >>> somewhere in physical memory, but it might also not be.  And one
    >>> processes address 0 is not the same as another processes address
    >>> 0. They both have the illusion that they have the full memory address
    >>> range to them selves, unaware of the fact that there are many
    >>> processes who also have that same illusion.

I _like_ having an explicit term for the _concept_ you're describing there; I
just had a problem with the use of the _term_ "virtual memory" for it - since
that term already has a different meaning to many people.

Try Googling "virtual memory" and you turn up things like this: "compensate
for physical memory shortages by temporarily transferring data from RAM to
disk". Which is why I proposed calling it "virtual addressing" instead.

    > I must admit that I'm rather surprised if the term really is unknown to
    > you.

No, of course I am familiar with "demand paging".


Anyway, this conversation has been very helpful in clarifying my thinking
about virtual memory/paging. I have updated the CHWiki article based on it:

  http://gunkies.org/wiki/Virtual_memory

including the breakdown into three separate (but related) concepts: i) virtual
addressing, ii) demand loading, and iii) paging. I'd be interested in any
comments people have.


    > Which also begs the question - was there also a RK11-A?

One assumes there much have been RK11-A's and -B's, otherwise they wouldn't
have gotten to RK11-C... :-)

I have no idea if both existed in physical form - one might have been just a
design exercise). However, the photo of the non-RK11-C indicator panel
confirms that at least one of them was actually implemented.


    > And the "chunks" on a PDP-11, running Unix, RSX or RSTS/E, or something
    > similar is also totally invisible.

Right, but not under MERT - although there clearly a single 'software' segment
might use more than one set of physical 'chunks'.

Actuallly, Unix is _somewhat_ similar, in that processes always have separate
stack and text/data 'areas' (they don't call them 'segments', as far as I
could see) - and separate text and data 'areas' too, when pure code is in
use; and any area might use more than one 'chunk'.

The difference is that Unix doesn't support 'segments' as an OS primitive, the
way MERT does.

       Noel


From bqt at update.uu.se  Sun May  6 06:53:36 2018
From: bqt at update.uu.se (Johnny Billquist)
Date: Sat, 5 May 2018 22:53:36 +0200
Subject: [TUHS] /dev/drum
In-Reply-To: <20180505130653.8D85618C079@mercury.lcs.mit.edu>
References: <20180505130653.8D85618C079@mercury.lcs.mit.edu>
Message-ID: <627cfce8-979d-13dc-fba2-ee955c41113d@update.uu.se>

On 2018-05-05 15:06, Noel Chiappa wrote:
>      > From: Johnny Billquist
> 
>      >> in MERT 'segments' (called that) were a basic system primitive, which
>      >> users had access to.
> 
>      > the OS gives you some construct which can easily be mapped on to the
>      > hardware.
> 
> Right. "A logical segment is a piece of contiguous memory, 32 to 32K 16-bit
> words long ... Associated with each segment are an internal segment
> identifiern and an optional global name." So it's clear how that maps onto the
> PDP-11 memory management hardware - and a MERT 'segment' might use more than
> one 'chunk'.

Aha! But then it is not actually giving programs direct access and 
manipulation of the hardware. It is a software construct and service 
offered by the OS, and the OS might fiddly around with various hardware 
to give this service.

So the hardware is totally invisible after all. You might understand how 
the OS realize the service using the PDP-11 hardware, but the program 
itself cannot manipulate the hardware, and is in fact totally oblivious 
to how the hardware works.

>      > It's actually not my definition. Demand paging is a term that have been
>      > used for this for the last 40 years, and is not something there is much
>      > contention about.
> 
> I wasn't talking about "demand paging", but rather your use of the term
> "virtual memory":

Ok. It wasn't totally clear, since you also use a different term for 
demand paging...

>      >>> Virtual memory is just *virtual* memory. It's not "real" or physical
>      >>> in the sense that it has a dedicated location in physical memory
>      >>> ... Instead, each process has its own memory, which might be mapped
>      >>> somewhere in physical memory, but it might also not be.  And one
>      >>> processes address 0 is not the same as another processes address
>      >>> 0. They both have the illusion that they have the full memory address
>      >>> range to them selves, unaware of the fact that there are many
>      >>> processes who also have that same illusion.
> 
> I _like_ having an explicit term for the _concept_ you're describing there; I
> just had a problem with the use of the _term_ "virtual memory" for it - since
> that term already has a different meaning to many people.
> 
> Try Googling "virtual memory" and you turn up things like this: "compensate
> for physical memory shortages by temporarily transferring data from RAM to
> disk". Which is why I proposed calling it "virtual addressing" instead.

Like I said. In the last few years, there has been a growing problem 
with lots of people not understanding virtual memory. I blame it on the 
monoculture we now have, where all people know, have been exposed to, 
and read any code about is x86 and Linux. And thus, they are at a point 
where they created some concepts in their heads, and anything that does 
not match all their preconceived ideas becomes weird.

The wikipedia article on virtual memory on and off have had such 
problems as well. It's not perfect now, but it has improved a lot from 
how it was for a while. But it has also been more correct at times as 
well. The discussions page is really enlightening.

But anyway, I certainly hope things have not in general degenerated 
enough that virtual memory actually have taken on a different meaning. 
There is also the constant issue that pops up with these "revisionist" 
interpretations that there are plenty of old documentation and 
references that contains definitions and usage of the term virtual 
memory that does not fit with their very restrictive interpretation.

> Anyway, this conversation has been very helpful in clarifying my thinking
> about virtual memory/paging. I have updated the CHWiki article based on it:
> 
>    http://gunkies.org/wiki/Virtual_memory
> 
> including the breakdown into three separate (but related) concepts: i) virtual
> addressing, ii) demand loading, and iii) paging. I'd be interested in any
> comments people have.

I might take a peek when I have some time.

>      > Which also begs the question - was there also a RK11-A?
> 
> One assumes there much have been RK11-A's and -B's, otherwise they wouldn't
> have gotten to RK11-C... :-)

Right. :-)

>      > And the "chunks" on a PDP-11, running Unix, RSX or RSTS/E, or something
>      > similar is also totally invisible.
> 
> Right, but not under MERT - although there clearly a single 'software' segment
> might use more than one set of physical 'chunks'.

Well. The PDP-11 chunks certainly, from your description above, would 
appear to be invisible to programs running under MERT. MERT provides a 
segment mechanism, which programs can use, but programs cannot play with 
the hardware. Thus, the hardware is invisible to the program. The MERT 
segment is visible, but such a segment might then involve one or more 
hardware "chunks". The program don't know, and do not deal with them 
individually or directly. In fact, the program would not even need to be 
aware of what the hardware have, or do. It's really invisible to the 
program. The MERT segment thingy is not a direct access or map to the 
hardware.

Or at least it is not, if I understood you correctly.

Those MERT segments sounds identical to the PLAS functionality provided 
by DEC OSes.

> Actuallly, Unix is _somewhat_ similar, in that processes always have separate
> stack and text/data 'areas' (they don't call them 'segments', as far as I
> could see) - and separate text and data 'areas' too, when pure code is in
> use; and any area might use more than one 'chunk'.
> 
> The difference is that Unix doesn't support 'segments' as an OS primitive, the
> way MERT does.

Right. But these are also not direct translations of the hardware 
functionality. The fact that these segments can be more than 8K should 
be enough of an argument showing that this is not the same as the 
hardware, and that the program do not know, care, or need to understand 
how the PDP-11 "chunks" actually appear or work.
(And I'll probably revert to saying pages after this reply, it's too 
much work to try and use a separate name for them.)

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From doug at cs.dartmouth.edu  Sun May  6 12:29:09 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sat, 05 May 2018 22:29:09 -0400
Subject: [TUHS] [groff] Brian Kernighan on the evoution of eqn, pic,
 grap into troff
Message-ID: <201805060229.w462T9Ee018534@coolidge.cs.Dartmouth.EDU>

> https://en.wikipedia.org/wiki/TeX#Pronunciation_and_spelling

Yes, TeX is supposed to be pronounced as Germans do Bach. And
Knuth further recommends that the name be typeset as a logo with
one letter off the base line. Damned if an awful lot of people,
especially LaTeX users, don't follow his advice. I've known
and admired Knuth for over 50 years, but part ways with him
on this. If you use the ready-made LaTeX logo in running text,
so should you also use flourished cursive for Coca-Cola and
Ford; and back in the day, discordantly slanted letters for
Holiday Inn. It's mad and it's a pox on the page.

Doug


From usotsuki at buric.co  Sun May  6 13:36:17 2018
From: usotsuki at buric.co (Steve Nickolas)
Date: Sat, 5 May 2018 23:36:17 -0400 (EDT)
Subject: [TUHS] [groff] Brian Kernighan on the evoution of eqn, pic,
 grap into troff
In-Reply-To: <201805060229.w462T9Ee018534@coolidge.cs.Dartmouth.EDU>
References: <201805060229.w462T9Ee018534@coolidge.cs.Dartmouth.EDU>
Message-ID: <alpine.BSF.2.02.1805052335060.55205@frieza.hoshinet.org>

On Sat, 5 May 2018, Doug McIlroy wrote:

>> https://en.wikipedia.org/wiki/TeX#Pronunciation_and_spelling
>
> Yes, TeX is supposed to be pronounced as Germans do Bach. And
> Knuth further recommends that the name be typeset as a logo with
> one letter off the base line. Damned if an awful lot of people,
> especially LaTeX users, don't follow his advice. I've known
> and admired Knuth for over 50 years, but part ways with him
> on this. If you use the ready-made LaTeX logo in running text,
> so should you also use flourished cursive for Coca-Cola and
> Ford; and back in the day, discordantly slanted letters for
> Holiday Inn. It's mad and it's a pox on the page.
>
> Doug
>

TeX drives me up a damn wall sometimes.  It certainly is better suited 
than, say, LibreOffice or M$ Word for what I do with it, but I still 
frequently find myself butting heads with it.

-uso.


From jnc at mercury.lcs.mit.edu  Sun May  6 23:07:38 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun,  6 May 2018 09:07:38 -0400 (EDT)
Subject: [TUHS] /dev/drum
Message-ID: <20180506130738.E59A618C079@mercury.lcs.mit.edu>

    > From: Johnny Billquist

    >> "A logical segment is a piece of contiguous memory, 32 to 32K 16-bit
    >> words long [which can grow in increments of 32 words]"

    > But then it is not actually giving programs direct access and
    > manipulation of the hardware. It is a software construct and service
    > offered by the OS, and the OS might fiddly around with various hardware
    > to give this service.

I don't understand how this is significant: most time-sharing OS's don't give
the users access to the memory management control hardware?

    > So the hardware is totally invisible after all.

Not quite - the semantics available for - and _visible_ to - the user are
constrained by the mechanisms of the underlying hardware.

Consider a machine with a KT11-B - it could not provide support for very small
segments, or be able to adjust the segment size with such small quanta. On the
other side, the KT11-B could support starting a 'software segment' at any
512-byte boundary in the virtual address space, unlike the KT11-C which only
supports 8KB boundaries.

    Noel


From bqt at update.uu.se  Mon May  7 01:57:23 2018
From: bqt at update.uu.se (Johnny Billquist)
Date: Sun, 6 May 2018 17:57:23 +0200
Subject: [TUHS] /dev/drum
In-Reply-To: <20180506130738.E59A618C079@mercury.lcs.mit.edu>
References: <20180506130738.E59A618C079@mercury.lcs.mit.edu>
Message-ID: <09e3b413-9b30-1763-6679-1cc11451e8b6@update.uu.se>

On 2018-05-06 15:07, Noel Chiappa wrote:
>      > From: Johnny Billquist
> 
>      >> "A logical segment is a piece of contiguous memory, 32 to 32K 16-bit
>      >> words long [which can grow in increments of 32 words]"
> 
>      > But then it is not actually giving programs direct access and
>      > manipulation of the hardware. It is a software construct and service
>      > offered by the OS, and the OS might fiddly around with various hardware
>      > to give this service.
> 
> I don't understand how this is significant: most time-sharing OS's don't give
> the users access to the memory management control hardware?

Right. I would probably say that no time-sharing OS with any kind of 
protection between processes will allow direct access to the hardware.

My point being that (I think we agreed) pages are invisible to the 
process, while segments are very visible. And here we talk from a 
hardware point of view.

So why would it not be significant? It's what the whole definition was 
about.

>      > So the hardware is totally invisible after all.
> 
> Not quite - the semantics available for - and _visible_ to - the user are
> constrained by the mechanisms of the underlying hardware.

That is not the same thing as being visible. The OS gives you some 
mechanisms or services. The OS might base that design on restrictions 
imposed by the underlying hardware, but the underlying hardware is in 
fact totally invisible. A user process use services provided by the OS, 
and does not try to manipulate, or is even aware of the underlying hardware.

> Consider a machine with a KT11-B - it could not provide support for very small
> segments, or be able to adjust the segment size with such small quanta. On the
> other side, the KT11-B could support starting a 'software segment' at any
> 512-byte boundary in the virtual address space, unlike the KT11-C which only
> supports 8KB boundaries.

Yes. But a user program running under some OS with protection, would not 
allow you to access the hardware anyway.

Anything like the MERT segments can in fact be provided with both types 
of memory management. And the program will not be aware of which 
hardware is involved, or how to set this up. The OS deals with all of that.

There might be some constraints on where the segment can appear in your 
virtual address space, but that does not change the fact that the 
service can be provided by the OS with either hardware.

Or, to take RSX PLAS directives as an example. When you create a region 
(which is the equivalent to a segment), it can have alignment on either 
a 64B resolution, or a 512B resolution. And the OS will try to 
accomodate. And where it appears in your virtual memory space, and what 
offsets to use and so on can be requested, but the OS will then give you 
something as close as it can to this, based on hardware restrictions.

All of this is so similar to mmap() that we could in fact be having this 
exact discussion based on mmap() instead, if that were to help.
I don't see you claiming that every machine use a segmented model, but 
running any modern Unix on any hardware will give you this exact same 
tools. Read up on the mmap() system call, if you don't already know it.
Now, would you say that this system call makes the hardware directly 
visible and manipulated by the user program?

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From jnc at mercury.lcs.mit.edu  Tue May  8 01:36:26 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon,  7 May 2018 11:36:26 -0400 (EDT)
Subject: [TUHS] /dev/drum
Message-ID: <20180507153626.1DAC918C075@mercury.lcs.mit.edu>

    > From: Johnny Billquist

    > My point being that ... pages are invisible to the process segments are
    > very visible. And here we talk from a hardware point of view.

So you're saying 'segmentation means instructions explicitly include segment
numbers, and the address space is a two-dimensional array', or 'segmentation
means pointers explicitly include segment numbers', or something like that?

I seem to recall machines where that wasn't so, but I don't have the time to
look for them. Maybe the IBM System 38? The two 'spaces' in the KA10/KI10,
although a degenerate case (fewer even than the PDP-11) are one example.

I'm more interested in the semantics that are provided, not bits in
instructions.

It's true that with a large address space, one can sort of simulate
segmentation. To me, machines which explicitly have segment numbers in
instructions/pointers are one end of a spectrum of 'segmented machines', but
that's not a strict requirement. I'm more concerned about how they are used,
what the system/user gets.

Similarly for paging - fixed sizes (or a small number of sizes) are part of
the definition, but I'm more interested in how it's used - for demand loading,
and to simplify main memory allocation purposes, etc.


    >> the semantics available for - and _visible_ to - the user are
    >> constrained by the mechanisms of the underlying hardware.

    > That is not the same thing as being visible.

It doesn't meet the definition above ('segment numbers in
instructions/pointers'), no. But I don't accept that definition.


    > All of this is so similar to mmap() that we could in fact be having this
    > exact discussion based on mmap() instead .. I don't see you claiming
    > that every machine use a segmented model

mmap() (and similar file->address space mapping mechanisms, which a bunch of
OS's have supported - TENEX/TOP-20, ITS, etc) are interesting, but to me,
orthagonal - although it clearly needs support from memory management hardware.

And one can add 'sharing memory between two processes' here, too; very similar
_mechanisms_ to mmap(), but different goals. (Although I suppose two processes
could map the same area of a file, and that would give them IPC mapping.)

	   Noel


From a.phillip.garcia at gmail.com  Tue May  8 04:22:09 2018
From: a.phillip.garcia at gmail.com (A. P. Garcia)
Date: Mon, 7 May 2018 14:22:09 -0400
Subject: [TUHS] unix "awesome list"
Message-ID: <CAFCBnZs9gK3gDcounRpVtm61kJZCjM8tBv3Jt5dqGr4+4wktpA@mail.gmail.com>

Hi,

There's a unix "awesome list". It mentions TUHS's wiki, as well as this quote:

"This is the Unix philosophy: Write programs that do one thing and do
it well. Write programs to work together. Write programs to handle
text streams, because that is a universal interface." - Douglas
McIlroy, former head of Bell Labs Computing Sciences Research Center

https://github.com/sirredbeard/Awesome-UNIX


From dave at horsfall.org  Tue May  8 07:10:55 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 8 May 2018 07:10:55 +1000 (EST)
Subject: [TUHS] unix "awesome list"
In-Reply-To: <CAFCBnZs9gK3gDcounRpVtm61kJZCjM8tBv3Jt5dqGr4+4wktpA@mail.gmail.com>
References: <CAFCBnZs9gK3gDcounRpVtm61kJZCjM8tBv3Jt5dqGr4+4wktpA@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.999.1805080707060.13425@aneurin.horsfall.org>

On Mon, 7 May 2018, A. P. Garcia wrote:

> "This is the Unix philosophy: Write programs that do one thing and do it 
> well. Write programs to work together. Write programs to handle text 
> streams, because that is a universal interface." - Douglas McIlroy, 
> former head of Bell Labs Computing Sciences Research Center
>
> https://github.com/sirredbeard/Awesome-UNIX

Sadly, Penguin/OS appears to have forgotten this, as it becomes more like 
Windoze every day...

-- Dave


From usotsuki at buric.co  Tue May  8 07:54:12 2018
From: usotsuki at buric.co (Steve Nickolas)
Date: Mon, 7 May 2018 17:54:12 -0400 (EDT)
Subject: [TUHS] unix "awesome list"
In-Reply-To: <alpine.BSF.2.21.999.1805080707060.13425@aneurin.horsfall.org>
References: <CAFCBnZs9gK3gDcounRpVtm61kJZCjM8tBv3Jt5dqGr4+4wktpA@mail.gmail.com>
 <alpine.BSF.2.21.999.1805080707060.13425@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.02.1805071753400.6043@frieza.hoshinet.org>

On Tue, 8 May 2018, Dave Horsfall wrote:

> On Mon, 7 May 2018, A. P. Garcia wrote:
>
>> "This is the Unix philosophy: Write programs that do one thing and do it 
>> well. Write programs to work together. Write programs to handle text 
>> streams, because that is a universal interface." - Douglas McIlroy, former 
>> head of Bell Labs Computing Sciences Research Center
>> 
>> https://github.com/sirredbeard/Awesome-UNIX
>
> Sadly, Penguin/OS appears to have forgotten this, as it becomes more like 
> Windoze every day...
>
> -- Dave
>

I blame people like Lennart Poettering who seem to be hellbent on erasing 
Linux's origins...

-uso.


From akosela at andykosela.com  Tue May  8 08:34:21 2018
From: akosela at andykosela.com (Andy Kosela)
Date: Mon, 7 May 2018 17:34:21 -0500
Subject: [TUHS] unix "awesome list"
In-Reply-To: <CAFCBnZs9gK3gDcounRpVtm61kJZCjM8tBv3Jt5dqGr4+4wktpA@mail.gmail.com>
References: <CAFCBnZs9gK3gDcounRpVtm61kJZCjM8tBv3Jt5dqGr4+4wktpA@mail.gmail.com>
Message-ID: <CALMnNGifG6m_hF4pURjiCq1rzWgA5sVpCfD1hgW8_6brO56hdA@mail.gmail.com>

On Monday, May 7, 2018, A. P. Garcia <a.phillip.garcia at gmail.com> wrote:

> Hi,
>
> There's a unix "awesome list". It mentions TUHS's wiki, as well as this
> quote:
>
> "This is the Unix philosophy: Write programs that do one thing and do
> it well. Write programs to work together. Write programs to handle
> text streams, because that is a universal interface." - Douglas
> McIlroy, former head of Bell Labs Computing Sciences Research Center
>
> https://github.com/sirredbeard/Awesome-UNIX
>

IMHO this "list" is strangely not distinguishing enough between SYSV and
BSD.  It seems to put every UNIX into the magical AT&T umbrella.

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

From ggm at algebras.org  Tue May  8 10:29:47 2018
From: ggm at algebras.org (George Michaelson)
Date: Tue, 8 May 2018 10:29:47 +1000
Subject: [TUHS] [groff] Brian Kernighan on the evoution of eqn, pic,
 grap into troff
In-Reply-To: <alpine.BSF.2.02.1805052335060.55205@frieza.hoshinet.org>
References: <201805060229.w462T9Ee018534@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.02.1805052335060.55205@frieza.hoshinet.org>
Message-ID: <CAKr6gn1Ln70_-jQfgd2Q+PEdddjQJNt0NiJHRdX5DAxTwxxgjA@mail.gmail.com>

I always envied people who had invested the time to understand
tex/latex. It felt like sitting next to senior wranglers in the maths
department, or the students heading to the civil service exams. What a
luxury: to learn how to apply cubic splines and bezier curves to
design ligatures, in the least possible instructions using a special
stack machine you designed to represent the ideal code, if you had a
computer to run it, bearing in mind that because *aesthetically* you
wanted your "o" to be slightly wider at the bottom than the top, you
had to wrangle a function in, to decide how to do that adjustment in a
non-linear manner given the scaling effects of applying the golden
mean to the design.

wait.. what were we doing again? Typesetting our theses? I can use -ms
for that. If I want the left margin in one inch, I say 1in. Who really
cares if the printer doesn't know whan an EM is?

T/roff might have been disgusting, but so was RUNOFF which I was
familiar with. So this is the classic "you can have it perfect, or
have it next tuesday" moment, which I believe was J Pierpoint Morgan,
who was in Zork, on the zorkmid, so I know it was a "thing".

Mind you, slitex was pretty good. I kind of wish I'd learned that.

Now, desperately trying to get papers into ACM and IEEE, I find myself
leaning on my elders, betters, and wisers, to understand which
\relax{} to do, and why. Its all greek to me.

On Sun, May 6, 2018 at 1:36 PM, Steve Nickolas <usotsuki at buric.co> wrote:
> On Sat, 5 May 2018, Doug McIlroy wrote:
>
>>> https://en.wikipedia.org/wiki/TeX#Pronunciation_and_spelling
>>
>>
>> Yes, TeX is supposed to be pronounced as Germans do Bach. And
>> Knuth further recommends that the name be typeset as a logo with
>> one letter off the base line. Damned if an awful lot of people,
>> especially LaTeX users, don't follow his advice. I've known
>> and admired Knuth for over 50 years, but part ways with him
>> on this. If you use the ready-made LaTeX logo in running text,
>> so should you also use flourished cursive for Coca-Cola and
>> Ford; and back in the day, discordantly slanted letters for
>> Holiday Inn. It's mad and it's a pox on the page.
>>
>> Doug
>>
>
> TeX drives me up a damn wall sometimes.  It certainly is better suited than,
> say, LibreOffice or M$ Word for what I do with it, but I still frequently
> find myself butting heads with it.
>
> -uso.


From jon at fourwinds.com  Tue May  8 10:39:58 2018
From: jon at fourwinds.com (Jon Steinhart)
Date: Mon, 07 May 2018 17:39:58 -0700
Subject: [TUHS] [groff] Brian Kernighan on the evoution of eqn, pic,
	grap into troff
In-Reply-To: <CAKr6gn1Ln70_-jQfgd2Q+PEdddjQJNt0NiJHRdX5DAxTwxxgjA@mail.gmail.com>
References: <201805060229.w462T9Ee018534@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.02.1805052335060.55205@frieza.hoshinet.org>
 <CAKr6gn1Ln70_-jQfgd2Q+PEdddjQJNt0NiJHRdX5DAxTwxxgjA@mail.gmail.com>
Message-ID: <201805080039.w480dwfd005761@darkstar.fourwinds.com>

George Michaelson writes:
> I always envied people who had invested the time to understand
> tex/latex. It felt like sitting next to senior wranglers in the maths
> department, or the students heading to the civil service exams. What a
> luxury: to learn how to apply cubic splines and bezier curves to
> design ligatures, in the least possible instructions using a special
> stack machine you designed to represent the ideal code, if you had a
> computer to run it, bearing in mind that because *aesthetically* you
> wanted your "o" to be slightly wider at the bottom than the top, you
> had to wrangle a function in, to decide how to do that adjustment in a
> non-linear manner given the scaling effects of applying the golden
> mean to the design.
>
> wait.. what were we doing again? Typesetting our theses? I can use -ms
> for that. If I want the left margin in one inch, I say 1in. Who really
> cares if the printer doesn't know whan an EM is?
>
> T/roff might have been disgusting, but so was RUNOFF which I was
> familiar with. So this is the classic "you can have it perfect, or
> have it next tuesday" moment, which I believe was J Pierpoint Morgan,
> who was in Zork, on the zorkmid, so I know it was a "thing".
>
> Mind you, slitex was pretty good. I kind of wish I'd learned that.
>
> Now, desperately trying to get papers into ACM and IEEE, I find myself
> leaning on my elders, betters, and wisers, to understand which
> \relax{} to do, and why. Its all greek to me.
>
> On Sun, May 6, 2018 at 1:36 PM, Steve Nickolas <usotsuki at buric.co> wrote:
> > On Sat, 5 May 2018, Doug McIlroy wrote:
> >
> >>> https://en.wikipedia.org/wiki/TeX#Pronunciation_and_spelling
> >>
> >>
> >> Yes, TeX is supposed to be pronounced as Germans do Bach. And
> >> Knuth further recommends that the name be typeset as a logo with
> >> one letter off the base line. Damned if an awful lot of people,
> >> especially LaTeX users, don't follow his advice. I've known
> >> and admired Knuth for over 50 years, but part ways with him
> >> on this. If you use the ready-made LaTeX logo in running text,
> >> so should you also use flourished cursive for Coca-Cola and
> >> Ford; and back in the day, discordantly slanted letters for
> >> Holiday Inn. It's mad and it's a pox on the page.
> >>
> >> Doug
> >>
> >
> > TeX drives me up a damn wall sometimes.  It certainly is better suited than,
> > say, LibreOffice or M$ Word for what I do with it, but I still frequently
> > find myself butting heads with it.
> >
> > -uso.

IMHO, the tex language is too ugly.  I much prefer troff.  But, and maybe this
will be a retirement project, giving troff tex's two-dimensional layout smarts
so that widows and orphans don't have to be handled manually would be nice.

Remember, we're lucky that Don didn't work on X Windows because he would
have called it Ech.

Jon


From dave at horsfall.org  Tue May  8 12:17:44 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 8 May 2018 12:17:44 +1000 (EST)
Subject: [TUHS] [groff] Brian Kernighan on the evoution of eqn, pic,
 grap into troff
In-Reply-To: <201805080039.w480dwfd005761@darkstar.fourwinds.com>
References: <201805060229.w462T9Ee018534@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.02.1805052335060.55205@frieza.hoshinet.org>
 <CAKr6gn1Ln70_-jQfgd2Q+PEdddjQJNt0NiJHRdX5DAxTwxxgjA@mail.gmail.com>
 <201805080039.w480dwfd005761@darkstar.fourwinds.com>
Message-ID: <alpine.BSF.2.21.999.1805081216080.79090@aneurin.horsfall.org>

On Mon, 7 May 2018, Jon Steinhart wrote:

> Remember, we're lucky that Don didn't work on X Windows because he would 
> have called it Ech.

Signature material!  May I?

-- Dave


From jon at fourwinds.com  Tue May  8 12:43:53 2018
From: jon at fourwinds.com (Jon Steinhart)
Date: Mon, 07 May 2018 19:43:53 -0700
Subject: [TUHS] [groff] Brian Kernighan on the evoution of eqn, pic,
	grap into troff
In-Reply-To: <alpine.BSF.2.21.999.1805081216080.79090@aneurin.horsfall.org>
References: <201805060229.w462T9Ee018534@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.02.1805052335060.55205@frieza.hoshinet.org>
 <CAKr6gn1Ln70_-jQfgd2Q+PEdddjQJNt0NiJHRdX5DAxTwxxgjA@mail.gmail.com>
 <201805080039.w480dwfd005761@darkstar.fourwinds.com>
 <alpine.BSF.2.21.999.1805081216080.79090@aneurin.horsfall.org>
Message-ID: <201805080243.w482hrVs020433@darkstar.fourwinds.com>

Dave Horsfall writes:
> On Mon, 7 May 2018, Jon Steinhart wrote:
>
> > Remember, we're lucky that Don didn't work on X Windows because he would 
> > have called it Ech.
>
> Signature material!  May I?
>
> -- Dave

Well, it's not original with me but sure, go ahead.


From bakul at bitblocks.com  Tue May  8 14:11:50 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Mon, 07 May 2018 21:11:50 -0700
Subject: [TUHS] [groff] Brian Kernighan on the evoution of eqn, pic,
	grap into troff
In-Reply-To: Your message of "Mon, 07 May 2018 17:39:58 -0700."
 <201805080039.w480dwfd005761@darkstar.fourwinds.com>
References: <201805060229.w462T9Ee018534@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.02.1805052335060.55205@frieza.hoshinet.org>
 <CAKr6gn1Ln70_-jQfgd2Q+PEdddjQJNt0NiJHRdX5DAxTwxxgjA@mail.gmail.com>
 <201805080039.w480dwfd005761@darkstar.fourwinds.com>
Message-ID: <20180508041157.C9ED9156E510@mail.bitblocks.com>

On Mon, 07 May 2018 17:39:58 -0700 Jon Steinhart <jon at fourwinds.com> wrote:
> 
> IMHO, the tex language is too ugly.  I much prefer troff.  But, and maybe this
> will be a retirement project, giving troff tex's two-dimensional layout smarts
> so that widows and orphans don't have to be handled manually would be nice.
> 
> Remember, we're lucky that Don didn't work on X Windows because he would
> have called it Ech.

You can pronounce TeX as if it is written in Cyrillic: Tiyekh!
And then of course, LyaTiyekh!

Though I vastly prefer TeX/LaTeX/XeLaTeX over troff (unlike
most folks on this list) and find even the source code more
legible than ugly control lines starting with a "." -- In *TeX
I can reformat most parahraphs to balance lines, without
things falling aport.

Now one can avoid most of the hassles for simple documentation
by using markdown or asciidoc & tools that generate .tex,
which can be rendered beautifully. Even here you can typically
use LaTeX formatting for equations.


From mutiny.mutiny at rediffmail.com  Tue May  8 18:14:37 2018
From: mutiny.mutiny at rediffmail.com (Mutiny)
Date: 8 May 2018 08:14:37 -0000
Subject: [TUHS] =?utf-8?q?unix_=22awesome_list=22?=
In-Reply-To: <alpine.BSF.2.02.1805071753400.6043@frieza.hoshinet.org>
Message-ID: <1525730080.S.4783.16394.f5-147-236.1525767277.6983@webmail.rediffmail.com>

&gt;I blame people like Lennart Poettering who seem to be hellbent on erasing Linux&#39;s origins...I don&#39;t think so. Red Hat does a extremely good job moving *nix/linux to the 3rd millennia.-uso.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180508/ffb79674/attachment.html>

From scj at yaccman.com  Tue May  8 07:53:26 2018
From: scj at yaccman.com (Steve Johnson)
Date: Mon, 07 May 2018 14:53:26 -0700
Subject: [TUHS] unix "awesome list"
In-Reply-To: <alpine.BSF.2.21.999.1805080707060.13425@aneurin.horsfall.org>
Message-ID: <b637e35002b1b5e78a943407e221d8da87464e4e@webmail.yaccman.com>

Some would argue that it was well on its way to being forgotten by
BSD.  The problem with that statement is that the deployment of mice
and touchscreens meant that the base premise (universal interface) was
no longer true.  Fonts and markup completed the job.

When I first used Unix, I wrote several ed scripts every day, and
several shell scripts each week.  Glass terminals made ed scripts
obsolete without any similar abstraction being available for doing
similar text operations on several related files.
I still write shell scripts from time to time, but I always feel a
little guilty that I'm not writing a simple GUI that would be much
clearer and easier to use, but take an order of magnitude longer to
write...

Steve

----- Original Message -----
From: "Dave Horsfall" <dave at horsfall.org>
To:"The Eunuchs Hysterical Society" <tuhs at tuhs.org>
Cc:
Sent:Tue, 8 May 2018 07:10:55 +1000 (EST)
Subject:Re: [TUHS] unix "awesome list"

 On Mon, 7 May 2018, A. P. Garcia wrote:

 > "This is the Unix philosophy: Write programs that do one thing and
do it 
 > well. Write programs to work together. Write programs to handle
text 
 > streams, because that is a universal interface." - Douglas McIlroy,

 > former head of Bell Labs Computing Sciences Research Center
 >
 > https://github.com/sirredbeard/Awesome-UNIX

 Sadly, Penguin/OS appears to have forgotten this, as it becomes more
like 
 Windoze every day...

 -- Dave

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

From tytso at mit.edu  Tue May  8 22:24:29 2018
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Tue, 8 May 2018 08:24:29 -0400
Subject: [TUHS] unix "awesome list"
In-Reply-To: <b637e35002b1b5e78a943407e221d8da87464e4e@webmail.yaccman.com>
References: <alpine.BSF.2.21.999.1805080707060.13425@aneurin.horsfall.org>
 <b637e35002b1b5e78a943407e221d8da87464e4e@webmail.yaccman.com>
Message-ID: <20180508122429.GG999@thunk.org>

On Mon, May 07, 2018 at 02:53:26PM -0700, Steve Johnson wrote:
> Some would argue that it was well on its way to being forgotten by
> BSD.  The problem with that statement is that the deployment of mice
> and touchscreens meant that the base premise (universal interface) was
> no longer true.  Fonts and markup completed the job.
> 
> When I first used Unix, I wrote several ed scripts every day, and
> several shell scripts each week.  Glass terminals made ed scripts
> obsolete without any similar abstraction being available for doing
> similar text operations on several related files.

While true, that's only part of the story.  There was also the issue
that what users wanted to *do* with computers got more complex.
Consider spreadsheets and relational databases --- how do they get
implemented in "the Unix way"?  There was rdb, but it was a bit of a
disaster from a performance perspective and only worked for toy
databases.  And this wasn't unique to Unix.  In the VMS world,
ALL-IN-1 offered group scheduling/calendaring and other "office
software" features.  You *could* implemnt a group scheduling system
using sed, awk, grep, cat, and pipelines --- but would you want to?
Is that the best way to go about doing things?

And on the hardware side, the advent of hot-pluggable hardware devices
and much more complex UI devices (sound, video cameras, etc.) that
need to be made accessible to the logged-in user sitting in front of a
particular console, put a lot more pressure on the simple login and
/dev model of historical Unix.

So sure, it's easy to criticize "PenguinOS" for departing from the
Unix ideal.  But what's the alternative?  Can the criticis design
something better that matches the needs and requirements of the users
(who don't like big question marks on dashboards as "user friendly"
error reporting) and the realities of modern hardware and modern user
interface?

And if so, would those critics care to implement it and contribute it
under a BSD-style license?  (Or some other Open Source License)?
After all competing with the user friendliness of GNOME should be that
hard --- and it's been getting easier over the years as GNOME cuts
feature after feature from their system.  :-)

					- Ted


From bakul at bitblocks.com  Tue May  8 23:51:14 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Tue, 08 May 2018 06:51:14 -0700
Subject: [TUHS] unix "awesome list"
In-Reply-To: Your message of "Tue, 08 May 2018 08:24:29 -0400."
 <20180508122429.GG999@thunk.org>
References: <alpine.BSF.2.21.999.1805080707060.13425@aneurin.horsfall.org>
 <b637e35002b1b5e78a943407e221d8da87464e4e@webmail.yaccman.com>
 <20180508122429.GG999@thunk.org>
Message-ID: <20180508135121.7D70C156E510@mail.bitblocks.com>

On Tue, 08 May 2018 08:24:29 -0400 "Theodore Y. Ts'o" <tytso at mit.edu> wrote:
Theodore Y. Ts'o writes:
> On Mon, May 07, 2018 at 02:53:26PM -0700, Steve Johnson wrote:
> > Some would argue that it was well on its way to being forgotten by
> > BSD. The problem with that statement is that the deployment of mice
> > and touchscreens meant that the base premise (universal interface) was
> > no longer true. Fonts and markup completed the job.
> > 
> > When I first used Unix, I wrote several ed scripts every day, and
> > several shell scripts each week. Glass terminals made ed scripts
> > obsolete without any similar abstraction being available for doing
> > similar text operations on several related files.
> 
> While true, that's only part of the story.  There was also the issue
> that what users wanted to *do* with computers got more complex.
> Consider spreadsheets and relational databases --- how do they get
> implemented in "the Unix way"?  There was rdb, but it was a bit of a
> disaster from a performance perspective and only worked for toy
> databases.  And this wasn't unique to Unix.  In the VMS world,
> ALL-IN-1 offered group scheduling/calendaring and other "office
> software" features.  You *could* implemnt a group scheduling system
> using sed, awk, grep, cat, and pipelines --- but would you want to?
> Is that the best way to go about doing things?
> 
> And on the hardware side, the advent of hot-pluggable hardware devices
> and much more complex UI devices (sound, video cameras, etc.) that
> need to be made accessible to the logged-in user sitting in front of a
> particular console, put a lot more pressure on the simple login and
> /dev model of historical Unix.
> 
> So sure, it's easy to criticize "PenguinOS" for departing from the
> Unix ideal.  But what's the alternative?  Can the criticis design
> something better that matches the needs and requirements of the users
> (who don't like big question marks on dashboards as "user friendly"
> error reporting) and the realities of modern hardware and modern user
> interface?
> 
> And if so, would those critics care to implement it and contribute it
> under a BSD-style license?  (Or some other Open Source License)?
> After all competing with the user friendliness of GNOME should be that
> hard --- and it's been getting easier over the years as GNOME cuts
> feature after feature from their system.  :-)
> 
> 					- Ted

Great response! Agree with a lot of this (except GNOME!).

Shell was a good glue language in that it allowed easy
composition of programs that fit its model from simpler
programs. A similar model exists for services composed from
microservices but now the 'pipes' are often not unidirectional
or simple lines of text. And dynamic scaling is required. etc.
But we do not have a similar easy to use glue language.
Graphical interfaces get used but except in special fields
they are not compositional. Graphical languages remained
researchy. in other areas existing solutions are rejected as
being not efficient enough or hard to integrate in the unix
model. Example: capabilities. Unix file descriptors are in
fact capabilities but they are still file/dir/device or socket
descriptors, mainly confined to individual processes.
Experiments in pure capability based OSes havent gone far. In
FreeBSD we have capsicum but that has added complexity, not
removed it. And we are still writing concurrent programs using
mutexes. No practical progress in 40 years.

If you think about it, most all the new things added in last 3
decades haven't had the cohesion of design like the original
unix design. And yet, I think extending the unix model is quite
possible.


From clemc at ccc.com  Wed May  9 00:53:16 2018
From: clemc at ccc.com (Clem Cole)
Date: Tue, 8 May 2018 10:53:16 -0400
Subject: [TUHS] unix "awesome list"
In-Reply-To: <20180508135121.7D70C156E510@mail.bitblocks.com>
References: <alpine.BSF.2.21.999.1805080707060.13425@aneurin.horsfall.org>
 <b637e35002b1b5e78a943407e221d8da87464e4e@webmail.yaccman.com>
 <20180508122429.GG999@thunk.org>
 <20180508135121.7D70C156E510@mail.bitblocks.com>
Message-ID: <CAC20D2Oez0HVf-6jXxkcVmVR_sVpwgm5j12ce-hhawegGpTXmQ@mail.gmail.com>

I'll take a slight different road on this topic.  I think we are dealing
with the paradox of progress. I don't blame Linux's developers any more
than I blame BSDs or anyone else.   Really it was hardware progress/Moore's
law that changed the rules :-)

As much as I wax a bit for the simplicity of the Fifth, Sixth, and Seventh
Editions of my youth, the truth is I would not want to try to use them
today.   My needs are now different and I think the is true for most people
also which is why a modern UNIX implementation is different from the
original ideas or maybe I should say ideal.  That said, a lot of what I did
then, ands like Steve, I still do use and many of the 'classic solutions' I
find are better for me (*i.e. *troff *vs.* MS-Word)

Pike's '*cat -v harmfu*l' paper foretold where we would get.   On the
PDP-11 with a limited address, a programmer was constrained so you had to
keep things simple.   The programming model of small simple programs that
did one thing well, was easier to 'enforce.'   The ideas that formed UNIX
make sense, and yoiu could build an extremely power 'system' from simple
and small things.   At the time, that was almost heretical.    But once HW
dropped in price and the address space issues relaxed the size of a program
that could be written, people did.  The cast was out of the bag, and there
was no going back.    I'm not saying all of the new BSDism of the time were
right, but they certainly made many things easier/more approachable for
many users and many/most live in modern UNIX definition.

I think Ted makes an excellent point, that *BSD and Linux, by their nature
of being 'open' and 'available' pushed the code along and that needs to
continue to be the high order bit.  Open and freely available had a huge
positive effect, because many of these new feature (like X-Windows,
Networking) were 'useful' and the cost to add them was accessible -- so
people added them.   But .... slowly the system changed and the
*expectations* of the users with them.

I admit, I'm torn.   I do think Pike was right and many of the new
features/frameworks *et al* are pretty lame (useless IMHO) and the
simpler/cleaner methods of old, are being ignored. Dave Pressotto and I
were talking a week or so ago and Dave made the observation that he's not
sure he knows how write a modern program now with all these frameworks,
IDEs, *etc* and I completely agree.  But that is the old guy in me talking;
but I really do want to see progress and the new generation make its mark.
I'm sure they will do wonderful things.

Bakul's observation of little >>practical<< progress is an interesting
one.   In many ways I agree, in others I'm not so sure.  I think Ted knows
that my major gripe with some of the Linux (and Gnu style) community has
been a focus on reimplementing things that were already there instead of
using what could have been taken from somewhere else such as BSD, or
replacing subsystems just because they could without really adding anything
(*i.e.* the whole systemd argument).

But over all, as much as I respect and think Ken and Dennis did amazing
work at the time, I do tend to love when new ideas/things have been done
beyond the original ideas from Ken and Dennis.  For instance, just as BSD
can take credit (or blame) or sockets and making UNIX really a 'networked
OS', Sun really gave us multiple file systems with the VFS, but  I strongly
credit Linux for really making kernel modules a reality (yup Solaris had
them, as did a few other systems - but it was really Linux that made it
wide spread).   I wish Linux had taken the idea of a modular kernel a tad
farther, and picked up things like Locus vproc work, because I personally
think modularity under the covers is better than the containers mess we
have today (and I agree with Tannenbaum that uKernel's make more sense to
me in the long run - even if they do cost something in speed).

it's also why I liked Plan 9 and have high hopes that a new OS, maybe
written is something like Rust might finally appear.   But I don't want it
re-implement UNIX or Linux.   Grab from them the subsystems that you need
to duplication, but don't re-invent.


Warren - at the risk of being political -- I think the paradox we have it
larger than just UNIX, although it is simple.  We can wallow and say
everything is bad, it was simpler in 1959 -- which exactly what some folks
in my country seem to be doing in other areas.  I personally can say my
world was simple in those days and I certainly have fond memories [read
Bill Bryson's
https://www.amazon.com/Life-Times-Thunderbolt-Kid-Memoir/dp/0767919378
which parrots many of my own memories of those times ], but UNIX, like the
world, has grown up and changed and is a lot more complicated.   I like
progress we have now.  I don't want the world the way it was any more than
I want run Fifth Edition on my Mac for day-2-day work.

Yes, I would like us to look at the good from the past and see if we can
have some of the good things again; but if it means giving up what gained
too, then we have gone backwards.  The problem is how to decide what was
good and what was bad?   What is real progress and what is just 'showing
off your money' to use a Forest Gump concept.

I suspect we will argue for a long time about what qualifies as progress
from the core idea of UNIX and what does not.

Clem

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

From cym224 at gmail.com  Wed May  9 00:54:58 2018
From: cym224 at gmail.com (Nemo)
Date: Tue, 8 May 2018 10:54:58 -0400
Subject: [TUHS] [groff] Brian Kernighan on the evoution of eqn, pic,
 grap into troff
In-Reply-To: <20180508041157.C9ED9156E510@mail.bitblocks.com>
References: <201805060229.w462T9Ee018534@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.02.1805052335060.55205@frieza.hoshinet.org>
 <CAKr6gn1Ln70_-jQfgd2Q+PEdddjQJNt0NiJHRdX5DAxTwxxgjA@mail.gmail.com>
 <201805080039.w480dwfd005761@darkstar.fourwinds.com>
 <20180508041157.C9ED9156E510@mail.bitblocks.com>
Message-ID: <CAJfiPzy8pSDnkwPevOVFHUNVP8Q046TARk2O1S6xN8wwhwdo=A@mail.gmail.com>

On 8 May 2018 at 00:11, Bakul Shah <bakul at bitblocks.com> wrote:
> On Mon, 07 May 2018 17:39:58 -0700 Jon Steinhart <jon at fourwinds.com> wrote:
>>
>> IMHO, the tex language is too ugly.  I much prefer troff.
[...]
> Though I vastly prefer TeX/LaTeX/XeLaTeX over troff (unlike
> most folks on this list)
[...]

Oh, this has the makings of another Mygol vs Yourtran flame war.

As an inflamatory datum point, I was a grad student when TeX was
installed and the secretaries all learnt TeX.  When LaTeX came in, we
all dumped *roff.

N.


From jnc at mercury.lcs.mit.edu  Wed May  9 01:17:22 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue,  8 May 2018 11:17:22 -0400 (EDT)
Subject: [TUHS] unix "awesome list"
Message-ID: <20180508151722.49CFC18C079@mercury.lcs.mit.edu>

    > From: Clem Cole

    > I agree with Tannenbaum that uKernel's make more sense to me in the long
    > run - even if they do cost something in speed

There's a certain irony in people complaining that ukernel's have more
overhead - while at the same time time mindlessly, and almost universally,
propogating such pinheaded computing hogs as '_mandating_ https for everything
under the sun' (even things as utterly pointless to protect as looking at
Wikipedia articles on mathematics), while simultaneously letting
Amazon/Facebook/Google do the 'all your data are belong to us' number; the
piling of Pelion upon Ossa in all the active content (page after page of
JavaScript, etc) in many (most?) modern Web sites that does nothing more than
'eye candy'; etc, etc.

	Noel


From imp at bsdimp.com  Wed May  9 01:22:53 2018
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 8 May 2018 09:22:53 -0600
Subject: [TUHS] unix "awesome list"
In-Reply-To: <20180508151722.49CFC18C079@mercury.lcs.mit.edu>
References: <20180508151722.49CFC18C079@mercury.lcs.mit.edu>
Message-ID: <CANCZdfp8htKqHtph=KCk78XzHOiSJiOmDkyFjOvCseGXCEG+mA@mail.gmail.com>

On Tue, May 8, 2018 at 9:17 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Clem Cole
>
>     > I agree with Tannenbaum that uKernel's make more sense to me in the
> long
>     > run - even if they do cost something in speed
>
> There's a certain irony in people complaining that ukernel's have more
> overhead - while at the same time time mindlessly, and almost universally,
> propogating such pinheaded computing hogs as '_mandating_ https for
> everything
> under the sun' (even things as utterly pointless to protect as looking at
> Wikipedia articles on mathematics), while simultaneously letting
> Amazon/Facebook/Google do the 'all your data are belong to us' number; the
> piling of Pelion upon Ossa in all the active content (page after page of
> JavaScript, etc) in many (most?) modern Web sites that does nothing more
> than
> 'eye candy'; etc, etc.
>

But I want sshd on my pdp11 so that I can securely log in :(

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

From jon at fourwinds.com  Wed May  9 01:23:30 2018
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 08 May 2018 08:23:30 -0700
Subject: [TUHS] unix "awesome list"
In-Reply-To: <CAC20D2Oez0HVf-6jXxkcVmVR_sVpwgm5j12ce-hhawegGpTXmQ@mail.gmail.com>
References: <alpine.BSF.2.21.999.1805080707060.13425@aneurin.horsfall.org>
 <b637e35002b1b5e78a943407e221d8da87464e4e@webmail.yaccman.com>
 <20180508122429.GG999@thunk.org>
 <20180508135121.7D70C156E510@mail.bitblocks.com>
 <CAC20D2Oez0HVf-6jXxkcVmVR_sVpwgm5j12ce-hhawegGpTXmQ@mail.gmail.com>
Message-ID: <201805081523.w48FNUXw018920@darkstar.fourwinds.com>

Here's an excerpt from the book on which I'm working (thanks to Clem for
proofreading) that is my take on how things got to be the way that they
are today.  BTW, I was coming into work one evening when Ken was heading
out the door for his sabbatical.  I remember him just waltzing past the
security guard with an armload of mag tapes and thinking wow, there aren't
that many people who could get away with that.

Jon


A long time ago people made money selling computers.  Software was written
and given away in order to help sell computers.  There was a culture of
sharing and working together to improve software.  More and more people
wrote and shared software as computers became more accessible.

The Multics operating system was collaboratively developed in the 1960s
by Bell Telephone Laboratories, General Electric, and the Massachusetts
Institute of Technology.  Bell pulled out of the project, and some of
the people (most notably Ken Thompson and Dennis Ritchie) there who had
worked on it decided to make a more practical version that ran on the
smaller minicomputers produced by the Digital Equipment Corporation (DEC).
It was the first portable operating system which means that it could run on
more than one type of computer.  This innovative operating system, UNIX,
embodied a new minimalist and modular philosophy for software that we'll
discuss shortly.

Ken Thompson took a copy of UNIX with him in 1975 when he took a sabbatical
year to teach at the University of California, Berkeley.  This had a huge
effect that still reverberates today.  Students had access to a real
working system.  They could examine the code to see how things worked,
and they could make changes.  Not only that, but they were exposed to the
philosophy.  Berkeley produced its own version of UNIX, BSD for Berkeley
SPoftware Distribution.

Students added many new important features to the system.  The networking
code that is the foundation of the Internet was written for UNIX at Berkeley.
Berkeley graduates started companies such as Sun Microsystems that made
commercial UNIX-based systems.

Personal computers changed this.  All of a sudden the people writing
software weren't the people selling computers, so they needed to charge
for it.  But there was still an attitude of ``it's great that we make
a living doing this cool stuff''.  This changed dramatically when Bill
Gates came on the scene.  As is evident from numerous court depositions,
his focus was on making money.  If he had to do something cool to make money
he would, but his priorities were opposite those of others in the industry.
How did this change things?

Software development began to be driven more by politics, lawyers, and
underhanded behavior than engineers.  Much of this focused on suppressing
innovation that competed with existing products.  For example, Microsoft
started with MS-DOS, a program that they bought from its developer Tim
Paterson.  Microsoft let it languish as they were making plenty of money
from it.  A company called Digital Research came out with an improved
version called DR-DOS.  When Microsoft came out with Windows, the original
version of which ran on top of DOS, they included a hidden, encrypted piece
of code that checked to see if the system was running MS-DOS or DR-DOS, and
generated phony errors if it found DR-DOS.  This made DR-DOS unsuccessful in
the marketplace even though it was a arguably better product for the money.

It wasn't just Microsoft.  Apple also sued Digital Research for copying their
user interface in a product called GEM.  Digital Research would probably
have prevailed eventually, but would have gone bankrupt in the process
because Apple had much deeper pockets.  Somewhat absurd when you realize
that the Apple user interface was substantially copied from the Xerox Alto.

Unfortunately, this mindset continues today with threatened big players
resorting to the courts instead of innovating their way out of their
difficulties.  Examples abound such as SCO versus IBM, Oracle versus Google,
Apple versus Samsung, Samsung versus Apple, Intellectual Ventures shell
companies versus the world, etc.

Personal computers started becoming popular in the mid-1980s.  It wasn't
practical to run UNIX on them because the hardware lacked a memory management
unit although there was a variant called Xenix that did run on PCs.

Colleges starting using personal computers to teach computer science because
they were cheaper.  However, unlike the UNIX-era graduates from Berkeley,
students did not have the ability to look at the code of the system that
they were using.  And the system with which they became familiar was
considerably less advanced than UNIX.  As a result graduates from this
era were not generally of the same quality.

In part as a reaction to this, Richard Stallman started the GNU (Gnu's Not
Unix) project in 1983.  Among other things, the goal was to create a free,
open-source version of UNIX.  Stallman created the copyleft, a variant
of the copyright used by others to protect their software.  The copyleft
essentially said that others were free to use and modify the code as long
as they made their modifications available under the same terms.  In other
words, we'll share our code with you if you share yours with everyone else.
The GNU project did a great job of recreating the UNIX utilities such as cp.
But it was slow to create the operating system itself.

Linus Torvaldis began work on what is now known as the Linux operating
system in 1991 because there was no GNU operating system.  To a large degree
this work was made possible by the existence of the GNU tools such as the
C compiler.  Linux has become extremely popular.  It's used heavily in
data centers (the cloud), it's the underlying software in Android devices,
it's in many appliances.  This book was written on a Linux system.

Large companies were originally skeptical about using open source software.
Who would fix the bugs?  Somewhat ludicrous; if you've ever reported a
bug to Microsoft, Apple, or any other large company you know how much
attention it gets.  In 1989, John Gilmore, David Henkel-Wallace, and
Michael Tiemann founded Cygnus Support to provide commercial support for
open source software.  It's existence greatly increased the willingness
of companies to use open source software.

In many ways Linux and GNU have brought us a new golden era similar to the
Berkeley UNIX days.  It's not quite as shiny because some of the people from
the PC era are making changes without really understanding the philosophy.


From scj at yaccman.com  Wed May  9 01:31:43 2018
From: scj at yaccman.com (Steve Johnson)
Date: Tue, 08 May 2018 08:31:43 -0700
Subject: [TUHS] unix "awesome list"
In-Reply-To: <CAC20D2Oez0HVf-6jXxkcVmVR_sVpwgm5j12ce-hhawegGpTXmQ@mail.gmail.com>
Message-ID: <146d3e969e94918e80c3d7dae01f0a839968e6bb@webmail.yaccman.com>

Well, as I look to the future I see the whole approach we have to
software running into a dead end.  In fact, I think software is
holding us back.   It wasn't always true.  In the old days,
software ideas (like floating point, index registers, caches, etc.)
proved their worth and were put into hardware to make them faster.  I
think around 1980 this stopped happening.  Instead, hardware gave us
20 years of Moore's law, with ever faster and cheaper processors. 
 The increase in performance pretty much hid the inefficiency that
the software bloat introduced.

Starting about 2000, this changed.  Hardware was no longer offering
increased speed.  But what it was offering was massive parallelism. 
The response was to cling to the one instruction at a time model,
introducing multicore and its attendant hardware complexity to try to
cling to the previous model of programming.   The hardware to make
this possible is expensive and does not scale.

My company, Wave Computing, has built a chip with 16,000 8-bit
processors on it.  And we have plans to build systems with up to a
quarter million processors.  We are breaking ground in new ways to
use hundreds of processors to solve problems very quickly.  It's a
new way of thinking, and it makes your brain hurt.  But is is what
the hardware is giving us, and there is at least another order of
magnitude ahead before this trend starts running out of steam.

And it's exciting...

Steve

----- Original Message -----
From:
 "Clem Cole" <clemc at ccc.com>

To:
"Bakul Shah" <bakul at bitblocks.com>
Cc:
"The Eunuchs Hysterical Society" <tuhs at tuhs.org>
Sent:
Tue, 8 May 2018 10:53:16 -0400
Subject:
Re: [TUHS] unix "awesome list"

I'll take a slight different road on this topic.  I think we are
dealing with the paradox of progress.
 I don't blame Linux's developers any more than I blame BSDs or
anyone else.   Really it was hardware progress/Moore's law that
changed the rules :-)

As much as I wax a bit for the simplicity of the Fifth, Sixth, and
Seventh Editions of my youth, the truth is I would not want to try to
use them today.   My needs are now different and I think the is true
for most people also which is why a modern UNIX implementation is
different from the original ideas or maybe I should say ideal.  That
said, a lot of what I did then, ands like Steve, I still do use and
many of the 'classic solutions' I find are better for me (_i.e. _troff
_vs._ MS-Word)

Pike's '_cat -v harmfu_l' paper foretold where we would get.   On
the PDP-11 with a limited address, a programmer was constrained so you
had to keep things simple.   The programming model of small simple
programs that did one thing well, was easier to 'enforce.'   The
ideas that formed UNIX make sense, and yoiu could build an extremely
power 'system' from simple and small things.   At the time, that was
almost heretical.    But once HW dropped in price and the address
space issues relaxed the size of a program that could be written,
people did.  The cast was out of the bag, and there was no going
back.    I'm not saying all of the new BSDism of the time were
right, but they certainly made many things easier/more approachable
for many users and many/most live in modern UNIX definition.

I think Ted makes an excellent point, that *BSD and Linux, by their
nature of being 'open' and 'available' pushed the code along and that
needs to continue to be the high order bit.  Open and freely
available had a huge positive effect, because many of these new
feature (like X-Windows, Networking) were 'useful' and the cost to add
them was accessible -- so people added them.   But .... slowly the
system changed and the _expectations_ of the users with them.

I admit, I'm torn.   I do think Pike was right and many of the new
features/frameworks _et al_ are pretty lame (useless IMHO) and the
simpler/cleaner methods of old, are being ignored. Dave Pressotto and
I were talking a week or so ago and Dave made the observation that
he's not sure he knows how write a modern program now with all these
frameworks, IDEs, _etc_ and I completely agree.  But that is the old
guy in me talking; but I really do want to see progress and the new
generation make its mark.  I'm sure they will do wonderful things. 

Bakul's observation of little >>practical<< progress is an interesting
one.   In many ways I agree, in others I'm not so sure.  I think
Ted knows that my major gripe with some of the Linux (and Gnu style)
community has been a focus on reimplementing things that were already
there instead of using what could have been taken from somewhere else
such as BSD, or replacing subsystems just because they could without
really adding anything (_i.e._ the whole systemd argument).

But over all, as much as I respect and think Ken and Dennis did
amazing work at the time, I do tend to love when new ideas/things have
been done beyond the original ideas from Ken and Dennis.  For
instance, just as BSD can take credit (or blame) or sockets and making
UNIX really a 'networked OS', Sun really gave us multiple file systems
with the VFS, but  I strongly credit Linux for really making kernel
modules a reality (yup Solaris had them, as did a few other systems -
but it was really Linux that made it wide spread).   I wish Linux
had taken the idea of a modular kernel a tad farther, and picked up
things like Locus vproc work, because I personally think modularity
under the covers is better than the containers mess we have today (and
I agree with Tannenbaum that uKernel's make more sense to me in the
long run - even if they do cost something in speed).

it's also why I liked Plan 9 and have high hopes that a new OS, maybe
written is something like Rust might finally appear.   But I don't
want it re-implement UNIX or Linux.   Grab from them the subsystems
that you need to duplication, but don't re-invent.

Warren - at the risk of being political -- I think the paradox we have
it larger than just UNIX, although it is simple.  We can wallow and
say everything is bad, it was simpler in 1959 -- which exactly what
some folks in my country seem to be doing in other areas.  I
personally can say my world was simple in those days and I certainly
have fond memories [read Bill Bryson's
https://www.amazon.com/Life-Times-Thunderbolt-Kid-Memoir/dp/0767919378
[1] which parrots many of my own memories of those times ], but UNIX,
like the world, has grown up and changed and is a lot more
complicated.   I like progress we have now.  I don't want the world
the way it was any more than I want run Fifth Edition on my Mac for
day-2-day work.

Yes, I would like us to look at the good from the past and see if we
can have some of the good things again; but if it means giving up what
gained too, then we have gone backwards.  The problem is how to
decide what was good and what was bad?   What is real progress and
what is just 'showing off your money' to use a Forest Gump concept.

I suspect we will argue for a long time about what qualifies as
progress from the core idea of UNIX and what does not.

Clem

ᐧ



Links:
------
[1]
https://www.amazon.com/Life-Times-Thunderbolt-Kid-Memoir/dp/0767919378

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

From krewat at kilonet.net  Wed May  9 02:18:02 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Tue, 8 May 2018 12:18:02 -0400
Subject: [TUHS] unix "awesome list"
In-Reply-To: <20180508151722.49CFC18C079@mercury.lcs.mit.edu>
References: <20180508151722.49CFC18C079@mercury.lcs.mit.edu>
Message-ID: <92064c68-1ab9-085f-3259-10efdf94da11@kilonet.net>



On 5/8/2018 11:17 AM, Noel Chiappa wrote:
>    
> There's a certain irony in people complaining that ukernel's have more
> overhead - while at the same time time mindlessly, and almost universally,
> propogating such pinheaded computing hogs as '_mandating_ https for everything
> under the sun' (even things as utterly pointless to protect as looking at
> Wikipedia articles on mathematics), while simultaneously letting
> Amazon/Facebook/Google do the 'all your data are belong to us' number; the
> piling of Pelion upon Ossa in all the active content (page after page of
> JavaScript, etc) in many (most?) modern Web sites that does nothing more than
> 'eye candy'; etc, etc.
>

Part of the https wave is the fact that the Tin Foil Hat Society thinks 
they are being maliciously monitored by the gov't. The move towards 
privacy on the Internet is fostered by this conspiracy-minded 
thoughtlessness. Meanwhile, it just adds another step to any entity 
wanting to figure out what you've been doing online. Either monitor your 
browser (ala telemetry), or the websites themselves. If one were to see 
https traffic to a website that's known for it's racist content, then 
that pretty much defines what you've been doing without having to 
decrypt the actual packets. Much less get your search history from 
Google in the first place.

I've heard this very same privacy concern from what I consider 
moderately intelligent people I associate with.

I have a (very) small website in http that has a few TOPS-10 items for 
download. That doesn't need to be https, but for some reason, I've heard 
that Google will lower my rankings because I'm not using https. What 
tomfoolery is this?

ak




From clemc at ccc.com  Wed May  9 02:32:00 2018
From: clemc at ccc.com (Clem Cole)
Date: Tue, 8 May 2018 12:32:00 -0400
Subject: [TUHS] unix "awesome list"
In-Reply-To: <146d3e969e94918e80c3d7dae01f0a839968e6bb@webmail.yaccman.com>
References: <CAC20D2Oez0HVf-6jXxkcVmVR_sVpwgm5j12ce-hhawegGpTXmQ@mail.gmail.com>
 <146d3e969e94918e80c3d7dae01f0a839968e6bb@webmail.yaccman.com>
Message-ID: <CAC20D2MxJLPfwK3d149GAGFHfRCzpa=wa8CDK3SuKPMJS=C9wA@mail.gmail.com>

On Tue, May 8, 2018 at 11:31 AM, Steve Johnson <scj at yaccman.com> wrote:

> Well, as I look to the future I see the whole approach we have to software
> running into a dead end.  In fact, I think software is holding us back.
>
​You might be right here, but where we disagree I think is economics.​  The
problem is that we can not afford to replace SW.   As I like to point out,
Fortran still pays my salary -- why because all the data and codes that use
that data written since the late 1950s.

Its just worse in the commercial side.  Word and Lookout/Exchange sucks -
but people use them and they are not going away.  Think about the LISP
Machine or the CM1 - lots of people though they were 'better' for some
concept of goodness.  But they failed in the end.






>
> ​...​
>
> Starting about 2000, this changed.  Hardware was no longer offering
> increased speed.  But what it was offering was massive parallelism.  The
> response was to cling to the one instruction at a time model, introducing
> multicore and its attendant hardware complexity to try to cling to the
> previous model of programming.   The hardware to make this possible is
> expensive and does not scale.
>
​I agree but ... IMO its going to take a real Christensen disruption with a
new customer base.   I just don't see that happening any time soon.
 Without a new customer base to support the new technology, the economics
of the keeping the old running has and will continue to go forward.​




>
> And it's exciting...
>
​I agree and I'm a fan and cheering from the sidelines .... but I'm
skeptical of success because the economics don't play to success..​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180508/facfc5f5/attachment.html>

From web at loomcom.com  Wed May  9 02:25:37 2018
From: web at loomcom.com (Seth Morabito)
Date: Tue, 08 May 2018 09:25:37 -0700
Subject: [TUHS] Old Usenet newsreader source code?
Message-ID: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>

Hi all,

Forgive this cross-post from cctalk, if you're seeing this message twice. TUHS seems like a very appropriate list for this question.

I'm experimenting with setting up UUCP and Usenet on a cluster of 3B2/400s, and I've quickly discovered that while it's trivial to find old source code for Usenet (B News and C News), it's virtually impossible to find source code for old news *readers*.

I'm looking especially for nn, which was my go-to at the time. The oldest version I've found so far is nn 6.4, which is too big to compile on a 3B2/400. If I could get my hands on 6.1 or earlier, I think I'd have a good chance.

I also found that trn 3.6 from 1994 works well enough, though it is fairly bloated. Earlier versions of that might be better.

Does anyone have better Google-fu than I do? Or perhaps you've got earlier sources squirreled away?

As an aside: If you were active on Usenet in 1989, what software were you using?

-Seth
-- 
  Seth Morabito
  web at loomcom.com


From lm at mcvoy.com  Wed May  9 02:36:43 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 8 May 2018 09:36:43 -0700
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
Message-ID: <20180508163643.GA16384@mcvoy.com>

> As an aside: If you were active on Usenet in 1989, what software were you using?

rn


From paul.winalski at gmail.com  Wed May  9 02:42:52 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Tue, 8 May 2018 12:42:52 -0400
Subject: [TUHS] [groff] Brian Kernighan on the evoution of eqn, pic,
 grap into troff
In-Reply-To: <CAKr6gn1Ln70_-jQfgd2Q+PEdddjQJNt0NiJHRdX5DAxTwxxgjA@mail.gmail.com>
References: <201805060229.w462T9Ee018534@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.02.1805052335060.55205@frieza.hoshinet.org>
 <CAKr6gn1Ln70_-jQfgd2Q+PEdddjQJNt0NiJHRdX5DAxTwxxgjA@mail.gmail.com>
Message-ID: <CABH=_VS3yFAWc4KCO+_6engO8NRhNqGSSk4uMG9Bk=DnOG3CbQ@mail.gmail.com>

On 5/7/18, George Michaelson <ggm at algebras.org> wrote:
>
> T/roff might have been disgusting, but so was RUNOFF which I was
> familiar with. So this is the classic "you can have it perfect, or
> have it next tuesday" moment, which I believe was J Pierpoint Morgan,
> who was in Zork, on the zorkmid, so I know it was a "thing".

The character in Zork was banker J. Pierpoint Flathead.  The zorkmid
coins and bills bore the likenesses of various kings of the Flathead
dynasty, such as Belwit the Flat and Dimwit Flathead.

-Paul W.


From imp at bsdimp.com  Wed May  9 02:43:30 2018
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 8 May 2018 10:43:30 -0600
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <20180508163643.GA16384@mcvoy.com>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
Message-ID: <CANCZdfqXiTgXCC0S0rX+TL4Ut1-9zayuBi3R19nUrbeUZyxY9Q@mail.gmail.com>

http://ftp.fi.netbsd.org/pub/misc/archive/comp.sources.unix/volume23/trn/
might be a good place to start looking.

Warner

On Tue, May 8, 2018 at 10:36 AM, Larry McVoy <lm at mcvoy.com> wrote:

> > As an aside: If you were active on Usenet in 1989, what software were
> you using?
>
> rn
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180508/cc1d52a8/attachment.html>

From krewat at kilonet.net  Wed May  9 02:53:40 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Tue, 8 May 2018 12:53:40 -0400
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
Message-ID: <3d106621-3889-19b5-4162-4bc039699a84@kilonet.net>



On 5/8/2018 12:25 PM, Seth Morabito wrote:
> I'm looking especially for nn, which was my go-to at the time. The oldest version I've found so far is nn 6.4, which is too big to compile on a 3B2/400. If I could get my hands on 6.1 or earlier, I think I'd have a good chance.
>
 From this: 
https://webcache.googleusercontent.com/search?q=cache:NhNfJ21wtY8J:https://static.loomcom.com/3b2/software/3b2archive/yahozna/misc/unix-c/usenet/000-index.txt+&cd=2&hl=en&ct=clnk&gl=us&client=firefox-b-1

I assume that nn 6.4 was indeed able to run on 3B2 but maybe not a model 
400?




From web at loomcom.com  Wed May  9 03:01:19 2018
From: web at loomcom.com (Seth Morabito)
Date: Tue, 08 May 2018 10:01:19 -0700
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <3d106621-3889-19b5-4162-4bc039699a84@kilonet.net>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <3d106621-3889-19b5-4162-4bc039699a84@kilonet.net>
Message-ID: <1525798879.1346575.1365076168.7DACCEFA@webmail.messagingengine.com>

On Tue, May 8, 2018, at 9:53 AM, Arthur Krewat wrote:
> 
> 
> On 5/8/2018 12:25 PM, Seth Morabito wrote:
> > I'm looking especially for nn, which was my go-to at the time. The oldest version I've found so far is nn 6.4, which is too big to compile on a 3B2/400. If I could get my hands on 6.1 or earlier, I think I'd have a good chance.
> >
>  From this: 
> https://webcache.googleusercontent.com/search?q=cache:NhNfJ21wtY8J:https://static.loomcom.com/3b2/software/3b2archive/yahozna/misc/unix-c/usenet/000-index.txt+&cd=2&hl=en&ct=clnk&gl=us&client=firefox-b-1
> 
> I assume that nn 6.4 was indeed able to run on 3B2 but maybe not a model 
> 400?

Well now I have to laugh... loomcom.com is my own server. Apparently I had old versions of trn and nn *right under my own nose*. That just goes to show how badly I need to curate that big dump of 3B2 stuff I've been hoarding.

Thank you for finding that.

(By the way, I reorganized recently. Everything under https://static.loomcom.com/3b2/software moved to https://static.loomcom.com/3b2/software_archive/ so I could build a brand new repository under the 'software' directory.)

-Seth
-- 
  Seth Morabito
  web at loomcom.com


From mparson at bl.org  Wed May  9 02:31:37 2018
From: mparson at bl.org (Michael Parson)
Date: Tue, 08 May 2018 11:31:37 -0500
Subject: [TUHS] unix "awesome list"
In-Reply-To: <20180508122429.GG999@thunk.org>
References: <alpine.BSF.2.21.999.1805080707060.13425@aneurin.horsfall.org>
 <b637e35002b1b5e78a943407e221d8da87464e4e@webmail.yaccman.com>
 <20180508122429.GG999@thunk.org>
Message-ID: <95a2a49d689b9a9c844e76ebf8385885@bl.org>

On 2018-05-08 07:24, Theodore Y. Ts'o wrote:
> On Mon, May 07, 2018 at 02:53:26PM -0700, Steve Johnson wrote:
>> Some would argue that it was well on its way to being forgotten by
>> BSD.  The problem with that statement is that the deployment of mice
>> and touchscreens meant that the base premise (universal interface) was
>> no longer true.  Fonts and markup completed the job.
>> 
>> When I first used Unix, I wrote several ed scripts every day, and
>> several shell scripts each week.  Glass terminals made ed scripts
>> obsolete without any similar abstraction being available for doing
>> similar text operations on several related files.
> 
> While true, that's only part of the story.  There was also the issue
> that what users wanted to *do* with computers got more complex.
> Consider spreadsheets and relational databases --- how do they get
> implemented in "the Unix way"?  There was rdb, but it was a bit of a
> disaster from a performance perspective and only worked for toy
> databases.  And this wasn't unique to Unix.  In the VMS world,
> ALL-IN-1 offered group scheduling/calendaring and other "office
> software" features.  You *could* implemnt a group scheduling system
> using sed, awk, grep, cat, and pipelines --- but would you want to?
> Is that the best way to go about doing things?
> 
> And on the hardware side, the advent of hot-pluggable hardware devices
> and much more complex UI devices (sound, video cameras, etc.) that
> need to be made accessible to the logged-in user sitting in front of a
> particular console, put a lot more pressure on the simple login and
> /dev model of historical Unix.
> 
> So sure, it's easy to criticize "PenguinOS" for departing from the
> Unix ideal.  But what's the alternative?  Can the criticis design
> something better that matches the needs and requirements of the users
> (who don't like big question marks on dashboards as "user friendly"
> error reporting) and the realities of modern hardware and modern user
> interface?
> 
> And if so, would those critics care to implement it and contribute it
> under a BSD-style license?  (Or some other Open Source License)?
> After all competing with the user friendliness of GNOME should be that
> hard --- and it's been getting easier over the years as GNOME cuts
> feature after feature from their system.  :-)
> 

For me, it's not really the proliferation of servers (rdbms, web 
servers, collaboration back-ends, etc), desktop apps (spreadsheets, word 
processors, etc), but more of the 'traditional' unix cli utils that have 
grown beyond the 'do one thing' mantra.

Going beyond 'cat -v considered harmful', things like ifconfig, route, 
and netstat being considered 'deprecated' and replaced with the 'ip' 
tool.  Same with syslog, cron, init, and who knows what else, being 
replaced with systemd and journald.  This doesn't even cover how vim has 
become way more than just a GNU re-implementation of vi.

-- 
Michael Parson
Pflugerville, TX
KF5LGQ


From arnold at skeeve.com  Wed May  9 03:06:02 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 08 May 2018 11:06:02 -0600
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <20180508163643.GA16384@mcvoy.com>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
Message-ID: <201805081706.w48H62gd027214@freefriends.org>

Larry McVoy <lm at mcvoy.com> wrote:

> > As an aside: If you were active on Usenet in 1989, what software were you using?
>
> rn

trn.  I *still* use it for the count-on-the-fingers-of-one-hand newgroups
that I follow.

Arnold


From clemc at ccc.com  Wed May  9 03:09:17 2018
From: clemc at ccc.com (Clem Cole)
Date: Tue, 8 May 2018 13:09:17 -0400
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <20180508163643.GA16384@mcvoy.com>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
Message-ID: <CAC20D2NtFhwpmXjfEWqjtt5gNMz2Z6uKVcULhvyj4L6FGz1ACg@mail.gmail.com>

On Tue, May 8, 2018 at 12:36 PM, Larry McVoy <lm at mcvoy.com> wrote:

> > As an aside: If you were active on Usenet in 1989, what software were
> you using?
>
> rn
>
​+1 I also transitioned to trn at some point before I quit​


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

From lm at mcvoy.com  Wed May  9 03:20:43 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 8 May 2018 10:20:43 -0700
Subject: [TUHS] unix "awesome list"
In-Reply-To: <95a2a49d689b9a9c844e76ebf8385885@bl.org>
References: <alpine.BSF.2.21.999.1805080707060.13425@aneurin.horsfall.org>
 <b637e35002b1b5e78a943407e221d8da87464e4e@webmail.yaccman.com>
 <20180508122429.GG999@thunk.org>
 <95a2a49d689b9a9c844e76ebf8385885@bl.org>
Message-ID: <20180508172043.GB16384@mcvoy.com>

On Tue, May 08, 2018 at 11:31:37AM -0500, Michael Parson wrote:
> Going beyond 'cat -v considered harmful', things like ifconfig, route, and
> netstat being considered 'deprecated' and replaced with the 'ip' tool.  Same
> with syslog, cron, init, and who knows what else, being replaced with
> systemd and journald.  This doesn't even cover how vim has become way more
> than just a GNU re-implementation of vi.

I'm not thrilled with the systemd stuff either, I still don't see that it is
solving anything that wasn't solved.  But somebody must like it, it's a big
change.

vim, on the other hand, oh do I love me some vim.  It's pretty faithful to
the original vi but you get split windows, infinite undo, it remembers 
stuff from one invocation to the next, it's pretty sweet.
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From crossd at gmail.com  Wed May  9 03:27:55 2018
From: crossd at gmail.com (Dan Cross)
Date: Tue, 8 May 2018 13:27:55 -0400
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <201805081706.w48H62gd027214@freefriends.org>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
Message-ID: <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>

On Tue, May 8, 2018 at 1:06 PM, <arnold at skeeve.com> wrote:

> Larry McVoy <lm at mcvoy.com> wrote:
> > > As an aside: If you were active on Usenet in 1989, what software were
> you using?
> >
> > rn
>
> trn.  I *still* use it for the count-on-the-fingers-of-one-hand newgroups
> that I follow.


I also still use trn for the small number of groups that I can bring myself
to still read semi-regularly.

I was lamenting the (asymptotic) death of usenet to a colleague the other
day and asked, "where are all the cool kids these days?" I was only half
joking: back when news was the main nexus of interaction for technical
communities, it really was where you'd go to find things out and where you
could reasonably expect to interact with experts. For example, occasionally
the likes of Dennis Ritchie would even post in comp.lang.c; Ken Thompson's
MiG-29 flight story posted to rec.aviation is a classic. But those days are
long gone, so where do technical communities communicate electronically?
I'm told Reddit is the new hotness, but it's just not the same (if for no
other reason than that it's totally centralized under the control of a
single corporate organization).

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

From tytso at mit.edu  Wed May  9 03:33:55 2018
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Tue, 8 May 2018 13:33:55 -0400
Subject: [TUHS] unix "awesome list"
In-Reply-To: <146d3e969e94918e80c3d7dae01f0a839968e6bb@webmail.yaccman.com>
References: <CAC20D2Oez0HVf-6jXxkcVmVR_sVpwgm5j12ce-hhawegGpTXmQ@mail.gmail.com>
 <146d3e969e94918e80c3d7dae01f0a839968e6bb@webmail.yaccman.com>
Message-ID: <20180508173355.GA28388@thunk.org>

On Tue, May 08, 2018 at 08:31:43AM -0700, Steve Johnson wrote:
> Well, as I look to the future I see the whole approach we have to
> software running into a dead end.  In fact, I think software is
> holding us back.

What's holding us back is our human minds' ability to manage
complexity.

> Starting about 2000, this changed.  Hardware was no longer offering
> increased speed.  But what it was offering was massive parallelism. 
> The response was to cling to the one instruction at a time model,
> introducing multicore and its attendant hardware complexity to try to
> cling to the previous model of programming.   The hardware to make
> this possible is expensive and does not scale.
> 
> My company, Wave Computing, has built a chip with 16,000 8-bit
> processors on it.  And we have plans to build systems with up to a
> quarter million processors.  We are breaking ground in new ways to
> use hundreds of processors to solve problems very quickly.  It's a
> new way of thinking, and it makes your brain hurt.

And that's the problem.  If we can't program the new machines, whether
it's Sun's attempt at large number of weak cores with their Niagra
chips, or your company's vast number of 8-bit processors --- as the
old saying goes, without software, it's just a doorstop.

Moving the discussion back to Unix, the problem is that we don't have
a lot of solutions to the complexity wall.  The most common one seems
to be deny the existence, or the validity of the requiremnts.  (e.g.,
"Teach them all English; if 7-bit ASCII was good enough for K&R, it's
good enough for me." or "Text files are all you need; why do you need
new-fangled things like group calendaring or spreadsheets"?)

Or you can just build on top of pre-existing systems, but then you get
complaints about kludge towers and overly complex systems.

Or you can give up on generality, and build a bespoke system that only
addresses the problem you are paid to solve.  Which may or may not be
cheaper than using the more general solution and brute-forcing the
problem by throwing more hardware on it, on the theory that hardware
is cheaper than software engineering skills.

> ... In the old days, software ideas (like floating point, index
> registers, caches, etc.)  proved their worth and were put into
> hardware to make them faster.  I think around 1980 this stopped
> happening. 

This is not strictly true.  A counter-example would be Google's Tensor
Processing Units[1].  That's an example of custome hardware replacing
what had previously been doing in pure software, or using more general
hardware units (e.g., GPU's).  Another example would be AES and
SHA-256 acceleration being done in hardware in multiple CPU
architectures, and in the data path between the CPU and the eMMC flash
on some cell phones.

[1] https://techcrunch.com/2017/05/17/google-announces-second-generation-of-tensor-processing-unit-chips/

I think it is true we have hit the point of diminishing returns, in
that as software gets more complex, finding things which are commonly
used enough, and which have enough of a benefit that it is worth the
engineering effort and cost of moving that functionality into hardware
is much harder now compared to a few decades ago.

   	       	   	       	     	     - Ted


From akosela at andykosela.com  Wed May  9 03:42:48 2018
From: akosela at andykosela.com (Andy Kosela)
Date: Tue, 8 May 2018 12:42:48 -0500
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
Message-ID: <CALMnNGj7A9PGxp0iTQbC0FBy3O1RfAG1zsVyDL8zVsK6Jp5wcA@mail.gmail.com>

On Tuesday, May 8, 2018, Dan Cross <crossd at gmail.com> wrote:

> On Tue, May 8, 2018 at 1:06 PM, <arnold at skeeve.com> wrote:
>
>> Larry McVoy <lm at mcvoy.com> wrote:
>> > > As an aside: If you were active on Usenet in 1989, what software were
>> you using?
>> >
>> > rn
>>
>> trn.  I *still* use it for the count-on-the-fingers-of-one-hand newgroups
>> that I follow.
>
>
> I also still use trn for the small number of groups that I can bring
> myself to still read semi-regularly.
>
> I was lamenting the (asymptotic) death of usenet to a colleague the other
> day and asked, "where are all the cool kids these days?" I was only half
> joking: back when news was the main nexus of interaction for technical
> communities, it really was where you'd go to find things out and where you
> could reasonably expect to interact with experts. For example, occasionally
> the likes of Dennis Ritchie would even post in comp.lang.c; Ken Thompson's
> MiG-29 flight story posted to rec.aviation is a classic. But those days are
> long gone, so where do technical communities communicate electronically?
>

The answer could be as simple as -- you are using one such medium at this
very moment.  I honestly believe technical mailing lists are the last
bastion of information exchange in the way most of us still remember.
Although I am writing this on an iPhone (and it really sucks for writing) I
still love to read/write emails on an old school DEC terminal or DOS era
VGA monitor.

All those new fads like reddit or web based forums just don't feel "right"
to me.

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

From ron at ronnatalie.com  Wed May  9 03:44:37 2018
From: ron at ronnatalie.com (Ron Natalie)
Date: Tue, 8 May 2018 13:44:37 -0400
Subject: [TUHS] Fun with early troff.
Message-ID: <007a01d3e6f4$3c9c47c0$b5d4d740$@ronnatalie.com>

I started with roff (the simplest but utterly frozen) and moved up to nroff.   It was a few years later I was involved with a rather project to make a CAT phototypesetter emulator for the Versatec printer-plotter (similar to the BSD vcat, which we had not seen yet).   My friend George Toth went to the Naval Research Laboratory and printed out the entire typeface on their CAT on transparent film.     Then he set out to figure out a way to digitize it.

Well, next door the the EE building (where the UNIX work took place at JHU) was the biophysics department.   They had Scanning Transmission Electron Microscope there, quite an impressive machine.    The front end of the thing was a PDP-11/20 with some digital to analog converters and vice versa and a frame buffer.    The software would control the positioning of the beam and read back how much came through the material and was detected.     Essentially, you were making a raster picture of the sample in the microscope. 

George comes up with this great idea.    He takes a regular oscilloscope.   He takes the deflection wires from the 11/20 off the microscope and puts them in the X and Y amplifiers of the scope.   He then put a photomultiplier tube in the shell of an old scope camera.    He'd cut out a single character and tape it the front of the scope and hang the camera  on it.   He'd fire up the microscope software and tell it to scan the sample.    It would then put the image in the frame buffer.   We'd pull the microscope RK05 pack out and boot miniunix and read the data from the frame buffer (why we didn't just write software to drive the A2D from miniunix I do not recall).

Eventually, George gets everything scanned in and cleaned up.    It worked somewhat adequately.

Another amusing feature was that Michael John Muuss (my mentor) wrote a macro package tmac.jm.    Some people were someone peeved that we now had a "nroff -mjm" option.

Years later after ditroff was in vogue, my boss was always after me to switch to some modern document prep (Framemaker or the like).   On one rough job I told him I'd do it but I didn't have time to learn framemaker.
I write one page of this proposal, print it and then go on.   My boss would proof it and then my coworker would come behind me and make the corrections.   I ended up rewriting a million dollar (a lot of money back in 1989 or so) proposal in two days, complete with 25 pages of narrative and may be 50 pages of TBL-based tables showing compliance with the RFP.    We won that contract and got several follow ons.

Years later I was reading a published book.   I noted little telltale bumps on the top of some of the tables.   I wrote the author..."Did you use tbl and pic to typeset this book?"    Sure enough he had.   But it was way after I thought anybody was still using  such technology.   Of course, I was happy when Springer-Verlag suddenly learned out to typeset books.    I had a number of their texts in college that didn't even look like the put a new ribbon in the typewriter when setting the book.



From mparson at bl.org  Wed May  9 03:49:15 2018
From: mparson at bl.org (Michael Parson)
Date: Tue, 8 May 2018 12:49:15 -0500 (CDT)
Subject: [TUHS] unix "awesome list"
In-Reply-To: <20180508172043.GB16384@mcvoy.com>
References: <alpine.BSF.2.21.999.1805080707060.13425@aneurin.horsfall.org>
 <b637e35002b1b5e78a943407e221d8da87464e4e@webmail.yaccman.com>
 <20180508122429.GG999@thunk.org> <95a2a49d689b9a9c844e76ebf8385885@bl.org>
 <20180508172043.GB16384@mcvoy.com>
Message-ID: <alpine.NEB.2.20.1805081239360.10555@neener.bl.org>

On Tue, 8 May 2018, Larry McVoy wrote:
> On Tue, May 08, 2018 at 11:31:37AM -0500, Michael Parson wrote:
>> Going beyond 'cat -v considered harmful', things like ifconfig,
>> route, and netstat being considered 'deprecated' and replaced with
>> the 'ip' tool.  Same with syslog, cron, init, and who knows what
>> else, being replaced with systemd and journald.  This doesn't even
>> cover how vim has become way more than just a GNU re-implementation
>> of vi.
>
> I'm not thrilled with the systemd stuff either, I still don't see that
> it is solving anything that wasn't solved.  But somebody must like it,
> it's a big change.

I'm not thrilled with it either, but it seems to be how things are
going, so, I've been forced to learn how to use it.

> vim, on the other hand, oh do I love me some vim.  It's pretty
> faithful to the original vi but you get split windows, infinite undo,
> it remembers stuff from one invocation to the next, it's pretty sweet.

I resisted it for a long time, installed nvi on my penguin boxes so I
could have something resembling the vi I was raised on, but I've come to
appreciate a few of its features.  It just took some time to reprogram
my fingers for some of the features.  I find 'vimdiff' extremely useful,
but it's not really 'the unix way'. :)

-- 
Michael Parson
Pflugerville, TX
KF5LGQ


From lm at mcvoy.com  Wed May  9 03:51:26 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 8 May 2018 10:51:26 -0700
Subject: [TUHS] Fun with early troff.
In-Reply-To: <007a01d3e6f4$3c9c47c0$b5d4d740$@ronnatalie.com>
References: <007a01d3e6f4$3c9c47c0$b5d4d740$@ronnatalie.com>
Message-ID: <20180508175126.GF16384@mcvoy.com>

+1.  I've written my own macro packages, I have an outliner that I
can produce troff from, the BK User Guide (dated though it is) looks
like it is troff -ms source, and for the most part it is, you can
roff the whole thing, and I wrote a tool that produces this html:

http://www.mcvoy.com/lm/bkdocs/UG/tmp/

I was talking to Marc Donner (at Morgan Stanley at that time) about how
much I loved roff and said "You love it because the high level macros
are saying _what_ you want not _how to do it_".  The how to do it is
inside the macro definition, if the macro package is complete you rarely
resort to \fBwhatever\fP you just say
.B whatever
which is really really parseable.

The other thing I love is how version control friendly it is.  All those
line breaks are super helpful to version control.

On Tue, May 08, 2018 at 01:44:37PM -0400, Ron Natalie wrote:
> I started with roff (the simplest but utterly frozen) and moved up to nroff.   It was a few years later I was involved with a rather project to make a CAT phototypesetter emulator for the Versatec printer-plotter (similar to the BSD vcat, which we had not seen yet).   My friend George Toth went to the Naval Research Laboratory and printed out the entire typeface on their CAT on transparent film.     Then he set out to figure out a way to digitize it.
> 
> Well, next door the the EE building (where the UNIX work took place at JHU) was the biophysics department.   They had Scanning Transmission Electron Microscope there, quite an impressive machine.    The front end of the thing was a PDP-11/20 with some digital to analog converters and vice versa and a frame buffer.    The software would control the positioning of the beam and read back how much came through the material and was detected.     Essentially, you were making a raster picture of the sample in the microscope. 
> 
> George comes up with this great idea.    He takes a regular oscilloscope.   He takes the deflection wires from the 11/20 off the microscope and puts them in the X and Y amplifiers of the scope.   He then put a photomultiplier tube in the shell of an old scope camera.    He'd cut out a single character and tape it the front of the scope and hang the camera  on it.   He'd fire up the microscope software and tell it to scan the sample.    It would then put the image in the frame buffer.   We'd pull the microscope RK05 pack out and boot miniunix and read the data from the frame buffer (why we didn't just write software to drive the A2D from miniunix I do not recall).
> 
> Eventually, George gets everything scanned in and cleaned up.    It worked somewhat adequately.
> 
> Another amusing feature was that Michael John Muuss (my mentor) wrote a macro package tmac.jm.    Some people were someone peeved that we now had a "nroff -mjm" option.
> 
> Years later after ditroff was in vogue, my boss was always after me to switch to some modern document prep (Framemaker or the like).   On one rough job I told him I'd do it but I didn't have time to learn framemaker.
> I write one page of this proposal, print it and then go on.   My boss would proof it and then my coworker would come behind me and make the corrections.   I ended up rewriting a million dollar (a lot of money back in 1989 or so) proposal in two days, complete with 25 pages of narrative and may be 50 pages of TBL-based tables showing compliance with the RFP.    We won that contract and got several follow ons.
> 
> Years later I was reading a published book.   I noted little telltale bumps on the top of some of the tables.   I wrote the author..."Did you use tbl and pic to typeset this book?"    Sure enough he had.   But it was way after I thought anybody was still using  such technology.   Of course, I was happy when Springer-Verlag suddenly learned out to typeset books.    I had a number of their texts in college that didn't even look like the put a new ribbon in the typewriter when setting the book.

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


From tytso at mit.edu  Wed May  9 03:53:10 2018
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Tue, 8 May 2018 13:53:10 -0400
Subject: [TUHS] unix "awesome list"
In-Reply-To: <95a2a49d689b9a9c844e76ebf8385885@bl.org>
References: <alpine.BSF.2.21.999.1805080707060.13425@aneurin.horsfall.org>
 <b637e35002b1b5e78a943407e221d8da87464e4e@webmail.yaccman.com>
 <20180508122429.GG999@thunk.org>
 <95a2a49d689b9a9c844e76ebf8385885@bl.org>
Message-ID: <20180508175310.GB28388@thunk.org>

On Tue, May 08, 2018 at 11:31:37AM -0500, Michael Parson wrote:
> Going beyond 'cat -v considered harmful', things like ifconfig, route, and
> netstat being considered 'deprecated' and replaced with the 'ip' tool.

For better or worse, *networking* has gotten much more complicated.
So there are many more ways of specfying a routing rule than just a IP
subnet, a mask, and a weight.  After a while, trying to add new
functionality to old interface just simply gets too hard.

Again, what's the solution?  You can deny the legitimacy of the new
features, and the requirements that caused those new featuers to be
designed and implemented.  Or you can accept that there's going to be
a new interface that is designed to be more extensible, and the old
interfaces will be maintained for backwards compatibility --- but if
you want to do something fancy, you'll need to use the new interfaces.

I still often used ifconfig myself, truth be told.  But there are
times when I will use the new interfaces, because I need to use the
new features.

As far as the question of using a multiplexed command --- e.g., "ip
route" versus "route", "ip link" versus ifconfig, that's really more
of a sylistic change to me.  "ip route" is a command line tool.  The
fact that there is a space in it doesn't offend me.  In fact, that
someone has attempted to design some level of user interface
consistency between "ip route" and "ip link" and "ip tunnel" is
actually something I consider to be a feature, and the fact that there
is single command, "ip", makes discovery of all of the types of
network configuration that one might want to do much easier.

This style of interface --- also used with "git", "hg", and many
others, is arguably nicer in terms of avoiding polluting the command
line namespace than the old MH approach of appropriating separate
commands, "show", "reply", "next", "prev", "reply", etc.

		      	       	     	     - Ted


From web at loomcom.com  Wed May  9 03:53:36 2018
From: web at loomcom.com (Seth Morabito)
Date: Tue, 08 May 2018 10:53:36 -0700
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
Message-ID: <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>

On Tue, May 8, 2018, at 10:27 AM, Dan Cross wrote:
> I was lamenting the (asymptotic) death of usenet to a colleague the
> other day and asked, "where are all the cool kids these days?" I was
> only half joking: back when news was the main nexus of interaction for
> technical communities, it really was where you'd go to find things out
> and where you could reasonably expect to interact with experts. For
> example, occasionally the likes of Dennis Ritchie would even post in
> comp.lang.c; Ken Thompson's MiG-29 flight story posted to rec.aviation
> is a classic. But those days are long gone, so where do technical
> communities communicate electronically? I'm told Reddit is the new
> hotness, but it's just not the same (if for no other reason than that
> it's totally centralized under the control of a single corporate
> organization).

I think a lot about the death of Usenet, the reasons for it, and what
we've learned. I don't know if I've come to any insightful conclusions,
but I do greatly miss it. In so many ways we've gone backward. We lost a
truly decentralized message board system where one log-in allowed you to
read anything about any topic, and replaced it with a mess of
incompatible systems. On one hand we've got phpBB forums scattered all
over the web that don't talk to each other, each of which requires its
own login and password. On the other hand we have walled gardens like
Reddit and Facebook that offer much of what Usenet did, but with clumsy
user interfaces and centralized control and massive privacy concerns.
There's just nothing like Usenet.
I find more and more communities moving to Facebook, which worries me
greatly. I'm not a fan. Other than that, mailing lists seem to continue
to cling to life as the gold standard of technical communication.
>         - Dan C.

-Seth
--
  Seth Morabito
  web at loomcom.com



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

From ron at ronnatalie.com  Wed May  9 04:02:32 2018
From: ron at ronnatalie.com (Ron Natalie)
Date: Tue, 8 May 2018 14:02:32 -0400
Subject: [TUHS] Fun with early troff.
In-Reply-To: <20180508175126.GF16384@mcvoy.com>
References: <007a01d3e6f4$3c9c47c0$b5d4d740$@ronnatalie.com>
 <20180508175126.GF16384@mcvoy.com>
Message-ID: <008201d3e6f6$bd665560$38330020$@ronnatalie.com>

My first job after graduation was to work on a uber-classified project at
Martin Marietta.   These guys had just come up with the idea of using the
PWB tools to manage government projects (this was 1981) so since I had some
time to kill waiting for my security clearance to come through, I helped
them set up the UNIX machines that were to be the source archives, etc.

One of things we needed was some stuff to handle classification markings
both for regular line printer (code) output and also for nroff.    I knew
Dennis Mumaugh at the NSA had written such so I wrote to him and he says
"sure, send me a blank tape."     Well several months later a double wrapped
package comes to my HOUSE (not the office).   Great.    I take it back to
the SCIF and open it up.    Turns out it's just my blank tape (I guess the
NSA can't send anything out if not double wrapped).    So I set forth to add
a field to all the .H directives in -mm to include the security
classification.   Then at the page break I gathered the highest markings and
all the code words and printed them at the top and bottom of page (this
required the "col" filter to be used for nroff output going to our
printers).      I then also buggered the lpr command to look for
classification markigns in the what strings  and print the appropriate
banners there.

When later doing some contract work for IBM, I re-stylized the -mm package
to make the output look just like IBM's UNIX manuals.   I'm not sure what
they actually used internally.




From gtaylor at tnetconsulting.net  Wed May  9 04:28:25 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 8 May 2018 12:28:25 -0600
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
Message-ID: <0caf5ac7-4acb-0430-04e6-c8e810a74b3f@spamtrap.tnetconsulting.net>

On 05/08/2018 11:53 AM, Seth Morabito wrote:
> I think a lot about the death of Usenet, the reasons for it, and what 
> we've learned. I don't know if I've come to any insightful conclusions, 
> but I do greatly miss it. In so many ways we've gone backward. We lost a 
> truly decentralized message board system where one log-in allowed you to 
> read anything about any topic, and replaced it with a mess of 
> incompatible systems. On one hand we've got phpBB forums scattered all 
> over the web that don't talk to each other, each of which requires its 
> own login and password. On the other hand we have walled gardens like 
> Reddit and Facebook that offer much of what Usenet did, but with clumsy 
> user interfaces and centralized control and massive privacy concerns. 
> There's just nothing like Usenet.

I've seen multiple people in this thread talk as if Usenet is gone / dead.

As an active Usenet user (daily) I wonder why people say that.  I still 
see a number of good conversations take place in newsgroups.

I also participate in newsgroups hosted on an open to the public but not 
peered news server daily.

I wonder how much of what is on the web could possibly benefit from a 
good web interface to a (potentially moderated) newsgroup.

Why re-invent storing and exchanging messages when NNTP works.  …well in 
my opinion.

> I find more and more communities moving to Facebook, which worries me 
> greatly. I'm not a fan. Other than that, mailing lists seem to continue 
> to cling to life as the gold standard of technical communication.

I just saw this happen on NANOG.  Someone asked about a group for DSL 
Network Operators and subsequently someone else mentioned that they just 
created a Facebook group, which got the obligatory "what about people 
that don't use Facebook" follow up.  Predictably there was yet another 
follow up indicating that it was the fault of people not using Facebook 
for not being able to access a public forum.

I am personally quite happy with (properly configured) mailing lists and 
newsgroups.



-- 
Grant. . . .
unix || die

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

From krewat at kilonet.net  Wed May  9 04:35:26 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Tue, 8 May 2018 14:35:26 -0400
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
Message-ID: <e600c456-d900-ffe2-cfcc-aa8331a77f58@kilonet.net>

USENET as an entity is still alive and well. The reason for it might be 
sharing of warez and porn, but for example, alt.sys.pdp10 still exists :)

The problem is, many of us have stopped using it for whatever reason, 
and certainly don't store/forward much.

Maybe it's time to take it back and get back to the original intention 
of USENET.


On 5/8/2018 1:53 PM, Seth Morabito wrote:
> I think a lot about the death of Usenet, the reasons for it, and what 
> we've learned.



From imp at bsdimp.com  Wed May  9 04:45:04 2018
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 8 May 2018 12:45:04 -0600
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <e600c456-d900-ffe2-cfcc-aa8331a77f58@kilonet.net>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <e600c456-d900-ffe2-cfcc-aa8331a77f58@kilonet.net>
Message-ID: <CANCZdfqWVoQmTjZMbOSTiyhp0y1mai_bwnJ0JFXzSxsjJrEfGg@mail.gmail.com>

On Tue, May 8, 2018 at 12:35 PM, Arthur Krewat <krewat at kilonet.net> wrote:

> USENET as an entity is still alive and well. The reason for it might be
> sharing of warez and porn, but for example, alt.sys.pdp10 still exists :)
>
> The problem is, many of us have stopped using it for whatever reason, and
> certainly don't store/forward much.
>
> Maybe it's time to take it back and get back to the original intention of
> USENET.


The infrastructure is there, though in reduced form as a percent of "the
internet". However, the content has largely moved to other venues.

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

From ches at cheswick.com  Wed May  9 04:40:23 2018
From: ches at cheswick.com (William Cheswick)
Date: Tue, 8 May 2018 14:40:23 -0400
Subject: [TUHS] unix "awesome list"
In-Reply-To: <146d3e969e94918e80c3d7dae01f0a839968e6bb@webmail.yaccman.com>
References: <146d3e969e94918e80c3d7dae01f0a839968e6bb@webmail.yaccman.com>
Message-ID: <29ECC550-9E6B-44F6-8272-79785D24F9EC@cheswick.com>

It is amazing how well pipes fit into this model, up to a point.  I once wrote a program
to generate and collate hundreds of thousands of images.  I used the  sed/grep/awk model,
with all the ease of attendant text I/O processing.

I was surprised one day to find it running twice as fast as usual.  They had doubled the number of
CPUs in the machine, and my program Just Worked.  Not bad for an idea that was 35 years old.

Of course, your fleet of processors will require different programming (CSP with go?).  I look forward
to see if your solutions are even remotely as easy and useful as the originals.  

BTW, will those processors basically be 8051s?

ches


> On 8May 2018, at 11:31 AM, Steve Johnson <scj at yaccman.com> wrote:
> 
> My company, Wave Computing, has built a chip with 16,000 8-bit processors on it.  And we have plans to build systems with up to a quarter million processors.  We are breaking ground in new ways to use hundreds of processors to solve problems very quickly.  It's a new way of thinking, and it makes your brain hurt.  But is is what the hardware is giving us, and there is at least another order of magnitude ahead before this trend starts running out of steam.
> 
> And it's exciting...
> 
> Steve

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

From lyndon at orthanc.ca  Wed May  9 05:00:48 2018
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Tue, 8 May 2018 12:00:48 -0700 (PDT)
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <e600c456-d900-ffe2-cfcc-aa8331a77f58@kilonet.net>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <e600c456-d900-ffe2-cfcc-aa8331a77f58@kilonet.net>
Message-ID: <alpine.BSF.2.21.1.1805081159390.81704@orthanc.ca>

> The problem is, many of us have stopped using it for whatever reason, and 
> certainly don't store/forward much.
>
> Maybe it's time to take it back and get back to the original intention of 
> USENET.

So where on Earth does one get an NNTP feed from these days?  Lord knows 
I've tried.  An no, I'm not talking about a pay-for-access NNRP host that 
I have to pull things from.


From gtaylor at tnetconsulting.net  Wed May  9 05:05:17 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 8 May 2018 13:05:17 -0600
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <e600c456-d900-ffe2-cfcc-aa8331a77f58@kilonet.net>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <e600c456-d900-ffe2-cfcc-aa8331a77f58@kilonet.net>
Message-ID: <1b32c1a7-69ae-6593-cd01-156f15b87edc@spamtrap.tnetconsulting.net>

On 05/08/2018 12:35 PM, Arthur Krewat wrote:
> USENET as an entity is still alive and well.

Indeed.  Some might argue that there's a resurgence of Usenet servers. 
I'm just one example that's has decided to run a text only news server. 
I see more of them every year.

> The reason for it might be sharing of warez and porn,

I personally don't object to content leveraging the Usenet 
infrastructure, *as* *long* *as* *it's* *legal*.

I can personally decide if I want to partake / consume in content or 
not.  —  Obviously my text only news server does not partake in 
non-textual content.

> but for example, alt.sys.pdp10 still exists

Yep.

I'm showing 164 messages since October 10th 2017.

% ls -1 /var/spool/news/articles/alt/sys/pdp10 | wc -l
164
% ls -l /var/spool/news/articles/alt/sys/pdp10 | grep 2017
-rw-rw-r-- 1 news news 1463 Oct 10  2017 1

> The problem is, many of us have stopped using it for whatever reason, 
> and certainly don't store/forward much.

Fair.

I wonder how different things would be if various web applications 
leveraged Usenet (NNTP) (or IMAP) as a back end storage for things like 
blogs / forums.

> Maybe it's time to take it back and get back to the original intention 
> of USENET.

I question if there is really anything to take back.  I was active in 
comp.mail.sendmail for years and then stopped when I changed jobs.  All 
I had to do was subscribe my news reader and continue like nothing ever 
changed.  (Save for the smaller amount of content in said newsgroup 
these days.)

I've personally run small news servers with ~10 peers twice.  One time 
years ago, and again now I have two news servers.  One is on my VPS with 
a bunch of peers and the other is in my house that only peers with my VPS.

If anyone wants to get back into the game, let me know and I'll happily 
peer with you.

I think that "take back" really directly translates to "use again".



-- 
Grant. . . .
unix || die

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

From gtaylor at tnetconsulting.net  Wed May  9 05:09:52 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 8 May 2018 13:09:52 -0600
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <alpine.BSF.2.21.1.1805081159390.81704@orthanc.ca>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <e600c456-d900-ffe2-cfcc-aa8331a77f58@kilonet.net>
 <alpine.BSF.2.21.1.1805081159390.81704@orthanc.ca>
Message-ID: <b9eaa91e-d8e2-8c94-48f5-ec9d7a956d76@spamtrap.tnetconsulting.net>

On 05/08/2018 01:00 PM, Lyndon Nerenberg wrote:
> So where on Earth does one get an NNTP feed from these days?  Lord knows 
> I've tried.  An no, I'm not talking about a pay-for-access NNRP host 
> that I have to pull things from.

Most of the text only news servers that I've seen will happily peer with 
you.

I'm peering with the following servers:

  · CMPublishers
  · ejre
  · Eternal-September
  · Gallaxial
  · Mixmin
  · Neva
  · snarked
  · UzoRetro
  · Weretis
  · Xanadu-BBS
  · XMission

Drop me a line if you'd like to peer.



-- 
Grant. . . .
unix || die

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

From krewat at kilonet.net  Wed May  9 05:11:11 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Tue, 8 May 2018 15:11:11 -0400
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <alpine.BSF.2.21.1.1805081159390.81704@orthanc.ca>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <e600c456-d900-ffe2-cfcc-aa8331a77f58@kilonet.net>
 <alpine.BSF.2.21.1.1805081159390.81704@orthanc.ca>
Message-ID: <990f91e8-01c0-cf25-4889-43e1580398ef@kilonet.net>

On 5/8/2018 3:00 PM, Lyndon Nerenberg wrote:
>> The problem is, many of us have stopped using it for whatever reason, 
>> and certainly don't store/forward much.
>>
>> Maybe it's time to take it back and get back to the original 
>> intention of USENET.
>
> So where on Earth does one get an NNTP feed from these days?  Lord 
> knows I've tried.  An no, I'm not talking about a pay-for-access NNRP 
> host that I have to pull things from.
>
That was going to be my next question ;) - Google has the entire archive 
(minus binaries), and most commercial places have it going back only 
3000 days or so.

Where's Deja News when you need 'em.


ak


From krewat at kilonet.net  Wed May  9 05:15:38 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Tue, 8 May 2018 15:15:38 -0400
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <1b32c1a7-69ae-6593-cd01-156f15b87edc@spamtrap.tnetconsulting.net>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <e600c456-d900-ffe2-cfcc-aa8331a77f58@kilonet.net>
 <1b32c1a7-69ae-6593-cd01-156f15b87edc@spamtrap.tnetconsulting.net>
Message-ID: <dbaac3d2-c19c-a675-6cb2-c0147bbc9c8a@kilonet.net>



On 5/8/2018 3:05 PM, Grant Taylor via TUHS wrote:
> If anyone wants to get back into the game, let me know and I'll 
> happily peer with you.
>
> I think that "take back" really directly translates to "use again".

I'll take you up on that offer :) - I do have an account with one of 
those commercial providers. Not sure how they'd take to pushing news 
articles to them, but it's worth a shot.

And yes. Agreed. Most of this information is useless as it stands now, 
but good for old times sake: 
(https://groups.google.com/forum/#!topic/comp.mail.maps/vHa2YT9Od_0)


#N        kilowatt
#S        Clone 80486DX2/66; Consensys SVR4.0.3
#O        Kilowatt Computers
#C        Arthur Krewat
#E        kilowatt!krewat,krewat at kilonet.org
#T        +1 516 253 2805
#P        51 Winnecomac Ave, Deer Park, NY, 11729
#L        40 47 N / 73 18 W
#R        Public FREE UNIX system - providing news and email for UNIX
#R        knowledgeable people. Free feeds available ...
#R        Call (516) 667-6142 - Hayes Ultra 14.4 (V.32bis/...)
#R        (516) 586-4743 - Telebit WorldBlazer (TurboPEP/V.32bis/...)
#R        This system, is the main UUCP interface to irises.kilonet.org 
<http://irises.kilonet.org>, the
#R        real news workhorse.
#U        src4src jaflrn areyes erixami dabeef
#U        irises dfbbs
#W        kilowatt!krewat (Arthur Krewat) ; Sun Feb 27 10:00:01 GMT 1994
#
kilowatt kilonet.org <http://kilonet.org>(LOCAL)
kilowatt = kilowatt.kilonet.org <http://kilowatt.kilonet.org>
kilowatt        src4src(DIRECT), jaflrn(DEMAND+FAST), 
areyes(EVENING+FAST), erixami(DIRECT+FAST), dabeef(DAILY+FAST), 
irises(LOCAL), dfbbs(DAILY+FAST)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180508/9db25ea6/attachment.html>

From usotsuki at buric.co  Wed May  9 05:23:07 2018
From: usotsuki at buric.co (Steve Nickolas)
Date: Tue, 8 May 2018 15:23:07 -0400 (EDT)
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <1b32c1a7-69ae-6593-cd01-156f15b87edc@spamtrap.tnetconsulting.net>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <e600c456-d900-ffe2-cfcc-aa8331a77f58@kilonet.net>
 <1b32c1a7-69ae-6593-cd01-156f15b87edc@spamtrap.tnetconsulting.net>
Message-ID: <alpine.BSF.2.02.1805081521210.83706@frieza.hoshinet.org>

On Tue, 8 May 2018, Grant Taylor via TUHS wrote:

> On 05/08/2018 12:35 PM, Arthur Krewat wrote:
>> USENET as an entity is still alive and well.
>
> Indeed.  Some might argue that there's a resurgence of Usenet servers. I'm 
> just one example that's has decided to run a text only news server. I see 
> more of them every year.
>
>> The reason for it might be sharing of warez and porn,
>
> I personally don't object to content leveraging the Usenet infrastructure, 
> *as* *long* *as* *it's* *legal*.
>
> I can personally decide if I want to partake / consume in content or not.  — 
> Obviously my text only news server does not partake in non-textual content.
>
>> but for example, alt.sys.pdp10 still exists
>
> Yep.
>
> I'm showing 164 messages since October 10th 2017.
>
> % ls -1 /var/spool/news/articles/alt/sys/pdp10 | wc -l
> 164
> % ls -l /var/spool/news/articles/alt/sys/pdp10 | grep 2017
> -rw-rw-r-- 1 news news 1463 Oct 10  2017 1
>
>> The problem is, many of us have stopped using it for whatever reason, and 
>> certainly don't store/forward much.
>
> Fair.
>
> I wonder how different things would be if various web applications leveraged 
> Usenet (NNTP) (or IMAP) as a back end storage for things like blogs / forums.
>
>> Maybe it's time to take it back and get back to the original intention of 
>> USENET.
>
> I question if there is really anything to take back.  I was active in 
> comp.mail.sendmail for years and then stopped when I changed jobs.  All I had 
> to do was subscribe my news reader and continue like nothing ever changed. 
> (Save for the smaller amount of content in said newsgroup these days.)

:(

> I've personally run small news servers with ~10 peers twice.  One time years 
> ago, and again now I have two news servers.  One is on my VPS with a bunch of 
> peers and the other is in my house that only peers with my VPS.
>
> If anyone wants to get back into the game, let me know and I'll happily peer 
> with you.

I've thought of running a usenet server or servers - I've got a few 
servers - but I don't even know about software to do so, let alone servers 
to peer with.

> I think that "take back" really directly translates to "use again".

I've never really stopped. xD

-uso.

From ron at ronnatalie.com  Wed May  9 05:26:00 2018
From: ron at ronnatalie.com (Ron Natalie)
Date: Tue, 8 May 2018 15:26:00 -0400
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
Message-ID: <00c501d3e702$65f60850$31e218f0$@ronnatalie.com>

I do as well.   The old comp.lang.xxx was a  real resource that no longer exists really.    I know what killed it, the lack of any real moderation (the moderation system was really the honor system).   Attempts at a cooperative social moderation and USENET death packets didn’t really stem the ultimate swamping of the system by ne’er-do-wells.

 

 

From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Seth Morabito


 

On Tue, May 8, 2018, at 10:27 AM, Dan Cross wrote:

I was lamenting the (asymptotic) death of usenet to a colleague the other day and asked, " 

 

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

From gtaylor at tnetconsulting.net  Wed May  9 05:29:21 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 8 May 2018 13:29:21 -0600
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <alpine.BSF.2.02.1805081521210.83706@frieza.hoshinet.org>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <e600c456-d900-ffe2-cfcc-aa8331a77f58@kilonet.net>
 <1b32c1a7-69ae-6593-cd01-156f15b87edc@spamtrap.tnetconsulting.net>
 <alpine.BSF.2.02.1805081521210.83706@frieza.hoshinet.org>
Message-ID: <4501e9ed-7e1f-e96e-0986-2166db13c8fc@spamtrap.tnetconsulting.net>

On 05/08/2018 01:23 PM, Steve Nickolas wrote:
> I've thought of running a usenet server or servers - I've got a few 
> servers - but I don't even know about software to do so, let alone 
> servers to peer with.

I've always used INN.  I'm happy enough, and it works for me.

There are a few other common news servers.  It depends on the platform 
that you want to run on.

I'm typically seeing < 100 MB of news a day.  My VPS has < 4 GB news 
spool going back 30 days.  My private server has unchecked storage and 
is using about 42 GB.

Peers can be found.  Email if you want help.

> I've never really stopped. xD

:-)



-- 
Grant. . . .
unix || die

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

From gtaylor at tnetconsulting.net  Wed May  9 05:35:38 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 8 May 2018 13:35:38 -0600
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <dbaac3d2-c19c-a675-6cb2-c0147bbc9c8a@kilonet.net>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <e600c456-d900-ffe2-cfcc-aa8331a77f58@kilonet.net>
 <1b32c1a7-69ae-6593-cd01-156f15b87edc@spamtrap.tnetconsulting.net>
 <dbaac3d2-c19c-a675-6cb2-c0147bbc9c8a@kilonet.net>
Message-ID: <1563e805-f47c-062e-14ff-bd2afe256aba@spamtrap.tnetconsulting.net>

On 05/08/2018 01:15 PM, Arthur Krewat wrote:
> I'll take you up on that offer :)

Cool.  :-)

I'll reply directly this evening with details for you.

> I do have an account with one of those commercial providers. Not sure 
> how they'd take to pushing news articles to them, but it's worth a shot.

I don't know how they would respond.

I'd hope that they would just see a higher than expected volume, and 
that you might be posting articles that they've already seen.

Effectively you're talking about a (reverse?) suck feed.



-- 
Grant. . . .
unix || die

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

From dave at horsfall.org  Wed May  9 05:37:13 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 9 May 2018 05:37:13 +1000 (EST)
Subject: [TUHS] unix "awesome list"
In-Reply-To: <92064c68-1ab9-085f-3259-10efdf94da11@kilonet.net>
References: <20180508151722.49CFC18C079@mercury.lcs.mit.edu>
 <92064c68-1ab9-085f-3259-10efdf94da11@kilonet.net>
Message-ID: <alpine.BSF.2.21.999.1805090533410.79090@aneurin.horsfall.org>

On Tue, 8 May 2018, Arthur Krewat wrote:

> I have a (very) small website in http that has a few TOPS-10 items for 
> download. That doesn't need to be https, but for some reason, I've heard 
> that Google will lower my rankings because I'm not using https. What 
> tomfoolery is this?

I'll bet my website (about a few feet away from me) is smaller still :-)

But yeah. I've been told that I *need* HTTPS, even though the damned site 
is purely passive...

-- 
Dave Horsfall BSc DTM (VK2KFU) -- FuglySoft -- Gosford IT -- Unix/C/Perl (AbW)
People who fail to / understand security / surely will suffer. (tks: RichardM)


From dave at horsfall.org  Wed May  9 05:41:37 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 9 May 2018 05:41:37 +1000 (EST)
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
Message-ID: <alpine.BSF.2.21.999.1805090538370.79090@aneurin.horsfall.org>

On Tue, 8 May 2018, Seth Morabito wrote:

> As an aside: If you were active on Usenet in 1989, what software were 
> you using?

You name it, I've used it :-)  rn, rnews, trn, tin...  As for the 
transport, it was B-news, C-news, NNTP, ACSnet...

-- Dave


From gtaylor at tnetconsulting.net  Wed May  9 05:48:46 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 8 May 2018 13:48:46 -0600
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <00c501d3e702$65f60850$31e218f0$@ronnatalie.com>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <00c501d3e702$65f60850$31e218f0$@ronnatalie.com>
Message-ID: <cb7bedc9-a9d0-c3d7-785c-4de7fcdd437e@spamtrap.tnetconsulting.net>

On 05/08/2018 01:26 PM, Ron Natalie wrote:
> I know what killed it, the lack of any real moderation (the moderation 
> system was really the honor system).

Are you referring to 3rd party cancel messages and the likes?

I'd swear that I'm subscribed to some moderated newsgroups where posted 
articles pass through moderators (algorithm) before being posted to the 
newsgroup.  —  I've not looked at the technology under the hood.

The various mozilla.* newsgroups immediately come to mind.



-- 
Grant. . . .
unix || die

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

From gtaylor at tnetconsulting.net  Wed May  9 05:54:26 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 8 May 2018 13:54:26 -0600
Subject: [TUHS] unix "awesome list"
In-Reply-To: <alpine.BSF.2.21.999.1805090533410.79090@aneurin.horsfall.org>
References: <20180508151722.49CFC18C079@mercury.lcs.mit.edu>
 <92064c68-1ab9-085f-3259-10efdf94da11@kilonet.net>
 <alpine.BSF.2.21.999.1805090533410.79090@aneurin.horsfall.org>
Message-ID: <cf7cb033-8539-9a06-2a56-820d19800095@spamtrap.tnetconsulting.net>

On 05/08/2018 01:37 PM, Dave Horsfall wrote:
> I'll bet my website (about a few feet away from me) is smaller still :-)

Props for hosting your own site.

> But yeah. I've been told that I *need* HTTPS, even though the damned 
> site is purely passive...

I think /need/ may be a strong word.

I *strongly* believe in the various cache ability aspects of unencrypted 
HTTP.

That being said, I understand and believe in the two following reasons 
for supporting encrypted HTTPS:

1)  Encryption (from a verifiable source) makes it next to impossible 
for malicious actors to inject things into your site's traffic.  (Think 
about the various JavaScript injection techniques used for ads / 
tracking / malware / crypto mining / etc.)
2)  Creating more noise for someone with higher value signal to hide in 
when they really need to.

Finally, things like Let's Encrypt and other free cert providers make it 
much less expensive to use encrypted HTTPS.

I'm perfectly fine with people running unencrypted HTTP and encrypted 
HTTPS side by side.  Even if you don't do a redirect from unencrypted 
HTTP to encrypted HTTPS.

It's really up to each site administrator.  I'm 60% for and 40% against 
encrypted HTTPS everywhere.



-- 
Grant. . . .
unix || die

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

From bakul at bitblocks.com  Wed May  9 06:01:27 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Tue, 08 May 2018 13:01:27 -0700
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: Your message of "Tue, 08 May 2018 12:00:48 -0700."
 <alpine.BSF.2.21.1.1805081159390.81704@orthanc.ca>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <e600c456-d900-ffe2-cfcc-aa8331a77f58@kilonet.net>
 <alpine.BSF.2.21.1.1805081159390.81704@orthanc.ca>
Message-ID: <20180508200135.47C7B156E510@mail.bitblocks.com>

On Tue, 08 May 2018 12:00:48 -0700 Lyndon Nerenberg <lyndon at orthanc.ca> wrote:
Lyndon Nerenberg writes:
> > The problem is, many of us have stopped using it for whatever reason, and 
> > certainly don't store/forward much.
> >
> > Maybe it's time to take it back and get back to the original intention of 
> > USENET.
> 
> So where on Earth does one get an NNTP feed from these days?  Lord knows 
> I've tried.  An no, I'm not talking about a pay-for-access NNRP host that 
> I have to pull things from.

$ echo $NNTPSERVER
news.eternal-september.org

I think you have to register and authenticate when you connect.

I use tin now. Used to use nn in nn-6.4 days. Also used
thunderbird in between. May have used every other reader at
various times.

Back in 1989 timeframe I used to get a pretty complete feed
via uucp and maintain locally with cnews. Recently I tried
using "fetchnews" recently for that purpose (for the groups I
want) since eternal-september is a bit slow but something went
wrong.


From crossd at gmail.com  Wed May  9 06:14:54 2018
From: crossd at gmail.com (Dan Cross)
Date: Tue, 8 May 2018 16:14:54 -0400
Subject: [TUHS] Fun with early troff.
In-Reply-To: <007a01d3e6f4$3c9c47c0$b5d4d740$@ronnatalie.com>
References: <007a01d3e6f4$3c9c47c0$b5d4d740$@ronnatalie.com>
Message-ID: <CAEoi9W7fNWOLv=Ad3r6HKBTZGH3w=vhxejXcNuSuGzmzpCvY1Q@mail.gmail.com>

On Tue, May 8, 2018 at 1:44 PM, Ron Natalie <ron at ronnatalie.com> wrote:

> [...]
> Years later I was reading a published book.   I noted little telltale
> bumps on the top of some of the tables.   I wrote the author..."Did you use
> tbl and pic to typeset this book?"    Sure enough he had.   But it was way
> after I thought anybody was still using  such technology.   [...]
>

At the end of 2009 I was recalled to active duty in the Marines to deploy
to Afghanistan, where I would embed with an Afghan Army Unit. Since I was
coming from the reserves, I got to spend a couple of months stateside
getting retrained on the sort basic Marine stuff you forget unless you're
doing it every day. A big portion of that was getting re-familiarized with
radio protocol and the "standard" messages for doing things like calling in
a helicopter casualty evacuation, unexploded ordinance, combat contact,
etc. For example, there is a NATO-standard "10-line" message for calling in
a casualty evacuation that contains things like, "how many people were
injured?", "how were they injured?", "what are the manner of injuries?",
"what is the location of the nearest landing zone?" and "how is the LZ
marked?"; that sort of thing.

As part of that training I had to spend a lot of time on a static-y radio
talking to helicopter pilots sitting on folding chair the next building
(pretending they were flying helicopters), but the part that is relevant is
that we were given a set of "cheat sheets" that contained all the standard
formats in tabular format. I remember looking at them and seeing similar
tell-tale bumps on the lines of the tables and thinking, "hey, this looks
like it was formatted using troff!"

After the initial retraining, I got sent to an active duty unit to go
through their "workup" and actually deploy with them. Naturally, once I got
to Camp Pendleton to join meet up with the active duty folks I wanted to
give all of my Marines (I also had two sailors and a US Army soldier under
my command too, but that's another story -- suffice it to say that the USMC
doesn't have medical personnel and we get them from the other services)
copies of those same cheatsheets and get them trained up on talking to the
birds and so forth so that any of us could call in an evac if necessary (or
call for fire, call in a TIC, or whatever). But my little cheatsheet was
laminated and didn't photocopy well. So, that evening when I got back to
the "BOQ" I fired up a laptop and typed in the troff to reproduce those
little cards. The result was *exactly* the same output, pixel for pixel (as
near as I could tell). I printed out a bunch of copies, took them to the
local Kinkos and laminated them, and distributed them the next day.

Yup. Troff. I took it to war.

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

From clemc at ccc.com  Wed May  9 06:34:25 2018
From: clemc at ccc.com (Clem Cole)
Date: Tue, 8 May 2018 16:34:25 -0400
Subject: [TUHS] I'm interested in the thoughts of the TUHS folks about this
Message-ID: <CAC20D2PBOwiyqim7sZZvygLs8WrDD1T0weROiOZpsY9kfR3jSg@mail.gmail.com>

I'm curious as UNIX folks if somewhere can enlighten me.   I sometimes
answer things on Quora and a few years ago the following question was
posted:

What does "Experience working in Unix/Linux environments" mean when given
as a required skill in company interviews? What do they want from us?
<https://www.quora.com/What-does-Experience-working-in-Unix-Linux-environments-mean-when-given-as-a-required-skill-in-company-interviews-What-do-they-want-from-us>



Why would this be considered a spam violation - which I was notified today
as being so.



It all depends the job for the specific experiences the hiring mangers want
to see. The #1 thing I believe they will looking for is something that does
not need to have a GUI to be useful. If you a simple user, it means you are
comfortable in a text based, shell environment and are at least familiar
with, if not proficient with the UNIX tools such as, ed, vi or emacs, grep,
tail, head, sed, awk, cut, join, tr, etc. You should be able to use one or
more of the Bourne Shell/Korn Shell/Bash family or CShell. You should be
familiar with the UNIX file tree and basic layout and its protection
scheme. It helps if you understand the differences between BSD, SysV, Mac
OSx, and Linux layout; but for many jobs in the UNIX community that may not
be required. You should also understand how to use the Unix man command to
get information on the tools you are using —* i.e.* you should have read,
if not own a copy of Kernighan and Pike The Unix Programming Environment
(Prentice-Hall Software Series): Brian W. Kernighan, Rob Pike:
9780139376818: Amazon.com: Books
<https://www.amazon.com/Unix-Programming-Environment-Prentice-Hall-Software/dp/013937681X/ref=sr_1_2?ie=UTF8&keywords=kernighan+and+pike&qid=1478793529&s=books&sr=1-2>
and
be proficient in the first four chapters. If the job requires you writing
scripts to be able to write Shell script (*i.e.* program the shell) using
the Bourne Shell syntax *i.e.* Chapter 5 (Shell Programming).

If you are a programmer, then you need to be used to using the UNIX/Linux
toolchains and probably not require an IDE - again as a programmer
knowledge if not our proficiency of at least source code control system
from SCCS, RCS, CVS, SVN, Mercurial, git or the like needed. Kernighan and
Pike’s Chapter’s 6–8 should be common knowledge. But to be honest, you also
should be familiar with the contents contained within it, if not own and
keep a copy of the Rich Steven’s Advanced Programming in the UNIX
Environment, 3rd Edition: W. Richard Stevens, Stephen A. Rago:
9780321637734: Amazon.com: Books
<https://www.amazon.com/Advanced-Programming-UNIX-Environment-3rd/dp/0321637739/ref=dp_ob_title_bk>
 (*aka* APUE) on your desk.

If you are system administrator, then the required set of tools get much
larger and besides the different way to “generate” (build) a system is a
good idea; but less tools for user maintenance. In this case you should be
familiar with, again if not own have a copy on your desk of Evi
Nemeth’s Amazon.com:
UNIX and Linux System Administration Handbook, 4th Edition (8580001058917):
Evi Nemeth, Garth Snyder, Trent R. Hein, Ben Whaley: Books
<https://www.amazon.com/UNIX-Linux-System-Administration-Handbook/dp/0131480057/ref=sr_1_1?ie=UTF8&keywords=evi+nemeth+unix&qid=1478793397&s=books&sr=1-1>
 - which is and has been one of if not the best UNIX admin work for many,
many years.

Updated 05/07/18: to explain I am not shilling for anyone. I am trying to
honestly answer the question and make helpful recommendations of how to
learn what the person asked to help them be better equipped to be employed
in the Unix world. I used Amazon’s URL’s because they are global and easy
to use as a reference. But I am not suggesting you purchase from them. In
fact, if you can borrow a copy from you library to start, that might be a
good idea.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180508/14eaca88/attachment.html>

From dave at horsfall.org  Wed May  9 06:48:28 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 9 May 2018 06:48:28 +1000 (EST)
Subject: [TUHS] unix "awesome list"
In-Reply-To: <20180508172043.GB16384@mcvoy.com>
References: <alpine.BSF.2.21.999.1805080707060.13425@aneurin.horsfall.org>
 <b637e35002b1b5e78a943407e221d8da87464e4e@webmail.yaccman.com>
 <20180508122429.GG999@thunk.org> <95a2a49d689b9a9c844e76ebf8385885@bl.org>
 <20180508172043.GB16384@mcvoy.com>
Message-ID: <alpine.BSF.2.21.999.1805090644560.79090@aneurin.horsfall.org>

On Tue, 8 May 2018, Larry McVoy wrote:

> vim, on the other hand, oh do I love me some vim.  It's pretty faithful 
> to the original vi but you get split windows, infinite undo, it 
> remembers stuff from one invocation to the next, it's pretty sweet.

Oh, I love VIM too, but I wish it had an "idiot" mode i.e. ignore any 
fumbled keys that did something strange and how do I get out of here 
because suddenly I see two windows when I meant to simply quit...

-- 
Dave Horsfall BSc DTM (VK2KFU) -- FuglySoft -- Gosford IT -- Unix/C/Perl (AbW)
People who fail to / understand security / surely will suffer. (tks: RichardM)


From khm at sciops.net  Wed May  9 06:43:42 2018
From: khm at sciops.net (Kurt H Maier)
Date: Tue, 8 May 2018 13:43:42 -0700
Subject: [TUHS] Fun with early troff.
In-Reply-To: <CAEoi9W7fNWOLv=Ad3r6HKBTZGH3w=vhxejXcNuSuGzmzpCvY1Q@mail.gmail.com>
References: <007a01d3e6f4$3c9c47c0$b5d4d740$@ronnatalie.com>
 <CAEoi9W7fNWOLv=Ad3r6HKBTZGH3w=vhxejXcNuSuGzmzpCvY1Q@mail.gmail.com>
Message-ID: <20180508204342.GA58741@wopr>

On Tue, May 08, 2018 at 04:14:54PM -0400, Dan Cross wrote:
>
> For example, there is a NATO-standard "10-line" message

When did they add the 10th line?  What is in it?  I was trained on the
9-line during my service, and I'd be fascinated to know what extra info
was judged important enough to update the manuals.

> 
> Yup. Troff. I took it to war.
> 

It's been well over a decade, but there were QRF bases in Kabul whose
security manuals and operation maps were generated onsite in TeX on my 
ancient Thinkpad.  I suspect, however, an academic study of combat-zone 
typesetting would be dominated by the inevitability of Powerpoint.

I've often noticed the battlefield is ruled by Windows (e.g. those
pilots were probably poking at Falconview) while the research side is
extremely tied to unix and its ilk.  Obviously BRLCAD and other ARL
involvement here, and just about all of of the DoD HPC program skews
toward unix and linux.

khm


From bigatojj at gmail.com  Wed May  9 06:54:20 2018
From: bigatojj at gmail.com (=?UTF-8?Q?Daniel_Camol=C3=AAs?=)
Date: Tue, 08 May 2018 20:54:20 +0000
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <00c501d3e702$65f60850$31e218f0$@ronnatalie.com>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <00c501d3e702$65f60850$31e218f0$@ronnatalie.com>
Message-ID: <CAM4FNSvrv-FGPFTywEj1YyFyYGvh_10ngXaBb0R1ae9UY92rCQ@mail.gmail.com>

Em ter, 8 de mai de 2018 16:26, Ron Natalie <ron at ronnatalie.com> escreveu:

>   I know what killed it, the lack of any real moderation (the moderation
> system was really the honor system).
>

I got in quite late in the game, in 2001, but as of today I still remember
it as the best way to discuss over the internet that I have experienced. I
agree on the lack of moderation being the weakness that made the noise
surpass the signal. All the web forum software that surfaced on the 00's
and beyond was mostly a response to that. If it weren't for this weakness,
people nowadays would probably be using web interfaces to nntp just like
they do to email, and we old farts could still be happily using our
preferred news clients.

So while I applaud the ones who are trying to keep the system alive, this
weakness (and maybe others), if not addressed, will pose a natural limit to
Usenet growth and quality. If we start putting servers up and manage to
attract good contributors back, the spam will follow and then the noise
will drive them away again.

But yet, we are at such a point where bandwidth and storage is so cheap
that reviving Usenet could be accomplished by a bunch of hobbists spending
little money. If at least we could solve the moderation weakness. Does
someone have any idea if there were any attempts at cracking this problem
that were open source and effective?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180508/5a581a50/attachment.html>

From lyndon at orthanc.ca  Wed May  9 06:54:35 2018
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Tue, 8 May 2018 13:54:35 -0700
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <alpine.BSF.2.21.1.1805081159390.81704@orthanc.ca>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <e600c456-d900-ffe2-cfcc-aa8331a77f58@kilonet.net>
 <alpine.BSF.2.21.1.1805081159390.81704@orthanc.ca>
Message-ID: <C6C961FD-97B3-47CB-86CC-EF543188C5BF@orthanc.ca>

> 
> So where on Earth does one get an NNTP feed from these days?

Wow!  I wasn't expecting that kind of response :-)  I'll be getting in touch with a few of you once I get INN spun up my server.

Thanks!

--lyndon



From bakul at bitblocks.com  Wed May  9 07:15:19 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Tue, 8 May 2018 14:15:19 -0700
Subject: [TUHS] unix "awesome list"
In-Reply-To: <CAC20D2Oez0HVf-6jXxkcVmVR_sVpwgm5j12ce-hhawegGpTXmQ@mail.gmail.com>
References: <alpine.BSF.2.21.999.1805080707060.13425@aneurin.horsfall.org>
 <b637e35002b1b5e78a943407e221d8da87464e4e@webmail.yaccman.com>
 <20180508122429.GG999@thunk.org>
 <20180508135121.7D70C156E510@mail.bitblocks.com>
 <CAC20D2Oez0HVf-6jXxkcVmVR_sVpwgm5j12ce-hhawegGpTXmQ@mail.gmail.com>
Message-ID: <F46226C4-418B-46A7-99AD-46EE11E5B1DF@bitblocks.com>

On May 8, 2018, at 7:53 AM, Clem Cole <clemc at ccc.com> wrote:
> 
> I'll take a slight different road on this topic.  I think we are dealing with the paradox of progress. I don't blame Linux's developers any more than I blame BSDs or anyone else.   Really it was hardware progress/Moore's law that changed the rules :-)

Agree about the paradox of progress. Success slowed down further
evolution.

While h/w speed and number of gates increased tremendously
the particular *direction* processor architecture took is
heavily influenced by prevailing software. So I think it is
really software that is to blame :-) Intel did add callgates
for better containment but they didn't get used much.

> I think Ted makes an excellent point, that *BSD and Linux, by their nature of being 'open' and 'available' pushed the code along and that needs to continue to be the high order bit.  Open and freely available had a huge positive effect, because many of these new feature (like X-Windows, Networking) were 'useful' and the cost to add them was accessible -- so people added them.   But .... slowly the system changed and the expectations of the users with them.

The price of success.  It is easier to bolt-on solutions to new
problems on existing platform than refine the platform. Plan9
tried that. That it failed has more to do with non-tech reasons.

> Bakul's observation of little >>practical<< progress is an interesting one.   In many ways I agree, in others I'm not so sure.  I think Ted knows that my major gripe with some of the Linux (and Gnu style) community has been a focus on reimplementing things that were already there instead of using what could have been taken from somewhere else such as BSD, or replacing subsystems just because they could without really adding anything (i.e. the whole systemd argument).

The lack of progress I am talking about has to do with
the devil's bargain of trading simplicity for "efficiency".
The 16bit CPU running at 5Mhz, with 256K of RAM and 5MB of disk
in 1981 is replaced with a 64 bit processor with 16 cores,
64GB of RAM, with 10TB of disk space, with HDMI screen and
1GB/s network port (and is cheaper in terms of 1981 dollars).
And yet we continue making this bargain.

Pipes provided a perfect way to modularize programs. But we
use shared memory and threads - mainly for squeezing out more
performance. We have known about microkernels for over 30
years. CSP for over 40 years. Capability systems for over
50 years. Yet these are largely absent. Even Go provides
unsafe shared memory access in spite of providing channels.


> But over all, as much as I respect and think Ken and Dennis did amazing work at the time, I do tend to love when new ideas/things have been done beyond the original ideas from Ken and Dennis.  For instance, just as BSD can take credit (or blame) or sockets and making UNIX really a 'networked OS', Sun really gave us multiple file systems with the VFS, but  I strongly credit Linux for really making kernel modules a reality (yup Solaris had them, as did a few other systems - but it was really Linux that made it wide spread).   I wish Linux had taken the idea of a modular kernel a tad farther, and picked up things like Locus vproc work, because I personally think modularity under the covers is better than the containers mess we have today (and I agree with Tannenbaum that uKernel's make more sense to me in the long run - even if they do cost something in speed).

Plan9 did a much cleaner job of adding filesystems and networking.
May be the 9p protocol doesn't scale so well but that could've been
fixed once it was used in production systems.

A capability system would obviate the need for containers.
If all external communication a process did was via capabilities,
it doesn't matter if they directly access some physical device or
virtual device, a local server or a remote server, a real file or
a synthetic file. Microkernels and caps are a good match. But they
too haven't been used enough in practice and will need evolution.

> it's also why I liked Plan 9 and have high hopes that a new OS, maybe written is something like Rust might finally appear.   But I don't want it re-implement UNIX or Linux.   Grab from them the subsystems that you need to duplication, but don't re-invent.
> 
> 
> Warren - at the risk of being political -- I think the paradox we have it larger than just UNIX, although it is simple.  We can wallow and say everything is bad, it was simpler in 1959 -- which exactly what some folks in my country seem to be doing in other areas.  I personally can say my world was simple in those days and I certainly have fond memories [read Bill Bryson's https://www.amazon.com/Life-Times-Thunderbolt-Kid-Memoir/dp/0767919378 which parrots many of my own memories of those times ], but UNIX, like the world, has grown up and changed and is a lot more complicated.   I like progress we have now.  I don't want the world the way it was any more than I want run Fifth Edition on my Mac for day-2-day work.
> 
> Yes, I would like us to look at the good from the past and see if we can have some of the good things again; but if it means giving up what gained too, then we have gone backwards.  The problem is how to decide what was good and what was bad?   What is real progress and what is just 'showing off your money' to use a Forest Gump concept.
> 
> I suspect we will argue for a long time about what qualifies as progress from the core idea of UNIX and what does not.

I think it is possible to gain equivalent feature comforts using
simpler systems. But my guess is "compatibility" requirement is
what will hold us back.

From bakul at bitblocks.com  Wed May  9 07:25:47 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Tue, 8 May 2018 14:25:47 -0700
Subject: [TUHS] unix "awesome list"
In-Reply-To: <146d3e969e94918e80c3d7dae01f0a839968e6bb@webmail.yaccman.com>
References: <146d3e969e94918e80c3d7dae01f0a839968e6bb@webmail.yaccman.com>
Message-ID: <52EA2E4F-7C9B-4675-A899-9F8C31D33CC7@bitblocks.com>

On May 8, 2018, at 8:31 AM, Steve Johnson <scj at yaccman.com> wrote:
> 
> My company, Wave Computing, has built a chip with 16,000 8-bit processors on it.  And we have plans to build systems with up to a quarter million processors.  We are breaking ground in new ways to use hundreds of processors to solve problems very quickly.  It's a new way of thinking, and it makes your brain hurt.  But is is what the hardware is giving us, and there is at least another order of magnitude ahead before this trend starts running out of steam.

This sounds like a software equivalent of an FPGA! You probably
have similar to "EDA" tools for placement and routing and 
mapping a program written in "HDL" to the underlying technology.
Mapping APL to this could be fun (APL programs have a similar
brain hurting side-effect!).

Somewhat relevant: A retrospective on 30 years of FPGA technology:

https://ieeexplore.ieee.org/document/7086413/#full-text-section



From mike.ab3ap at gmail.com  Wed May  9 07:27:05 2018
From: mike.ab3ap at gmail.com (Mike Markowski)
Date: Tue, 8 May 2018 17:27:05 -0400
Subject: [TUHS] Old Usenet / local communitites
In-Reply-To: <CALMnNGj7A9PGxp0iTQbC0FBy3O1RfAG1zsVyDL8zVsK6Jp5wcA@mail.gmail.com>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <CALMnNGj7A9PGxp0iTQbC0FBy3O1RfAG1zsVyDL8zVsK6Jp5wcA@mail.gmail.com>
Message-ID: <337b387a-081d-cba3-7e9c-b535267ddd91@gmail.com>

>     On Tue, May 8, 2018 at 1:06 PM, <arnold at skeeve.com
>     <mailto:arnold at skeeve.com>> wrote:
> 
>     I was lamenting the (asymptotic) death of usenet to a colleague the
>     other day and asked, "where are all the cool kids these days?" I was
>     only half joking: back when news was the main nexus of interaction
>     for technical communities, it really was where you'd go to find
>     things out and where you could reasonably expect to interact with
>     experts. 
I also miss local news groups.  My university had many and later my 
employer, US Army Ballistic Research Lab (BRL), had some.  They were 
great, non-centralized places to, surprise, share news.  No equivalent 
seems to exist.

Mike Markowski


From gtaylor at tnetconsulting.net  Wed May  9 07:50:10 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 8 May 2018 15:50:10 -0600
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <990f91e8-01c0-cf25-4889-43e1580398ef@kilonet.net>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <e600c456-d900-ffe2-cfcc-aa8331a77f58@kilonet.net>
 <alpine.BSF.2.21.1.1805081159390.81704@orthanc.ca>
 <990f91e8-01c0-cf25-4889-43e1580398ef@kilonet.net>
Message-ID: <32ce2766-95f0-41ac-9c39-4e29e5b58eaa@spamtrap.tnetconsulting.net>

On 05/08/2018 01:11 PM, Arthur Krewat wrote:
> Google has the entire archive

I've often thought about trying to import the old articles for specific 
newsgroups into my server.  (Particularly the newsgroups that I used to 
/ do haunt.)  But I suspect that they have been modified in some way 
that I won't like.



-- 
Grant. . . .
unix || die

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

From lm at mcvoy.com  Wed May  9 07:54:05 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 8 May 2018 14:54:05 -0700
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <32ce2766-95f0-41ac-9c39-4e29e5b58eaa@spamtrap.tnetconsulting.net>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <e600c456-d900-ffe2-cfcc-aa8331a77f58@kilonet.net>
 <alpine.BSF.2.21.1.1805081159390.81704@orthanc.ca>
 <990f91e8-01c0-cf25-4889-43e1580398ef@kilonet.net>
 <32ce2766-95f0-41ac-9c39-4e29e5b58eaa@spamtrap.tnetconsulting.net>
Message-ID: <20180508215405.GM16384@mcvoy.com>

> On 05/08/2018 01:11 PM, Arthur Krewat wrote:
> >Google has the entire archive

Is it searchable?  THe old dejanews archive was searchable back to the 80's.


From gtaylor at tnetconsulting.net  Wed May  9 07:56:49 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 8 May 2018 15:56:49 -0600
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <20180508200135.47C7B156E510@mail.bitblocks.com>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <e600c456-d900-ffe2-cfcc-aa8331a77f58@kilonet.net>
 <alpine.BSF.2.21.1.1805081159390.81704@orthanc.ca>
 <20180508200135.47C7B156E510@mail.bitblocks.com>
Message-ID: <fefdad47-8c8b-4f4f-c093-162c31f28100@spamtrap.tnetconsulting.net>

On 05/08/2018 02:01 PM, Bakul Shah wrote:
> Back in 1989 timeframe I used to get a pretty complete feed via uucp and 
> maintain locally with cnews. Recently I tried using "fetchnews" recently 
> for that purpose (for the groups I want) since eternal-september is a 
> bit slow but something went wrong.

Do you want a UUCP (bag) feed again?

I provided UUCP "bag" feed to one of my peers on the first server I ran. 
  I'd be happy to do so again.

  - UUCP "bag" files pushed / pulled via SCP / SFTP.
     - Could probably be done over email too.
  - UUCP over SSH
  - UUCP over TCP port 540)
  - Secure UUCP TCP port 4031)

Obviously:

  - NNTP over TCP port 119
  - Secure NNTP over TCP port 563

I'm also willing to hear about other creative options too.

  - VPN
     - IPSec
     - SSL / TLS
     - WireGuard
     - OpenVPN



-- 
Grant. . . .
unix || die

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

From gtaylor at tnetconsulting.net  Wed May  9 07:58:54 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 8 May 2018 15:58:54 -0600
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <20180508215405.GM16384@mcvoy.com>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <e600c456-d900-ffe2-cfcc-aa8331a77f58@kilonet.net>
 <alpine.BSF.2.21.1.1805081159390.81704@orthanc.ca>
 <990f91e8-01c0-cf25-4889-43e1580398ef@kilonet.net>
 <32ce2766-95f0-41ac-9c39-4e29e5b58eaa@spamtrap.tnetconsulting.net>
 <20180508215405.GM16384@mcvoy.com>
Message-ID: <571a1b0a-fc39-a6a4-f10e-4316fde9745a@spamtrap.tnetconsulting.net>

On 05/08/2018 03:54 PM, Larry McVoy wrote:
> Is it searchable?  THe old dejanews archive was searchable back to the 80's.

Google makes things searchable:

https://groups.google.com/forum/#!forum/comp.mail.sendmail

Replace comp.mail.sendmail to search the group(s) you're interested in. 
(I haunt c.m.sendmail.)



-- 
Grant. . . .
unix || die

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

From crossd at gmail.com  Wed May  9 08:01:33 2018
From: crossd at gmail.com (Dan Cross)
Date: Tue, 8 May 2018 18:01:33 -0400
Subject: [TUHS] Fun with early troff.
In-Reply-To: <20180508204342.GA58741@wopr>
References: <007a01d3e6f4$3c9c47c0$b5d4d740$@ronnatalie.com>
 <CAEoi9W7fNWOLv=Ad3r6HKBTZGH3w=vhxejXcNuSuGzmzpCvY1Q@mail.gmail.com>
 <20180508204342.GA58741@wopr>
Message-ID: <CAEoi9W4_6PqyNbd-W3qF23zDAF15xcB6o6rsOKTH0qWzTLQiTg@mail.gmail.com>

On Tue, May 8, 2018 at 4:43 PM, Kurt H Maier <khm at sciops.net> wrote:

> On Tue, May 08, 2018 at 04:14:54PM -0400, Dan Cross wrote:
> >
> > For example, there is a NATO-standard "10-line" message
>
> When did they add the 10th line?  What is in it?  I was trained on the
> 9-line during my service, and I'd be fascinated to know what extra info
> was judged important enough to update the manuals.


Oh man. I had to go look it up and I found a copy on some website at
Lejeune and another one at training command. It looks like the NATO
standard *9* line request plus a line for patient information (name,
initials, last4, etc). Odd considering that if you've got multiple patients
you'd need more than one "line". Anyway, there's a copy in this document:
http://www.trngcmd.marines.mil/Portals/207/Docs/TBS/THULS.pdf (search for
"CASEVAC").

>
> > Yup. Troff. I took it to war.
> >
>
> It's been well over a decade, but there were QRF bases in Kabul whose
> security manuals and operation maps were generated onsite in TeX on my
> ancient Thinkpad.  I suspect, however, an academic study of combat-zone
> typesetting would be dominated by the inevitability of Powerpoint.


Neat. What branch were you?

I used to get super-annoyed when higher would muck with my manifests which
were, of course, Excel documents. "How do you know these total numbers are
correct?" "Because that cell is a formula that is the sum of all the other
relevant cells and unless you think that Microsoft can't ADD then there's
no reason for it to be incorrect. Please tell Lance Corporal Schmuckatelli
to stop overwriting my shit because he definitely can't add. Oh, and he
should probably get counseled to go take, 'Math for Marines' again; this
time without cheating and copying the answers out of the back fo the MCI."

I've often noticed the battlefield is ruled by Windows (e.g. those
> pilots were probably poking at Falconview)


Those helo pilots were just sitting on chairs eating potato chips in an
otherwise empty shipping container out at MOUTown and making things up as
they went along.

while the research side is
> extremely tied to unix and its ilk.  Obviously BRLCAD and other ARL
> involvement here, and just about all of of the DoD HPC program skews
> toward unix and linux.


Funny, the BFT in my M-ATV ran Linux. I got the guys down at the
maintenance depot to give me login name and password for their account so I
could play solitaire when nothing was going on.

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

From henry.r.bent at gmail.com  Wed May  9 08:22:06 2018
From: henry.r.bent at gmail.com (Henry Bent)
Date: Tue, 8 May 2018 18:22:06 -0400
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <990f91e8-01c0-cf25-4889-43e1580398ef@kilonet.net>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <e600c456-d900-ffe2-cfcc-aa8331a77f58@kilonet.net>
 <alpine.BSF.2.21.1.1805081159390.81704@orthanc.ca>
 <990f91e8-01c0-cf25-4889-43e1580398ef@kilonet.net>
Message-ID: <CAEdTPBfoSbh8HygKKB+pABBs8a6P0zsSYyZ6sNpheLtppX=ZcQ@mail.gmail.com>

My father was the sysadmin for Deja News at the time they were bought by
Google.  I was told that the "buyout" consisted of some Google folks
showing up with a rack of drives, dumping all of Deja News's data over a
weekend, and then flying back out to Mountain View.

-Henry

On 8 May 2018 at 15:11, Arthur Krewat <krewat at kilonet.net> wrote:

> On 5/8/2018 3:00 PM, Lyndon Nerenberg wrote:
>
>> The problem is, many of us have stopped using it for whatever reason, and
>>> certainly don't store/forward much.
>>>
>>> Maybe it's time to take it back and get back to the original intention
>>> of USENET.
>>>
>>
>> So where on Earth does one get an NNTP feed from these days?  Lord knows
>> I've tried.  An no, I'm not talking about a pay-for-access NNRP host that I
>> have to pull things from.
>>
>> That was going to be my next question ;) - Google has the entire archive
> (minus binaries), and most commercial places have it going back only 3000
> days or so.
>
> Where's Deja News when you need 'em.
>
>
> ak
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180508/9b6862b7/attachment.html>

From reed at reedmedia.net  Wed May  9 07:49:12 2018
From: reed at reedmedia.net (Jeremy C. Reed)
Date: Tue, 8 May 2018 16:49:12 -0500 (CDT)
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
Message-ID: <alpine.NEB.2.20.1805081637250.4373@t1.m.reedmedia.net>

On Tue, 8 May 2018, Seth Morabito wrote:

> I'm experimenting with setting up UUCP and Usenet on a cluster of 
> 3B2/400s, and I've quickly discovered that while it's trivial to find 
> old source code for Usenet (B News and C News), it's virtually 
> impossible to find source code for old news *readers*.
> 
> I'm looking especially for nn, which was my go-to at the time. The 
> oldest version I've found so far is nn 6.4, which is too big to 
> compile on a 3B2/400. If I could get my hands on 6.1 or earlier, I 
> think I'd have a good chance.

rn was available for 4.3BSD

I don't find this code on TUHS, but I got mine from disk 2 of the 
CSRG Archives. (You can find some old versions of it searching for 
"/new/rn/ng.h".)


From krewat at kilonet.net  Wed May  9 08:32:45 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Tue, 8 May 2018 18:32:45 -0400
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <CAEdTPBfoSbh8HygKKB+pABBs8a6P0zsSYyZ6sNpheLtppX=ZcQ@mail.gmail.com>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <e600c456-d900-ffe2-cfcc-aa8331a77f58@kilonet.net>
 <alpine.BSF.2.21.1.1805081159390.81704@orthanc.ca>
 <990f91e8-01c0-cf25-4889-43e1580398ef@kilonet.net>
 <CAEdTPBfoSbh8HygKKB+pABBs8a6P0zsSYyZ6sNpheLtppX=ZcQ@mail.gmail.com>
Message-ID: <8120ea75-3573-0931-bf35-f18bf2e4c9f3@kilonet.net>



On 5/8/2018 6:22 PM, Henry Bent wrote:
> My father was the sysadmin for Deja News at the time they were bought 
> by Google.  I was told that the "buyout" consisted of some Google 
> folks showing up with a rack of drives, dumping all of Deja News's 
> data over a weekend, and then flying back out to Mountain View.

Where are the original drives? Or tapes? (insert devilish grin emoticon 
here)

ak


From bqt at update.uu.se  Wed May  9 08:39:36 2018
From: bqt at update.uu.se (Johnny Billquist)
Date: Wed, 9 May 2018 00:39:36 +0200
Subject: [TUHS] /dev/drum
In-Reply-To: <mailman.1.1525744802.16322.tuhs@minnie.tuhs.org>
References: <mailman.1.1525744802.16322.tuhs@minnie.tuhs.org>
Message-ID: <56c4a8d3-c4dc-5876-7ca3-acda31ee9dc7@update.uu.se>

On 08.05.18 04:00, jnc at mercury.lcs.mit.edu  (Noel Chiappa) wrote:
>      > From: Johnny Billquist
> 
>      > My point being that ... pages are invisible to the process segments are
>      > very visible. And here we talk from a hardware point of view.
> 
> So you're saying 'segmentation means instructions explicitly include segment
> numbers, and the address space is a two-dimensional array', or 'segmentation
> means pointers explicitly include segment numbers', or something like that?

Not really. I'm trying to understand your argument.

You said:
"BTW, this reminds me of another key differentiator between paging and
segments, which is that paging was originally _invisible_ to the user 
(except
for setting the total size of the process), whereas segmentation is 
explicitly
visible to the user."

And then you used MERT as an example of this.

My point then is, how is MERT any different from mmap() under Unix? 
Would you then say that the paging is visible under Unix, meaning that 
this is then segmentation?

In my view, you are talking about a software concept. And as such, it 
has no bearing on whether a machine have pages or segments, as that is a 
hardware thing and distinction, while anything done as a service by the 
OS is a completely different, and independent question.

> I'm more interested in the semantics that are provided, not bits in
> instructions.

Well, if we talk semantics instead of the hardware, then you can just 
say that any machine is segmented, and you can say that any machine is 
have pages. Because I can certainly make it appear both ways from the 
software point of view for applications running under an OS.
And I can definitely do that on a PDP-11. The OS can force pages to 
always be 8K in size, and the OS can (as done by lots of OSes) provide a 
mechanism that gives you something you call segments.

> It's true that with a large address space, one can sort of simulate
> segmentation. To me, machines which explicitly have segment numbers in
> instructions/pointers are one end of a spectrum of 'segmented machines', but
> that's not a strict requirement. I'm more concerned about how they are used,
> what the system/user gets.

So, again. Where does mmap() put you then?
And, just to point out the obvious, any machine with pages have a page 
table, and the page table entry is selected based on the high bits of 
the virtual address. Exactly the same as on the PDP-11. The only 
difference is the number of pages, and the fact that the page on the 
PDP-11 do not have a fixed length, but can be terminated earlier if wanted.
So, pages are explicitly numbered in pointers on any machine with pages.

> Similarly for paging - fixed sizes (or a small number of sizes) are part of
> the definition, but I'm more interested in how it's used - for demand loading,
> and to simplify main memory allocation purposes, etc.

I don't get it. So, in which way are you still saying that a PDP-11 
don't have pages?

>      >> the semantics available for - and_visible_  to - the user are
>      >> constrained by the mechanisms of the underlying hardware.
> 
>      > That is not the same thing as being visible.
> 
> It doesn't meet the definition above ('segment numbers in
> instructions/pointers'), no. But I don't accept that definition.

I'm trying to find out what your definition is. :-)
And if it is consistent and makes sense... :-)

>      > All of this is so similar to mmap() that we could in fact be having this
>      > exact discussion based on mmap() instead .. I don't see you claiming
>      > that every machine use a segmented model
> 
> mmap() (and similar file->address space mapping mechanisms, which a bunch of
> OS's have supported - TENEX/TOP-20, ITS, etc) are interesting, but to me,
> orthagonal - although it clearly needs support from memory management hardware.

Can you explain how mmap() is any different from the service provided by 
MERT?

> And one can add 'sharing memory between two processes' here, too; very similar
> _mechanisms_  to mmap(), but different goals. (Although I suppose two processes
> could map the same area of a file, and that would give them IPC mapping.)

That how a single copy of shared libraries happen under Unix.
Exactly what happens if you modify the memory depends on what flags you 
give to mmap().

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From gtaylor at tnetconsulting.net  Wed May  9 08:55:31 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 8 May 2018 16:55:31 -0600
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <CAM4FNSvrv-FGPFTywEj1YyFyYGvh_10ngXaBb0R1ae9UY92rCQ@mail.gmail.com>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <00c501d3e702$65f60850$31e218f0$@ronnatalie.com>
 <CAM4FNSvrv-FGPFTywEj1YyFyYGvh_10ngXaBb0R1ae9UY92rCQ@mail.gmail.com>
Message-ID: <d569f4c8-fe39-b220-3313-07b3be365ebf@spamtrap.tnetconsulting.net>

On 05/08/2018 02:54 PM, Daniel Camolês wrote:
> I got in quite late in the game, in 2001, but as of today I still 
> remember it as the best way to discuss over the internet that I have 
> experienced. I agree on the lack of moderation being the weakness that 
> made the noise surpass the signal. All the web forum software that 
> surfaced on the 00's and beyond was mostly a response to that. If it 
> weren't for this weakness, people nowadays would probably be using web 
> interfaces to nntp just like they do to email, and we old farts could 
> still be happily using our preferred news clients.

As much as I want to agree with you, I think that the stand alone 
islands still would have gotten more popular than Usenet at least for 
the following reason:

1)  Web sites can control what the site looks like, thus the GUI people 
can fiddle to their hearts content.
2)  It's much simpler to build some random database to hold comments for 
a web forum than it is to comply with / inter operate with / adhere to 
(arguably simple) standards.

> So while I applaud the ones who are trying to keep the system alive, 
> this weakness (and maybe others), if not addressed, will pose a natural 
> limit to Usenet growth and quality. If we start putting servers up and 
> manage to attract good contributors back, the spam will follow and then 
> the noise will drive them away again.

I don't know how many people can be brought back to Usenet.  Further, I 
don't know how many people I want brought back to Usenet.

IMHO Usenet works for those that want it to work.  It provides the 
desired service and is IMHO just obscure enough that the mainstream is 
not on it.  I'm cool with that.

> But yet, we are at such a point where bandwidth and storage is so cheap 
> that reviving Usenet could be accomplished by a bunch of hobbists 
> spending little money. If at least we could solve the moderation 
> weakness. Does someone have any idea if there were any attempts at 
> cracking this problem that were open source and effective?

I think there are a number of people / hobbyists that run (text only) 
news servers (like myself) doing exactly that.

I think there are some efforts at reducing spam and making moderation 
work.  I don't know any details about them.

I think that we need to hold server operators accountable for people 
that post crap through them.  I routinely see lots of crap posted to 
specific Linux newsgroups, and almost all of it passes through a 
specific server (network).  Just about the time that I get motivated to 
contact the abuse contact, the crap stops.



-- 
Grant. . . .
unix || die

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

From henry.r.bent at gmail.com  Wed May  9 08:59:08 2018
From: henry.r.bent at gmail.com (Henry Bent)
Date: Tue, 8 May 2018 18:59:08 -0400
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <8120ea75-3573-0931-bf35-f18bf2e4c9f3@kilonet.net>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <e600c456-d900-ffe2-cfcc-aa8331a77f58@kilonet.net>
 <alpine.BSF.2.21.1.1805081159390.81704@orthanc.ca>
 <990f91e8-01c0-cf25-4889-43e1580398ef@kilonet.net>
 <CAEdTPBfoSbh8HygKKB+pABBs8a6P0zsSYyZ6sNpheLtppX=ZcQ@mail.gmail.com>
 <8120ea75-3573-0931-bf35-f18bf2e4c9f3@kilonet.net>
Message-ID: <CAEdTPBdM=DXh_dzXRPjxdU-eHY-CSbduPx-jjDoGZjXxxcnjjg@mail.gmail.com>

On 8 May 2018 at 18:32, Arthur Krewat <krewat at kilonet.net> wrote:

>
>
> On 5/8/2018 6:22 PM, Henry Bent wrote:
>
>> My father was the sysadmin for Deja News at the time they were bought by
>> Google.  I was told that the "buyout" consisted of some Google folks
>> showing up with a rack of drives, dumping all of Deja News's data over a
>> weekend, and then flying back out to Mountain View.
>>
>
> Where are the original drives? Or tapes? (insert devilish grin emoticon
> here)
>
> ak
>

I have no idea where they are now.  At the time they were in Austin, TX.  I
imagine that they probably just went to one of those many IT scrapyards,
the warehouses full of old parts that the owners sell on eBay.

About the same time - 2001? - when I was a student at Oberlin, an alumnus
who was working for mp3.com "donated" several full height racks of 2U
servers to the college.  Apparently the tax writeoff for donating the
servers was better than what they were going to get from the scrap folks,
and it all looked good on paper.   But the CS department had no idea what
to do with all of this hardware!   Remember that we were a small liberal
arts college, and that the entire department at that time was served by a
single DEC Alpha box.  So there was a free-for-all, everyone in the CS
department got to take as many machines as they had a use for (dual Pentium
III Intel boards, as I recall), which turned out to not make a significant
dent in the material we were given... The most astonishing part of the
whole experience was that mp3.com had not bothered to wipe the drives of
these machines, so they still booted to some variety of Linux (Red Hat?)
and were full of useless distributed data.

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

From lyndon at orthanc.ca  Wed May  9 09:16:07 2018
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Tue, 8 May 2018 16:16:07 -0700
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <d569f4c8-fe39-b220-3313-07b3be365ebf@spamtrap.tnetconsulting.net>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <00c501d3e702$65f60850$31e218f0$@ronnatalie.com>
 <CAM4FNSvrv-FGPFTywEj1YyFyYGvh_10ngXaBb0R1ae9UY92rCQ@mail.gmail.com>
 <d569f4c8-fe39-b220-3313-07b3be365ebf@spamtrap.tnetconsulting.net>
Message-ID: <5FC9A20A-22A3-4EAF-8227-49D5839A9F76@orthanc.ca>


> On May 8, 2018, at 3:55 PM, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
> 
> I think there are a number of people / hobbyists that run (text only) news servers (like myself) doing exactly that.

I don't understand what a "text only" news server is.  A "news" server schleps "news" around via NNTP.  The protocol is "text," as is SMTP for mail.  Is there a "binary" variation?

From henry.r.bent at gmail.com  Wed May  9 09:18:46 2018
From: henry.r.bent at gmail.com (Henry Bent)
Date: Tue, 8 May 2018 19:18:46 -0400
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <5FC9A20A-22A3-4EAF-8227-49D5839A9F76@orthanc.ca>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <00c501d3e702$65f60850$31e218f0$@ronnatalie.com>
 <CAM4FNSvrv-FGPFTywEj1YyFyYGvh_10ngXaBb0R1ae9UY92rCQ@mail.gmail.com>
 <d569f4c8-fe39-b220-3313-07b3be365ebf@spamtrap.tnetconsulting.net>
 <5FC9A20A-22A3-4EAF-8227-49D5839A9F76@orthanc.ca>
Message-ID: <CAEdTPBc_f5qRYwizF2B-2cxL0vf4n6G1W19ftFOQC3XJN=fF_g@mail.gmail.com>

On 8 May 2018 at 19:16, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:

>
> > On May 8, 2018, at 3:55 PM, Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
> wrote:
> >
> > I think there are a number of people / hobbyists that run (text only)
> news servers (like myself) doing exactly that.
>
> I don't understand what a "text only" news server is.  A "news" server
> schleps "news" around via NNTP.  The protocol is "text," as is SMTP for
> mail.  Is there a "binary" variation?


I was curious about this too - do yo just detect encoded attachments and
delete them?

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

From ggm at algebras.org  Wed May  9 09:21:44 2018
From: ggm at algebras.org (George Michaelson)
Date: Wed, 9 May 2018 09:21:44 +1000
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <CAEdTPBc_f5qRYwizF2B-2cxL0vf4n6G1W19ftFOQC3XJN=fF_g@mail.gmail.com>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <00c501d3e702$65f60850$31e218f0$@ronnatalie.com>
 <CAM4FNSvrv-FGPFTywEj1YyFyYGvh_10ngXaBb0R1ae9UY92rCQ@mail.gmail.com>
 <d569f4c8-fe39-b220-3313-07b3be365ebf@spamtrap.tnetconsulting.net>
 <5FC9A20A-22A3-4EAF-8227-49D5839A9F76@orthanc.ca>
 <CAEdTPBc_f5qRYwizF2B-2cxL0vf4n6G1W19ftFOQC3XJN=fF_g@mail.gmail.com>
Message-ID: <CAKr6gn1ztC7naN5j33RGSS3xa5B+vSFvfvu3++jAYBnMkS_XUw@mail.gmail.com>

usenet became a primary channel for sharing music, pictures and
videos. files were split into chunks, and then refreshed as chunks.
Its like p2p before bittorrent with little or no in-band feedback.
(you would see people begging for fragment 101/1001 to be re-sent)

this reached the point where, by article count and bytecount, far more
of USENET was binary target mime attachments than discourse.

-G

On Wed, May 9, 2018 at 9:18 AM, Henry Bent <henry.r.bent at gmail.com> wrote:
> On 8 May 2018 at 19:16, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:
>>
>>
>> > On May 8, 2018, at 3:55 PM, Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
>> > wrote:
>> >
>> > I think there are a number of people / hobbyists that run (text only)
>> > news servers (like myself) doing exactly that.
>>
>> I don't understand what a "text only" news server is.  A "news" server
>> schleps "news" around via NNTP.  The protocol is "text," as is SMTP for
>> mail.  Is there a "binary" variation?
>
>
> I was curious about this too - do yo just detect encoded attachments and
> delete them?
>
> -Henry
>


From gtaylor at tnetconsulting.net  Wed May  9 09:22:29 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 8 May 2018 17:22:29 -0600
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <5FC9A20A-22A3-4EAF-8227-49D5839A9F76@orthanc.ca>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <00c501d3e702$65f60850$31e218f0$@ronnatalie.com>
 <CAM4FNSvrv-FGPFTywEj1YyFyYGvh_10ngXaBb0R1ae9UY92rCQ@mail.gmail.com>
 <d569f4c8-fe39-b220-3313-07b3be365ebf@spamtrap.tnetconsulting.net>
 <5FC9A20A-22A3-4EAF-8227-49D5839A9F76@orthanc.ca>
Message-ID: <a53fa1bd-aba0-cc39-f7b5-8f544f2df3f4@spamtrap.tnetconsulting.net>

On 05/08/2018 05:16 PM, Lyndon Nerenberg wrote:
> I don't understand what a "text only" news server is.  A "news" server 
> schleps "news" around via NNTP.  The protocol is "text," as is SMTP 
> for mail.

"Test only" means no binary files.  (UUCP or MIME encoded).

No images / no warz / no pr0n / etc.

I'm sure that something does occasionally slip through.  But it should 
be such a rarity that nobody notices.

It also means that a number of the *.bin.* (et al) newsgroups are omitted.

"Text only" is just a generic classification and way of saying that I'm 
not going to provide binary content.  Read:  Go get that from one of the 
big professional players.  ;-)

> Is there a "binary" variation?

There is the NNTPS variant of running NNTP over SSL (TLS), but that 
binary component is just the transport, not the protocol that runs 
through it.

That being said, I think there there may be a tiny bit of binary to 
NNTP.  Or at least every time I've looked at it with tcpdump / 
Wirershark there was something about the replies from the receiving 
server that make me think that ACKs / NAKs may be binary.  But chances 
are good that I'm not paying enough attention and misinterpreting something.



-- 
Grant. . . .
unix || die

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

From gtaylor at tnetconsulting.net  Wed May  9 09:25:07 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 8 May 2018 17:25:07 -0600
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <CAEdTPBc_f5qRYwizF2B-2cxL0vf4n6G1W19ftFOQC3XJN=fF_g@mail.gmail.com>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <00c501d3e702$65f60850$31e218f0$@ronnatalie.com>
 <CAM4FNSvrv-FGPFTywEj1YyFyYGvh_10ngXaBb0R1ae9UY92rCQ@mail.gmail.com>
 <d569f4c8-fe39-b220-3313-07b3be365ebf@spamtrap.tnetconsulting.net>
 <5FC9A20A-22A3-4EAF-8227-49D5839A9F76@orthanc.ca>
 <CAEdTPBc_f5qRYwizF2B-2cxL0vf4n6G1W19ftFOQC3XJN=fF_g@mail.gmail.com>
Message-ID: <50e40b23-bf3c-f40a-2e9a-55d68007b686@spamtrap.tnetconsulting.net>

On 05/08/2018 05:18 PM, Henry Bent wrote:
> I was curious about this too - do yo just detect encoded attachments and 
> delete them?

Yes and / or no.

Yes in that there are things like CleanFeed that can be configured to 
reject typical binary encoding methods (UUCP & MIME being most predominant).

No in that it is possible to exclude groups that have (some variant of) 
".bin." in their name.

It is possible to use a combination of either of the above techniques.



-- 
Grant. . . .
unix || die

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

From gtaylor at tnetconsulting.net  Wed May  9 09:37:51 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 8 May 2018 17:37:51 -0600
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <a53fa1bd-aba0-cc39-f7b5-8f544f2df3f4@spamtrap.tnetconsulting.net>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <00c501d3e702$65f60850$31e218f0$@ronnatalie.com>
 <CAM4FNSvrv-FGPFTywEj1YyFyYGvh_10ngXaBb0R1ae9UY92rCQ@mail.gmail.com>
 <d569f4c8-fe39-b220-3313-07b3be365ebf@spamtrap.tnetconsulting.net>
 <5FC9A20A-22A3-4EAF-8227-49D5839A9F76@orthanc.ca>
 <a53fa1bd-aba0-cc39-f7b5-8f544f2df3f4@spamtrap.tnetconsulting.net>
Message-ID: <E9E4A14B-CF7A-4DEA-AEAE-9DA54623A476@tnetconsulting.net>

On May 8, 2018, at 5:22 PM, Grant Taylor <gtaylor at tnetconsulting.net> wrote:
> 
> "Test only" means no binary files.  (UUCP or MIME encoded).

s/s/x/

It also usually implies that only smaller messages are accepted.

Where smaller is usually some power of 2 or 10 kB per message.



-- 
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2338 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180508/0a1112bb/attachment.bin>

From lyndon at orthanc.ca  Wed May  9 09:06:09 2018
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Tue, 8 May 2018 16:06:09 -0700
Subject: [TUHS] (early parallel/concurrent computing) (was: unix
 "awesome list")
In-Reply-To: <146d3e969e94918e80c3d7dae01f0a839968e6bb@webmail.yaccman.com>
References: <146d3e969e94918e80c3d7dae01f0a839968e6bb@webmail.yaccman.com>
Message-ID: <FAED01BC-5B5D-4EB7-8195-2D13F3460E51@orthanc.ca>


> On May 8, 2018, at 8:31 AM, Steve Johnson <scj at yaccman.com> wrote:
> 
> My company, Wave Computing, has built a chip with 16,000 8-bit processors on it.  And we have plans to build systems with up to a quarter million processors.  We are breaking ground in new ways to use hundreds of processors to solve problems very quickly.  It's a new way of thinking, and it makes your brain hurt.  But is is what the hardware is giving us, and there is at least another order of magnitude ahead before this trend starts running out of steam.

This might be going a bit out-of-bounds for the mailing list, but ...

How does what you are doing compare with the work the Myrias folks were doing in the mid-late 1980s with their n-way 680x0(?) parallel machines?  Didn't they make it to 256 processors before it collapsed?  I'm not aware of any papers that came out of their work, although I would think there must have been at least a few.  (Dan Wilson, are you on this mailing list?)

I didn't have the opportunity to see what Myrias was putting together as their OS.  But I did get to play with an indirect off-shoot of their work: a massive scale (for the time) file server, based on some of that parallel processing technology.  It mimicked the Plan9 Venti in some ways.  It was very block-oriented in its external API, and I used that lowish-level API to write a backend file store for the big-a** IMAP servers we were developing at the time.  I'm sure it would have kicked NetApp and friends around the block, but this was the late 1990s, and we were limited by 100 Mb/s Ethernet, so there was no real way to tell.

--lyndon



From johnl at johnlabovitz.com  Wed May  9 09:39:00 2018
From: johnl at johnlabovitz.com (John Labovitz)
Date: Tue, 8 May 2018 19:39:00 -0400
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
Message-ID: <81216ABB-D4DF-4A63-B26D-6DB2A5428E1F@johnlabovitz.com>

On May 8, 2018, at 12:25 PM, Seth Morabito <web at loomcom.com> wrote:

> As an aside: If you were active on Usenet in 1989, what software were you using?

Maybe a bit earlier — 1985–1987? — but I always loved Kenneth Almquist’s ‘vnews’ as a newsreader. There was something incredibly simple and graceful about it. It was curses-based, but at the same time very Unix-y — no BBS-like prompts or extra noise. Minimal and perfect. Many times I’ve tried to build a similar interface on modern systems, and it’s harder than one would think.

A few years back I found a shar file of some late vnews distribution. (Sadly, I can’t find a link now — but have the sources if anyone wants.) I was surprised how complicated the C code was, not to mention the build system! No blame to Almquist at all — I’d simply forgotten how difficult it was in the ‘80s to architect software that could work on more than one Unix distribution.

I ran vnews, and I think C news, on a Parallel XR300 machine, which was (in theory) a fault-tolerant box with Sun motherboards. That was in Maryland — I was psc!jsl.

—John

From reed at reedmedia.net  Wed May  9 10:08:50 2018
From: reed at reedmedia.net (Jeremy C. Reed)
Date: Tue, 8 May 2018 19:08:50 -0500 (CDT)
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <81216ABB-D4DF-4A63-B26D-6DB2A5428E1F@johnlabovitz.com>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <81216ABB-D4DF-4A63-B26D-6DB2A5428E1F@johnlabovitz.com>
Message-ID: <alpine.NEB.2.20.1805081903340.4373@t1.m.reedmedia.net>

On Tue, 8 May 2018, John Labovitz wrote:

> Maybe a bit earlier ? 1985?1987? ? but I always loved Kenneth 
> Almquist?s ?vnews? as a newsreader. There was something incredibly 

This was also available with 4.2BSD. I also don't see on TUHS, but a 
search for 43bsd news/src/readnews.c should find it on the web. I got my 
copy from disk 2 from the CSRG Archives. Well I see readnews there on 
disk 1 for 4.2BSD too (without the visual interface).


From reed at reedmedia.net  Wed May  9 10:11:36 2018
From: reed at reedmedia.net (Jeremy C. Reed)
Date: Tue, 8 May 2018 19:11:36 -0500 (CDT)
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <alpine.NEB.2.20.1805081903340.4373@t1.m.reedmedia.net>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <81216ABB-D4DF-4A63-B26D-6DB2A5428E1F@johnlabovitz.com>
 <alpine.NEB.2.20.1805081903340.4373@t1.m.reedmedia.net>
Message-ID: <alpine.NEB.2.20.1805081910070.4373@t1.m.reedmedia.net>

On Tue, 8 May 2018, Jeremy C. Reed wrote:

> On Tue, 8 May 2018, John Labovitz wrote:
> 
> > Maybe a bit earlier ? 1985?1987? ? but I always loved Kenneth 
> > Almquist?s ?vnews? as a newsreader. There was something incredibly 
> 
> This was also available with 4.2BSD. I also don't see on TUHS, but a 
> search for 43bsd news/src/readnews.c should find it on the web. I got my 
> copy from disk 2 from the CSRG Archives. Well I see readnews there on 
> disk 1 for 4.2BSD too (without the visual interface).

Seth that old 1983 code is at 
https://www.tuhs.org/cgi-bin/utree.pl?file=4.2BSD//usr/src/new/new/news/src
(See the Makefile about readnews.)

(Hey why does that TUHS view say 1970-01-01?)


From ron at ronnatalie.com  Wed May  9 10:25:08 2018
From: ron at ronnatalie.com (Ron Natalie)
Date: Tue, 8 May 2018 20:25:08 -0400
Subject: [TUHS] (early parallel/concurrent computing) (was: unix
	"awesome list")
In-Reply-To: <FAED01BC-5B5D-4EB7-8195-2D13F3460E51@orthanc.ca>
References: <146d3e969e94918e80c3d7dae01f0a839968e6bb@webmail.yaccman.com>
 <FAED01BC-5B5D-4EB7-8195-2D13F3460E51@orthanc.ca>
Message-ID: <016301d3e72c$2fae3680$8f0aa380$@ronnatalie.com>

BRL had contracted with the Denver Electronics Corporation (Denelcor) to
build a fluid dynamic platform.   Early plans were for an analog and then
hybrid computer, but this quickly evolved into the all-digital Heterogenous
Element Procesor.   The computer was MIMD and could run 40 or so threads
simultaneously while hardware scheduling 256 times that.   Each memory
location in the main memory had a "full-empty" bit which allowed you to to
execute instructions like "Wait until Full, then Store", and the processor
handled all that.

Of course, this was about the time Mike Muuss and his band were becoming
real firecrackers in the labs.    Mike shot his mouth off  that we could put
UNIX on it (our answer to everything) and the lab management took us up on
the offer.    Perhaps, with the exception of some of the MultibusII stuff,
one of the nicest UNIX architectures around.

Mike immediately set to work.   He did the C compiler while Doug Kingson did
the assembler.   I did the loader I think.   We then started on the kernel.
Mike doing the low level stuff and the guts of the kernel and me doing all
the IO (the "dmr" directory traditionally).      About the time we got the
thing running I realized that the IO performance was terrible.    The thing
had a sidecar unit with 32 distinct unibuses which  really should have been
fast enough, except the latency to start the I/Os was about ten ops/sec.
Me and the HEP designer, Burton Smith sat down at the Golden Corral
steakhouse in Aberdeen and designed a new processor that sat on the main
memory bus.   It was built out of spare HEP parts and a PDP-11/34 that I had
lying around as the control processer.   I through in the LOS operating
system (No time for sharing -- Uniprocessor system) scavenged from my BRL
Gateway code to drive it.   In two days we had drastically increased the IO
performance.

The thing ran parallizable apps, notably Mike's BRL ray tracing "CAD"
package.    We pretty much used it to generate a movie of a shell's eye view
of a collision with a tank.   The system was replaced with a Cray XMP.

Amusingly in our machine room, awaiting arrival of the HEP were taped out
markings where all the cabinets went around a central building pillar.
Visiting the machine in the factor, it was laid out around a taped marking
showing the location of our post.

-Ron




From bakul at bitblocks.com  Wed May  9 10:31:56 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Tue, 8 May 2018 17:31:56 -0700
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <81216ABB-D4DF-4A63-B26D-6DB2A5428E1F@johnlabovitz.com>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <81216ABB-D4DF-4A63-B26D-6DB2A5428E1F@johnlabovitz.com>
Message-ID: <4B63E929-018A-42F4-8D35-7BE156038134@bitblocks.com>

On May 8, 2018, at 4:39 PM, John Labovitz <johnl at johnlabovitz.com> wrote:
> 
> Maybe a bit earlier — 1985–1987? — but I always loved Kenneth Almquist’s ‘vnews’ as a newsreader. There was something incredibly simple and graceful about it. It was curses-based, but at the same time very Unix-y — no BBS-like prompts or extra noise. Minimal and perfect. Many times I’ve tried to build a similar interface on modern systems, and it’s harder than one would think.
> 
> A few years back I found a shar file of some late vnews distribution. (Sadly, I can’t find a link now — but have the sources if anyone wants.) I was surprised how complicated the C code was, not to mention the build system! No blame to Almquist at all — I’d simply forgotten how difficult it was in the ‘80s to architect software that could work on more than one Unix distribution.
> 
> I ran vnews, and I think C news, on a Parallel XR300 machine, which was (in theory) a fault-tolerant box with Sun motherboards. That was in Maryland — I was psc!jsl.

I had stashed away comp.sources.unix archives in 2002.
Volumes 1 through 29. I find the below news related items.
Both vnews (Jan 1985) and rn (May 1985) are in volume 1.

[Now it all seems more complicated than needed.]

$ grep news comp.sources.unix/index
newshar                 The Connoisseur's Shar, version 2
newsweed                Newsweed: a program to delete unwanted news articles
readnews.1              Manual page for 2.10.2 readnews(1)
vnews.1                 Manual page for 2.10.2 vnews(1)
vnews/part[1-7]         Vnews part 1
xfernews                xfernews software
pnews.patch             Patch to Pnews to save article
newspace                newspace - determine newsgroup disk usage
newbatcha               Usenet news batcher control program
newbatchb               Usenet news batcher control program
newscnt                 Count unread news articles
2.11news/part[01-08]    2.11 News Documentation and Conversion
2.11news/part[09-10]    2.11 News Miscellaneous Files
2.11news/part[11-19]    2.11 News Source
2.11news/part20         News change log and makefile
2.11news/patch[01-08]   Patch #1 for news 2.11 source
multi-feed.c++          Simultaneous multi-site news feeder in C++
vn/part[01-03]          The VN news reader
cnews/part[01-14]       C News alpha release
vn.jan.88/part[01-05]   VN newsreader, 1/88 version
nntp1.5/part[01-09]     Network News Transfer Protocol, version 1.5
headers                 Selectively retrieve news article headers
cnews2/part[01]19]      Cnews production release
cnews1/patch1           Cnews production release, Patch1
nn/part[01-15]          NN, a Usenet news reader
nn/patch1               NN, a Usenet news reader, Patch1
snefru/part[01-04]      Snefru hash and netnews validation ...
nn6.4/part[01-22]       NN Newsreader, release 6.4
nn6.4/patch[1-4]        NN newsreader, release 6.4
newsxd/part[01-03]      Netnews transmission daemon



From wkt at tuhs.org  Wed May  9 10:42:35 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 9 May 2018 10:42:35 +1000
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <alpine.NEB.2.20.1805081910070.4373@t1.m.reedmedia.net>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <81216ABB-D4DF-4A63-B26D-6DB2A5428E1F@johnlabovitz.com>
 <alpine.NEB.2.20.1805081903340.4373@t1.m.reedmedia.net>
 <alpine.NEB.2.20.1805081910070.4373@t1.m.reedmedia.net>
Message-ID: <20180509004235.GA27296@minnie.tuhs.org>

On Tue, May 08, 2018 at 07:11:36PM -0500, Jeremy C. Reed wrote:
>Seth that old 1983 code is at
>https://www.tuhs.org/cgi-bin/utree.pl?file=4.2BSD//usr/src/new/new/news/src
>(See the Makefile about readnews.)
>
>(Hey why does that TUHS view say 1970-01-01?)

That must have been the timestamps on the files when I added them :)

Cheers, Warren


From usotsuki at buric.co  Wed May  9 10:46:34 2018
From: usotsuki at buric.co (Steve Nickolas)
Date: Tue, 8 May 2018 20:46:34 -0400 (EDT)
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <4501e9ed-7e1f-e96e-0986-2166db13c8fc@spamtrap.tnetconsulting.net>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <e600c456-d900-ffe2-cfcc-aa8331a77f58@kilonet.net>
 <1b32c1a7-69ae-6593-cd01-156f15b87edc@spamtrap.tnetconsulting.net>
 <alpine.BSF.2.02.1805081521210.83706@frieza.hoshinet.org>
 <4501e9ed-7e1f-e96e-0986-2166db13c8fc@spamtrap.tnetconsulting.net>
Message-ID: <alpine.BSF.2.02.1805082043540.3372@frieza.hoshinet.org>

On Tue, 8 May 2018, Grant Taylor via TUHS wrote:

> I've always used INN.  I'm happy enough, and it works for me.
>
> There are a few other common news servers.  It depends on the platform that 
> you want to run on.
>
> I'm typically seeing < 100 MB of news a day.  My VPS has < 4 GB news spool 
> going back 30 days.  My private server has unchecked storage and is using 
> about 42 GB.
>
> Peers can be found.  Email if you want help.

The servers I have are a Debian (Linux) VPS, a Debian (Linux) dedicated 
server, a FreeBSD dedicated server and a Debian (FreeBSD) quasi-VPS - I 
could probably use any or all of those.  The straight FreeBSD box is my 
mail server (Postfix).

-uso.


From usotsuki at buric.co  Wed May  9 10:54:52 2018
From: usotsuki at buric.co (Steve Nickolas)
Date: Tue, 8 May 2018 20:54:52 -0400 (EDT)
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <5FC9A20A-22A3-4EAF-8227-49D5839A9F76@orthanc.ca>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <00c501d3e702$65f60850$31e218f0$@ronnatalie.com>
 <CAM4FNSvrv-FGPFTywEj1YyFyYGvh_10ngXaBb0R1ae9UY92rCQ@mail.gmail.com>
 <d569f4c8-fe39-b220-3313-07b3be365ebf@spamtrap.tnetconsulting.net>
 <5FC9A20A-22A3-4EAF-8227-49D5839A9F76@orthanc.ca>
Message-ID: <alpine.BSF.2.02.1805082054040.3372@frieza.hoshinet.org>

On Tue, 8 May 2018, Lyndon Nerenberg wrote:

>
>> On May 8, 2018, at 3:55 PM, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
>>
>> I think there are a number of people / hobbyists that run (text only) news servers (like myself) doing exactly that.
>
> I don't understand what a "text only" news server is.  A "news" server schleps "news" around via NNTP.  The protocol is "text," as is SMTP for mail.  Is there a "binary" variation?

There's a bunch of groups, like alt.binaries.*, that carry large volumes 
of pirated material (software, videos, DVDISOs, etc.).  A text-only server 
excludes those groups.

-uso.


From khm at sciops.net  Wed May  9 11:28:53 2018
From: khm at sciops.net (Kurt H Maier)
Date: Tue, 8 May 2018 18:28:53 -0700
Subject: [TUHS] (early parallel/concurrent computing) (was: unix
 "awesome list")
In-Reply-To: <016301d3e72c$2fae3680$8f0aa380$@ronnatalie.com>
References: <146d3e969e94918e80c3d7dae01f0a839968e6bb@webmail.yaccman.com>
 <FAED01BC-5B5D-4EB7-8195-2D13F3460E51@orthanc.ca>
 <016301d3e72c$2fae3680$8f0aa380$@ronnatalie.com>
Message-ID: <20180509012853.GA81424@wopr>

On Tue, May 08, 2018 at 08:25:08PM -0400, Ron Natalie wrote:
> 
> Of course, this was about the time Mike Muuss and his band were becoming
> real firecrackers in the labs.    Mike shot his mouth off  that we could put
> UNIX on it (our answer to everything) and the lab management took us up on
> the offer.    Perhaps, with the exception of some of the MultibusII stuff,
> one of the nicest UNIX architectures around.
> 

A gentleman at ARL during my time there once mentioned they had some
"real nice parallel systems" until someone "ruined them with unix"... I
never did get details on which system he would have preferred pristine.

khm


From mparson at bl.org  Wed May  9 12:01:19 2018
From: mparson at bl.org (Michael Parson)
Date: Tue, 8 May 2018 21:01:19 -0500 (CDT)
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <CAEdTPBdM=DXh_dzXRPjxdU-eHY-CSbduPx-jjDoGZjXxxcnjjg@mail.gmail.com>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <e600c456-d900-ffe2-cfcc-aa8331a77f58@kilonet.net>
 <alpine.BSF.2.21.1.1805081159390.81704@orthanc.ca>
 <990f91e8-01c0-cf25-4889-43e1580398ef@kilonet.net>
 <CAEdTPBfoSbh8HygKKB+pABBs8a6P0zsSYyZ6sNpheLtppX=ZcQ@mail.gmail.com>
 <8120ea75-3573-0931-bf35-f18bf2e4c9f3@kilonet.net>
 <CAEdTPBdM=DXh_dzXRPjxdU-eHY-CSbduPx-jjDoGZjXxxcnjjg@mail.gmail.com>
Message-ID: <alpine.NEB.2.20.1805082056260.10555@neener.bl.org>

On Tue, 8 May 2018, Henry Bent wrote:
> On 8 May 2018 at 18:32, Arthur Krewat <krewat at kilonet.net> wrote:
>> On 5/8/2018 6:22 PM, Henry Bent wrote:
>>
>>> My father was the sysadmin for Deja News at the time they were
>>> bought by Google.  I was told that the "buyout" consisted of some
>>> Google folks showing up with a rack of drives, dumping all of Deja
>>> News's data over a weekend, and then flying back out to Mountain
>>> View.
>>
>> Where are the original drives? Or tapes? (insert devilish grin
>> emoticon here)
>>
>> ak
>
> I have no idea where they are now.  At the time they were in Austin,
> TX.  I imagine that they probably just went to one of those many IT
> scrapyards, the warehouses full of old parts that the owners sell on
> eBay.

It was all auctioned off.  I went to that auction... it was the dot-com
bust auction where I saw things turn from being able to get a good deal
to a lot of stupid going on.  I bought two boxes full of SCSI hard
drives for $79/ea.  Turns out, it was about 20 drives and they were
mostly 4 and 9 gig Seagate HD's that still had a year or two left on
their warranty.  I turned around and re-sold them, untested, but with
a copy of the warranty status for each one with it, for something like
$5 or 10/gig.

-- 
Michael Parson
Pflugerville, TX
KF5LGQ


From mparson at bl.org  Wed May  9 11:55:33 2018
From: mparson at bl.org (Michael Parson)
Date: Tue, 8 May 2018 20:55:33 -0500 (CDT)
Subject: [TUHS] Old Usenet newsreader source code?
In-Reply-To: <CAEdTPBfoSbh8HygKKB+pABBs8a6P0zsSYyZ6sNpheLtppX=ZcQ@mail.gmail.com>
References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com>
 <20180508163643.GA16384@mcvoy.com>
 <201805081706.w48H62gd027214@freefriends.org>
 <CAEoi9W6Me2FuZoNUXGppO7KYvfXE7C0b4jdt-do8x-yq-YynMg@mail.gmail.com>
 <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com>
 <e600c456-d900-ffe2-cfcc-aa8331a77f58@kilonet.net>
 <alpine.BSF.2.21.1.1805081159390.81704@orthanc.ca>
 <990f91e8-01c0-cf25-4889-43e1580398ef@kilonet.net>
 <CAEdTPBfoSbh8HygKKB+pABBs8a6P0zsSYyZ6sNpheLtppX=ZcQ@mail.gmail.com>
Message-ID: <alpine.NEB.2.20.1805082054310.10555@neener.bl.org>

On Tue, 8 May 2018, Henry Bent wrote:

> My father was the sysadmin for Deja News at the time they were bought by
> Google.  I was told that the "buyout" consisted of some Google folks
> showing up with a rack of drives, dumping all of Deja News's data over a
> weekend, and then flying back out to Mountain View.

Now that makes me feel old.  I was the sysadmin for the datacenter
Deja's servers were in.  Who is your dad, if I don't know him directly,
I probably know a few that do.

-- 
Michael Parson
Pflugerville, TX
KF5LGQ


From rob at robdiamond.com  Thu May 10 06:15:38 2018
From: rob at robdiamond.com (Robert Diamond)
Date: Wed, 9 May 2018 16:15:38 -0400
Subject: [TUHS] Windows Notepad to support Unix line endings
Message-ID: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com>

30+ years later…
https://blogs.msdn.microsoft.com/commandline/2018/05/08/extended-eol-in-notepad/ <https://blogs.msdn.microsoft.com/commandline/2018/05/08/extended-eol-in-notepad/>

---
Robert Diamond
rob at robdiamond.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180509/454366e6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3862 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180509/454366e6/attachment.bin>

From gtaylor at tnetconsulting.net  Thu May 10 07:54:27 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 9 May 2018 15:54:27 -0600
Subject: [TUHS] Windows Notepad to support Unix line endings
In-Reply-To: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com>
References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com>
Message-ID: <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net>

On 05/09/2018 02:15 PM, Robert Diamond wrote:
> 30+ years later…
> https://blogs.msdn.microsoft.com/commandline/2018/05/08/extended-eol-in-notepad/

I guess I'm just a curmudgeon.

I can't be arsed to care that much about Notepad supporting unix new line.

Wordpad, which ships with Windows (even if it's not installed by 
default), has supported unix new line for as long as I can remember.

So … I don't feel Notepad supporting unix new lines to be that big of a 
deal.

What am I missing?



-- 
Grant. . . .
unix || die

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

From davida at pobox.com  Thu May 10 07:57:32 2018
From: davida at pobox.com (David Arnold)
Date: Thu, 10 May 2018 07:57:32 +1000
Subject: [TUHS] Windows Notepad to support Unix line endings
In-Reply-To: <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net>
References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com>
 <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net>
Message-ID: <FBB7EBC3-FFAA-4DDA-915C-156D6B67B225@pobox.com>

Double-click on a .txt file will invoke Notepad, unless you’ve reconfigured things.



d

> On 10 May 2018, at 07:54, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
> 
> On 05/09/2018 02:15 PM, Robert Diamond wrote:
>> 30+ years later…
>> https://blogs.msdn.microsoft.com/commandline/2018/05/08/extended-eol-in-notepad/
> 
> I guess I'm just a curmudgeon.
> 
> I can't be arsed to care that much about Notepad supporting unix new line.
> 
> Wordpad, which ships with Windows (even if it's not installed by default), has supported unix new line for as long as I can remember.
> 
> So … I don't feel Notepad supporting unix new lines to be that big of a deal.
> 
> What am I missing?
> 
> 
> 
> -- 
> Grant. . . .
> unix || die
> 



From gtaylor at tnetconsulting.net  Thu May 10 08:23:56 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 9 May 2018 16:23:56 -0600
Subject: [TUHS] Windows Notepad to support Unix line endings
In-Reply-To: <FBB7EBC3-FFAA-4DDA-915C-156D6B67B225@pobox.com>
References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com>
 <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net>
 <FBB7EBC3-FFAA-4DDA-915C-156D6B67B225@pobox.com>
Message-ID: <1cfffd7b-4490-7ebc-d892-b603d8312f9d@spamtrap.tnetconsulting.net>

On 05/09/2018 03:57 PM, David Arnold wrote:
> Double-click on a .txt file will invoke Notepad, unless you’ve 
> reconfigured things.

Right-click on a .txt file
Left-click on Open With
Left-click on Wordpad
(Optionally) Left-click on "always use this program…"

Sure, it's a preference change.  But it's a user level preference.

Is it nice that Notepad will now open files with unix new lines?  Sure.

Do I think it's worth some of the hype that I'm seeing?  Nope.



-- 
Grant. . . .
unix || die

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

From krewat at kilonet.net  Thu May 10 08:30:47 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 9 May 2018 18:30:47 -0400
Subject: [TUHS] Windows Notepad to support Unix line endings
In-Reply-To: <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net>
References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com>
 <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net>
Message-ID: <e4161f58-e8d6-4800-4195-f51344123e3f@kilonet.net>

On 5/9/2018 5:54 PM, Grant Taylor via TUHS wrote:
> What am I missing? 

I was reading comments on an article about this today, and someone 
raised the idea that Windows is dead, and Microsoft will just switch to 
Linux.

Can you imagine a world where one operating system dominates the playing 
field, both server and client? And while some would say "well, UNIX won" 
- I don't consider Linux to be "UNIX" just as many here do not.

They have SQL Server for Linux now, and they have a Linux subsystem for 
Windows that allows you to run Linux binaries on Windows. I'd love to 
see some benchmarks of SQL Server on Linux vs. Windows.

How long before they take the Windows GUI and video drivers and slap it 
on top of Linux for a test spin? (if they haven't already)

I wonder how Dave Cutler would feel about that? :)

art k.



From tfb at tfeb.org  Thu May 10 08:41:24 2018
From: tfb at tfeb.org (Tim Bradshaw)
Date: Wed, 9 May 2018 23:41:24 +0100
Subject: [TUHS] Windows Notepad to support Unix line endings
In-Reply-To: <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net>
References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com>
 <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net>
Message-ID: <FE89D3CA-8028-4775-9CE5-4AB1D68515EE@tfeb.org>

On 9 May 2018, at 22:54, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
> 
> What am I missing?

That the most popular text editor in the world now supports Unix line endings.

(I made that up, but I would not be surprised if it was true).


From lm at mcvoy.com  Thu May 10 08:54:34 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 9 May 2018 15:54:34 -0700
Subject: [TUHS] Windows Notepad to support Unix line endings
In-Reply-To: <e4161f58-e8d6-4800-4195-f51344123e3f@kilonet.net>
References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com>
 <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net>
 <e4161f58-e8d6-4800-4195-f51344123e3f@kilonet.net>
Message-ID: <20180509225433.GA31783@mcvoy.com>

On Wed, May 09, 2018 at 06:30:47PM -0400, Arthur Krewat wrote:
> How long before they take the Windows GUI and video drivers and slap it on
> top of Linux for a test spin? (if they haven't already)

I've actually wanted this for decades.  The Windows programming environment
leaves a lot to be desired.  And nobody, except app writers, cares about
the kernel, it could be linux and so long as they had backwards compat
Windows APIs everyone would be happy.


From cym224 at gmail.com  Thu May 10 09:08:20 2018
From: cym224 at gmail.com (Nemo)
Date: Wed, 9 May 2018 19:08:20 -0400
Subject: [TUHS] Windows Notepad to support Unix line endings
In-Reply-To: <1cfffd7b-4490-7ebc-d892-b603d8312f9d@spamtrap.tnetconsulting.net>
References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com>
 <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net>
 <FBB7EBC3-FFAA-4DDA-915C-156D6B67B225@pobox.com>
 <1cfffd7b-4490-7ebc-d892-b603d8312f9d@spamtrap.tnetconsulting.net>
Message-ID: <CAJfiPzx270NLQAXAC9FUaxafqiAz8LePFw=6cDYNkM_c0CiAFg@mail.gmail.com>

On 05/09/18 18:23, Grant Taylor via TUHS wrote:
[...]
>
> Is it nice that Notepad will now open files with unix new lines?  Sure.
>
> Do I think it's worth some of the hype that I'm seeing?  Nope.


Maybe you do not work with people who only know grunt-and-poke.

I usually making notes in LF-based text format and received so much
flack over it that I began running unix2dos before uploading or
sending anything. With this, I can now skip the last step.

N.


From cym224 at gmail.com  Thu May 10 09:10:02 2018
From: cym224 at gmail.com (Nemo)
Date: Wed, 9 May 2018 19:10:02 -0400
Subject: [TUHS] Windows Notepad to support Unix line endings
In-Reply-To: <CAJfiPzx270NLQAXAC9FUaxafqiAz8LePFw=6cDYNkM_c0CiAFg@mail.gmail.com>
References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com>
 <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net>
 <FBB7EBC3-FFAA-4DDA-915C-156D6B67B225@pobox.com>
 <1cfffd7b-4490-7ebc-d892-b603d8312f9d@spamtrap.tnetconsulting.net>
 <CAJfiPzx270NLQAXAC9FUaxafqiAz8LePFw=6cDYNkM_c0CiAFg@mail.gmail.com>
Message-ID: <CAJfiPzzedkvACojbr3vzFiVna3vkPZLULH2Yhin9bzGcdtgLfg@mail.gmail.com>

On 09/05/2018, Nemo <cym224 at gmail.com> wrote:

Oops -- I may have accidentally posted a duplicate. Apologies.

N.


From gtaylor at tnetconsulting.net  Thu May 10 09:28:32 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 9 May 2018 17:28:32 -0600
Subject: [TUHS] Windows Notepad to support Unix line endings
In-Reply-To: <CAJfiPzx270NLQAXAC9FUaxafqiAz8LePFw=6cDYNkM_c0CiAFg@mail.gmail.com>
References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com>
 <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net>
 <FBB7EBC3-FFAA-4DDA-915C-156D6B67B225@pobox.com>
 <1cfffd7b-4490-7ebc-d892-b603d8312f9d@spamtrap.tnetconsulting.net>
 <CAJfiPzx270NLQAXAC9FUaxafqiAz8LePFw=6cDYNkM_c0CiAFg@mail.gmail.com>
Message-ID: <69bc5bc2-b1cb-7d68-379c-57c579af9bd9@spamtrap.tnetconsulting.net>

On 05/09/2018 05:08 PM, Nemo wrote:
> Maybe you do not work with people who only know grunt-and-poke.

Oh, I've worked with them before.

I just go out of my way to edgumicate them.  I'll learn them gud.

(Maybe the 3' pipe wrench has something to do with it.)

Suffice it to say that I will bend over backwards to teach people how to 
fish for themselves.  I will likely give them fish exactly once.

> I usually making notes in LF-based text format and received so much 
> flack over it that I began running unix2dos before uploading or sending 
> anything. With this, I can now skip the last step.

I'll believe that in five years.  After the version of Notepad that 
supports unix new lines is on current and (then) older systems.  Until 
then, you'll probably still be pandering to them.

I did say that I'm a curmudgeon, didn't I?



-- 
Grant. . . .
unix || die

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

From norman at oclsc.org  Thu May 10 10:32:30 2018
From: norman at oclsc.org (Norman Wilson)
Date: Wed,  9 May 2018 20:32:30 -0400 (EDT)
Subject: [TUHS] Windows Notepad to support Unix line endings
Message-ID: <20180510003230.5120F4422F@lignose.oclsc.org>

Grant Taylor:

  (Maybe the 3' pipe wrench has something to do with it.)

=======

Real pipes don't need wrenches.  Maybe those in Windows do.

Norman Wilson
Toronto ON


From gtaylor at tnetconsulting.net  Thu May 10 11:10:08 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 9 May 2018 19:10:08 -0600
Subject: [TUHS] Windows Notepad to support Unix line endings
In-Reply-To: <20180510003230.5120F4422F@lignose.oclsc.org>
References: <20180510003230.5120F4422F@lignose.oclsc.org>
Message-ID: <6B624601-1161-44D7-99C3-4B423DACBEC5@tnetconsulting.net>

The cast iron gas pipe that I’ve worked in beggars to differ.



-- 
Grant. . . .
unix || die

> On May 9, 2018, at 6:32 PM, Norman Wilson <norman at oclsc.org> wrote:
> 
> Grant Taylor:
> 
>  (Maybe the 3' pipe wrench has something to do with it.)
> 
> =======
> 
> Real pipes don't need wrenches.  Maybe those in Windows do.
> 
> Norman Wilson
> Toronto ON
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2338 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180509/d3cd2568/attachment.bin>

From gtaylor at tnetconsulting.net  Thu May 10 13:49:16 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 9 May 2018 21:49:16 -0600
Subject: [TUHS] UUCP "bag" files
Message-ID: <04c44cba-fefe-b5c6-d683-618ed3ddb0cb@spamtrap.tnetconsulting.net>

Does anyone know why UUCP "bag" files are called "bag"?

Seeing as this relates to unix-to-unix-copy, I figured that someone on 
TUHS might have an idea.

Thanks in advance.



-- 
Grant. . . .
unix || die

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

From lyndon at orthanc.ca  Thu May 10 13:51:03 2018
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Wed, 9 May 2018 20:51:03 -0700
Subject: [TUHS] UUCP "bag" files
In-Reply-To: <04c44cba-fefe-b5c6-d683-618ed3ddb0cb@spamtrap.tnetconsulting.net>
References: <04c44cba-fefe-b5c6-d683-618ed3ddb0cb@spamtrap.tnetconsulting.net>
Message-ID: <9D7839FC-A3EB-4211-887D-BCE67229E1D6@orthanc.ca>


> On May 9, 2018, at 8:49 PM, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
> 
> Does anyone know why UUCP "bag" files are called "bag"?

What are they to begin with?  Having run some "major" UUCP hubs in the day, I have no clue what a UUCP "bag" is ...

From gtaylor at tnetconsulting.net  Thu May 10 14:53:01 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 9 May 2018 22:53:01 -0600
Subject: [TUHS] UUCP "bag" files
In-Reply-To: <9D7839FC-A3EB-4211-887D-BCE67229E1D6@orthanc.ca>
References: <04c44cba-fefe-b5c6-d683-618ed3ddb0cb@spamtrap.tnetconsulting.net>
 <9D7839FC-A3EB-4211-887D-BCE67229E1D6@orthanc.ca>
Message-ID: <042d9aff-82df-d267-e585-3dfe57b06252@spamtrap.tnetconsulting.net>

On 05/09/2018 09:51 PM, Lyndon Nerenberg wrote:
> What are they to begin with?  Having run some "major" UUCP hubs in the 
> day, I have no clue what a UUCP "bag" is ...

I see them in the context of Usenet via UUCP, so rnews.

The best that I can tell is that they are simply the messages that need 
to be sent written into a single file that is then transferred via some 
mechanism, ftp being a common one.

It looks like it might be the output of nntpsend or send-nntp.  Or 
perhaps output of downstream / related UUCP commands.

I often see it mentioned in close proximity of DNews.



-- 
Grant. . . .
unix || die

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

From bakul at bitblocks.com  Thu May 10 15:03:34 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 09 May 2018 22:03:34 -0700
Subject: [TUHS] UUCP "bag" files
In-Reply-To: Your message of "Wed, 09 May 2018 22:53:01 -0600."
 <042d9aff-82df-d267-e585-3dfe57b06252@spamtrap.tnetconsulting.net>
References: <04c44cba-fefe-b5c6-d683-618ed3ddb0cb@spamtrap.tnetconsulting.net>
 <9D7839FC-A3EB-4211-887D-BCE67229E1D6@orthanc.ca>
 <042d9aff-82df-d267-e585-3dfe57b06252@spamtrap.tnetconsulting.net>
Message-ID: <20180510050341.64DDC156E510@mail.bitblocks.com>

On Wed, 09 May 2018 22:53:01 -0600 Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
> 
> On 05/09/2018 09:51 PM, Lyndon Nerenberg wrote:
> > What are they to begin with?  Having run some "major" UUCP hubs in the
> > day, I have no clue what a UUCP "bag" is ...
> 
> I see them in the context of Usenet via UUCP, so rnews.
> 
> The best that I can tell is that they are simply the messages that need
> to be sent written into a single file that is then transferred via some
> mechanism, ftp being a common one.
> 
> It looks like it might be the output of nntpsend or send-nntp.  Or
> perhaps output of downstream / related UUCP commands.
> 
> I often see it mentioned in close proximity of DNews.

From dnews manual

Sucking in UUCP or Satellite articles

  DNEWS can read UUCP bag files in standard rnews format,
  these are often used by satellite systems, the satellite
  receiver software may write 'uucp' files to a directory on
  your system, dnews can then automatically scan and read in
  items that appear in this directory. To read these files
  just specify in dnews.conf the directory and file names that
  DNews should scan, e.g. in dnews.conf

I have a vague memory of some folks (Mark Horton?) sending usenet
data in the unused portion satellite TV signal (stargate?).

Ah, this must be it!:

https://web.archive.org/web/19981203103811/http://www.stargate.com/history.html


From cym224 at gmail.com  Thu May 10 23:34:39 2018
From: cym224 at gmail.com (Nemo)
Date: Thu, 10 May 2018 09:34:39 -0400
Subject: [TUHS] Windows Notepad to support Unix line endings
In-Reply-To: <69bc5bc2-b1cb-7d68-379c-57c579af9bd9@spamtrap.tnetconsulting.net>
References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com>
 <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net>
 <FBB7EBC3-FFAA-4DDA-915C-156D6B67B225@pobox.com>
 <1cfffd7b-4490-7ebc-d892-b603d8312f9d@spamtrap.tnetconsulting.net>
 <CAJfiPzx270NLQAXAC9FUaxafqiAz8LePFw=6cDYNkM_c0CiAFg@mail.gmail.com>
 <69bc5bc2-b1cb-7d68-379c-57c579af9bd9@spamtrap.tnetconsulting.net>
Message-ID: <CAJfiPzwq_ECc0nr7gM0fJa0PrnuW_tMRjrfYW8jBvsSu8f+1zQ@mail.gmail.com>

On 9 May 2018 at 19:28, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
> On 05/09/2018 05:08 PM, Nemo wrote:
>>
>> Maybe you do not work with people who only know grunt-and-poke.
>
> Oh, I've worked with them before.
>
> I just go out of my way to edgumicate them.  I'll learn them gud.
>
> (Maybe the 3' pipe wrench has something to do with it.)

I can only dream of this... The grunt-and-pokers are all in Legal and
they can damage me more than I can damage them.

N.

>
> Suffice it to say that I will bend over backwards to teach people how to
> fish for themselves.  I will likely give them fish exactly once.
[...]


From jpl.jpl at gmail.com  Fri May 11 00:10:23 2018
From: jpl.jpl at gmail.com (John P. Linderman)
Date: Thu, 10 May 2018 10:10:23 -0400
Subject: [TUHS] UUCP "bag" files
In-Reply-To: <9D7839FC-A3EB-4211-887D-BCE67229E1D6@orthanc.ca>
References: <04c44cba-fefe-b5c6-d683-618ed3ddb0cb@spamtrap.tnetconsulting.net>
 <9D7839FC-A3EB-4211-887D-BCE67229E1D6@orthanc.ca>
Message-ID: <CAC0cEp8QS8K56YL3o2f9LLXWdSws0J_UMUD38bUZ-3i=JZF5YQ@mail.gmail.com>

I asked Dave Nowitz, one of the authors of HoneyDanBer UUCP (the others
being Peter Honeyman and Brian Redman) if he knew what bag files were. He
said

Never heard of bag files.
Maybe whoever wrote the linux version did it?


On Wed, May 9, 2018 at 11:51 PM, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:

>
> > On May 9, 2018, at 8:49 PM, Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
> wrote:
> >
> > Does anyone know why UUCP "bag" files are called "bag"?
>
> What are they to begin with?  Having run some "major" UUCP hubs in the
> day, I have no clue what a UUCP "bag" is ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180510/39f973a4/attachment.html>

From chet.ramey at case.edu  Fri May 11 00:25:27 2018
From: chet.ramey at case.edu (Chet Ramey)
Date: Thu, 10 May 2018 10:25:27 -0400
Subject: [TUHS] UUCP "bag" files
In-Reply-To: <042d9aff-82df-d267-e585-3dfe57b06252@spamtrap.tnetconsulting.net>
References: <04c44cba-fefe-b5c6-d683-618ed3ddb0cb@spamtrap.tnetconsulting.net>
 <9D7839FC-A3EB-4211-887D-BCE67229E1D6@orthanc.ca>
 <042d9aff-82df-d267-e585-3dfe57b06252@spamtrap.tnetconsulting.net>
Message-ID: <3a393f09-d437-9951-98ee-24ddcdce120e@case.edu>

On 5/10/18 12:53 AM, Grant Taylor via TUHS wrote:
> On 05/09/2018 09:51 PM, Lyndon Nerenberg wrote:
>> What are they to begin with?  Having run some "major" UUCP hubs in the
>> day, I have no clue what a UUCP "bag" is ...
> 
> I see them in the context of Usenet via UUCP, so rnews.

Yes. Bag files are a file format used to transfer news via uucp,
popularized by dnews. I think they originated with satellite news
systems.

"Setting up a UUCP feed into DNEWS
	addsvc -del dposter
	addsvc -add dposter dposter.exe "dposter -dir c:\uucp\in -to news.here.com"
    This will search for files called *.bag in the directory c:\uucp\in
    and after processing them it will delete them.  It's your job to write
    a batch script to get the files in this directory and uncompress them
    if necessary.
    You may also need to add ihave access to your own machine:
         news.here.com:read,post,ihave:::*

    The BAG/UUCP file format is:

    #! rnews nnnn
    ...(article, exactly nnnn bytes, counting each end of line as one byte)
    #! rnews nnnn
    ...(next article)...

Setting up a UUCP feed out of DNEWS
   In newsfeeds.conf add a feed, e.g.
           	site site1.name.uucp
	       		groups *

   Add a service (or process to run xmit and dposter)
	addsvc -add dxmit1 xmit.exe "dxmit1 site.name.edu -at *5 * -uucp
c:\dnews\site1 "

   This will create files called news000n.bag in the directory
c:\dnews\site1  	
   It's your job to uucp copy these to the destination sites, and delete them.
   If you want you can compress them first.  :-)

   The format of the file is:

    #! rnews nnnn
    ...(article, exactly nnnn bytes, counting each end of line as one byte)
    #! rnews nnnn
    ...(next article)..."


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


From gtaylor at tnetconsulting.net  Fri May 11 01:24:28 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Thu, 10 May 2018 09:24:28 -0600
Subject: [TUHS] Windows Notepad to support Unix line endings
In-Reply-To: <CAJfiPzwq_ECc0nr7gM0fJa0PrnuW_tMRjrfYW8jBvsSu8f+1zQ@mail.gmail.com>
References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com>
 <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net>
 <FBB7EBC3-FFAA-4DDA-915C-156D6B67B225@pobox.com>
 <1cfffd7b-4490-7ebc-d892-b603d8312f9d@spamtrap.tnetconsulting.net>
 <CAJfiPzx270NLQAXAC9FUaxafqiAz8LePFw=6cDYNkM_c0CiAFg@mail.gmail.com>
 <69bc5bc2-b1cb-7d68-379c-57c579af9bd9@spamtrap.tnetconsulting.net>
 <CAJfiPzwq_ECc0nr7gM0fJa0PrnuW_tMRjrfYW8jBvsSu8f+1zQ@mail.gmail.com>
Message-ID: <43a2e6e1-6e72-f28f-4341-d1a5b05dfaba@spamtrap.tnetconsulting.net>

On 05/10/2018 07:34 AM, Nemo wrote:
> I can only dream of this... The grunt-and-pokers are all in Legal and 
> they can damage me more than I can damage them.

I frequently figured out a way to make it so that the grunt-and-pokers 
felt like it behooved them to learn how to do things on their own.  The 
likely suspects are 1) faster response time (I came in later than they 
did) and 2) it saved money in that they didn't have to wait on me and I 
didn't have to delay work on other projects.  Thus the (sometimes 
begrudgingly) agreed that learning how to turn on the overhead lights 
was better than waiting on me to come in and do it later.  (Effectively 
speaking.)



-- 
Grant. . . .
unix || die

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

From gtaylor at tnetconsulting.net  Fri May 11 01:28:05 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Thu, 10 May 2018 09:28:05 -0600
Subject: [TUHS] UUCP "bag" files
In-Reply-To: <3a393f09-d437-9951-98ee-24ddcdce120e@case.edu>
References: <04c44cba-fefe-b5c6-d683-618ed3ddb0cb@spamtrap.tnetconsulting.net>
 <9D7839FC-A3EB-4211-887D-BCE67229E1D6@orthanc.ca>
 <042d9aff-82df-d267-e585-3dfe57b06252@spamtrap.tnetconsulting.net>
 <3a393f09-d437-9951-98ee-24ddcdce120e@case.edu>
Message-ID: <9a749ac4-6017-c907-dc6e-28eff66858a5@spamtrap.tnetconsulting.net>

On 05/10/2018 08:25 AM, Chet Ramey wrote:
> Yes. Bag files are a file format used to transfer news via uucp, 
> popularized by dnews. I think they originated with satellite news systems.

This seems to be exactly the topic that I'm asking about.

Unfortunately it doesn't hint at why the files are called "bag" files.

I have seen documentation that indicates that they had the ".bag" file 
extension.  But that in and of itself doesn't offer any clue as to why 
that extension was chosen.

Hence the question of "why".  ;-)



-- 
Grant. . . .
unix || die

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

From mah at mhorton.net  Fri May 11 01:46:50 2018
From: mah at mhorton.net (Mary Ann Horton)
Date: Thu, 10 May 2018 08:46:50 -0700
Subject: [TUHS] UUCP "bag" files
In-Reply-To: <20180510050341.64DDC156E510@mail.bitblocks.com>
References: <04c44cba-fefe-b5c6-d683-618ed3ddb0cb@spamtrap.tnetconsulting.net>
 <9D7839FC-A3EB-4211-887D-BCE67229E1D6@orthanc.ca>
 <042d9aff-82df-d267-e585-3dfe57b06252@spamtrap.tnetconsulting.net>
 <20180510050341.64DDC156E510@mail.bitblocks.com>
Message-ID: <e838615c-9bcc-07c5-8a62-3f756e843005@mhorton.net>

Stargate did not use anything called "bags".  I just checked the source 
code to confirm.

It also didn't use D news.  Stargate required B news.

Remember - Stargate was in the 1987 time frame.  Googling for Dnews 
turns up a CNet page saying it was released in 2004.

     Mary Ann


On 05/09/2018 10:03 PM, Bakul Shah wrote:
> On Wed, 09 May 2018 22:53:01 -0600 Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
>> On 05/09/2018 09:51 PM, Lyndon Nerenberg wrote:
>>> What are they to begin with?  Having run some "major" UUCP hubs in the
>>> day, I have no clue what a UUCP "bag" is ...
>> I see them in the context of Usenet via UUCP, so rnews.
>>
>> The best that I can tell is that they are simply the messages that need
>> to be sent written into a single file that is then transferred via some
>> mechanism, ftp being a common one.
>>
>> It looks like it might be the output of nntpsend or send-nntp.  Or
>> perhaps output of downstream / related UUCP commands.
>>
>> I often see it mentioned in close proximity of DNews.
>  From dnews manual
>
> Sucking in UUCP or Satellite articles
>
>    DNEWS can read UUCP bag files in standard rnews format,
>    these are often used by satellite systems, the satellite
>    receiver software may write 'uucp' files to a directory on
>    your system, dnews can then automatically scan and read in
>    items that appear in this directory. To read these files
>    just specify in dnews.conf the directory and file names that
>    DNews should scan, e.g. in dnews.conf
>
> I have a vague memory of some folks (Mark Horton?) sending usenet
> data in the unused portion satellite TV signal (stargate?).
>
> Ah, this must be it!:
>
> https://web.archive.org/web/19981203103811/http://www.stargate.com/history.html



From crossd at gmail.com  Fri May 11 02:03:22 2018
From: crossd at gmail.com (Dan Cross)
Date: Thu, 10 May 2018 16:03:22 +0000
Subject: [TUHS] UUCP "bag" files
In-Reply-To: <9a749ac4-6017-c907-dc6e-28eff66858a5@spamtrap.tnetconsulting.net>
References: <04c44cba-fefe-b5c6-d683-618ed3ddb0cb@spamtrap.tnetconsulting.net>
 <9D7839FC-A3EB-4211-887D-BCE67229E1D6@orthanc.ca>
 <042d9aff-82df-d267-e585-3dfe57b06252@spamtrap.tnetconsulting.net>
 <3a393f09-d437-9951-98ee-24ddcdce120e@case.edu>
 <9a749ac4-6017-c907-dc6e-28eff66858a5@spamtrap.tnetconsulting.net>
Message-ID: <CAEoi9W5c5nMtEOF-JCj5J6U2b2+2hNxmLTiVoJYU2CA9X+fRYQ@mail.gmail.com>

On Thu, May 10, 2018, 11:28 AM Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
wrote:

> On 05/10/2018 08:25 AM, Chet Ramey wrote:
> > Yes. Bag files are a file format used to transfer news via uucp,
> > popularized by dnews. I think they originated with satellite news
> systems.
>
> This seems to be exactly the topic that I'm asking about.
>
> Unfortunately it doesn't hint at why the files are called "bag" files.
>

Totally hazarding a guess, but I'd imagine the etymology comes from a news
bag, as in the thing slung over the should and hauled around by the
neighborhood kid who delivers newspapers in the morning (that holds the
to-be-delivered news).

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

From chet.ramey at case.edu  Fri May 11 02:08:02 2018
From: chet.ramey at case.edu (Chet Ramey)
Date: Thu, 10 May 2018 12:08:02 -0400
Subject: [TUHS] UUCP "bag" files
In-Reply-To: <e838615c-9bcc-07c5-8a62-3f756e843005@mhorton.net>
References: <04c44cba-fefe-b5c6-d683-618ed3ddb0cb@spamtrap.tnetconsulting.net>
 <9D7839FC-A3EB-4211-887D-BCE67229E1D6@orthanc.ca>
 <042d9aff-82df-d267-e585-3dfe57b06252@spamtrap.tnetconsulting.net>
 <20180510050341.64DDC156E510@mail.bitblocks.com>
 <e838615c-9bcc-07c5-8a62-3f756e843005@mhorton.net>
Message-ID: <e8991591-9e12-e453-f074-e604b98cf719@case.edu>

On 5/10/18 11:46 AM, Mary Ann Horton wrote:
> Stargate did not use anything called "bags".  I just checked the source
> code to confirm.
> 
> It also didn't use D news.  Stargate required B news.

There are many other satellite internet providers that have appeared since
stargate. For instance:

http://www.infostar.de/knowhow/satfeed.txt

The dnews documentation references them:

"DNEWS can read UUCP bag files in standard rnews format, these are often
used by satellite systems,
the satellite receiver software may write 'uucp' files to a directory on
your system, dnews can then
automatically scan and read in items that appear in this directory."

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


From gtaylor at tnetconsulting.net  Fri May 11 02:24:33 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Thu, 10 May 2018 10:24:33 -0600
Subject: [TUHS] UUCP "bag" files
In-Reply-To: <CAEoi9W5c5nMtEOF-JCj5J6U2b2+2hNxmLTiVoJYU2CA9X+fRYQ@mail.gmail.com>
References: <04c44cba-fefe-b5c6-d683-618ed3ddb0cb@spamtrap.tnetconsulting.net>
 <9D7839FC-A3EB-4211-887D-BCE67229E1D6@orthanc.ca>
 <042d9aff-82df-d267-e585-3dfe57b06252@spamtrap.tnetconsulting.net>
 <3a393f09-d437-9951-98ee-24ddcdce120e@case.edu>
 <9a749ac4-6017-c907-dc6e-28eff66858a5@spamtrap.tnetconsulting.net>
 <CAEoi9W5c5nMtEOF-JCj5J6U2b2+2hNxmLTiVoJYU2CA9X+fRYQ@mail.gmail.com>
Message-ID: <c438ac42-c520-3c73-1a1e-991afcc3353f@spamtrap.tnetconsulting.net>

On 05/10/2018 10:03 AM, Dan Cross wrote:
> Totally hazarding a guess, but I'd imagine the etymology comes from a 
> news bag, as in the thing slung over the should and hauled around by the 
> neighborhood kid who delivers newspapers in the morning (that holds the 
> to-be-delivered news).

That makes sense and is a news analog of what I was thinking for email 
over UUCP, the old mail bags that trains used to pick up and drop off, 
or otherwise used in bulk mail transport.

I just haven't been able to find much.  Further what I've found is more 
speculatory than anything else.



-- 
Grant. . . .
unix || die

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

From arnold at skeeve.com  Fri May 11 03:34:17 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 10 May 2018 11:34:17 -0600
Subject: [TUHS] I'm interested in the thoughts of the TUHS folks about
 this
In-Reply-To: <CAC20D2PBOwiyqim7sZZvygLs8WrDD1T0weROiOZpsY9kfR3jSg@mail.gmail.com>
References: <CAC20D2PBOwiyqim7sZZvygLs8WrDD1T0weROiOZpsY9kfR3jSg@mail.gmail.com>
Message-ID: <201805101734.w4AHYHtj018212@freefriends.org>

Clem Cole <clemc at ccc.com> wrote:

> I'm curious as UNIX folks if somewhere can enlighten me.   I sometimes
> answer things on Quora and a few years ago the following question was
> posted:
>
> What does "Experience working in Unix/Linux environments" mean when given
> as a required skill in company interviews? What do they want from us?
> <https://www.quora.com/What-does-Experience-working-in-Unix-Linux-environments-mean-when-given-as-a-required-skill-in-company-interviews-What-do-they-want-from-us>

Nice article about skill sets, Clem.

If anyone has a copy of the last edition of "UNIX In A Nutshell" from
O'Reilly, I put a bibliography there of what I considered the necessary
books to read to become a Unix Guru.  I had read most of them along my
journey ...

Thanks,

Arnold


From dave at horsfall.org  Fri May 11 05:34:44 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 11 May 2018 05:34:44 +1000 (EST)
Subject: [TUHS] Happy birthday, Edsger Dijkstra!
Message-ID: <alpine.BSF.2.21.999.1805110520390.79090@aneurin.horsfall.org>

Born on this day in 1930, he gave us ALGOL, the basis of all decent 
programming languages today, and the entire concept of structured 
programming.  Ah, well I remember the ALGOLW compiler on the 360...

There's a beaut article here:

     https://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF

And remember, testing can show the presence of errors, but not their 
absence...

-- 
Dave Horsfall BSc DTM (VK2KFU) -- FuglySoft -- Gosford IT -- Unix/C/Perl (AbW)
People who fail to / understand security / surely will suffer. (tks: RichardM)


From dave at horsfall.org  Fri May 11 07:09:02 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 11 May 2018 07:09:02 +1000 (EST)
Subject: [TUHS] Windows Notepad to support Unix line endings
In-Reply-To: <e4161f58-e8d6-4800-4195-f51344123e3f@kilonet.net>
References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com>
 <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net>
 <e4161f58-e8d6-4800-4195-f51344123e3f@kilonet.net>
Message-ID: <alpine.BSF.2.21.999.1805110706220.79090@aneurin.horsfall.org>

On Wed, 9 May 2018, Arthur Krewat wrote:

> Can you imagine a world where one operating system dominates the playing 
> field, both server and client? And while some would say "well, UNIX won" 
> - I don't consider Linux to be "UNIX" just as many here do not.

LINUX Is Not UniX.

-- 
Dave Horsfall BSc DTM (VK2KFU) -- FuglySoft -- Gosford IT -- Unix/C/Perl (AbW)
People who fail to / understand security / surely will suffer. (tks: RichardM)


From arnold at skeeve.com  Fri May 11 07:21:50 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 10 May 2018 15:21:50 -0600
Subject: [TUHS] Windows Notepad to support Unix line endings
In-Reply-To: <alpine.BSF.2.21.999.1805110706220.79090@aneurin.horsfall.org>
References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com>
 <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net>
 <e4161f58-e8d6-4800-4195-f51344123e3f@kilonet.net>
 <alpine.BSF.2.21.999.1805110706220.79090@aneurin.horsfall.org>
Message-ID: <201805102121.w4ALLoPA014948@freefriends.org>


> On Wed, 9 May 2018, Arthur Krewat wrote:
>
> > Can you imagine a world where one operating system dominates the playing 
> > field, both server and client? And while some would say "well, UNIX won" 
> > - I don't consider Linux to be "UNIX" just as many here do not.

Dave Horsfall <dave at horsfall.org> wrote:
> LINUX Is Not UniX.

Yada yada yada.

Given the choice between Windows dominating the world and Linux dominating
the world, I suspect everyone would still prefer it to be Linux, even
with all its shortcomings.

Nonetheless, I doubt that M$FT will abandon Windows for a Linux kernel
anytime soon.

Arnold


From skogtun at gmail.com  Fri May 11 07:47:36 2018
From: skogtun at gmail.com (Harald Arnesen)
Date: Thu, 10 May 2018 23:47:36 +0200
Subject: [TUHS] Windows Notepad to support Unix line endings
In-Reply-To: <alpine.BSF.2.21.999.1805110706220.79090@aneurin.horsfall.org>
References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com>
 <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net>
 <e4161f58-e8d6-4800-4195-f51344123e3f@kilonet.net>
 <alpine.BSF.2.21.999.1805110706220.79090@aneurin.horsfall.org>
Message-ID: <37ef96d3-e291-4ece-c159-9d6ecfc68210@gmail.com>

Dave Horsfall [05/10/2018 11:09 PM]:

> On Wed, 9 May 2018, Arthur Krewat wrote:
> 
>> Can you imagine a world where one operating system dominates the playing 
>> field, both server and client? And while some would say "well, UNIX won" 
>> - I don't consider Linux to be "UNIX" just as many here do not.
> 
> LINUX Is Not UniX.

Quoting Dennis:

"I don’t really distinguish between Linux and things that are more or
less direct descendants of Unix. I think they’re all the same at some
level. Often, people ask me, "Do you feel jealous about Linux being the
big thing." And the answer is no, for the same reason. I think they’re
the same."

. Linux Magazine: The Guru (15 June 2001)..



From clemc at ccc.com  Fri May 11 07:49:43 2018
From: clemc at ccc.com (Clem Cole)
Date: Thu, 10 May 2018 17:49:43 -0400
Subject: [TUHS] Windows Notepad to support Unix line endings
In-Reply-To: <alpine.BSF.2.21.999.1805110706220.79090@aneurin.horsfall.org>
References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com>
 <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net>
 <e4161f58-e8d6-4800-4195-f51344123e3f@kilonet.net>
 <alpine.BSF.2.21.999.1805110706220.79090@aneurin.horsfall.org>
Message-ID: <CAC20D2Og3sa9quiBezk4H939LwKFQpwD2sPWkVijPkXZYPjPAg@mail.gmail.com>

below...

On Thu, May 10, 2018 at 5:09 PM, Dave Horsfall <dave at horsfall.org> wrote:

> LINUX Is Not UniX.


A few thoughts ...
1.) Be careful - the US courts have said that *UNIX is not a code base or
any one implementation - it's a set of ideas​.*  That is the whole basis of
the BSDi case and why in the end AT&T lost.  It WAS their ideas, but it
just can not be a trade secret.  If AT&T had been able to claim it as a
trade secret, Linux, Minix, Coherent *et al *would have been in violation
too (which is why it was so silly to sue them).
2.) I believe that Linux is the current popular implementation of UNIX.
 Yes it hurts my fingers by some of the changes, but it looks, smells and
quacks like duck.   Linux uses the AT&T IP -- the published ideas.  All of
us on this list, just like Linus, are 'mentally contaminated' by Ken and
Dennis's core idea.   That's the basic fact and it not going away.
3.) Claiming LINUX Is Not UniX is like saying FORTRAN95 is not FORTRAN
because its not like F2, F4, F77 etc...   I'd like to point out that in
fact, modern FTN compilers can pretty much accept the old code - which
pretty darned amazing (and thankfully I'm not a compiler writer).    But
for guys like me in the HPC business, FORTRAN is still useful, as it pays
our salary.   The thing we have to remember is that the target matured, and
moved on.  It aint quite like it was and there is no going back.

I think that's the point and Ted and Larry have suggested so many times.
 Linux took the token from AT&T, BSD, Solaris, *etc*... and moved it.  Some
of us, myself included, find many of the changes gratuitous and a PITA, but
that is the price of progress. I remember that a lot of people at AT&T
thought the BSD changes were gratuitous too.   So Linux is the 3rd path of
the UNIX heritage.

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

From gtaylor at tnetconsulting.net  Fri May 11 08:59:53 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Thu, 10 May 2018 16:59:53 -0600
Subject: [TUHS] Windows Notepad to support Unix line endings
In-Reply-To: <CAC20D2Og3sa9quiBezk4H939LwKFQpwD2sPWkVijPkXZYPjPAg@mail.gmail.com>
References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com>
 <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net>
 <e4161f58-e8d6-4800-4195-f51344123e3f@kilonet.net>
 <alpine.BSF.2.21.999.1805110706220.79090@aneurin.horsfall.org>
 <CAC20D2Og3sa9quiBezk4H939LwKFQpwD2sPWkVijPkXZYPjPAg@mail.gmail.com>
Message-ID: <8ac8822b-e17b-4763-7d1c-3460a713183e@spamtrap.tnetconsulting.net>

Very well said Clem.

Linux is not Unix.
Linux is unix.

Note the case difference.

Linux does not have the licensing to claim to be a proper Unix (clone) 
and thus the privilege to use the uppercase "U".  But (IMHO) Linux is 
very much in the unix spirit or idea.

Analogy:  A Toyota Tacoma is not a Ford Ranger (Unix) but they are both 
pickup trucks (unix).



-- 
Grant. . . .
unix || die

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

From wobblygong at gmail.com  Fri May 11 09:13:35 2018
From: wobblygong at gmail.com (Wesley Parish)
Date: Fri, 11 May 2018 11:13:35 +1200
Subject: [TUHS] Windows Notepad to support Unix line endings
In-Reply-To: <CAC20D2Og3sa9quiBezk4H939LwKFQpwD2sPWkVijPkXZYPjPAg@mail.gmail.com>
References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com>
 <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net>
 <e4161f58-e8d6-4800-4195-f51344123e3f@kilonet.net>
 <alpine.BSF.2.21.999.1805110706220.79090@aneurin.horsfall.org>
 <CAC20D2Og3sa9quiBezk4H939LwKFQpwD2sPWkVijPkXZYPjPAg@mail.gmail.com>
Message-ID: <CACNPpeYHcUd4uRw9Xrw4pcJksEv1e6v0WGFX6Pf82NieWQxAcg@mail.gmail.com>

That was the impression I got from the various Unix and UNIX(TM)
documents that Groklaw discussed during The SCO Group's Foot-In-Mouth
case against Linux, IBM and The Rest Of The World.

Wesley Parish

On 5/11/18, Clem Cole <clemc at ccc.com> wrote:
> below...
>
> On Thu, May 10, 2018 at 5:09 PM, Dave Horsfall <dave at horsfall.org> wrote:
>
>> LINUX Is Not UniX.
>
>
> A few thoughts ...
> 1.) Be careful - the US courts have said that *UNIX is not a code base or
> any one implementation - it's a set of ideas​.*  That is the whole basis of
> the BSDi case and why in the end AT&T lost.  It WAS their ideas, but it
> just can not be a trade secret.  If AT&T had been able to claim it as a
> trade secret, Linux, Minix, Coherent *et al *would have been in violation
> too (which is why it was so silly to sue them).
> 2.) I believe that Linux is the current popular implementation of UNIX.
>  Yes it hurts my fingers by some of the changes, but it looks, smells and
> quacks like duck.   Linux uses the AT&T IP -- the published ideas.  All of
> us on this list, just like Linus, are 'mentally contaminated' by Ken and
> Dennis's core idea.   That's the basic fact and it not going away.
> 3.) Claiming LINUX Is Not UniX is like saying FORTRAN95 is not FORTRAN
> because its not like F2, F4, F77 etc...   I'd like to point out that in
> fact, modern FTN compilers can pretty much accept the old code - which
> pretty darned amazing (and thankfully I'm not a compiler writer).    But
> for guys like me in the HPC business, FORTRAN is still useful, as it pays
> our salary.   The thing we have to remember is that the target matured, and
> moved on.  It aint quite like it was and there is no going back.
>
> I think that's the point and Ted and Larry have suggested so many times.
>  Linux took the token from AT&T, BSD, Solaris, *etc*... and moved it.  Some
> of us, myself included, find many of the changes gratuitous and a PITA, but
> that is the price of progress. I remember that a lot of people at AT&T
> thought the BSD changes were gratuitous too.   So Linux is the 3rd path of
> the UNIX heritage.
>
> Clem
> ᐧ
> ᐧ
>


From lyndon at orthanc.ca  Fri May 11 09:38:54 2018
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Thu, 10 May 2018 16:38:54 -0700
Subject: [TUHS] UUCP "bag" files
In-Reply-To: <CAC0cEp8QS8K56YL3o2f9LLXWdSws0J_UMUD38bUZ-3i=JZF5YQ@mail.gmail.com>
References: <04c44cba-fefe-b5c6-d683-618ed3ddb0cb@spamtrap.tnetconsulting.net>
 <9D7839FC-A3EB-4211-887D-BCE67229E1D6@orthanc.ca>
 <CAC0cEp8QS8K56YL3o2f9LLXWdSws0J_UMUD38bUZ-3i=JZF5YQ@mail.gmail.com>
Message-ID: <EF997042-58AC-4212-A5EE-947F87C7EB08@orthanc.ca>


> On May 10, 2018, at 7:10 AM, John P. Linderman <jpl.jpl at gmail.com> wrote:
> 
> I asked Dave Nowitz, one of the authors of HoneyDanBer UUCP (the others being Peter Honeyman and Brian Redman) if he knew what bag files were. He said
> 
> Never heard of bag files.

We always referred to them as "rnews batches," since that's what they were.



From jpl.jpl at gmail.com  Fri May 11 10:24:18 2018
From: jpl.jpl at gmail.com (John P. Linderman)
Date: Thu, 10 May 2018 20:24:18 -0400
Subject: [TUHS] UUCP "bag" files
In-Reply-To: <EF997042-58AC-4212-A5EE-947F87C7EB08@orthanc.ca>
References: <04c44cba-fefe-b5c6-d683-618ed3ddb0cb@spamtrap.tnetconsulting.net>
 <9D7839FC-A3EB-4211-887D-BCE67229E1D6@orthanc.ca>
 <CAC0cEp8QS8K56YL3o2f9LLXWdSws0J_UMUD38bUZ-3i=JZF5YQ@mail.gmail.com>
 <EF997042-58AC-4212-A5EE-947F87C7EB08@orthanc.ca>
Message-ID: <CAC0cEp93k_RrhPQD598W-nZQSA3c8Fe81Qu1CCF=zmvjA7yuCw@mail.gmail.com>

So calling them "uucp bag files" is akin to calling something an "ed editor
file" because the ed editor was able to update them?

On Thu, May 10, 2018 at 7:38 PM, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:

>
> > On May 10, 2018, at 7:10 AM, John P. Linderman <jpl.jpl at gmail.com>
> wrote:
> >
> > I asked Dave Nowitz, one of the authors of HoneyDanBer UUCP (the others
> being Peter Honeyman and Brian Redman) if he knew what bag files were. He
> said
> >
> > Never heard of bag files.
>
> We always referred to them as "rnews batches," since that's what they were.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180510/b4efb753/attachment.html>

From imp at bsdimp.com  Fri May 11 10:35:40 2018
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 10 May 2018 18:35:40 -0600
Subject: [TUHS] Windows Notepad to support Unix line endings
In-Reply-To: <8ac8822b-e17b-4763-7d1c-3460a713183e@spamtrap.tnetconsulting.net>
References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com>
 <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net>
 <e4161f58-e8d6-4800-4195-f51344123e3f@kilonet.net>
 <alpine.BSF.2.21.999.1805110706220.79090@aneurin.horsfall.org>
 <CAC20D2Og3sa9quiBezk4H939LwKFQpwD2sPWkVijPkXZYPjPAg@mail.gmail.com>
 <8ac8822b-e17b-4763-7d1c-3460a713183e@spamtrap.tnetconsulting.net>
Message-ID: <CANCZdfpGvdUa2M5-xJQY5wjTqij6UwkojGfJDMqxTw54JAa5Aw@mail.gmail.com>

On Thu, May 10, 2018 at 4:59 PM, Grant Taylor via TUHS <tuhs at minnie.tuhs.org
> wrote:

> Very well said Clem.
>
> Linux is not Unix.
> Linux is unix.
>

Linux is not UNIX.

According to the UNIX trademark guidelines, the second one is not
permitted... :)

Note the case difference.
>
> Linux does not have the licensing to claim to be a proper Unix (clone) and
> thus the privilege to use the uppercase "U".  But (IMHO) Linux is very much
> in the unix spirit or idea.
>

There were a couple of very specific distributions of Linux that passed the
Unix licensing tests from the X/Open group years ago, but I don't know what
happened after that.


> Analogy:  A Toyota Tacoma is not a Ford Ranger (Unix) but they are both
> pickup trucks (unix).


I was going to say that Linux is a UNIX-like operating system, but The Open
Group doesn't like that either :)

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

From tytso at mit.edu  Fri May 11 11:29:45 2018
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Thu, 10 May 2018 21:29:45 -0400
Subject: [TUHS] Windows Notepad to support Unix line endings
In-Reply-To: <8ac8822b-e17b-4763-7d1c-3460a713183e@spamtrap.tnetconsulting.net>
References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com>
 <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net>
 <e4161f58-e8d6-4800-4195-f51344123e3f@kilonet.net>
 <alpine.BSF.2.21.999.1805110706220.79090@aneurin.horsfall.org>
 <CAC20D2Og3sa9quiBezk4H939LwKFQpwD2sPWkVijPkXZYPjPAg@mail.gmail.com>
 <8ac8822b-e17b-4763-7d1c-3460a713183e@spamtrap.tnetconsulting.net>
Message-ID: <20180511012945.GI8335@thunk.org>

Why does it matter?  A rose by any other name....

I will observe that people who are insisting on Linux and how it
should be named usually have some kind of agenda.  Take for example,
someone who tried to rename Linux as GNU/Linux.

For people who want to insist that Linux is not Unix; that's fine.  I
usually like to yank their chain by saying, tongue in cheek, that
sure, Linux is not Unix, but it is largely compatible with Legacy Unix
systems.  :-)

						- Ted


From davida at pobox.com  Fri May 11 12:16:26 2018
From: davida at pobox.com (David Arnold)
Date: Fri, 11 May 2018 12:16:26 +1000
Subject: [TUHS] Windows Notepad to support Unix line endings
In-Reply-To: <1cfffd7b-4490-7ebc-d892-b603d8312f9d@spamtrap.tnetconsulting.net>
References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com>
 <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net>
 <FBB7EBC3-FFAA-4DDA-915C-156D6B67B225@pobox.com>
 <1cfffd7b-4490-7ebc-d892-b603d8312f9d@spamtrap.tnetconsulting.net>
Message-ID: <303AF181-6500-4ECC-BAE8-4D839D6CB8CF@pobox.com>

The upside for me as someone who packages software for Windows is that I can have README.txt, LICENSE.txt, etc, files in the Windows package and they’ll work out of the box for people who haven’t done the reconfiguration dance you describe.

Previously, I’ve had to run unix2dos on all the text files in the Windows package.

So in a few years when I stop supporting anything older than Windows-10.whatever-this-one-is-called, I’ll be able to simplify my packaging scripts slightly.

As you say … not really worthy of the hype.



d


> On 10 May 2018, at 08:23, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
> 
> On 05/09/2018 03:57 PM, David Arnold wrote:
>> Double-click on a .txt file will invoke Notepad, unless you’ve reconfigured things.
> 
> Right-click on a .txt file
> Left-click on Open With
> Left-click on Wordpad
> (Optionally) Left-click on "always use this program…"
> 
> Sure, it's a preference change.  But it's a user level preference.
> 
> Is it nice that Notepad will now open files with unix new lines?  Sure.
> 
> Do I think it's worth some of the hype that I'm seeing?  Nope.
> 
> 
> 
> -- 
> Grant. . . .
> unix || die
> 



From gtaylor at tnetconsulting.net  Fri May 11 12:21:45 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Thu, 10 May 2018 20:21:45 -0600
Subject: [TUHS] Windows Notepad to support Unix line endings
In-Reply-To: <303AF181-6500-4ECC-BAE8-4D839D6CB8CF@pobox.com>
References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com>
 <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net>
 <FBB7EBC3-FFAA-4DDA-915C-156D6B67B225@pobox.com>
 <1cfffd7b-4490-7ebc-d892-b603d8312f9d@spamtrap.tnetconsulting.net>
 <303AF181-6500-4ECC-BAE8-4D839D6CB8CF@pobox.com>
Message-ID: <6516b7d1-b091-79f6-9712-58622a4deb41@spamtrap.tnetconsulting.net>

On 05/10/2018 08:16 PM, David Arnold wrote:
> As you say … not really worthy of the hype.

Is it a nice feature to have?  Yes.
Will it save people (like yourself) time?  Likely.

Is it worth hype (that I'm seeing)?  I don't think so.

Read:  My opinion is that Notepad's new feature is not worth the hype 
that I am seeing.

I feel like Notepad's new feature is going to impact fewer people than 
something like the Windows XP firewall being enabled by default did.



-- 
Grant. . . .
unix || die

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

From gtaylor at tnetconsulting.net  Fri May 11 13:42:56 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Thu, 10 May 2018 21:42:56 -0600
Subject: [TUHS] UUCP "bag" files
In-Reply-To: <EF997042-58AC-4212-A5EE-947F87C7EB08@orthanc.ca>
References: <04c44cba-fefe-b5c6-d683-618ed3ddb0cb@spamtrap.tnetconsulting.net>
 <9D7839FC-A3EB-4211-887D-BCE67229E1D6@orthanc.ca>
 <CAC0cEp8QS8K56YL3o2f9LLXWdSws0J_UMUD38bUZ-3i=JZF5YQ@mail.gmail.com>
 <EF997042-58AC-4212-A5EE-947F87C7EB08@orthanc.ca>
Message-ID: <3d317540-757f-7a24-941d-b8f0ced91e87@spamtrap.tnetconsulting.net>

On 05/10/2018 05:38 PM, Lyndon Nerenberg wrote:
> We always referred to them as "rnews batches," since that's what they were.

Not if there's also email / commands / files transfers in the batch.  ;-)



-- 
Grant. . . .
unix || die

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

From gtaylor at tnetconsulting.net  Fri May 11 13:51:31 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Thu, 10 May 2018 21:51:31 -0600
Subject: [TUHS] UUCP "bag" files
In-Reply-To: <CAC0cEp93k_RrhPQD598W-nZQSA3c8Fe81Qu1CCF=zmvjA7yuCw@mail.gmail.com>
References: <04c44cba-fefe-b5c6-d683-618ed3ddb0cb@spamtrap.tnetconsulting.net>
 <9D7839FC-A3EB-4211-887D-BCE67229E1D6@orthanc.ca>
 <CAC0cEp8QS8K56YL3o2f9LLXWdSws0J_UMUD38bUZ-3i=JZF5YQ@mail.gmail.com>
 <EF997042-58AC-4212-A5EE-947F87C7EB08@orthanc.ca>
 <CAC0cEp93k_RrhPQD598W-nZQSA3c8Fe81Qu1CCF=zmvjA7yuCw@mail.gmail.com>
Message-ID: <cffa9d0c-def5-90bf-b566-dd9567eaa038@spamtrap.tnetconsulting.net>

On 05/10/2018 06:24 PM, John P. Linderman wrote:
> So calling them "uucp bag files" is akin to calling something an "ed 
> editor file" because the ed editor was able to update them?

I frequently hear of something referred to as "a (Microsoft) Word 
{document,file}".

They are a bag of mail / news / remote commands / file transfers that 
are used by UUCP.

I'm not saying it's correct or not.  I'm just saying it's what I 
frequently hear them referred to as.

I was hoping that someone has some sort of authoritative information as 
to why they were called "bag".



-- 
Grant. . . .
unix || die

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

From lyndon at orthanc.ca  Fri May 11 13:58:18 2018
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Thu, 10 May 2018 20:58:18 -0700
Subject: [TUHS] UUCP "bag" files
In-Reply-To: <3d317540-757f-7a24-941d-b8f0ced91e87@spamtrap.tnetconsulting.net>
References: <04c44cba-fefe-b5c6-d683-618ed3ddb0cb@spamtrap.tnetconsulting.net>
 <9D7839FC-A3EB-4211-887D-BCE67229E1D6@orthanc.ca>
 <CAC0cEp8QS8K56YL3o2f9LLXWdSws0J_UMUD38bUZ-3i=JZF5YQ@mail.gmail.com>
 <EF997042-58AC-4212-A5EE-947F87C7EB08@orthanc.ca>
 <3d317540-757f-7a24-941d-b8f0ced91e87@spamtrap.tnetconsulting.net>
Message-ID: <AF685A3D-CD03-4FB2-B5F7-16C4CF14A477@orthanc.ca>


> On May 10, 2018, at 8:42 PM, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
> 
> On 05/10/2018 05:38 PM, Lyndon Nerenberg wrote:
>> We always referred to them as "rnews batches," since that's what they were.
> 
> Not if there's also email / commands / files transfers in the batch.  ;-)

UUCP would transfer many batch jobs in a single session, Each job was a single command.  So you would have a mix of 'uux remote!rmail' and 'uux remote!rnews' all stacked up in the job queue to be transferred and executed on the remote host.

'uucp' and 'uux' just created remote batch jobs in a queue directory.  When 'uucico' eventually fired off, it would send the command files over, along with any associated data files.

You could 'uucp' and 'uux' anything you liked, modulo restrictions placed upon you by the administrators of the local and remote hosts.

--lyndon



From gtaylor at tnetconsulting.net  Fri May 11 14:09:06 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Thu, 10 May 2018 22:09:06 -0600
Subject: [TUHS] UUCP "bag" files
In-Reply-To: <AF685A3D-CD03-4FB2-B5F7-16C4CF14A477@orthanc.ca>
References: <04c44cba-fefe-b5c6-d683-618ed3ddb0cb@spamtrap.tnetconsulting.net>
 <9D7839FC-A3EB-4211-887D-BCE67229E1D6@orthanc.ca>
 <CAC0cEp8QS8K56YL3o2f9LLXWdSws0J_UMUD38bUZ-3i=JZF5YQ@mail.gmail.com>
 <EF997042-58AC-4212-A5EE-947F87C7EB08@orthanc.ca>
 <3d317540-757f-7a24-941d-b8f0ced91e87@spamtrap.tnetconsulting.net>
 <AF685A3D-CD03-4FB2-B5F7-16C4CF14A477@orthanc.ca>
Message-ID: <5f6aa9eb-d56e-7a42-5d61-53d60ed9eefd@spamtrap.tnetconsulting.net>

On 05/10/2018 09:58 PM, Lyndon Nerenberg wrote:
> UUCP would transfer many batch jobs in a single session, Each job was 
> a single command.  So you would have a mix of 'uux remote!rmail' and 
> 'uux remote!rnews' all stacked up in the job queue to be transferred 
> and executed on the remote host.

Agreed.

Those were all discrete jobs and associated files in the UUCP queue.

It's my understanding that bag files were an aggregation / collection of 
what uucico (or something closely related) would typically write to the 
modem connected to the remote system.  This output was redirected to a 
single, monolithic file, called a bag.

At least that's my understanding.

This bag would then be transferred some means out of band.

The last time I did this, someone would periodically ftp the bag files 
off of the server.  (I don't remember why he wanted bag files instead of 
standard UUCP.)

I've heard of people using bag file(s) to put news (et al) onto a flash 
drive / tape and sneaker net it across to other disconnected systems 
where the process was done in reverse.

> 'uucp' and 'uux' just created remote batch jobs in a queue directory. 
> When 'uucico' eventually fired off, it would send the command files over, 
> along with any associated data files.

That's typical UUCP.  That's distinctly different than my understanding 
of bag files.

> You could 'uucp' and 'uux' anything you liked, modulo restrictions placed 
> upon you by the administrators of the local and remote hosts.

Yep.



-- 
Grant. . . .
unix || die

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

From lyndon at orthanc.ca  Fri May 11 14:18:23 2018
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Thu, 10 May 2018 21:18:23 -0700
Subject: [TUHS] UUCP "bag" files
In-Reply-To: <5f6aa9eb-d56e-7a42-5d61-53d60ed9eefd@spamtrap.tnetconsulting.net>
References: <04c44cba-fefe-b5c6-d683-618ed3ddb0cb@spamtrap.tnetconsulting.net>
 <9D7839FC-A3EB-4211-887D-BCE67229E1D6@orthanc.ca>
 <CAC0cEp8QS8K56YL3o2f9LLXWdSws0J_UMUD38bUZ-3i=JZF5YQ@mail.gmail.com>
 <EF997042-58AC-4212-A5EE-947F87C7EB08@orthanc.ca>
 <3d317540-757f-7a24-941d-b8f0ced91e87@spamtrap.tnetconsulting.net>
 <AF685A3D-CD03-4FB2-B5F7-16C4CF14A477@orthanc.ca>
 <5f6aa9eb-d56e-7a42-5d61-53d60ed9eefd@spamtrap.tnetconsulting.net>
Message-ID: <3FA3D7C3-CFD1-4FD3-803A-A93B2F5A6F1D@orthanc.ca>


> On May 10, 2018, at 9:09 PM, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
> 
> It's my understanding that bag files were an aggregation / collection of what uucico (or something closely related) would typically write to the modem connected to the remote system.  This output was redirected to a single, monolithic file, called a bag.

Yes, but rnews understood batching from day one.  It would have been insane to execute rnews on each and every article sent across.  (I made that mistake in a config file once; that the remote host didn't completely die was a testament to CTIX.)  That's why every news transport batched up multiple articles into a single 'uux remote!rnews' job.  This existed from at least the bnews software, and we always called them "news batches" or similar.

There were no "bags."

But there were patches to BSD's UUCP that allowed rnews batching to take place in a 'streaming' manner, avoiding the need to stack up the data files in /var/spool/uucp.  I remember applying patches to the patches running on 'alberta' (U of Alberta) that solved some backlog problems they were having with downstream sites (one of which was mine).

--lyndon



From clemc at ccc.com  Fri May 11 23:09:12 2018
From: clemc at ccc.com (Clem Cole)
Date: Fri, 11 May 2018 09:09:12 -0400
Subject: [TUHS] Windows Notepad to support Unix line endings
In-Reply-To: <20180511012945.GI8335@thunk.org>
References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com>
 <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net>
 <e4161f58-e8d6-4800-4195-f51344123e3f@kilonet.net>
 <alpine.BSF.2.21.999.1805110706220.79090@aneurin.horsfall.org>
 <CAC20D2Og3sa9quiBezk4H939LwKFQpwD2sPWkVijPkXZYPjPAg@mail.gmail.com>
 <8ac8822b-e17b-4763-7d1c-3460a713183e@spamtrap.tnetconsulting.net>
 <20180511012945.GI8335@thunk.org>
Message-ID: <CAC20D2NCVdB-77LbXh773=fyPUSEg1SyHAUW0prJog7hQ6dXVA@mail.gmail.com>

On Thu, May 10, 2018 at 9:29 PM, Theodore Y. Ts'o <tytso at mit.edu> wrote:

> Why does it matter?  A rose by any other name....
>

​Exactly...​



>
> I will observe that people who are insisting on Linux and how it
> should be named usually have some kind of agenda.  Take for example,
> someone who tried to rename Linux as GNU/Linux.
>
​You I think hit it on the head (unfortunately).




>
> For people who want to insist that Linux is not Unix; that's fine.  I
> usually like to yank their chain by saying, tongue in cheek, that
> sure, Linux is not Unix, but it is largely compatible with Legacy Unix
> systems.  :-)

​Touché​

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

From mike.ab3ap at gmail.com  Sat May 12 03:20:43 2018
From: mike.ab3ap at gmail.com (Mike Markowski)
Date: Fri, 11 May 2018 13:20:43 -0400
Subject: [TUHS] Z3 from 1941
Message-ID: <6b39276c-dcb4-3d95-10d2-8ee5cdecc58e@gmail.com>

Tomorrow, May 12, in 1941 the Z3 computer was presented by Konrad Zuse:

   https://en.wikipedia.org/wiki/Z3_(computer)

I enjoyed reading the specs at the bottom of the Wikipedia page.  I 
never heard of this project until today, coming across it an article.

Mike Markowski


From rob at robdiamond.com  Sat May 12 03:57:25 2018
From: rob at robdiamond.com (Robert Diamond)
Date: Fri, 11 May 2018 13:57:25 -0400
Subject: [TUHS] Resurrecting a PDP11
Message-ID: <4582D584-8332-43FC-83CD-DD627CB897F3@robdiamond.com>

Just thought I’d share a quick video - some folks in my office got a PDP11/34 up running Adventure under RT-11 today.
https://www.youtube.com/watch?v=U_jB23UqgCY <https://www.youtube.com/watch?v=U_jB23UqgCY>

(Sorry for vertical orientation and non-Unix-related content)

---
Robert Diamond
rob at robdiamond.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180511/c64661aa/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3862 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180511/c64661aa/attachment.bin>

From dave at horsfall.org  Sat May 12 08:21:13 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 12 May 2018 08:21:13 +1000 (EST)
Subject: [TUHS] The birth of the Z3
Message-ID: <alpine.BSF.2.21.999.1805120810571.79090@aneurin.horsfall.org>

Way back on this day in 1941, Conrad Zuse unveiled the Z3; it was the 
first programmable automatic computer as we know it (Colossus 1 was not 
general-purpose).  The last news I heard about the Z3 was that she was 
destroyed in an air-raid...

This pretty much started computing, as we know it.

-- Dave


From cym224 at gmail.com  Sat May 12 11:40:54 2018
From: cym224 at gmail.com (Nemo)
Date: Fri, 11 May 2018 21:40:54 -0400
Subject: [TUHS] Who used *ROFF?
Message-ID: <CAJfiPzzeniiZjj0z9p8Y8e==T6WJ0W1B_8iutj4uZaNVTf+iQQ@mail.gmail.com>

I have read that one of the first groups in AT&T to use early Unix was
the legal dep't, specifically to use *roff to write patent
applications.  Can anyone elaborate on this or supply references?
(This would in great contrast to today, where most applications are
written with certain products despite the USPTO, EPO, and others only
accepting PDF versions.)  It would also be interesting to learn how
the writers were taught *roff, what editors were used, and what they
thought.  (I recall that the secretaries, as they were then called, in
the math dep't used vi to compose plain TeX documents and xdvi to
proofread them.)

N.


From lyndon at orthanc.ca  Sat May 12 12:00:28 2018
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Fri, 11 May 2018 19:00:28 -0700
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <CAJfiPzzeniiZjj0z9p8Y8e==T6WJ0W1B_8iutj4uZaNVTf+iQQ@mail.gmail.com>
References: <CAJfiPzzeniiZjj0z9p8Y8e==T6WJ0W1B_8iutj4uZaNVTf+iQQ@mail.gmail.com>
Message-ID: <CBBD3ECE-2A0C-4DAE-ACD9-344FA6FC6DFF@orthanc.ca>


> On May 11, 2018, at 6:40 PM, Nemo <cym224 at gmail.com> wrote:
> 
> It would also be interesting to learn how
> the writers were taught *roff, what editors were used, and what they
> thought.  (I recall that the secretaries, as they were then called, in
> the math dep't used vi to compose plain TeX documents and xdvi to
> proofread them.)

The original AT&T patents work would have pre-dated vi and TeX, so they would have been using ed and [nt]roff I would guess.  The BSTJ is probably a good starting point for the early history.

In the mid-late 1980s I helped deploy UNIX into a court reporting company that had been using Convergent Ngen workstations to edit and proof court transcripts.  Within a couple of months we had the court reporters trained up on vi, spell, troff, etc.  They would upload their tapes from the steno machine to the UNIX server, edit and proof the documents, then typeset the results to a Postscript printer.  Those masters would then be duplicated and sent out to the customers.

Of the dozen or so reporters working there, at least three or four wrote their own troff macro packages, along with an assortment of awk scripts to help catch errors in the transcript source documents.

Today, when I hear people bitch about not having Word on their desktop, I just laugh ;-)

--lyndon



From dave at horsfall.org  Sat May 12 12:11:10 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 12 May 2018 12:11:10 +1000 (EST)
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <CBBD3ECE-2A0C-4DAE-ACD9-344FA6FC6DFF@orthanc.ca>
References: <CAJfiPzzeniiZjj0z9p8Y8e==T6WJ0W1B_8iutj4uZaNVTf+iQQ@mail.gmail.com>
 <CBBD3ECE-2A0C-4DAE-ACD9-344FA6FC6DFF@orthanc.ca>
Message-ID: <alpine.BSF.2.21.999.1805121209240.79090@aneurin.horsfall.org>

On Fri, 11 May 2018, Lyndon Nerenberg wrote:

[ ...]

> Today, when I hear people bitch about not having Word on their desktop, 
> I just laugh ;-)

We used to walk up-hill to work, both ways...

-- Dave


From lyndon at orthanc.ca  Sat May 12 12:17:26 2018
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Fri, 11 May 2018 19:17:26 -0700
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <alpine.BSF.2.21.999.1805121209240.79090@aneurin.horsfall.org>
References: <CAJfiPzzeniiZjj0z9p8Y8e==T6WJ0W1B_8iutj4uZaNVTf+iQQ@mail.gmail.com>
 <CBBD3ECE-2A0C-4DAE-ACD9-344FA6FC6DFF@orthanc.ca>
 <alpine.BSF.2.21.999.1805121209240.79090@aneurin.horsfall.org>
Message-ID: <A32F6D0F-E125-4A2A-ABC8-44E9FE170BB2@orthanc.ca>


> On May 11, 2018, at 7:11 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> We used to walk up-hill to work, both ways...

And it felt *good* :-)


From dave at horsfall.org  Sat May 12 12:54:03 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 12 May 2018 12:54:03 +1000 (EST)
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <A32F6D0F-E125-4A2A-ABC8-44E9FE170BB2@orthanc.ca>
References: <CAJfiPzzeniiZjj0z9p8Y8e==T6WJ0W1B_8iutj4uZaNVTf+iQQ@mail.gmail.com>
 <CBBD3ECE-2A0C-4DAE-ACD9-344FA6FC6DFF@orthanc.ca>
 <alpine.BSF.2.21.999.1805121209240.79090@aneurin.horsfall.org>
 <A32F6D0F-E125-4A2A-ABC8-44E9FE170BB2@orthanc.ca>
Message-ID: <alpine.BSF.2.21.999.1805121246080.79090@aneurin.horsfall.org>

On Fri, 11 May 2018, Lyndon Nerenberg wrote:

>> We used to walk up-hill to work, both ways...
>
> And it felt *good* :-)

<accent=Irish>

And you tell that to the young people of today. and they won't believe 
you.

</accent>

-- dave


From dave at horsfall.org  Sat May 12 13:19:37 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 12 May 2018 13:19:37 +1000 (EST)
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <alpine.BSF.2.21.999.1805121246080.79090@aneurin.horsfall.org>
References: <CAJfiPzzeniiZjj0z9p8Y8e==T6WJ0W1B_8iutj4uZaNVTf+iQQ@mail.gmail.com>
 <CBBD3ECE-2A0C-4DAE-ACD9-344FA6FC6DFF@orthanc.ca>
 <alpine.BSF.2.21.999.1805121209240.79090@aneurin.horsfall.org>
 <A32F6D0F-E125-4A2A-ABC8-44E9FE170BB2@orthanc.ca>
 <alpine.BSF.2.21.999.1805121246080.79090@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.21.999.1805121313070.79090@aneurin.horsfall.org>

On Sat, 12 May 2018, Dave Horsfall wrote:

> <accent=Irish>
>
> And you tell that to the young people of today. and they won't believe 
> you.

Arrgghh!  It was the four *Yorkshiremen*, of course...

-- Dave


From lyndon at orthanc.ca  Sat May 12 13:26:44 2018
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Fri, 11 May 2018 20:26:44 -0700
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <alpine.BSF.2.21.999.1805121313070.79090@aneurin.horsfall.org>
References: <CAJfiPzzeniiZjj0z9p8Y8e==T6WJ0W1B_8iutj4uZaNVTf+iQQ@mail.gmail.com>
 <CBBD3ECE-2A0C-4DAE-ACD9-344FA6FC6DFF@orthanc.ca>
 <alpine.BSF.2.21.999.1805121209240.79090@aneurin.horsfall.org>
 <A32F6D0F-E125-4A2A-ABC8-44E9FE170BB2@orthanc.ca>
 <alpine.BSF.2.21.999.1805121246080.79090@aneurin.horsfall.org>
 <alpine.BSF.2.21.999.1805121313070.79090@aneurin.horsfall.org>
Message-ID: <1B26C52C-FC3F-4D7E-BC74-47B31E868F63@orthanc.ca>

>> 
>> And you tell that to the young people of today. and they won't believe you.
> 
> Arrgghh!  It was the four *Yorkshiremen*, of course...

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

Half the Python's + Marty Feldman!

From gtaylor at tnetconsulting.net  Sat May 12 14:30:13 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Fri, 11 May 2018 22:30:13 -0600
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <CBBD3ECE-2A0C-4DAE-ACD9-344FA6FC6DFF@orthanc.ca>
References: <CAJfiPzzeniiZjj0z9p8Y8e==T6WJ0W1B_8iutj4uZaNVTf+iQQ@mail.gmail.com>
 <CBBD3ECE-2A0C-4DAE-ACD9-344FA6FC6DFF@orthanc.ca>
Message-ID: <594a8368-2b49-f184-3c35-929d6f2615d4@spamtrap.tnetconsulting.net>

On 05/11/2018 08:00 PM, Lyndon Nerenberg wrote:
> Of the dozen or so reporters working there, at least three or four wrote 
> their own troff macro packages, along with an assortment of awk scripts 
> to help catch errors in the transcript source documents.

I'll believe it.

My step mother is a court reporter and she's told me many stories about 
how she and her colleagues have created custom dictionaries, processing 
macros (in their proprietary software), and a lot of other things that 
most computer users simply don't do any more.



-- 
Grant. . . .
unix || die

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

From gtaylor at tnetconsulting.net  Sat May 12 14:39:03 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Fri, 11 May 2018 22:39:03 -0600
Subject: [TUHS] UUCP "bag" files
In-Reply-To: <3FA3D7C3-CFD1-4FD3-803A-A93B2F5A6F1D@orthanc.ca>
References: <04c44cba-fefe-b5c6-d683-618ed3ddb0cb@spamtrap.tnetconsulting.net>
 <9D7839FC-A3EB-4211-887D-BCE67229E1D6@orthanc.ca>
 <CAC0cEp8QS8K56YL3o2f9LLXWdSws0J_UMUD38bUZ-3i=JZF5YQ@mail.gmail.com>
 <EF997042-58AC-4212-A5EE-947F87C7EB08@orthanc.ca>
 <3d317540-757f-7a24-941d-b8f0ced91e87@spamtrap.tnetconsulting.net>
 <AF685A3D-CD03-4FB2-B5F7-16C4CF14A477@orthanc.ca>
 <5f6aa9eb-d56e-7a42-5d61-53d60ed9eefd@spamtrap.tnetconsulting.net>
 <3FA3D7C3-CFD1-4FD3-803A-A93B2F5A6F1D@orthanc.ca>
Message-ID: <3b2c9232-055f-af38-f94b-8c91702599f5@spamtrap.tnetconsulting.net>

On 05/10/2018 10:18 PM, Lyndon Nerenberg wrote:
> Yes, but rnews understood batching from day one.  It would have been 
> insane to execute rnews on each and every article sent across.  (I made 
> that mistake in a config file once; that the remote host didn't completely 
> die was a testament to CTIX.)  That's why every news transport batched 
> up multiple articles into a single 'uux remote!rnews' job.  This existed 
> from at least the bnews software, and we always called them "news batches" 
> or similar.

Well, I don't know what to say.  After a LOT of research, extracting old 
archives, digging through a LOT of things, I can only come to the 
conclusion that what have been called "bag" files in the circles that 
I've traveled in are in fact the output of batcher, thus standard "#! 
rnews <length>" files.

I think part of my confusion was that I was working with using UUCP at 
the same time to transport files via sneaker net using something similar 
to batcher / rnews files.  I guess I conflated the two things.

I'm sorry for the confusion.

> There were no "bags."

They might not have been a different format (like I thought) but there 
were most definitely referred to as "bag" files in the circles that I've 
traveled.

I have repeatedly found reference to them, around DNews, and being 
called "bag" files because of the ".bag" file extension that they had.

I haven't been able to find anything to indicate if the nickname came 
from the file extension or if the file extension came from the nickname.

chicken ("bag") <-> egg (.bag extension) ¯\_(ツ)_/¯

Thank you all for your input.

I'm sorry for the confusion.



-- 
Grant. . . .
unix || die

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

From dave at horsfall.org  Sat May 12 16:34:38 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 12 May 2018 16:34:38 +1000 (EST)
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <594a8368-2b49-f184-3c35-929d6f2615d4@spamtrap.tnetconsulting.net>
References: <CAJfiPzzeniiZjj0z9p8Y8e==T6WJ0W1B_8iutj4uZaNVTf+iQQ@mail.gmail.com>
 <CBBD3ECE-2A0C-4DAE-ACD9-344FA6FC6DFF@orthanc.ca>
 <594a8368-2b49-f184-3c35-929d6f2615d4@spamtrap.tnetconsulting.net>
Message-ID: <alpine.BSF.2.21.999.1805121628140.79090@aneurin.horsfall.org>

On Fri, 11 May 2018, Grant Taylor via TUHS wrote:

> My step mother is a court reporter and she's told me many stories about 
> how she and her colleagues have created custom dictionaries, processing 
> macros (in their proprietary software), and a lot of other things that 
> most computer users simply don't do any more.

A court reporter?  I knew a bird once; she was a court reporter in a 
previous life, and had short-hand for "and he said" etc...

-- Dave


From jnc at mercury.lcs.mit.edu  Sat May 12 21:01:27 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat, 12 May 2018 07:01:27 -0400 (EDT)
Subject: [TUHS] Who used *ROFF?
Message-ID: <20180512110127.0B81418C08E@mercury.lcs.mit.edu>

    > From: Nemo

    > I have read that one of the first groups in AT&T to use early Unix was
    > the legal dep't, specifically to use *roff to write patent applications.
    > Can anyone elaborate on this or supply references?

Are you familiar with the description in Dennis M. Ritchie, "The Evolution of
the Unix Time-sharing System":

  https://www.bell-labs.com/usr/dmr/www/hist.htm

(in the section "The first PDP-11 system")? Not a great deal of detail, but...

    > It would also be interesting to learn how the writers were taught *roff,
    > what editors were used

I'm pretty sure 'ed' was the only editor available at that point.

    Noel




From clemc at ccc.com  Sat May 12 21:38:47 2018
From: clemc at ccc.com (Clem cole)
Date: Sat, 12 May 2018 07:38:47 -0400
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <20180512110127.0B81418C08E@mercury.lcs.mit.edu>
References: <20180512110127.0B81418C08E@mercury.lcs.mit.edu>
Message-ID: <411A8705-100C-4A3B-99A5-A2EDD9EC6DF5@ccc.com>

Right and it was ASR37 (paper) if I’m not mistaken.  Which were upper and lower case.   I also believe that is why that’s the default terminal that original roff and nroff assumes it has. 

This is before glass tty’s where popular 

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

On May 12, 2018, at 7:01 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:

>> From: Nemo
> 
>> I have read that one of the first groups in AT&T to use early Unix was
>> the legal dep't, specifically to use *roff to write patent applications.
>> Can anyone elaborate on this or supply references?
> 
> Are you familiar with the description in Dennis M. Ritchie, "The Evolution of
> the Unix Time-sharing System":
> 
>  https://www.bell-labs.com/usr/dmr/www/hist.htm
> 
> (in the section "The first PDP-11 system")? Not a great deal of detail, but...
> 
>> It would also be interesting to learn how the writers were taught *roff,
>> what editors were used
> 
> I'm pretty sure 'ed' was the only editor available at that point.
> 
>    Noel
> 
> 


From rudi.j.blom at gmail.com  Sat May 12 21:51:58 2018
From: rudi.j.blom at gmail.com (Rudi Blom)
Date: Sat, 12 May 2018 18:51:58 +0700
Subject: [TUHS] Windows Notepad to support Unix line endings
Message-ID: <CAMYpm84HKwz1Dj-JEyd01y292RqTmiSBa9JMdj-T+8PFEPjpog@mail.gmail.com>

Hardly ever use notepad, hardly ever used notepad. Especially since I
discovered notepad++ many years ago ( https://notepad-plus-plus.org )

Of course, I use what is handy for what I'm doing. 'vim' I use when I
want to do some 'manipulation :-)


From clemc at ccc.com  Sun May 13 01:04:26 2018
From: clemc at ccc.com (Clem Cole)
Date: Sat, 12 May 2018 11:04:26 -0400
Subject: [TUHS] The birth of the Z3
In-Reply-To: <alpine.BSF.2.21.999.1805120810571.79090@aneurin.horsfall.org>
References: <alpine.BSF.2.21.999.1805120810571.79090@aneurin.horsfall.org>
Message-ID: <CAC20D2PdNM52dg8v_LJ_yF_3COocJG7afXbNd0uZhs5UEopkgA@mail.gmail.com>

On Fri, May 11, 2018 at 6:21 PM, Dave Horsfall <dave at horsfall.org> wrote:

> Way back on this day in 1941, Conrad Zuse unveiled the Z3; it was the
> first programmable automatic computer as we know it (Colossus 1 was not
> general-purpose).  The last news I heard about the Z3 was that she was
> destroyed in an air-raid...
>
> This pretty much started computing, as we know it.


​Again be careful -- we don't want to go down that rat hole.   There has
been always been an argument since it (as well as Atanasoff and Aiken's
machines all) lacks a conditional branch.    Although, I do believe some
one the UK proved the Z3 to be Turing complete; but the argument will
always be there.

What I tell people is that Babbage theorized the computational device and
Lady Ada extended the theorized to general programmability  (to play music
I believe) but it was never built and she and Babbage argued a bit about
it.   The Loom folks demonstrated that the idea programmability was
possible.   Zuse put the two idea together and reduce it practice.

But .. until we also include a conditional branch the ability to do self
modify code we don't really have the machine with think of as the automatic
programmable computer.

Check out:
http://page.mi.fu-berlin.de/rojas/1993/Who_invented_the_computer.pdf its a
fun read.

There is a nice table in it:

Machine             Memory & CPU Separated           Conditional Branching
       Soft or Hard Programming      Support Self Modify    Indirect
Addressing
Babbage                   yes
    yes                                    soft
              proposed                      no
Zuse                          yes
         no                                    soft
                        no                           no
Atanasoff                   yes
       no                                    hard
                     no                          no
Aiken Mark1              no
    no                                    soft
                  no                           no
ENIAC                       no
       partial                              hard
                   no                          no
Manchester               yes
  yes                                    soft
                   yes                        no
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180512/29879436/attachment.html>

From gtaylor at tnetconsulting.net  Sun May 13 04:56:36 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Sat, 12 May 2018 12:56:36 -0600
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <20180512110127.0B81418C08E@mercury.lcs.mit.edu>
References: <20180512110127.0B81418C08E@mercury.lcs.mit.edu>
Message-ID: <f3e8efbe-9d03-719f-cf34-e6e20cc33791@spamtrap.tnetconsulting.net>

On 05/12/2018 05:01 AM, Noel Chiappa wrote:
> Are you familiar with the description in Dennis M. Ritchie, "The Evolution 
> of the Unix Time-sharing System":
> 
>   https://www.bell-labs.com/usr/dmr/www/hist.htm

That link seems to be missing a final "l".

Link - The Evolution of the Unix Time-sharing System
  - https://www.bell-labs.com/usr/dmr/www/hist.html

Now where did I put my coffee?



-- 
Grant. . . .
unix || die

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

From rudi.j.blom at gmail.com  Sun May 13 15:55:23 2018
From: rudi.j.blom at gmail.com (Rudi Blom)
Date: Sun, 13 May 2018 12:55:23 +0700
Subject: [TUHS] Who used *ROFF?
Message-ID: <CAMYpm84tY6Ke=7KadjgBtV33giAGbTiZyxKiqR-UO=N_0saJFg@mail.gmail.com>

>From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
>To: tuhs at tuhs.org
>Cc: jnc at mercury.lcs.mit.edu
>Subject: Re: [TUHS] Who used *ROFF?
>Message-ID: <20180512110127.0B81418C08E at mercury.lcs.mit.edu>
>
 <snip>
>Are you familiar with the description in Dennis M. Ritchie, "The Evolution of
>the Unix Time-sharing System":
>
>  https://www.bell-labs.com/usr/dmr/www/hist.htm
>
<snip>

Please note the URL should end with ".html", not ".htm"

I wasted 5 minutes (insert big grin) wondering why I got an 404 like

404 Not Found
Code: NoSuchKey
Message: The specified key does not exist.
Key: hist.htm
RequestId: 454E36190753F99C
HostId: 6EJTsEdvnbnAr4VO7+mxSWH+dcX8X6AGRLZxwOLha/9q5G2CAxsVbEw6aMF+NHIPbhrAQ+/t/8o=


From grog at lemis.com  Sun May 13 16:52:04 2018
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Sun, 13 May 2018 16:52:04 +1000
Subject: [TUHS] The birth of the Z3
In-Reply-To: <CAC20D2PdNM52dg8v_LJ_yF_3COocJG7afXbNd0uZhs5UEopkgA@mail.gmail.com>
References: <alpine.BSF.2.21.999.1805120810571.79090@aneurin.horsfall.org>
 <CAC20D2PdNM52dg8v_LJ_yF_3COocJG7afXbNd0uZhs5UEopkgA@mail.gmail.com>
Message-ID: <20180513065204.GD7079@eureka.lemis.com>

On Saturday, 12 May 2018 at 11:04:26 -0400, Clem Cole wrote:
> On Fri, May 11, 2018 at 6:21 PM, Dave Horsfall <dave at horsfall.org> wrote:
>
>> Way back on this day in 1941, Conrad Zuse unveiled the Z3; it was the
>> first programmable automatic computer as we know it (Colossus 1 was not
>> general-purpose).  The last news I heard about the Z3 was that she was
>> destroyed in an air-raid...
>>
>> This pretty much started computing, as we know it.
>
> But .. until we also include a conditional branch the ability to do
> self modify code we don't really have the machine with think of as
> the automatic programmable computer.
>
> Check out:
> http://page.mi.fu-berlin.de/rojas/1993/Who_invented_the_computer.pdf its a
> fun read.

That's an interesting document, but it refers to the Z1, not the Z3.
But Wikipedia confirms that the Z3 also didn't have conditional
instructions.

Conditional branch is only one way to do that, of course.  The PDP-8,
for example, didn't have one, just (like many machines of the day)
conditional skip instructions.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180513/4fffeb86/attachment.sig>

From wkt at tuhs.org  Sun May 13 19:19:02 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 13 May 2018 19:19:02 +1000
Subject: [TUHS] Latest IOCCC Entry: PDP-7 and PDP-11 emulator
Message-ID: <20180513091902.GA15525@minnie.tuhs.org>

All, in case you haven't seen it:

	https://www.ioccc.org/2018/mills/

This is a PDP-7 emulator in C, enough to run PDP-7 Unix. But the author
has written a PDP-11 emulator in PDP-7 assembly, and uses this to run
2.9BSD on the emulated PDP-7 :-)

Cheers, Warren


From cym224 at gmail.com  Sun May 13 23:52:49 2018
From: cym224 at gmail.com (Nemo)
Date: Sun, 13 May 2018 09:52:49 -0400
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <20180512110127.0B81418C08E@mercury.lcs.mit.edu>
References: <20180512110127.0B81418C08E@mercury.lcs.mit.edu>
Message-ID: <CAJfiPzz_NJ=9C3dRuzMFXgE04s03R-XK34mAo4pFGkVSi-aTFA@mail.gmail.com>

On 12/05/2018, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> > From: Nemo
>
> > I have read that one of the first groups in AT&T to use early Unix was
> > the legal dep't, specifically to use *roff to write patent applications.
> > Can anyone elaborate on this or supply references?
>
> Are you familiar with the description in Dennis M. Ritchie, "The Evolution of
> the Unix Time-sharing System":
>
>   https://www.bell-labs.com/usr/dmr/www/hist.htm
>
> (in the section "The first PDP-11 system")? Not a great deal of detail,
> but...

Yes -- that was (is) the source that I read.  I was hoping for anecdotes
and the such from someone who was there.

> > It would also be interesting to learn how the writers were taught *roff,
> > what editors were used
>
> I'm pretty sure 'ed' was the only editor available at that point.

"Ed, man!"  #6-)

N.

>
>     Noel
>
>
>


From imp at bsdimp.com  Mon May 14 03:32:05 2018
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 13 May 2018 11:32:05 -0600
Subject: [TUHS] Latest IOCCC Entry: PDP-7 and PDP-11 emulator
In-Reply-To: <20180513091902.GA15525@minnie.tuhs.org>
References: <20180513091902.GA15525@minnie.tuhs.org>
Message-ID: <CANCZdfqJJ6-ZfMbLh9obDfh-=nNiwDX4AgXoffEK-xbcvW=FWg@mail.gmail.com>

Wow! I feel inadequate for merely trying to write a user-mode emulator in
qemu for venix...

Warner

On Sun, May 13, 2018 at 3:19 AM, Warren Toomey <wkt at tuhs.org> wrote:

> All, in case you haven't seen it:
>
>         https://www.ioccc.org/2018/mills/
>
> This is a PDP-7 emulator in C, enough to run PDP-7 Unix. But the author
> has written a PDP-11 emulator in PDP-7 assembly, and uses this to run
> 2.9BSD on the emulated PDP-7 :-)
>
> Cheers, Warren
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180513/7719ff8b/attachment.html>

From clemc at ccc.com  Mon May 14 07:07:44 2018
From: clemc at ccc.com (Clem cole)
Date: Sun, 13 May 2018 17:07:44 -0400
Subject: [TUHS] The birth of the Z3
In-Reply-To: <20180513065204.GD7079@eureka.lemis.com>
References: <alpine.BSF.2.21.999.1805120810571.79090@aneurin.horsfall.org>
 <CAC20D2PdNM52dg8v_LJ_yF_3COocJG7afXbNd0uZhs5UEopkgA@mail.gmail.com>
 <20180513065204.GD7079@eureka.lemis.com>
Message-ID: <C4B35508-D311-4413-973F-2D6176519B02@ccc.com>

Yes of course.  I used to program the 8 so I remember.  But I (sloppily) think of them the same way although you are correct they are different in implementation.  But my key point is until conditional instructions that change the path come along we are not to the general purpose computing platform.  

Their is a open question about the need to support self modifying code too.  I personally don’t think of that as important as the need for conditional instructions which I do think need to be there before you can really call it a computer.   But that’s my opinion and others clearly believe neither are needed.  

Clem

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

> On May 13, 2018, at 2:52 AM, Greg 'groggy' Lehey <grog at lemis.com> wrote:
> 
>> On Saturday, 12 May 2018 at 11:04:26 -0400, Clem Cole wrote:
>>> On Fri, May 11, 2018 at 6:21 PM, Dave Horsfall <dave at horsfall.org> wrote:
>>> 
>>> Way back on this day in 1941, Conrad Zuse unveiled the Z3; it was the
>>> first programmable automatic computer as we know it (Colossus 1 was not
>>> general-purpose).  The last news I heard about the Z3 was that she was
>>> destroyed in an air-raid...
>>> 
>>> This pretty much started computing, as we know it.
>> 
>> But .. until we also include a conditional branch the ability to do
>> self modify code we don't really have the machine with think of as
>> the automatic programmable computer.
>> 
>> Check out:
>> http://page.mi.fu-berlin.de/rojas/1993/Who_invented_the_computer.pdf its a
>> fun read.
> 
> That's an interesting document, but it refers to the Z1, not the Z3.
> But Wikipedia confirms that the Z3 also didn't have conditional
> instructions.
> 
> Conditional branch is only one way to do that, of course.  The PDP-8,
> for example, didn't have one, just (like many machines of the day)
> conditional skip instructions.
> 
> Greg
> --
> Sent from my desktop computer.
> Finger grog at lemis.com for PGP public key.
> See complete headers for address and phone numbers.
> This message is digitally signed.  If your Microsoft mail program
> reports problems, please read http://lemis.com/broken-MUA


From jnc at mercury.lcs.mit.edu  Mon May 14 07:30:42 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun, 13 May 2018 17:30:42 -0400 (EDT)
Subject: [TUHS] The birth of the Z3
Message-ID: <20180513213042.0914C18C09C@mercury.lcs.mit.edu>

    > From: Clem Cole

    > Their is a open question about the need to support self modifying code
    > too. I personally don't think of that as important as the need for
    > conditional instructions which I do think need to be there before you
    > can really call it a computer. 

Here's one way to look at it: with conditional branching, one can always
write a program to _emulate_ a machine with self-modifying code (if that's
what floats your boat, computing-wise) - because that's exactly what older,
simple microcoded machines (which don't, of course, have self-modifying code
- their programs are in ROM) do.

	Noel


From mike.ab3ap at gmail.com  Mon May 14 07:44:27 2018
From: mike.ab3ap at gmail.com (Mike Markowski)
Date: Sun, 13 May 2018 17:44:27 -0400
Subject: [TUHS] The birth of the Z3
In-Reply-To: <20180513213042.0914C18C09C@mercury.lcs.mit.edu>
References: <20180513213042.0914C18C09C@mercury.lcs.mit.edu>
Message-ID: <86258450-6c66-1a5e-c18c-392f0fd4ec8f@gmail.com>

On 05/13/2018 05:30 PM, Noel Chiappa wrote:
>      > From: Clem Cole
> 
>      > Their is a open question about the need to support self modifying code
>      > too. I personally don't think of that as important as the need for
>      > conditional instructions which I do think need to be there before you
>      > can really call it a computer.
> 
> Here's one way to look at it: with conditional branching, one can always
> write a program to _emulate_ a machine with self-modifying code (if that's
> what floats your boat, computing-wise) - because that's exactly what older,
> simple microcoded machines (which don't, of course, have self-modifying code
> - their programs are in ROM) do.
> 
> 	Noel

Rewording that, as I recall from Computability Theory there are three 
statements needed for Turing completeness:

   1. S <- 0         S is some var
   2. S <- S + 1
   3. if S=0 goto L  L is some line#

Beyond that everything else is icing on the cake.  Kind of like needing 
nothing more than a bunch of NAND gates to build a computer, 
disregarding practicality...

Mike Markowski



From dave at horsfall.org  Mon May 14 13:27:28 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 14 May 2018 13:27:28 +1000 (EST)
Subject: [TUHS] The birth of the Z3
In-Reply-To: <86258450-6c66-1a5e-c18c-392f0fd4ec8f@gmail.com>
References: <20180513213042.0914C18C09C@mercury.lcs.mit.edu>
 <86258450-6c66-1a5e-c18c-392f0fd4ec8f@gmail.com>
Message-ID: <alpine.BSF.2.21.999.1805141324410.79090@aneurin.horsfall.org>

On Sun, 13 May 2018, Mike Markowski wrote:

> Beyond that everything else is icing on the cake.  Kind of like needing 
> nothing more than a bunch of NAND gates to build a computer, 
> disregarding practicality...

Or a bunch of NOR gates, which are equivalent :-)  I'd demonstrate the 
proof here, but my TeX skills aren't up to it...

-- Dave


From doug at cs.dartmouth.edu  Mon May 14 22:19:50 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Mon, 14 May 2018 08:19:50 -0400
Subject: [TUHS] Who used *ROFF?
Message-ID: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>

Here's part of the story.

> From: "Doug McIlroy" <doug at cs.dartmouth.edu>
> To:<tuhs at minnie.tuhs.org>
> Sent:Fri, 16 Dec 2016 21:09:16 -0500
> Subject:[TUHS] How Unix made it
to the top
>
> It has often been told how the Bell Labs law department became the 
> first non-research department to use Unix, displacing a newly acquired 
> stand-alone word-processing system that fell short of the department's 
> hopes because it couldn't number the lines on patent applications, 
> as USPTO required. When Joe Ossanna heard of this, he told them about 
> nroff and promised to give it line-numbering capability the next day.  
> They tried it and were hooked. Patent secretaries became remote 
> members of the fellowship of the Unix lab. In due time the law
> department got its own machine. 

Come to think of it, they must already have had a machine, probably
leased from the commercial word-processing company, for they had DEC
tapes they needed to convert to Unix format. Several of us in the Unix
lab spent a memorable afternoon decoding the proprietary format. It was
finally broken when we computed a bitwise autocorrelation function. It
had a big peak at seven. The tapes were pure ASCII rather than bytewise
ASCII--a lot of work for very little data compression.

As for training, the secretaries had to learn nroff and ed plus the
usual lot of ls, mkdir, mv, cp, rm. The patent department had to invest
in modems and order phone lines to plug them into. I don't know what
terminals they used.

>From this distant point in time it seems that it all happened in a couple
of weeks. Joe Ossanna did most of the teaching, and no doubt supplied
samples to copy. As far as I know the only other instructional materials
would have been man pages and the nroff manual (forbiddingly terse,
though thorough). He may have made a patent-macro package, but I doubt
it; I think honor for the first real macro package goes to Lesk's -ms.

Doug


From dave at horsfall.org  Mon May 14 22:41:27 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 14 May 2018 22:41:27 +1000 (EST)
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
Message-ID: <alpine.BSF.2.21.999.1805142237130.79090@aneurin.horsfall.org>

On Mon, 14 May 2018, Doug McIlroy wrote:

> Here's part of the story.

[...]

You mentioned "nroff" a few times; would it not have been "troff" for 
their C/A/T photo-typesetter?  At least, that was the lore that I heard...

And what was "C/A/T" anyway (assuming that my memory is not failing me)?

-- Dave


From ralph at inputplus.co.uk  Mon May 14 23:00:24 2018
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Mon, 14 May 2018 14:00:24 +0100
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <alpine.BSF.2.21.999.1805142237130.79090@aneurin.horsfall.org>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.21.999.1805142237130.79090@aneurin.horsfall.org>
Message-ID: <20180514130024.E0EC0200B3@orac.inputplus.co.uk>

Hi Dave,

> Doug McIlroy wrote:
> > Here's part of the story.
>
> You mentioned "nroff" a few times; would it not have been "troff" for
> their C/A/T photo-typesetter?  At least, that was the lore that I
> heard...

The https://en.wikipedia.org/wiki/CAT_(phototypesetter) came later, and
with it the need to support more complex devices than nroff, `new roff'.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From lm at mcvoy.com  Tue May 15 00:34:53 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 14 May 2018 07:34:53 -0700
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
Message-ID: <20180514143453.GA26148@mcvoy.com>

On Mon, May 14, 2018 at 08:19:50AM -0400, Doug McIlroy wrote:
> though thorough). He may have made a patent-macro package, but I doubt
> it; I think honor for the first real macro package goes to Lesk's -ms.

And still, all these years later, my macro package of choice (tried the
others, I like -ms best).


From clemc at ccc.com  Tue May 15 00:45:42 2018
From: clemc at ccc.com (Clem cole)
Date: Mon, 14 May 2018 10:45:42 -0400
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <alpine.BSF.2.21.999.1805142237130.79090@aneurin.horsfall.org>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.21.999.1805142237130.79090@aneurin.horsfall.org>
Message-ID: <F6DADFE5-62B0-4312-9668-90FD45AF1CC6@ccc.com>

Runoff from other systems begat Unix roff.   Which begat new roff - aka  nroff.  both assume an ASR 37 as the output device.  When the first typesetter was procured typesetter roff aka troff, was born which assumes the C/A/T as the output device (which is a binary format).    This is also were typesetter C comes from.   Note these are 3 separate and different programs although nroff and troff mostly take the same input language.  These were included in V5/6/7 IIRC 



When newer typesetters were obtained and after the death of troff’s author,  Brian rewrote the nroff/troff package to create ditroff- device independent typesetter roff which also could support ASCII output nroff style

This version was released independently of the OS and took a separate license.   

Ditroff was reimplemented by Clark (IIRC) to create today’s groff which takes mostly a superset of the ditroff input language.  

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

> On May 14, 2018, at 8:41 AM, Dave Horsfall <dave at horsfall.org> wrote:
> 
>> On Mon, 14 May 2018, Doug McIlroy wrote:
>> 
>> Here's part of the story.
> 
> [...]
> 
> You mentioned "nroff" a few times; would it not have been "troff" for their C/A/T photo-typesetter?  At least, that was the lore that I heard...
> 
> And what was "C/A/T" anyway (assuming that my memory is not failing me)?
> 
> -- Dave


From clemc at ccc.com  Tue May 15 00:46:27 2018
From: clemc at ccc.com (Clem cole)
Date: Mon, 14 May 2018 10:46:27 -0400
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <20180514143453.GA26148@mcvoy.com>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <20180514143453.GA26148@mcvoy.com>
Message-ID: <1EC7822E-816F-45FB-8A15-3A051515E39A@ccc.com>

+1

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

> On May 14, 2018, at 10:34 AM, Larry McVoy <lm at mcvoy.com> wrote:
> 
>> On Mon, May 14, 2018 at 08:19:50AM -0400, Doug McIlroy wrote:
>> though thorough). He may have made a patent-macro package, but I doubt
>> it; I think honor for the first real macro package goes to Lesk's -ms.
> 
> And still, all these years later, my macro package of choice (tried the
> others, I like -ms best).


From lm at mcvoy.com  Tue May 15 01:04:31 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 14 May 2018 08:04:31 -0700
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <F6DADFE5-62B0-4312-9668-90FD45AF1CC6@ccc.com>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.21.999.1805142237130.79090@aneurin.horsfall.org>
 <F6DADFE5-62B0-4312-9668-90FD45AF1CC6@ccc.com>
Message-ID: <20180514150431.GB26148@mcvoy.com>

> Ditroff was reimplemented by Clark (IIRC) to create today???s groff which takes mostly a superset of the ditroff input language.  

Yep.  In early C++ which I found questionable but he made it work.

One of the superset things is something I got him to do in pic, the
'i'th construct.  This chunk of pic:

	for i = 1 to units by 1 do {
		line <-> dashed from `i'th [].C.s - (.10, 0) to \
		    last box.nw + (i/(units+1)*w, 0)
	}

is part of the code that produces this:

	http://www.mcvoy.com/lm/sunbox.pdf

and I could change "units" and have more or less machines.  That's a diagram
of the first cluster that Sun shipped, code named sunbox, shipped as
SparcCluster I.  My baby, never went anywhere, but my product marketing
guy came up to me about a decade later, after Google was a thing, and
said "I guess you were right about that clustering idea" :)

Source for the diagram is here:

	http://www.mcvoy.com/lm/pic/sunbox.pic

Traditional troff can't handle that unless someone backported the 'i'th
construct (which is obvious, right?).

--lm


From clemc at ccc.com  Tue May 15 01:04:36 2018
From: clemc at ccc.com (Clem cole)
Date: Mon, 14 May 2018 11:04:36 -0400
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <F6DADFE5-62B0-4312-9668-90FD45AF1CC6@ccc.com>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.21.999.1805142237130.79090@aneurin.horsfall.org>
 <F6DADFE5-62B0-4312-9668-90FD45AF1CC6@ccc.com>
Message-ID: <6447802C-34AD-4F73-ACBC-8C14D9500306@ccc.com>

Thinking about this typesetter C may have been later with ditroff.  

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

> On May 14, 2018, at 10:45 AM, Clem cole <clemc at ccc.com> wrote:
> 
> Runoff from other systems begat Unix roff.   Which begat new roff - aka  nroff.  both assume an ASR 37 as the output device.  When the first typesetter was procured typesetter roff aka troff, was born which assumes the C/A/T as the output device (which is a binary format).    This is also were typesetter C comes from.   Note these are 3 separate and different programs although nroff and troff mostly take the same input language.  These were included in V5/6/7 IIRC 
> 
> 
> 
> When newer typesetters were obtained and after the death of troff’s author,  Brian rewrote the nroff/troff package to create ditroff- device independent typesetter roff which also could support ASCII output nroff style
> 
> This version was released independently of the OS and took a separate license.   
> 
> Ditroff was reimplemented by Clark (IIRC) to create today’s groff which takes mostly a superset of the ditroff input language.  
> 
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
> 
>>> On May 14, 2018, at 8:41 AM, Dave Horsfall <dave at horsfall.org> wrote:
>>> 
>>> On Mon, 14 May 2018, Doug McIlroy wrote:
>>> 
>>> Here's part of the story.
>> 
>> [...]
>> 
>> You mentioned "nroff" a few times; would it not have been "troff" for their C/A/T photo-typesetter?  At least, that was the lore that I heard...
>> 
>> And what was "C/A/T" anyway (assuming that my memory is not failing me)?
>> 
>> -- Dave


From arnold at skeeve.com  Tue May 15 01:10:23 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 14 May 2018 09:10:23 -0600
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
Message-ID: <201805141510.w4EFANsG002686@freefriends.org>

Hi.

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

> From this distant point in time it seems that it all happened in a couple
> of weeks. Joe Ossanna did most of the teaching, and no doubt supplied
> samples to copy. As far as I know the only other instructional materials
> would have been man pages and the nroff manual (forbiddingly terse,
> though thorough). He may have made a patent-macro package, but I doubt
> it; I think honor for the first real macro package goes to Lesk's -ms.

Wouldn't the -man macros have predated -ms?

Agreed, -man isn't for full-fledged "regular" documents and papers, but
in terms of removing the need for low-level *roff markup, it certainly
does the job.

(Of course, that may be what you meant by saying "the first *real* macro
package ...")

Thanks!

Arnold


From lm at mcvoy.com  Tue May 15 01:11:34 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 14 May 2018 08:11:34 -0700
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <20180514150431.GB26148@mcvoy.com>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.21.999.1805142237130.79090@aneurin.horsfall.org>
 <F6DADFE5-62B0-4312-9668-90FD45AF1CC6@ccc.com>
 <20180514150431.GB26148@mcvoy.com>
Message-ID: <20180514151134.GC26148@mcvoy.com>

BTW, I still find pic really useful, I use it to lay out stuff because
you can draw stuff to scale.  I've used it to lay out my shop, furniture
I've built, where I trenched ethernet, etc.  The fact that you can scale
the picture means you can do stuff in inches or feet or whatever you like,
scale it to fit on a page, get it the way you want and then read off the
real life dimensions.

I don't know of any other tool that lets you do drawings like that, they
are all point and click which I find far less useful.  I like pic because
you can (well I can) look at the code and see the picture.  I find that
very elegant.

At UWisc we had something called xfig that spit out pic but it was really
crappy pic, useless to edit.  Does anyone know of anything that is like
that that spits out pic that you could read?  Or a similar tool?  Or is
pic still the best?

On Mon, May 14, 2018 at 08:04:31AM -0700, Larry McVoy wrote:
> > Ditroff was reimplemented by Clark (IIRC) to create today???s groff which takes mostly a superset of the ditroff input language.  
> 
> Yep.  In early C++ which I found questionable but he made it work.
> 
> One of the superset things is something I got him to do in pic, the
> 'i'th construct.  This chunk of pic:
> 
> 	for i = 1 to units by 1 do {
> 		line <-> dashed from `i'th [].C.s - (.10, 0) to \
> 		    last box.nw + (i/(units+1)*w, 0)
> 	}
> 
> is part of the code that produces this:
> 
> 	http://www.mcvoy.com/lm/sunbox.pdf
> 
> and I could change "units" and have more or less machines.  That's a diagram
> of the first cluster that Sun shipped, code named sunbox, shipped as
> SparcCluster I.  My baby, never went anywhere, but my product marketing
> guy came up to me about a decade later, after Google was a thing, and
> said "I guess you were right about that clustering idea" :)
> 
> Source for the diagram is here:
> 
> 	http://www.mcvoy.com/lm/pic/sunbox.pic
> 
> Traditional troff can't handle that unless someone backported the 'i'th
> construct (which is obvious, right?).
> 
> --lm

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


From jon at fourwinds.com  Tue May 15 01:21:26 2018
From: jon at fourwinds.com (Jon Steinhart)
Date: Mon, 14 May 2018 08:21:26 -0700
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <20180514151134.GC26148@mcvoy.com>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.21.999.1805142237130.79090@aneurin.horsfall.org>
 <F6DADFE5-62B0-4312-9668-90FD45AF1CC6@ccc.com>
 <20180514150431.GB26148@mcvoy.com> <20180514151134.GC26148@mcvoy.com>
Message-ID: <201805141521.w4EFLQK8025059@darkstar.fourwinds.com>

Larry McVoy writes:
> BTW, I still find pic really useful, ...

I use pic all the time.  One of the things that I find most useful, which
is unfortunately not supported by things like xfig, is invisible elements.
I draw most complicated pictures by constructing scaffold of invisible items
and hanging the visible items onto it.  That way, if I start running out of
space I can just shrink the scaffold.  Sure beats having to rescale piles of
elements and then move them around in WYSIWYG packages.

Also, as part of the book project, I have a script that I've written that
converts the original troff source into OpenOffice XHTML since my publisher
won't do troff.  Not a serious script as it just looks for macro names, it
doesn't expand and interpret all of the low-level requests.  But, part of
the script extracts pic images into separate files, runs them through groff,
converts the output to PDF, converts that to SVG, runs it through inkscape
in batch mode to crop excess whitespace from the image, and then imports it
into the OpenOffice documents.  Of course, while SVG is the only vector
graphics format that OpenOffic supports, it makes a mess of it and converts
it to bitmaps internally.  But, it works with the publisher's production
toolchain as they can work on the SVG images separately.

Once again, a testament to "little languages" and "composable tools".

Jon


From arnold at skeeve.com  Tue May 15 01:33:50 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 14 May 2018 09:33:50 -0600
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <6447802C-34AD-4F73-ACBC-8C14D9500306@ccc.com>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.21.999.1805142237130.79090@aneurin.horsfall.org>
 <F6DADFE5-62B0-4312-9668-90FD45AF1CC6@ccc.com>
 <6447802C-34AD-4F73-ACBC-8C14D9500306@ccc.com>
Message-ID: <201805141533.w4EFXohE005568@freefriends.org>

You may be right. It seems to be shortly after the '78 release of V7.
For the full story on ditroff, see Brian's papers on it at
http://www.cs.princeton.edu/~bwk/202/index.html .  They are fascinating
(and fun!) reading.

Arnold

Clem cole <clemc at ccc.com> wrote:

> Thinking about this typesetter C may have been later with ditroff.  
>
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
>
> > On May 14, 2018, at 10:45 AM, Clem cole <clemc at ccc.com> wrote:
> > 
> > Runoff from other systems begat Unix roff.   Which begat new roff - aka  nroff.  both assume an ASR 37 as the output device.  When the first typesetter was procured typesetter roff aka troff, was born which assumes the C/A/T as the output device (which is a binary format).    This is also were typesetter C comes from.   Note these are 3 separate and different programs although nroff and troff mostly take the same input language.  These were included in V5/6/7 IIRC 
> > 
> > 
> > 
> > When newer typesetters were obtained and after the death of troff???s author,  Brian rewrote the nroff/troff package to create ditroff- device independent typesetter roff which also could support ASCII output nroff style
> > 
> > This version was released independently of the OS and took a separate license.   
> > 
> > Ditroff was reimplemented by Clark (IIRC) to create today???s groff which takes mostly a superset of the ditroff input language.  
> > 
> > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
> > 
> >>> On May 14, 2018, at 8:41 AM, Dave Horsfall <dave at horsfall.org> wrote:
> >>> 
> >>> On Mon, 14 May 2018, Doug McIlroy wrote:
> >>> 
> >>> Here's part of the story.
> >> 
> >> [...]
> >> 
> >> You mentioned "nroff" a few times; would it not have been "troff" for their C/A/T photo-typesetter?  At least, that was the lore that I heard...
> >> 
> >> And what was "C/A/T" anyway (assuming that my memory is not failing me)?
> >> 
> >> -- Dave


From lm at mcvoy.com  Tue May 15 01:46:41 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 14 May 2018 08:46:41 -0700
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <201805141521.w4EFLQK8025059@darkstar.fourwinds.com>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.21.999.1805142237130.79090@aneurin.horsfall.org>
 <F6DADFE5-62B0-4312-9668-90FD45AF1CC6@ccc.com>
 <20180514150431.GB26148@mcvoy.com>
 <20180514151134.GC26148@mcvoy.com>
 <201805141521.w4EFLQK8025059@darkstar.fourwinds.com>
Message-ID: <20180514154641.GE26148@mcvoy.com>

+1 

You should share your scripts, I've done similar stuff and other people
have sometimes found it useful.

I do the same thing with the invis stuff, super handy.

On Mon, May 14, 2018 at 08:21:26AM -0700, Jon Steinhart wrote:
> Larry McVoy writes:
> > BTW, I still find pic really useful, ...
> 
> I use pic all the time.  One of the things that I find most useful, which
> is unfortunately not supported by things like xfig, is invisible elements.
> I draw most complicated pictures by constructing scaffold of invisible items
> and hanging the visible items onto it.  That way, if I start running out of
> space I can just shrink the scaffold.  Sure beats having to rescale piles of
> elements and then move them around in WYSIWYG packages.
> 
> Also, as part of the book project, I have a script that I've written that
> converts the original troff source into OpenOffice XHTML since my publisher
> won't do troff.  Not a serious script as it just looks for macro names, it
> doesn't expand and interpret all of the low-level requests.  But, part of
> the script extracts pic images into separate files, runs them through groff,
> converts the output to PDF, converts that to SVG, runs it through inkscape
> in batch mode to crop excess whitespace from the image, and then imports it
> into the OpenOffice documents.  Of course, while SVG is the only vector
> graphics format that OpenOffic supports, it makes a mess of it and converts
> it to bitmaps internally.  But, it works with the publisher's production
> toolchain as they can work on the SVG images separately.
> 
> Once again, a testament to "little languages" and "composable tools".
> 
> Jon

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


From jon at fourwinds.com  Tue May 15 01:57:43 2018
From: jon at fourwinds.com (Jon Steinhart)
Date: Mon, 14 May 2018 08:57:43 -0700
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <20180514154641.GE26148@mcvoy.com>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.21.999.1805142237130.79090@aneurin.horsfall.org>
 <F6DADFE5-62B0-4312-9668-90FD45AF1CC6@ccc.com>
 <20180514150431.GB26148@mcvoy.com> <20180514151134.GC26148@mcvoy.com>
 <201805141521.w4EFLQK8025059@darkstar.fourwinds.com>
 <20180514154641.GE26148@mcvoy.com>
Message-ID: <201805141557.w4EFvhXI030104@darkstar.fourwinds.com>

Larry McVoy writes:
> +1 
>
> You should share your scripts, I've done similar stuff and other people
> have sometimes found it useful.
>
> I do the same thing with the invis stuff, super handy.

Well, they're all one-offs so not sure hoe generally useful they are.
Oh, one more great thing about pic is the ease at which other programs
can generate it; I do that a lot when a picture is produced from a pile
of data.


From jnc at mercury.lcs.mit.edu  Tue May 15 01:58:10 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 14 May 2018 11:58:10 -0400 (EDT)
Subject: [TUHS] Who used *ROFF?
Message-ID: <20180514155810.32B6918C0A4@mercury.lcs.mit.edu>

    > From: Clem cole

    > Thinking about this typesetter C may have been later with ditroff.

Not so sure about that; we had that C at MIT, but only regular troff (which
had been hacked to drive a Varian).

    > From: Arnold Skeeve

    > It seems to be shortly after the '78 release of V7.

No, typesetter C definitely pre-dated V7. The 'PWB1' system at MIT had the new
C.

Looking at the documentation files for the extension (e.g. addition of
'long's), none of them have dates in them (alas), but my hard-copy printout of
one is dated "May 8 1978", and it was several years old at that point.

(Also, several sources give '79 for V7 - Salus says 'June 1979').

       Noel


From ralph at inputplus.co.uk  Tue May 15 02:37:59 2018
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Mon, 14 May 2018 17:37:59 +0100
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <F6DADFE5-62B0-4312-9668-90FD45AF1CC6@ccc.com>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.21.999.1805142237130.79090@aneurin.horsfall.org>
 <F6DADFE5-62B0-4312-9668-90FD45AF1CC6@ccc.com>
Message-ID: <20180514163759.57317200B3@orac.inputplus.co.uk>

Hi Clem,

> This is also were typesetter C comes from.

What's that?

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From cym224 at gmail.com  Tue May 15 02:41:48 2018
From: cym224 at gmail.com (Nemo Nusquam)
Date: Mon, 14 May 2018 12:41:48 -0400
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <201805141521.w4EFLQK8025059@darkstar.fourwinds.com>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.21.999.1805142237130.79090@aneurin.horsfall.org>
 <F6DADFE5-62B0-4312-9668-90FD45AF1CC6@ccc.com>
 <20180514150431.GB26148@mcvoy.com> <20180514151134.GC26148@mcvoy.com>
 <201805141521.w4EFLQK8025059@darkstar.fourwinds.com>
Message-ID: <402237b0-3ea0-db27-1670-a2e9db94e197@gmail.com>

On 05/14/18 11:21, Jon Steinhart wrote (in part):
> Also, as part of the book project, I have a script that I've written that
> converts the original troff source into OpenOffice XHTML since my publisher
> won't do troff.

I am curious about PHI.  Tannenbaum praises troff in his prefaces (and 
says that all his books are written in troff).  Not much on the PHI website.

N.


From imp at bsdimp.com  Tue May 15 02:54:01 2018
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 14 May 2018 10:54:01 -0600
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <20180514155810.32B6918C0A4@mercury.lcs.mit.edu>
References: <20180514155810.32B6918C0A4@mercury.lcs.mit.edu>
Message-ID: <CANCZdfpw74=rKPBy5rdHryy9LQzMkyX57ELxrgjCghb43oGf7w@mail.gmail.com>

On Mon, May 14, 2018 at 9:58 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Clem cole
>
>     > Thinking about this typesetter C may have been later with ditroff.
>
> Not so sure about that; we had that C at MIT, but only regular troff (which
> had been hacked to drive a Varian).
>
>     > From: Arnold Skeeve
>
>     > It seems to be shortly after the '78 release of V7.
>
> No, typesetter C definitely pre-dated V7. The 'PWB1' system at MIT had the
> new
> C.
>
> Looking at the documentation files for the extension (e.g. addition of
> 'long's), none of them have dates in them (alas), but my hard-copy
> printout of
> one is dated "May 8 1978", and it was several years old at that point.
>
> (Also, several sources give '79 for V7 - Salus says 'June 1979').
>

The kernels in the release tapes from TUHS are dated June 8, 1979. They are
the latest dated files in the archives (apart maybe from a few directories).

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

From jnc at mercury.lcs.mit.edu  Tue May 15 03:13:24 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 14 May 2018 13:13:24 -0400 (EDT)
Subject: [TUHS] Who used *ROFF?
Message-ID: <20180514171324.ED41C18C0A9@mercury.lcs.mit.edu>

    > From: Ralph Corderoy <ralph at inputplus.co.uk>

    >> This is also were typesetter C comes from.

    > What's that?

An evolution of C past the fairly early version in V6, but prior
to V7. Reputedly the name comes from extensions done for doing troff.
See:

  http://ana-3.lcs.mit.edu/~jnc/history/unix/CChanges.txt
  http://ana-3.lcs.mit.edu/~jnc/history/unix/COChanges.txt

for some historical documentation.

	Noel


From arnold at skeeve.com  Tue May 15 04:13:06 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 14 May 2018 12:13:06 -0600
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <402237b0-3ea0-db27-1670-a2e9db94e197@gmail.com>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.21.999.1805142237130.79090@aneurin.horsfall.org>
 <F6DADFE5-62B0-4312-9668-90FD45AF1CC6@ccc.com>
 <20180514150431.GB26148@mcvoy.com> <20180514151134.GC26148@mcvoy.com>
 <201805141521.w4EFLQK8025059@darkstar.fourwinds.com>
 <402237b0-3ea0-db27-1670-a2e9db94e197@gmail.com>
Message-ID: <201805141813.w4EID65f027854@freefriends.org>

Nemo Nusquam <cym224 at gmail.com> wrote:

> On 05/14/18 11:21, Jon Steinhart wrote (in part):
> > Also, as part of the book project, I have a script that I've written that
> > converts the original troff source into OpenOffice XHTML since my publisher
> > won't do troff.
>
> I am curious about PHI.  Tannenbaum praises troff in his prefaces (and 
> says that all his books are written in troff).  Not much on the PHI website.
>
> N.

This is getting off-topic.  Prentice Hall (Pearson) generally works with
Word but they are able to make allowance for other formats. For sure TeX,
and they can work with troff if the author wants to provide the "camera
ready copy" themselves (see, for example, Brian's book on Go, done with
groff).

I wrote my PH book in Texinfo and the converted it to DocBook XML; they
used a contractor to actually go from there to typesettable copy.

Arnold


From jon at fourwinds.com  Tue May 15 04:18:48 2018
From: jon at fourwinds.com (Jon Steinhart)
Date: Mon, 14 May 2018 11:18:48 -0700
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <201805141813.w4EID65f027854@freefriends.org>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.21.999.1805142237130.79090@aneurin.horsfall.org>
 <F6DADFE5-62B0-4312-9668-90FD45AF1CC6@ccc.com>
 <20180514150431.GB26148@mcvoy.com> <20180514151134.GC26148@mcvoy.com>
 <201805141521.w4EFLQK8025059@darkstar.fourwinds.com>
 <402237b0-3ea0-db27-1670-a2e9db94e197@gmail.com>
 <201805141813.w4EID65f027854@freefriends.org>
Message-ID: <201805141818.w4EIImT0016471@darkstar.fourwinds.com>

arnold at skeeve.com writes:
> Nemo Nusquam <cym224 at gmail.com> wrote:
>
> > On 05/14/18 11:21, Jon Steinhart wrote (in part):
> > > Also, as part of the book project, I have a script that I've written that
> > > converts the original troff source into OpenOffice XHTML since my publisher
> > > won't do troff.
> >
> > I am curious about PHI.  Tannenbaum praises troff in his prefaces (and 
> > says that all his books are written in troff).  Not much on the PHI website.
> >
> > N.
>
> This is getting off-topic.  Prentice Hall (Pearson) generally works with
> Word but they are able to make allowance for other formats. For sure TeX,
> and they can work with troff if the author wants to provide the "camera
> ready copy" themselves (see, for example, Brian's book on Go, done with
> groff).
>
> I wrote my PH book in Texinfo and the converted it to DocBook XML; they
> used a contractor to actually go from there to typesettable copy.
>
> Arnold

Well, this issue, at least in my case, isn't troff per-se.  It's that editors
and such want to be able to read test, make comments in the margins, and track
changes.  I would claim that troff, tex, et. al. are great tools for people
who write stuff and shepherd it to publication which is great for specs and
technical papers and all that.  What's lacking is tools for the involvement
of third-parties such as editors.

Jon


From lm at mcvoy.com  Tue May 15 04:25:37 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 14 May 2018 11:25:37 -0700
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <201805141818.w4EIImT0016471@darkstar.fourwinds.com>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.21.999.1805142237130.79090@aneurin.horsfall.org>
 <F6DADFE5-62B0-4312-9668-90FD45AF1CC6@ccc.com>
 <20180514150431.GB26148@mcvoy.com>
 <20180514151134.GC26148@mcvoy.com>
 <201805141521.w4EFLQK8025059@darkstar.fourwinds.com>
 <402237b0-3ea0-db27-1670-a2e9db94e197@gmail.com>
 <201805141813.w4EID65f027854@freefriends.org>
 <201805141818.w4EIImT0016471@darkstar.fourwinds.com>
Message-ID: <20180514182537.GI26148@mcvoy.com>

On Mon, May 14, 2018 at 11:18:48AM -0700, Jon Steinhart wrote:
> arnold at skeeve.com writes:
> > Nemo Nusquam <cym224 at gmail.com> wrote:
> >
> > > On 05/14/18 11:21, Jon Steinhart wrote (in part):
> > > > Also, as part of the book project, I have a script that I've written that
> > > > converts the original troff source into OpenOffice XHTML since my publisher
> > > > won't do troff.
> > >
> > > I am curious about PHI.  Tannenbaum praises troff in his prefaces (and 
> > > says that all his books are written in troff).  Not much on the PHI website.
> > >
> > > N.
> >
> > This is getting off-topic.  Prentice Hall (Pearson) generally works with
> > Word but they are able to make allowance for other formats. For sure TeX,
> > and they can work with troff if the author wants to provide the "camera
> > ready copy" themselves (see, for example, Brian's book on Go, done with
> > groff).
> >
> > I wrote my PH book in Texinfo and the converted it to DocBook XML; they
> > used a contractor to actually go from there to typesettable copy.
> >
> > Arnold
> 
> Well, this issue, at least in my case, isn't troff per-se.  It's that editors
> and such want to be able to read test, make comments in the margins, and track
> changes.  I would claim that troff, tex, et. al. are great tools for people
> who write stuff and shepherd it to publication which is great for specs and
> technical papers and all that.  What's lacking is tools for the involvement
> of third-parties such as editors.

I've successfully used troff to write our commercial contract.
I collaborated with a guy at Fenwick&West, taught him enough troff -ms
that he could make changes.  We sourced 6 different contracts from one doc
and the lawyer *loved* that, he really wanted that fuctionality in Word.


From imp at bsdimp.com  Tue May 15 04:33:20 2018
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 14 May 2018 12:33:20 -0600
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <20180514182537.GI26148@mcvoy.com>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.21.999.1805142237130.79090@aneurin.horsfall.org>
 <F6DADFE5-62B0-4312-9668-90FD45AF1CC6@ccc.com>
 <20180514150431.GB26148@mcvoy.com>
 <20180514151134.GC26148@mcvoy.com>
 <201805141521.w4EFLQK8025059@darkstar.fourwinds.com>
 <402237b0-3ea0-db27-1670-a2e9db94e197@gmail.com>
 <201805141813.w4EID65f027854@freefriends.org>
 <201805141818.w4EIImT0016471@darkstar.fourwinds.com>
 <20180514182537.GI26148@mcvoy.com>
Message-ID: <CANCZdfoaKy-v0Dg9GPx7kYd4qkv_xxC_UjDMiAU017cDqjhLJQ@mail.gmail.com>

>
> I've successfully used troff to write our commercial contract.
> I collaborated with a guy at Fenwick&West, taught him enough troff -ms
> that he could make changes.  We sourced 6 different contracts from one doc
> and the lawyer *loved* that, he really wanted that fuctionality in Word.
>

I may need to start doing that for the routine leases I do for some rental
property I own. I lamely just do some word fill in the blank things now,
but I may have to switch :)

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

From dave at horsfall.org  Tue May 15 07:02:23 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 15 May 2018 07:02:23 +1000 (EST)
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <20180514143453.GA26148@mcvoy.com>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <20180514143453.GA26148@mcvoy.com>
Message-ID: <alpine.BSF.2.21.999.1805150649120.79090@aneurin.horsfall.org>

On Mon, 14 May 2018, Larry McVoy wrote:

> And still, all these years later, my macro package of choice (tried the 
> others, I like -ms best).

I had a boss once who demanded that we learn -mm; for some reason I still 
preferred -ms, as it somehow seemed more "natural", and I still use it to 
this day (well, when I'm not using the Mac, that is).

I used to joke that the only way that I'll write in -mm is if I was paid 
to do so :-)  And it won't be cheap...

-- Dave


From clemc at ccc.com  Tue May 15 07:31:21 2018
From: clemc at ccc.com (Clem Cole)
Date: Mon, 14 May 2018 17:31:21 -0400
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <20180514171324.ED41C18C0A9@mercury.lcs.mit.edu>
References: <20180514171324.ED41C18C0A9@mercury.lcs.mit.edu>
Message-ID: <CAC20D2NsQAZQzOq1PM2w19TBJ584Zu0ic1RjkE_jvSsWviXKkQ@mail.gmail.com>

On Mon, May 14, 2018 at 1:13 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Ralph Corderoy <ralph at inputplus.co.uk>
>
>     >> This is also were typesetter C comes from.
>
>     > What's that?
>
> An evolution of C past the fairly early version in V6, but prior
> to V7. Reputedly the name comes from extensions done for doing troff.
>

​Right -- what gets a little messy is that you need to understand the
*roff, the C compiler and the base OS were all being changed and released
in parallel of each other.   How different features made it into the wild
was not linear.

I mentioned the roff to nroff to troff to ditroff stream earlier today.
What I do not remember is the independent troff releases.   I think I
remember that there was an early troff that went out independent of one of
the kernels.  The problem is that like Noel I know we had it at CMU and
UCB, but I do not remember its provenance.   As Noel points out, few of us
outside of Bell Labs had C/A/T typesetters.   But there was  C/A/T
typesetter emulator for the Versatec and Variam plotters called 'vcat'
which converted the typesetter codes into pixels for the plotter and used
the 'Hershey Fonts' which were the first generally available bit maps
around at I believe 200 dpi [this was originally distributed in an early
USENIX tape IICR and later came out as part of 2 or 3 BSD -- I believe Tom
Ferrin at UCSF had his hand in its creation].

As Noel and I have talk about in the past, V6 beget PWB 1.0 - the former
from MH and the later out of Whippany IIRC - and there are some small
difference in the kernels.  Ken and Dennis​ continued there kernel work at
MH and a number of kernel changes were done by them that were substantial
from V6 -- this kernel is generally called the UNIX/TS kernel.

There was never an official UNIX/TS release, but it `leaked' from MH
primarily by the AT&T employees on their OYOC year [One Year On Campus - or
some times One Year in California ;-)    For instance Ted brought it to us
at CMU and Noel and team had that kernel at MIT.      UNIX/TS would become
the basis of the kernel that went out in V7; with a number of other
additions and changes.

Dennis and Steve of course were working on changes to the language.   These
compilers would come out inside of AT&T as needed but we less available
directly to the rest of us.   Again how they made it outside was sometimes
a tad random.   Sometime, I want to say 1976-77 time frame Dennis and Brian
were also writing the 'White Book' - aka K&R [again I saw a xerographic
draft that Ted had at the time and wishes it had been around a few years
earlier].   Please remember that until the publishing of K&R there was not
stdio in the language (v6 had the portable C library a precursor and there
were some others).

As I said, the typesetter (troff) support was available independent of the
OS at one point for V6 (and inside the Bell System PWB 1.0).    K&R had not
yet been published but that version of troff needed stdio, IIRC.  So as
part of the package, the version of the Ritchie Compiler that could compile
it was included in the distribution by AT&T.   This version was >>close<<
to the C that would be come out in V7 but not 100% the same compiler.
Hence it is referred to as 'typesetter C.'

A versions of ditroff would be released that did not include the C
compiler, because by that point the language was wide spread.

What I do not remember is which version of troff was included in the
original 'typesetter' distribution.   I want to say it was troff not
ditroff, but I have forgotten.

Clem

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

From clemc at ccc.com  Tue May 15 07:35:37 2018
From: clemc at ccc.com (Clem Cole)
Date: Mon, 14 May 2018 17:35:37 -0400
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <E1C949A7-2E2E-4668-9763-F6CE52ECA002@xs4all.nl>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.21.999.1805142237130.79090@aneurin.horsfall.org>
 <F6DADFE5-62B0-4312-9668-90FD45AF1CC6@ccc.com>
 <6447802C-34AD-4F73-ACBC-8C14D9500306@ccc.com>
 <E1C949A7-2E2E-4668-9763-F6CE52ECA002@xs4all.nl>
Message-ID: <CAC20D2OLxw7XcMyfWazHW4MEHvodHBKpmM2fokjgGx=gopJEWw@mail.gmail.com>

On Mon, May 14, 2018 at 5:32 PM, Jaap Akkerhuis <jaapna at xs4all.nl> wrote:

>
>
> Thinking about this typesetter C may have been later with ditroff.
>
>
> No.
>
> What I remember, there was first roff written in assembler.  It was
> then rewrittn into C (but now with real macro capabilities.  roff
> has a lt build in), Typesetter C appeared in Edition 6.1 (of 6.2)
> since the n/troff code demanded a lot from the C-compiler.  To make
> it possible to run it on a pdp11 there was the hack turning data
> into test (for the hyphenation tables).  Ditroff was done by bwk
> to be devie independent.
>
> Regards,
>
> jaap
>
> ​Thanks -- this make sense and it the piece that I could not remember.  ​

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

From jaapna at xs4all.nl  Tue May 15 07:32:42 2018
From: jaapna at xs4all.nl (Jaap Akkerhuis)
Date: Mon, 14 May 2018 22:32:42 +0100
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <6447802C-34AD-4F73-ACBC-8C14D9500306@ccc.com>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.21.999.1805142237130.79090@aneurin.horsfall.org>
 <F6DADFE5-62B0-4312-9668-90FD45AF1CC6@ccc.com>
 <6447802C-34AD-4F73-ACBC-8C14D9500306@ccc.com>
Message-ID: <E1C949A7-2E2E-4668-9763-F6CE52ECA002@xs4all.nl>



> Thinking about this typesetter C may have been later with ditroff.


No.

What I remember, there was first roff written in assembler.  It was
then rewrittn into C (but now with real macro capabilities.  roff
has a lt build in), Typesetter C appeared in Edition 6.1 (of 6.2)
since the n/troff code demanded a lot from the C-compiler.  To make
it possible to run it on a pdp11 there was the hack turning data
into test (for the hyphenation tables).  Ditroff was done by bwk
to be devie independent.

Regards,

	jaap

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180514/175d6014/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: Message signed with OpenPGP
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180514/175d6014/attachment.sig>

From dave at horsfall.org  Tue May 15 09:04:38 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 15 May 2018 09:04:38 +1000 (EST)
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <alpine.BSF.2.21.999.1805142237130.79090@aneurin.horsfall.org>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.21.999.1805142237130.79090@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.21.999.1805150901160.79090@aneurin.horsfall.org>

On Mon, 14 May 2018, Dave Horsfall wrote:

> And what was "C/A/T" anyway (assuming that my memory is not failing me)?

Wow!  What a beautiful machine...  Now I understand the "four fonts" 
stuff.

Thanks, all.

-- Dave


From ron at ronnatalie.com  Tue May 15 09:42:24 2018
From: ron at ronnatalie.com (Ron Natalie)
Date: Mon, 14 May 2018 19:42:24 -0400
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <alpine.BSF.2.21.999.1805142237130.79090@aneurin.horsfall.org>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.21.999.1805142237130.79090@aneurin.horsfall.org>
Message-ID: <01c701d3ebdd$36b88b00$a429a100$@ronnatalie.com>

CAT = Computer Assisted Typesetter.   It was built by a company called
Graphic Systems (GSI).    It was the original device troff was done for.
Many of the original troff limitations go to the fact it was driving this
device:  there are only four fonts.   These are held on film strips on a
drum.   Not the most sophisticated font system, but ahead of its time.   It
had only been on the market for two years when the labs got it and wrote
troff.

I believe the one we had access to (and used for the previously mentioned
versatec emulation) was at the Naval Research Laboratory.




From dave at horsfall.org  Tue May 15 11:21:22 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 15 May 2018 11:21:22 +1000 (EST)
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <20180512110127.0B81418C08E@mercury.lcs.mit.edu>
References: <20180512110127.0B81418C08E@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.21.999.1805151115220.79090@aneurin.horsfall.org>

On Sat, 12 May 2018, Noel Chiappa wrote:

> I'm pretty sure 'ed' was the only editor available at that point.

I boss I used to work for insisted that we all learn "ed", because one day 
it might be the only editor available to you; well, one day he was right, 
when /usr on a client's box got creamed after a head crash...

-- Dave


From lyndon at orthanc.ca  Tue May 15 11:32:12 2018
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Mon, 14 May 2018 18:32:12 -0700
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <alpine.BSF.2.21.999.1805151115220.79090@aneurin.horsfall.org>
References: <20180512110127.0B81418C08E@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.999.1805151115220.79090@aneurin.horsfall.org>
Message-ID: <4521D159-F19A-479C-9D5A-B1FFDAE658C4@orthanc.ca>


> On May 14, 2018, at 6:21 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> I boss I used to work for insisted that we all learn "ed", because one day it might be the only editor available to you; well, one day he was right, when /usr on a client's box got creamed after a head crash...

What I always find odd is the bunch moaning about ed(1) being obsolete, obtuse, and hard to learn, tend to have a healthy stock of sed(1) scripts they ran hourly if not more often.

From bakul at bitblocks.com  Tue May 15 12:06:02 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Mon, 14 May 2018 19:06:02 -0700
Subject: [TUHS] Who used *ROFF?
In-Reply-To: Your message of "Tue, 15 May 2018 11:21:22 +1000."
 <alpine.BSF.2.21.999.1805151115220.79090@aneurin.horsfall.org>
References: <20180512110127.0B81418C08E@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.999.1805151115220.79090@aneurin.horsfall.org>
Message-ID: <20180515020611.5A16F156E7DB@mail.bitblocks.com>

On Tue, 15 May 2018 11:21:22 +1000 Dave Horsfall <dave at horsfall.org> wrote:
Dave Horsfall writes:
> On Sat, 12 May 2018, Noel Chiappa wrote:
> 
> > I'm pretty sure 'ed' was the only editor available at that point.
> 
> I boss I used to work for insisted that we all learn "ed", because one day 
> it might be the only editor available to you; well, one day he was right, 
> when /usr on a client's box got creamed after a head crash...

Your boss must've been an optimist.

I once had to rescue a system where the root dir block was
lost.  No ed.  Luckily our bootrom had commands for peek/poke
& disk block IO.  The v7 filesystem layout was simple enough
and I remembered enough of it that I was able to patch it
enough to bring it up and run fsck.


From jon at fourwinds.com  Tue May 15 12:22:58 2018
From: jon at fourwinds.com (Jon Steinhart)
Date: Mon, 14 May 2018 19:22:58 -0700
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <20180515020611.5A16F156E7DB@mail.bitblocks.com>
References: <20180512110127.0B81418C08E@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.999.1805151115220.79090@aneurin.horsfall.org>
 <20180515020611.5A16F156E7DB@mail.bitblocks.com>
Message-ID: <201805150222.w4F2Mwnn004038@darkstar.fourwinds.com>

Bakul Shah writes:
> On Tue, 15 May 2018 11:21:22 +1000 Dave Horsfall <dave at horsfall.org> wrote:
> Dave Horsfall writes:
> > On Sat, 12 May 2018, Noel Chiappa wrote:
> > 
> > > I'm pretty sure 'ed' was the only editor available at that point.
> > 
> > I boss I used to work for insisted that we all learn "ed", because one day 
> > it might be the only editor available to you; well, one day he was right, 
> > when /usr on a client's box got creamed after a head crash...
>
> Your boss must've been an optimist.
>
> I once had to rescue a system where the root dir block was
> lost.  No ed.  Luckily our bootrom had commands for peek/poke
> & disk block IO.  The v7 filesystem layout was simple enough
> and I remembered enough of it that I was able to patch it
> enough to bring it up and run fsck.

If we're gonna get into "when I was young" stories we need to get
back to repairing filesystems from the front panel switches.


From lyndon at orthanc.ca  Tue May 15 12:27:26 2018
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Mon, 14 May 2018 19:27:26 -0700
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <201805150222.w4F2Mwnn004038@darkstar.fourwinds.com>
References: <20180512110127.0B81418C08E@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.999.1805151115220.79090@aneurin.horsfall.org>
 <20180515020611.5A16F156E7DB@mail.bitblocks.com>
 <201805150222.w4F2Mwnn004038@darkstar.fourwinds.com>
Message-ID: <6200BC9B-57F4-4221-BFAC-A7494A3A3277@orthanc.ca>


> On May 14, 2018, at 7:22 PM, Jon Steinhart <jon at fourwinds.com> wrote:
> 
> If we're gonna get into "when I was young" stories we need to get
> back to repairing filesystems from the front panel switches.

s/repairing/entering/



From lm at mcvoy.com  Tue May 15 12:45:32 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 14 May 2018 19:45:32 -0700
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <6200BC9B-57F4-4221-BFAC-A7494A3A3277@orthanc.ca>
References: <20180512110127.0B81418C08E@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.999.1805151115220.79090@aneurin.horsfall.org>
 <20180515020611.5A16F156E7DB@mail.bitblocks.com>
 <201805150222.w4F2Mwnn004038@darkstar.fourwinds.com>
 <6200BC9B-57F4-4221-BFAC-A7494A3A3277@orthanc.ca>
Message-ID: <20180515024532.GG26148@mcvoy.com>

On Mon, May 14, 2018 at 07:27:26PM -0700, Lyndon Nerenberg wrote:
> 
> > On May 14, 2018, at 7:22 PM, Jon Steinhart <jon at fourwinds.com> wrote:
> > 
> > If we're gonna get into "when I was young" stories we need to get
> > back to repairing filesystems from the front panel switches.
> 
> s/repairing/entering/

I watched Neil Lincoln do that on an ETA-10.  Really did, though it wasn't
fsck, it was just the boot sequence.
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From dave at horsfall.org  Tue May 15 14:51:06 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 15 May 2018 14:51:06 +1000 (EST)
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <20180515024532.GG26148@mcvoy.com>
References: <20180512110127.0B81418C08E@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.999.1805151115220.79090@aneurin.horsfall.org>
 <20180515020611.5A16F156E7DB@mail.bitblocks.com>
 <201805150222.w4F2Mwnn004038@darkstar.fourwinds.com>
 <6200BC9B-57F4-4221-BFAC-A7494A3A3277@orthanc.ca>
 <20180515024532.GG26148@mcvoy.com>
Message-ID: <alpine.BSF.2.21.999.1805151449310.79090@aneurin.horsfall.org>

On Mon, 14 May 2018, Larry McVoy wrote:

> I watched Neil Lincoln do that on an ETA-10.  Really did, though it 
> wasn't fsck, it was just the boot sequence.

We had to do that on the Cyber 72 all the time, on its "dead start" panel.

-- Dave


From jaapna at xs4all.nl  Tue May 15 20:28:05 2018
From: jaapna at xs4all.nl (Jaap Akkerhuis)
Date: Tue, 15 May 2018 11:28:05 +0100
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <6200BC9B-57F4-4221-BFAC-A7494A3A3277@orthanc.ca>
References: <20180512110127.0B81418C08E@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.999.1805151115220.79090@aneurin.horsfall.org>
 <20180515020611.5A16F156E7DB@mail.bitblocks.com>
 <201805150222.w4F2Mwnn004038@darkstar.fourwinds.com>
 <6200BC9B-57F4-4221-BFAC-A7494A3A3277@orthanc.ca>
Message-ID: <68021D24-BCD4-4C2F-AF01-4E7E084AB56B@xs4all.nl>



> On May 15, 2018, at 3:27, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:
> 
> 
>> On May 14, 2018, at 7:22 PM, Jon Steinhart <jon at fourwinds.com> wrote:
>> 
>> If we're gonna get into "when I was young" stories we need to get
>> back to repairing filesystems from the front panel switches.
> 
> s/repairing/entering/

Early unixes had dsw: Delete by SWitch register.

	jaap



From ron at ronnatalie.com  Tue May 15 22:11:48 2018
From: ron at ronnatalie.com (Ron Natalie)
Date: Tue, 15 May 2018 08:11:48 -0400
Subject: [TUHS] Good ol' ed (Was *ROFF)
Message-ID: <01e701d3ec45$e7211580$b5634080$@ronnatalie.com>

I never really learned VI.   I can stumbled through it in ex mode if I have
to.   If there's no EMACS on the UNIX system I'm using, I use ed.
You get real good at regular expressions.    Some of my employees were
pretty amazed at how fast I could make code changes with just ed.




From doug at cs.dartmouth.edu  Tue May 15 22:20:15 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Tue, 15 May 2018 08:20:15 -0400
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <20180514143453.GA26148@mcvoy.com>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <20180514143453.GA26148@mcvoy.com>
Message-ID: <201805151220.w4FCKFXn002220@coolidge.cs.Dartmouth.EDU>

Me too.

Larry McVoy wrote:

> On Mon, May 14, 2018 at 08:19:50AM -0400, Doug McIlroy wrote:
>> I think honor for the first real macro package goes to Lesk's -ms.
>
> And still, all these years later, my macro package of choice (tried the
> others, I like -ms best).


From doug at cs.dartmouth.edu  Tue May 15 22:52:03 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Tue, 15 May 2018 08:52:03 -0400
Subject: [TUHS] Who used *ROFF?
Message-ID: <201805151252.w4FCq3Fx002374@coolidge.cs.Dartmouth.EDU>


> Wouldn't the -man macros have predated -ms?

Indeed. My error. 

The original -man package was quite weak. It got a major face
lift for v7 and once more at v9 or so. And further man-page
packages are still duking it out today. -ms has lots of rivals,
too, but its continued popularity attests to Mike Lesk's fine
sense of design.

Doug


From clemc at ccc.com  Tue May 15 23:40:02 2018
From: clemc at ccc.com (Clem Cole)
Date: Tue, 15 May 2018 09:40:02 -0400
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <201805151252.w4FCq3Fx002374@coolidge.cs.Dartmouth.EDU>
References: <201805151252.w4FCq3Fx002374@coolidge.cs.Dartmouth.EDU>
Message-ID: <CAC20D2M5-krMuR-EK=EyufUwjtLJTZeucfByknCFbD3qy5jqpg@mail.gmail.com>

On Tue, May 15, 2018 at 8:52 AM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:

>
> > Wouldn't the -man macros have predated -ms?
>
> Indeed. My error.

​You tell me, but I always understood/was lead to believe, they were
related i.e. -man and -ms​ took from each other. Don't Lesk have his hand
in both?



>
>
> The original -man package was quite weak. It got a major face
> lift for v7 and once more at v9 or so. And further man-page
> packages are still duking it out today. -ms has lots of rivals,
> too, but its continued popularity attests to Mike Lesk's fine
> sense of design.
>
​Amen...​

​It's always been the most straight forward of any I have known.

We added a few Macro's to it for some books, but pretty much used it as it
is for basic documents.   Janet Egan, Steve Talbot and someone else who's
name I've forgotten, wrote a wonderful "Masscomp Style Guide" for all the
books - I still have my copy.   Tim took it with him when he created
O'Reilly.   All of the original 'NutShell' books and the set that got the
O'Reilly empire started (the X11 stuff) was all Masscomp superset of -ms.

Clem

​
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180515/08dae8a9/attachment.html>

From cym224 at gmail.com  Wed May 16 00:07:39 2018
From: cym224 at gmail.com (Nemo)
Date: Tue, 15 May 2018 10:07:39 -0400
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <alpine.BSF.2.21.999.1805150649120.79090@aneurin.horsfall.org>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <20180514143453.GA26148@mcvoy.com>
 <alpine.BSF.2.21.999.1805150649120.79090@aneurin.horsfall.org>
Message-ID: <CAJfiPzy0x1owguLm2wJXn78hCNeFq62N8b1tYT-SmWcSZriAZQ@mail.gmail.com>

On 14/05/2018, Dave Horsfall <dave at horsfall.org> wrote (in part):
> I had a boss once who demanded that we learn -mm; for some reason I still
> preferred -ms, as it somehow seemed more "natural", and I still use it to
> this day (well, when I'm not using the Mac, that is).

Why not? The Mac has it: /usr/share/groff/1.19.2/tmac/s.tmac


From arnold at skeeve.com  Wed May 16 00:17:38 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 15 May 2018 08:17:38 -0600
Subject: [TUHS] Good ol' ed (Was *ROFF)
In-Reply-To: <01e701d3ec45$e7211580$b5634080$@ronnatalie.com>
References: <01e701d3ec45$e7211580$b5634080$@ronnatalie.com>
Message-ID: <201805151417.w4FEHcIF009897@freefriends.org>

"Ron Natalie" <ron at ronnatalie.com> wrote:

> I never really learned VI.   I can stumbled through it in ex mode if I have
> to.   If there's no EMACS on the UNIX system I'm using, I use ed.
> You get real good at regular expressions.    Some of my employees were
> pretty amazed at how fast I could make code changes with just ed.

I did learn vi, after having learned ed first.  I drop down to the ex
command line for major regexp-based surgery too.  I also get the amazement
from co-workers who watch me do stuff. :-)  This is particularly true
of the, er, younger coworkers (kids today ... :-) who can't manage
outside an IDE.

Arnold


From arnold at skeeve.com  Wed May 16 00:18:29 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 15 May 2018 08:18:29 -0600
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <201805151252.w4FCq3Fx002374@coolidge.cs.Dartmouth.EDU>
References: <201805151252.w4FCq3Fx002374@coolidge.cs.Dartmouth.EDU>
Message-ID: <201805151418.w4FEITFb009960@freefriends.org>

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

> > Wouldn't the -man macros have predated -ms?
>
> Indeed. My error. 
>
> The original -man package was quite weak. It got a major face
> lift for v7 and once more at v9 or so. And further man-page
> packages are still duking it out today. -ms has lots of rivals,
> too, but its continued popularity attests to Mike Lesk's fine
> sense of design.
>
> Doug

OK, much thanks.

I like -ms, but if I was going to write a book with nested lists
and so on, I'd use -mm.

Arnold


From arnold at skeeve.com  Wed May 16 00:23:34 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 15 May 2018 08:23:34 -0600
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <CAC20D2M5-krMuR-EK=EyufUwjtLJTZeucfByknCFbD3qy5jqpg@mail.gmail.com>
References: <201805151252.w4FCq3Fx002374@coolidge.cs.Dartmouth.EDU>
 <CAC20D2M5-krMuR-EK=EyufUwjtLJTZeucfByknCFbD3qy5jqpg@mail.gmail.com>
Message-ID: <201805151423.w4FENYlQ010613@freefriends.org>

Clem Cole <clemc at ccc.com> wrote:

> We added a few Macro's to it for some books, but pretty much used it as it
> is for basic documents.   Janet Egan, Steve Talbot and someone else who's
> name I've forgotten, wrote a wonderful "Masscomp Style Guide" for all the
> books - I still have my copy.   Tim took it with him when he created
> O'Reilly.   All of the original 'NutShell' books and the set that got the
> O'Reilly empire started (the X11 stuff) was all Masscomp superset of -ms.

They were still using this circa 1997; I did the update of sed&awk in
troff, but by then O'Reilly had switched to DocBook. They converted
the book to DocBook, but actually printed it by running it through
some hairy perl scripts that turned it *back* into troff -ms + their
additional macros!

It was a mess, but eventually the book got printed.

As an aside, they still use DocBook, but with a more rational printing
engine. Nevertheless, something simple like:

	short	Text text text text
		Text text text text

	long item here
		Text text text text
		Text text text text

which troff handled with ease takes a lot of tweaking and style sheets
and Heaven-knows-what-else to do in DocBook. Bleah.

Arnold


From lm at mcvoy.com  Wed May 16 00:37:52 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 15 May 2018 07:37:52 -0700
Subject: [TUHS] Good ol' ed (Was *ROFF)
In-Reply-To: <201805151417.w4FEHcIF009897@freefriends.org>
References: <01e701d3ec45$e7211580$b5634080$@ronnatalie.com>
 <201805151417.w4FEHcIF009897@freefriends.org>
Message-ID: <20180515143752.GA7115@mcvoy.com>

On Tue, May 15, 2018 at 08:17:38AM -0600, arnold at skeeve.com wrote:
> "Ron Natalie" <ron at ronnatalie.com> wrote:
> 
> > I never really learned VI.   I can stumbled through it in ex mode if I have
> > to.   If there's no EMACS on the UNIX system I'm using, I use ed.
> > You get real good at regular expressions.    Some of my employees were
> > pretty amazed at how fast I could make code changes with just ed.
> 
> I did learn vi, after having learned ed first.  I drop down to the ex
> command line for major regexp-based surgery too.  I also get the amazement
> from co-workers who watch me do stuff. :-)  This is particularly true
> of the, er, younger coworkers (kids today ... :-) who can't manage
> outside an IDE.

In fairness to them, I don't know how you learn the good stuff outside
of a terminal room.  I learned so much by watching the screen change
and going "WTF?  How did you do that?"

There is only so much you can stuff into a manual.
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From crossd at gmail.com  Wed May 16 00:37:53 2018
From: crossd at gmail.com (Dan Cross)
Date: Tue, 15 May 2018 10:37:53 -0400
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <CAJfiPzy0x1owguLm2wJXn78hCNeFq62N8b1tYT-SmWcSZriAZQ@mail.gmail.com>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <20180514143453.GA26148@mcvoy.com>
 <alpine.BSF.2.21.999.1805150649120.79090@aneurin.horsfall.org>
 <CAJfiPzy0x1owguLm2wJXn78hCNeFq62N8b1tYT-SmWcSZriAZQ@mail.gmail.com>
Message-ID: <CAEoi9W5FYaRn9YsLiysnmbt5DfnQnfRQ1576He+wi-rw2ypx2g@mail.gmail.com>

On Tue, May 15, 2018 at 10:07 AM, Nemo <cym224 at gmail.com> wrote:
> On 14/05/2018, Dave Horsfall <dave at horsfall.org> wrote (in part):
> > I had a boss once who demanded that we learn -mm; for some reason I
still
> > preferred -ms, as it somehow seemed more "natural", and I still use it
to
> > this day (well, when I'm not using the Mac, that is).
>
> Why not? The Mac has it: /usr/share/groff/1.19.2/tmac/s.tmac

I have some vague distant memory of a commercial Unix variant that came
with troff and the -mm macros, but without -ms. I can't remember which it
was (or if I'm just imagining things). Anyone have any ideas?

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

From clemc at ccc.com  Wed May 16 00:47:57 2018
From: clemc at ccc.com (Clem cole)
Date: Tue, 15 May 2018 10:47:57 -0400
Subject: [TUHS] Good ol' ed (Was *ROFF)
In-Reply-To: <20180515143752.GA7115@mcvoy.com>
References: <01e701d3ec45$e7211580$b5634080$@ronnatalie.com>
 <201805151417.w4FEHcIF009897@freefriends.org>
 <20180515143752.GA7115@mcvoy.com>
Message-ID: <F6D4D841-93B0-4D4A-B2CC-7FB9D2FC95E4@ccc.com>

Yeah.  We lost that and it was a good thing.  Programming became a operation between you and your computer in the privacy of your own office. 

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

> On May 15, 2018, at 10:37 AM, Larry McVoy <lm at mcvoy.com> wrote:
> 
>> On Tue, May 15, 2018 at 08:17:38AM -0600, arnold at skeeve.com wrote:
>> "Ron Natalie" <ron at ronnatalie.com> wrote:
>> 
>>> I never really learned VI.   I can stumbled through it in ex mode if I have
>>> to.   If there's no EMACS on the UNIX system I'm using, I use ed.
>>> You get real good at regular expressions.    Some of my employees were
>>> pretty amazed at how fast I could make code changes with just ed.
>> 
>> I did learn vi, after having learned ed first.  I drop down to the ex
>> command line for major regexp-based surgery too.  I also get the amazement
>> from co-workers who watch me do stuff. :-)  This is particularly true
>> of the, er, younger coworkers (kids today ... :-) who can't manage
>> outside an IDE.
> 
> In fairness to them, I don't know how you learn the good stuff outside
> of a terminal room.  I learned so much by watching the screen change
> and going "WTF?  How did you do that?"
> 
> There is only so much you can stuff into a manual.
> -- 
> ---
> Larry McVoy                     lm at mcvoy.com             http://www.mcvoy.com/lm 


From clemc at ccc.com  Wed May 16 00:55:24 2018
From: clemc at ccc.com (Clem cole)
Date: Tue, 15 May 2018 10:55:24 -0400
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <CAEoi9W5FYaRn9YsLiysnmbt5DfnQnfRQ1576He+wi-rw2ypx2g@mail.gmail.com>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <20180514143453.GA26148@mcvoy.com>
 <alpine.BSF.2.21.999.1805150649120.79090@aneurin.horsfall.org>
 <CAJfiPzy0x1owguLm2wJXn78hCNeFq62N8b1tYT-SmWcSZriAZQ@mail.gmail.com>
 <CAEoi9W5FYaRn9YsLiysnmbt5DfnQnfRQ1576He+wi-rw2ypx2g@mail.gmail.com>
Message-ID: <C92734BB-E8EA-448E-852F-7B9A68B9850B@ccc.com>

The PWB children used -mm  I seem to remember that the base system 3 and maybe the original sysv did not include it since troff was not apart. If you pulled from BSD or ditroff; you got it.    

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

> On May 15, 2018, at 10:37 AM, Dan Cross <crossd at gmail.com> wrote:
> 
> On Tue, May 15, 2018 at 10:07 AM, Nemo <cym224 at gmail.com> wrote:
> > On 14/05/2018, Dave Horsfall <dave at horsfall.org> wrote (in part):
> > > I had a boss once who demanded that we learn -mm; for some reason I still
> > > preferred -ms, as it somehow seemed more "natural", and I still use it to
> > > this day (well, when I'm not using the Mac, that is).
> >
> > Why not? The Mac has it: /usr/share/groff/1.19.2/tmac/s.tmac
> 
> I have some vague distant memory of a commercial Unix variant that came with troff and the -mm macros, but without -ms. I can't remember which it was (or if I'm just imagining things). Anyone have any ideas?
> 
>         - Dan C.
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180515/a555fcb5/attachment.html>

From lm at mcvoy.com  Wed May 16 00:59:38 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 15 May 2018 07:59:38 -0700
Subject: [TUHS] PWB - what is the history?
In-Reply-To: <C92734BB-E8EA-448E-852F-7B9A68B9850B@ccc.com>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <20180514143453.GA26148@mcvoy.com>
 <alpine.BSF.2.21.999.1805150649120.79090@aneurin.horsfall.org>
 <CAJfiPzy0x1owguLm2wJXn78hCNeFq62N8b1tYT-SmWcSZriAZQ@mail.gmail.com>
 <CAEoi9W5FYaRn9YsLiysnmbt5DfnQnfRQ1576He+wi-rw2ypx2g@mail.gmail.com>
 <C92734BB-E8EA-448E-852F-7B9A68B9850B@ccc.com>
Message-ID: <20180515145938.GC7879@mcvoy.com>

So what's the back story with PWB?  It seems like sort of a back water
but as I recall, they had some interesting stuff.  I feel like there 
was a "learn" command and another one that tried to tell you about
common grammer (english, not yacc) problems in your prose.  So far
as I know, those didn't make it into the mainstream, or if they did,
they were weak reimplementations that didn't work as well as the
originals.

On Tue, May 15, 2018 at 10:55:24AM -0400, Clem cole wrote:
> The PWB children used -mm  I seem to remember that the base system 3 and maybe the original sysv did not include it since troff was not apart. If you pulled from BSD or ditroff; you got it.    
> 
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
> 
> > On May 15, 2018, at 10:37 AM, Dan Cross <crossd at gmail.com> wrote:
> > 
> > On Tue, May 15, 2018 at 10:07 AM, Nemo <cym224 at gmail.com> wrote:
> > > On 14/05/2018, Dave Horsfall <dave at horsfall.org> wrote (in part):
> > > > I had a boss once who demanded that we learn -mm; for some reason I still
> > > > preferred -ms, as it somehow seemed more "natural", and I still use it to
> > > > this day (well, when I'm not using the Mac, that is).
> > >
> > > Why not? The Mac has it: /usr/share/groff/1.19.2/tmac/s.tmac
> > 
> > I have some vague distant memory of a commercial Unix variant that came with troff and the -mm macros, but without -ms. I can't remember which it was (or if I'm just imagining things). Anyone have any ideas?
> > 
> >         - Dan C.
> > 

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


From crossd at gmail.com  Wed May 16 01:10:07 2018
From: crossd at gmail.com (Dan Cross)
Date: Tue, 15 May 2018 11:10:07 -0400
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <C92734BB-E8EA-448E-852F-7B9A68B9850B@ccc.com>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <20180514143453.GA26148@mcvoy.com>
 <alpine.BSF.2.21.999.1805150649120.79090@aneurin.horsfall.org>
 <CAJfiPzy0x1owguLm2wJXn78hCNeFq62N8b1tYT-SmWcSZriAZQ@mail.gmail.com>
 <CAEoi9W5FYaRn9YsLiysnmbt5DfnQnfRQ1576He+wi-rw2ypx2g@mail.gmail.com>
 <C92734BB-E8EA-448E-852F-7B9A68B9850B@ccc.com>
Message-ID: <CAEoi9W4JQt1T=JZ5G=i4zcxSKVF+aZxA+=Y5xmENmqPTMxZq=w@mail.gmail.com>

On Tue, May 15, 2018 at 10:55 AM, Clem cole <clemc at ccc.com> wrote:
> On May 15, 2018, at 10:37 AM, Dan Cross <crossd at gmail.com> wrote:
> > On Tue, May 15, 2018 at 10:07 AM, Nemo <cym224 at gmail.com> wrote:
> > > On 14/05/2018, Dave Horsfall <dave at horsfall.org> wrote (in part):
> > > > I had a boss once who demanded that we learn -mm; for some reason I
still
> > > > preferred -ms, as it somehow seemed more "natural", and I still use
it to
> > > > this day (well, when I'm not using the Mac, that is).
> > >
> > > Why not? The Mac has it: /usr/share/groff/1.19.2/tmac/s.tmac
> >
> > I have some vague distant memory of a commercial Unix variant that came
with troff and the -mm macros, but without -ms. I can't remember which it
was (or if I'm just imagining things). Anyone have any ideas?
>
> The PWB children used -mm  I seem to remember that the base system 3 and
maybe the original sysv did not include it since troff was not apart. If
you pulled from BSD or ditroff; you got it.

Maybe that's what it was. Let's see, System V's I have known and loathed[*]:

AIX on RT and RS/6k, Irix, HP-UX, UNISYS, Solaris 2.x for x in 2-5; perhaps
others that I can't recall now.

Perhaps it was one of them? For some reason, AIX is sticking out in my head
as not having the full compliment of troff macros as supplied by BSD
distributions. Something *definitely* didn't come with -me, though I can't
recall what now.

        - Dan C.

[*] "Loathed" is entirely too strong of a word, but in the enthusiasm of
first exposure combined with the headiness (read: ignorance) of youth, it
was easy to fall prey to the tribalism of the pro-BSD people on my campus;
the response was less rational and more emotional. That said, we've covered
in great depth on this list how Solaris 2.x, in particular, was rushed to
market too early; attempts at conversion from SunOS 4.x were fraught and
that left a bad taste for some time. Like wanting to wear the same jacket
as a rock star, wanting to run the same software as one's idols was an
attempt to gather some amount of cachet that was unwarranted. But just as
the music I listened to when I was 8 years old was dramatically different
than the music that I liked at 13, which is still somewhat removed from
that which I listen to most often now (though curiously there is much more
continuity there), I find that I wouldn't really want to go back to SunOS 4
on a SPARCstation 1, let alone 4.3BSD on a VAX, even with a relatively nice
HP or DEC terminal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180515/21497d29/attachment.html>

From imp at bsdimp.com  Wed May 16 01:12:00 2018
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 15 May 2018 09:12:00 -0600
Subject: [TUHS] Good ol' ed (Was *ROFF)
In-Reply-To: <F6D4D841-93B0-4D4A-B2CC-7FB9D2FC95E4@ccc.com>
References: <01e701d3ec45$e7211580$b5634080$@ronnatalie.com>
 <201805151417.w4FEHcIF009897@freefriends.org>
 <20180515143752.GA7115@mcvoy.com>
 <F6D4D841-93B0-4D4A-B2CC-7FB9D2FC95E4@ccc.com>
Message-ID: <CANCZdfpzyP-ntUW-FgZ26FpdN_Yp3C5QoMF8Be0TOT1-_B6B7w@mail.gmail.com>

Lord knows I learned Unix by watching my peers type it...

In the long run that was both good and bad, though, since now all I get to
see people type are shell scripts which range from brilliant to rubbish...
The only way to know where on that spectrum things are is to read a bunch
of them... and to get burned a few times stealing the techniques that are
best described, in hindsight, as "it seemed like a good idea at the time."

Warner

On Tue, May 15, 2018 at 8:47 AM, Clem cole <clemc at ccc.com> wrote:

> Yeah.  We lost that and it was a good thing.  Programming became a
> operation between you and your computer in the privacy of your own office.
>
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not
> quite.
>
> > On May 15, 2018, at 10:37 AM, Larry McVoy <lm at mcvoy.com> wrote:
> >
> >> On Tue, May 15, 2018 at 08:17:38AM -0600, arnold at skeeve.com wrote:
> >> "Ron Natalie" <ron at ronnatalie.com> wrote:
> >>
> >>> I never really learned VI.   I can stumbled through it in ex mode if I
> have
> >>> to.   If there's no EMACS on the UNIX system I'm using, I use ed.
> >>> You get real good at regular expressions.    Some of my employees were
> >>> pretty amazed at how fast I could make code changes with just ed.
> >>
> >> I did learn vi, after having learned ed first.  I drop down to the ex
> >> command line for major regexp-based surgery too.  I also get the
> amazement
> >> from co-workers who watch me do stuff. :-)  This is particularly true
> >> of the, er, younger coworkers (kids today ... :-) who can't manage
> >> outside an IDE.
> >
> > In fairness to them, I don't know how you learn the good stuff outside
> > of a terminal room.  I learned so much by watching the screen change
> > and going "WTF?  How did you do that?"
> >
> > There is only so much you can stuff into a manual.
> > --
> > ---
> > Larry McVoy                     lm at mcvoy.com
> http://www.mcvoy.com/lm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180515/2412348b/attachment.html>

From imp at bsdimp.com  Wed May 16 01:13:44 2018
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 15 May 2018 09:13:44 -0600
Subject: [TUHS] PWB - what is the history?
In-Reply-To: <20180515145938.GC7879@mcvoy.com>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <20180514143453.GA26148@mcvoy.com>
 <alpine.BSF.2.21.999.1805150649120.79090@aneurin.horsfall.org>
 <CAJfiPzy0x1owguLm2wJXn78hCNeFq62N8b1tYT-SmWcSZriAZQ@mail.gmail.com>
 <CAEoi9W5FYaRn9YsLiysnmbt5DfnQnfRQ1576He+wi-rw2ypx2g@mail.gmail.com>
 <C92734BB-E8EA-448E-852F-7B9A68B9850B@ccc.com>
 <20180515145938.GC7879@mcvoy.com>
Message-ID: <CANCZdfo8QzA4s2Ki0STm0ULuuZewXSS8KQhhzT6v=pxRw5ntqA@mail.gmail.com>

On Tue, May 15, 2018 at 8:59 AM, Larry McVoy <lm at mcvoy.com> wrote:

> So what's the back story with PWB?  It seems like sort of a back water
> but as I recall, they had some interesting stuff.  I feel like there
> was a "learn" command and another one that tried to tell you about
> common grammer (english, not yacc) problems in your prose.  So far
> as I know, those didn't make it into the mainstream, or if they did,
> they were weak reimplementations that didn't work as well as the
> originals.
>

learn was in BSD distributions, though they never made the leap to
{Net,Open,Free}BSD in any useful way because the source material had become
dated by then.

Warner


> On Tue, May 15, 2018 at 10:55:24AM -0400, Clem cole wrote:
> > The PWB children used -mm  I seem to remember that the base system 3 and
> maybe the original sysv did not include it since troff was not apart. If
> you pulled from BSD or ditroff; you got it.
> >
> > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not
> quite.
> >
> > > On May 15, 2018, at 10:37 AM, Dan Cross <crossd at gmail.com> wrote:
> > >
> > > On Tue, May 15, 2018 at 10:07 AM, Nemo <cym224 at gmail.com> wrote:
> > > > On 14/05/2018, Dave Horsfall <dave at horsfall.org> wrote (in part):
> > > > > I had a boss once who demanded that we learn -mm; for some reason
> I still
> > > > > preferred -ms, as it somehow seemed more "natural", and I still
> use it to
> > > > > this day (well, when I'm not using the Mac, that is).
> > > >
> > > > Why not? The Mac has it: /usr/share/groff/1.19.2/tmac/s.tmac
> > >
> > > I have some vague distant memory of a commercial Unix variant that
> came with troff and the -mm macros, but without -ms. I can't remember which
> it was (or if I'm just imagining things). Anyone have any ideas?
> > >
> > >         - Dan C.
> > >
>
> --
> ---
> Larry McVoy                  lm at mcvoy.com
> http://www.mcvoy.com/lm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180515/3119ec97/attachment.html>

From nobozo at gmail.com  Wed May 16 01:14:35 2018
From: nobozo at gmail.com (Jon Forrest)
Date: Tue, 15 May 2018 08:14:35 -0700
Subject: [TUHS] PWB - what is the history?
In-Reply-To: <20180515145938.GC7879@mcvoy.com>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <20180514143453.GA26148@mcvoy.com>
 <alpine.BSF.2.21.999.1805150649120.79090@aneurin.horsfall.org>
 <CAJfiPzy0x1owguLm2wJXn78hCNeFq62N8b1tYT-SmWcSZriAZQ@mail.gmail.com>
 <CAEoi9W5FYaRn9YsLiysnmbt5DfnQnfRQ1576He+wi-rw2ypx2g@mail.gmail.com>
 <C92734BB-E8EA-448E-852F-7B9A68B9850B@ccc.com>
 <20180515145938.GC7879@mcvoy.com>
Message-ID: <34f124e4-9c08-290c-555d-17e6cb7b6190@gmail.com>



On 5/15/2018 7:59 AM, Larry McVoy wrote:
> So what's the back story with PWB?  It seems like sort of a back water
> but as I recall, they had some interesting stuff.  I feel like there
> was a "learn" command and another one that tried to tell you about
> common grammer (english, not yacc) problems in your prose.  So far
> as I know, those didn't make it into the mainstream, or if they did,
> they were weak reimplementations that didn't work as well as the
> originals.

We used PWB at Ford Aerospace in the late 70s. It might have been
the closest to a commercial Unix version there was back then. John 
Mashey had a lot to do with PWB so maybe he can say a few words about
it if he's on here.

It's ironic - back in the late 70s there were almost as many
variations of Unix as there are Linux distributions now. It made the
commercial software vendors crazy because each required separate
development and QA resources, and none of them had enough traction
to be the only version that a vendor would support (like maybe
RedHat now).

Jon Forrest


From crossd at gmail.com  Wed May 16 01:14:30 2018
From: crossd at gmail.com (Dan Cross)
Date: Tue, 15 May 2018 11:14:30 -0400
Subject: [TUHS] PWB - what is the history?
In-Reply-To: <20180515145938.GC7879@mcvoy.com>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <20180514143453.GA26148@mcvoy.com>
 <alpine.BSF.2.21.999.1805150649120.79090@aneurin.horsfall.org>
 <CAJfiPzy0x1owguLm2wJXn78hCNeFq62N8b1tYT-SmWcSZriAZQ@mail.gmail.com>
 <CAEoi9W5FYaRn9YsLiysnmbt5DfnQnfRQ1576He+wi-rw2ypx2g@mail.gmail.com>
 <C92734BB-E8EA-448E-852F-7B9A68B9850B@ccc.com>
 <20180515145938.GC7879@mcvoy.com>
Message-ID: <CAEoi9W57g18g++yhuiVNkCryY3FAq95COvnuvva6eKSbv68V3g@mail.gmail.com>

On Tue, May 15, 2018 at 10:59 AM, Larry McVoy <lm at mcvoy.com> wrote:

> So what's the back story with PWB?  It seems like sort of a back water
> but as I recall, they had some interesting stuff.  I feel like there
> was a "learn" command and another one that tried to tell you about
> common grammer (english, not yacc) problems in your prose.  So far
> as I know, those didn't make it into the mainstream, or if they did,
> they were weak reimplementations that didn't work as well as the
> originals.
>

I think you mean 'style' and 'diction'. I thought those came from research?
I remember seeing papers about them in a manual; maybe 7th Ed or
4.2/4.3BSD? Similarly with learn: I have a vague memory of seeing it with
BSD, but I thought it came from 6th or 7th edition. A quick look shows a
copy in 7th Ed.

        - Dan C.


On Tue, May 15, 2018 at 10:55:24AM -0400, Clem cole wrote:
> > The PWB children used -mm  I seem to remember that the base system 3 and
> maybe the original sysv did not include it since troff was not apart. If
> you pulled from BSD or ditroff; you got it.
> >
> > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not
> quite.
> >
> > > On May 15, 2018, at 10:37 AM, Dan Cross <crossd at gmail.com> wrote:
> > >
> > > On Tue, May 15, 2018 at 10:07 AM, Nemo <cym224 at gmail.com> wrote:
> > > > On 14/05/2018, Dave Horsfall <dave at horsfall.org> wrote (in part):
> > > > > I had a boss once who demanded that we learn -mm; for some reason
> I still
> > > > > preferred -ms, as it somehow seemed more "natural", and I still
> use it to
> > > > > this day (well, when I'm not using the Mac, that is).
> > > >
> > > > Why not? The Mac has it: /usr/share/groff/1.19.2/tmac/s.tmac
> > >
> > > I have some vague distant memory of a commercial Unix variant that
> came with troff and the -mm macros, but without -ms. I can't remember which
> it was (or if I'm just imagining things). Anyone have any ideas?
> > >
> > >         - Dan C.
> > >
>
> --
> ---
> Larry McVoy                  lm at mcvoy.com
> http://www.mcvoy.com/lm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180515/234ceaba/attachment.html>

From arnold at skeeve.com  Wed May 16 01:09:36 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 15 May 2018 09:09:36 -0600
Subject: [TUHS] Good ol' ed (Was *ROFF)
In-Reply-To: <20180515143752.GA7115@mcvoy.com>
References: <01e701d3ec45$e7211580$b5634080$@ronnatalie.com>
 <201805151417.w4FEHcIF009897@freefriends.org>
 <20180515143752.GA7115@mcvoy.com>
Message-ID: <201805151509.w4FF9axM016451@freefriends.org>

> In fairness to them, I don't know how you learn the good stuff outside
> of a terminal room.  I learned so much by watching the screen change
> and going "WTF?  How did you do that?"
>
> There is only so much you can stuff into a manual.

Indeed. But this can be taught; however, it seems that many of the
younger generation aren't interested in learning it.  As Clem noted,
losing the terminal room has had a negative impact on learning.

(Boy, are we just a bunch of old farts, or what ... :-)

Arnold


From lm at mcvoy.com  Wed May 16 01:18:10 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 15 May 2018 08:18:10 -0700
Subject: [TUHS] Good ol' ed (Was *ROFF)
In-Reply-To: <201805151509.w4FF9axM016451@freefriends.org>
References: <01e701d3ec45$e7211580$b5634080$@ronnatalie.com>
 <201805151417.w4FEHcIF009897@freefriends.org>
 <20180515143752.GA7115@mcvoy.com>
 <201805151509.w4FF9axM016451@freefriends.org>
Message-ID: <20180515151810.GE7879@mcvoy.com>

On Tue, May 15, 2018 at 09:09:36AM -0600, arnold at skeeve.com wrote:
> > In fairness to them, I don't know how you learn the good stuff outside
> > of a terminal room.  I learned so much by watching the screen change
> > and going "WTF?  How did you do that?"
> >
> > There is only so much you can stuff into a manual.
> 
> Indeed. But this can be taught; however, it seems that many of the
> younger generation aren't interested in learning it.  As Clem noted,
> losing the terminal room has had a negative impact on learning.
> 
> (Boy, are we just a bunch of old farts, or what ... :-)

I'm not old, oh, wait.  And get off my lawn!  :)
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From jon at fourwinds.com  Wed May 16 01:34:44 2018
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 15 May 2018 08:34:44 -0700
Subject: [TUHS] Good ol' ed (Was *ROFF)
In-Reply-To: <20180515151810.GE7879@mcvoy.com>
References: <01e701d3ec45$e7211580$b5634080$@ronnatalie.com>
 <201805151417.w4FEHcIF009897@freefriends.org>
 <20180515143752.GA7115@mcvoy.com>
 <201805151509.w4FF9axM016451@freefriends.org>
 <20180515151810.GE7879@mcvoy.com>
Message-ID: <201805151534.w4FFYihS007916@darkstar.fourwinds.com>

Larry McVoy writes:
> On Tue, May 15, 2018 at 09:09:36AM -0600, arnold at skeeve.com wrote:
> > > In fairness to them, I don't know how you learn the good stuff outside
> > > of a terminal room.  I learned so much by watching the screen change
> > > and going "WTF?  How did you do that?"
> > >
> > > There is only so much you can stuff into a manual.
> > 
> > Indeed. But this can be taught; however, it seems that many of the
> > younger generation aren't interested in learning it.  As Clem noted,
> > losing the terminal room has had a negative impact on learning.
> > 
> > (Boy, are we just a bunch of old farts, or what ... :-)
>
> I'm not old, oh, wait.  And get off my lawn!  :)

I have fond memories of the "public terminal" room that was somewhere
on the 4th or 5th floor of building 2 at Murray Hill.  Never knew who
you'd run into there.


From clemc at ccc.com  Wed May 16 01:38:06 2018
From: clemc at ccc.com (Clem Cole)
Date: Tue, 15 May 2018 11:38:06 -0400
Subject: [TUHS] PWB - what is the history?
In-Reply-To: <20180515145938.GC7879@mcvoy.com>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <20180514143453.GA26148@mcvoy.com>
 <alpine.BSF.2.21.999.1805150649120.79090@aneurin.horsfall.org>
 <CAJfiPzy0x1owguLm2wJXn78hCNeFq62N8b1tYT-SmWcSZriAZQ@mail.gmail.com>
 <CAEoi9W5FYaRn9YsLiysnmbt5DfnQnfRQ1576He+wi-rw2ypx2g@mail.gmail.com>
 <C92734BB-E8EA-448E-852F-7B9A68B9850B@ccc.com>
 <20180515145938.GC7879@mcvoy.com>
Message-ID: <CAC20D2OP109yyMaQ8fhwWR-ryEbykCVus3p7U7naGriXwfTLrw@mail.gmail.com>

On Tue, May 15, 2018 at 10:59 AM, Larry McVoy <lm at mcvoy.com> wrote:

> So what's the back story with PWB?  It seems like sort of a back water
> but as I recall, they had some interesting stuff.

​Actually PWB (1.0) gave on you of your favorite tools -- SCCS ;-)

V6 was semi-widely distributed to the Academics.  Basically the tier-1 CS
schools all had it, but it was probably few than 50-75 licenses.  It was
also were the first commercial use license was written (originally for Rand
Corp).

Programmer's Workbench - aka PWB was John Mashey and team in Whippany.
 They took a V6 system and make some changes, primarily in how groups
worked and added a bunch of user level tools that made it easier to write
and maintain long term commercial software that was being sent out the Bell
Operating Companies -- IIRC the #5ESS project was a big driver but I'm less
sure of that.

PWB was not officially released to the Universities it was originally only
available inside the Bell System, but because of the commerical use license
AT&T started to rethink.   BTW:  some of the University got it from AT&T
employees that brought it with them.    This was how SCCS made it to UCB
because it was not part of the research editions.   Who brought it, there I
never knew.  Noel may know how it made it to MIT, it came to CMU from Phill
Karn and Ted Kowalski.

PWB 2.0 was released a few years later and was based on the UNIX/TS kernel
and some other changes and it was around this time that the UNIX Support
Group was formed in Summit, where aps, Ted, and Steve Johnson spent time.
  This got even less widely used outside of the Bell System because V7 had
been released which also based on the UNIX/TS kernel.  I believe that this
was released via Summit, but Steve or aps may know more.

With V7 there also came the first commercial binary redistribution license,
and commercial use license was modified for the first time.

​Judge Green broke the Bell System up....​


So, AT&T started to negotiate with 10 commercial firms that had
redistribution licenses and we also customers of Prof Allison at Stanford
who brokered the meetings [I was the technical rep from Tektronix, along
with a lawyer].   I'm not sure I can remember everyone in the room at
Ricki's Hyatt.   But Gates was there from Microsoft (only time I ever met
him), Bill Munson from DEC, I've forgotten the HP and IBM reps, 3Com was
Metcalfe, was SCO and few others.  I can see a picture of the faces in my
mind, I just can not remember the names].  What I remember was Gates saying
'You guys don't get it.  The only thing that matters for SW is Volume' --
they wanted to pay $25 a copy max and DEC/IBM/HP thought $1500-2000 was
just fine, since their average systems cost  was $150K.

So ...  PWB 3.0 came about 2-3 years later and Research was supposed to be
out of the distribution business and the new commercial license was created
from that negotiation.     AT&T is allowed to be in the computer business
and renamed it System III.   But if you look at the printed manual, it had
already been created and calls it PWB 3.0.



​Clem​

PS learn, style and diction were part of 7th edition BTW...

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

From ralph at inputplus.co.uk  Wed May 16 01:56:21 2018
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Tue, 15 May 2018 16:56:21 +0100
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <201805151423.w4FENYlQ010613@freefriends.org>
References: <201805151252.w4FCq3Fx002374@coolidge.cs.Dartmouth.EDU>
 <CAC20D2M5-krMuR-EK=EyufUwjtLJTZeucfByknCFbD3qy5jqpg@mail.gmail.com>
 <201805151423.w4FENYlQ010613@freefriends.org>
Message-ID: <20180515155621.0B986200C2@orac.inputplus.co.uk>

Hi,

Arnold wrote:
> Clem wrote:
> > wrote a wonderful "Masscomp Style Guide" for all the books - I still
> > have my copy.   Tim took it with him when he created O'Reilly.

Tim talks about Masscomp and the start of O'Reilly.
https://plus.google.com/+TimOReilly/posts/5cw5z69qZPg

> DocBook. Bleah.

Eric S. Raymond has a long-term plan underway to get all man-page source
moved to DocBook or asciidoc using his doclifter program, and convincing
projects to make the switch.  Unfortunately, some have.  DocBook stinks
and it shows how long the project has been going that Eric chose it back
when it and XML were still shiny.

He argues that decent-quality output, e.g. PDF, isn't required any more.
(I like man pages I'm reading from top to bottom in higher resolution
than a TTY, e.g. perl(1) when you could learn it from its single page.)
http://esr.ibiblio.org/?p=7998

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From clemc at ccc.com  Wed May 16 02:33:31 2018
From: clemc at ccc.com (Clem Cole)
Date: Tue, 15 May 2018 12:33:31 -0400
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <20180515155621.0B986200C2@orac.inputplus.co.uk>
References: <201805151252.w4FCq3Fx002374@coolidge.cs.Dartmouth.EDU>
 <CAC20D2M5-krMuR-EK=EyufUwjtLJTZeucfByknCFbD3qy5jqpg@mail.gmail.com>
 <201805151423.w4FENYlQ010613@freefriends.org>
 <20180515155621.0B986200C2@orac.inputplus.co.uk>
Message-ID: <CAC20D2M-KOnWg8MB7GmHU_SqY-YsMwYCN_cy90=NQDC2DRzYCQ@mail.gmail.com>

On Tue, May 15, 2018 at 11:56 AM, Ralph Corderoy <ralph at inputplus.co.uk>
wrote:

>
> Eric S. Raymond has a long-term plan underway to get all man-page source
> moved to DocBook or asciidoc using his doclifter program, and convincing
> projects to make the switch.  Unfortunately, some have.  DocBook stinks
> and it shows how long the project has been going that Eric chose it back
> when it and XML were still shiny.
>
xkcd on Standards <https://xkcd.com/927/>  (And the Gnu guys have their doc
standard ...)

Things are more like the are today then they have ever been before."
Dwight David Eisenhower ​
ᐧ
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180515/8a69f62d/attachment.html>

From imp at bsdimp.com  Wed May 16 02:36:53 2018
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 15 May 2018 10:36:53 -0600
Subject: [TUHS] Good ol' ed (Was *ROFF)
In-Reply-To: <201805151534.w4FFYihS007916@darkstar.fourwinds.com>
References: <01e701d3ec45$e7211580$b5634080$@ronnatalie.com>
 <201805151417.w4FEHcIF009897@freefriends.org>
 <20180515143752.GA7115@mcvoy.com>
 <201805151509.w4FF9axM016451@freefriends.org>
 <20180515151810.GE7879@mcvoy.com>
 <201805151534.w4FFYihS007916@darkstar.fourwinds.com>
Message-ID: <CANCZdfoumAPdc_BYwo=vvOugubqBkbUJrfR90bi8-M9nr_utRQ@mail.gmail.com>

On Tue, May 15, 2018 at 9:34 AM, Jon Steinhart <jon at fourwinds.com> wrote:

> Larry McVoy writes:
> > On Tue, May 15, 2018 at 09:09:36AM -0600, arnold at skeeve.com wrote:
> > > > In fairness to them, I don't know how you learn the good stuff
> outside
> > > > of a terminal room.  I learned so much by watching the screen change
> > > > and going "WTF?  How did you do that?"
> > > >
> > > > There is only so much you can stuff into a manual.
> > >
> > > Indeed. But this can be taught; however, it seems that many of the
> > > younger generation aren't interested in learning it.  As Clem noted,
> > > losing the terminal room has had a negative impact on learning.
> > >
> > > (Boy, are we just a bunch of old farts, or what ... :-)
> >
> > I'm not old, oh, wait.  And get off my lawn!  :)
>
> I have fond memories of the "public terminal" room that was somewhere
> on the 4th or 5th floor of building 2 at Murray Hill.  Never knew who
> you'd run into there.
>

Even at conferences, the hacking lounges provide only the barest flavor of
what's going on here. Though I still see the cool thing I want to use, it's
often painful to glance over people's shoulders... Some code can't be
unseen :)

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

From imp at bsdimp.com  Wed May 16 02:53:15 2018
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 15 May 2018 10:53:15 -0600
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <CAC20D2M-KOnWg8MB7GmHU_SqY-YsMwYCN_cy90=NQDC2DRzYCQ@mail.gmail.com>
References: <201805151252.w4FCq3Fx002374@coolidge.cs.Dartmouth.EDU>
 <CAC20D2M5-krMuR-EK=EyufUwjtLJTZeucfByknCFbD3qy5jqpg@mail.gmail.com>
 <201805151423.w4FENYlQ010613@freefriends.org>
 <20180515155621.0B986200C2@orac.inputplus.co.uk>
 <CAC20D2M-KOnWg8MB7GmHU_SqY-YsMwYCN_cy90=NQDC2DRzYCQ@mail.gmail.com>
Message-ID: <CANCZdfr9PMF=ntA9q9cX4ykMvwNTaF9Rm05ZZuMs_ezPAVsnOg@mail.gmail.com>

On Tue, May 15, 2018 at 10:33 AM, Clem Cole <clemc at ccc.com> wrote:

>
>
> On Tue, May 15, 2018 at 11:56 AM, Ralph Corderoy <ralph at inputplus.co.uk>
> wrote:
>
>>
>> Eric S. Raymond has a long-term plan underway to get all man-page source
>> moved to DocBook or asciidoc using his doclifter program, and convincing
>> projects to make the switch.  Unfortunately, some have.  DocBook stinks
>> and it shows how long the project has been going that Eric chose it back
>> when it and XML were still shiny.
>>
> xkcd on Standards <https://xkcd.com/927/>  (And the Gnu guys have their
> doc standard ...)
>
> Things are more like the are today then they have ever been before."
> Dwight David Eisenhower ​
> ᐧ
> ᐧ
>

I recently committed a fix to FreeBSD that made booting a little less
verbose. Seems like on EC3 the scrolling is painfully slow. By removing the
one-line-per-core/thread (well, 5 lines) I was able to speed up boot times
40%. My comment was 'The more things change, the more it's 1985 again' when
I was doing similar hacks to make programs run faster when run from the
Decwriter II in the lap connected at 300 baud...

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

From tytso at mit.edu  Wed May 16 02:54:25 2018
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Tue, 15 May 2018 12:54:25 -0400
Subject: [TUHS] Good ol' ed (Was *ROFF)
In-Reply-To: <01e701d3ec45$e7211580$b5634080$@ronnatalie.com>
References: <01e701d3ec45$e7211580$b5634080$@ronnatalie.com>
Message-ID: <20180515165425.GB17777@thunk.org>

On Tue, May 15, 2018 at 08:11:48AM -0400, Ron Natalie wrote:
> I never really learned VI.   I can stumbled through it in ex mode if I have
> to.   If there's no EMACS on the UNIX system I'm using, I use ed.
> You get real good at regular expressions.    Some of my employees were
> pretty amazed at how fast I could make code changes with just ed.

/bin/ed's commands are mostly the same as the line editing tools that
Dec's PDP-8's 4k disk monitor system, PDP-15 backround/foreground
monitor, and the RT-11's editor.  I learned it on my own, from the
manuals only --- and when you are using an teletype, you have a *huge*
amount of incentive to learn all of the tricks you can.

So my choice of editors largely follows Ron; I never really learned
VI, so it's Emacs or ed.  And if you're on a ghastly slow
internet-on-an-airplane connection, being able to use ed is a really
useful skill --- it just gives you flashbacks to using a teletype as
an interface.


       	  	       	     	    - Ted


From arnold at skeeve.com  Wed May 16 02:55:46 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 15 May 2018 10:55:46 -0600
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <20180515155621.0B986200C2@orac.inputplus.co.uk>
References: <201805151252.w4FCq3Fx002374@coolidge.cs.Dartmouth.EDU>
 <CAC20D2M5-krMuR-EK=EyufUwjtLJTZeucfByknCFbD3qy5jqpg@mail.gmail.com>
 <201805151423.w4FENYlQ010613@freefriends.org>
 <20180515155621.0B986200C2@orac.inputplus.co.uk>
Message-ID: <201805151655.w4FGtlbw029930@freefriends.org>

> Arnold wrote:
> > DocBook. Bleah.

Ralph Corderoy <ralph at inputplus.co.uk> wrote:
> Eric S. Raymond has a long-term plan underway to get all man-page source
> moved to DocBook or asciidoc using his doclifter program, and convincing
> projects to make the switch.  Unfortunately, some have.  DocBook stinks
> and it shows how long the project has been going that Eric chose it back
> when it and XML were still shiny.
>
> He argues that decent-quality output, e.g. PDF, isn't required any more.

He's wrong about that, and also that DocBook is wonderful. It's great
for machine processing (which is why O'Reilly likes it) but it's AWFUL
for the human author.

In fact, it's so bad that these days O'Reilly uses AsciiDoc with a
toolchain to convert to DocBook for printing.

> http://esr.ibiblio.org/?p=7998

Interesting reading (I skimmed it), but I will never switch any of
my man pages over to DocBook.

My two cents (as we wander even further afield),

Arnold


From clemc at ccc.com  Wed May 16 02:55:24 2018
From: clemc at ccc.com (Clem Cole)
Date: Tue, 15 May 2018 12:55:24 -0400
Subject: [TUHS] Thoughts on UNIX Licensing vs UNIX Technology
Message-ID: <CAC20D2Pn4yXK102-E4ptOqfLt4Pg8Ba-qOaNDbyx7o09sxrxdQ@mail.gmail.com>

Larry’s question about PWB made me think it might be useful to this list
for some of this to be written down.



When you write the story of UNIX, licensing is a huge part of it (both good
and bad).  As I have tried to explain before the 1956 consent decree and
the later 1980 Judge Green ruling, as well as how the AT&T legal department
set up the licenses really cast huge shadows that almost seem trite today;
but seem to have been forgotten.



In fact later licensing would become so important, one of the more infamous
UNIX wars was based on it (if you go back to the original OSF Founding
Principles – two of them are ‘Fair and Stable Licensing Terms’).   As we
all know, because of the original 1956 decree, AT&T was not allowed to be
in the computer business and so when people came calling both to use it
(Academically and Commercially) and to relicense it; history has shown that
AT&T’s management killed the golden goose.   I’d love to hear the views of
Doug, Steve, Ken and other who were inside looking out.



FWIW: These are my thoughts from an Academic and Commercial user back in
the day.   AT&T’s management was clearly concerned about the consent decree
and the original licenses show it.   UNIX was licensed for free to academic
institutions for research use (sans a small tape copying fee) and the bits
were ‘abandoned on your door step.’     This style of license, along with
the publishing of the ideas behind really did get the ideas out and the
academic community loved it.   We used it and we were able to share
everything.



The academic license was fine until people want to start to use in a
commercial setting (Rand Corp).   Again, AT&T legal is worried about being
perceived in the computer business, so the original commercial use license
shows it.  AT&T licensing basically uses the academic license but add the
ability to actually use it for commercial purposes.    Then the first
Universities start to want to use UNIX more like a commercial system [Dan
Klein and I would go on strike and force CMU to purchase first commercial
use license for an Academic setting, following by Case Western].



As AT&T management realized the UNIX IP did seem to be some value, just
like the transistor had been earlier, it seems like they wanted to find a
way to keep it under their control.   I remember having a dinner
conversation with Dennis at a USENIX about this topic.  Steve has expressed
they told many folks to treated it as a ‘trade secret’ (which is strange to
me since the cat as already out of the bag by then and the ideas (IP)
behind UNIX had already been extensively published (we even had USENIX
formed to discuss ideas).



By the time Judge Green allows AT&T to be in the computer business I think
AT&T management completely misunderstood the value of what they had.    The
AT&T legal team had changed the commercial rules in every new UNIX release
a new license was created, and thus firms like DEC, HP, IBM *et al* were
getting annoyed because they had begun to invest in the technology
themselves and the feeling inside of those firms was that AT&T management
was changing the ground rules after the game started.



IMO a funny thing happened (bad karma), it seems like the tighter AT&T
management seems to try to control things in the UNIX community, the less
control the community gave them.   Clearly, the new features of the
technology started to be driven by BSD.  But the license was the one place
they could control and they tried.    In fact, by the time of the SVR4 it
all came to a head and OSF was formed because most firms were unwilling to
give AT&T the kind of control they were asking in the that license [as
Larry has previously expressed, Sun made a Faustian deal WRT to SVR4].   In
the end, the others were shipping from an SVR3 license or had bought it
out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180515/2e20310b/attachment.html>

From lyndon at orthanc.ca  Wed May 16 05:48:51 2018
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Tue, 15 May 2018 12:48:51 -0700 (PDT)
Subject: [TUHS] PWB - what is the history?
In-Reply-To: <CAEoi9W57g18g++yhuiVNkCryY3FAq95COvnuvva6eKSbv68V3g@mail.gmail.com>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <20180514143453.GA26148@mcvoy.com>
 <alpine.BSF.2.21.999.1805150649120.79090@aneurin.horsfall.org>
 <CAJfiPzy0x1owguLm2wJXn78hCNeFq62N8b1tYT-SmWcSZriAZQ@mail.gmail.com>
 <CAEoi9W5FYaRn9YsLiysnmbt5DfnQnfRQ1576He+wi-rw2ypx2g@mail.gmail.com>
 <C92734BB-E8EA-448E-852F-7B9A68B9850B@ccc.com>
 <20180515145938.GC7879@mcvoy.com>
 <CAEoi9W57g18g++yhuiVNkCryY3FAq95COvnuvva6eKSbv68V3g@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.999.1805151245500.80036@orthanc.ca>

> I think you mean 'style' and 'diction'. I thought those came from research? I
> remember seeing papers about them in a manual; maybe 7th Ed or 4.2/4.3BSD?

IIRC they were written up in the BSTJ "Unix" number.

> Similarly with learn: I have a vague memory of seeing it with BSD, but I
> thought it came from 6th or 7th edition. A quick look shows a copy in 7th Ed.

I remmber learn being present on at least one early Xenix release I played 
with.  I've long forgotten the details of which release, though.


From ca6c at bitmessage.ch  Wed May 16 06:04:56 2018
From: ca6c at bitmessage.ch (=?iso-8859-1?B?Q+Fn?=)
Date: Tue, 15 May 2018 16:04:56 -0400
Subject: [TUHS] Good ol' ed (Was *ROFF)
In-Reply-To: <01e701d3ec45$e7211580$b5634080$@ronnatalie.com>
References: <01e701d3ec45$e7211580$b5634080$@ronnatalie.com>
Message-ID: <20180515200456.GA7849@syrtis>

"ed is the standard text editor"



From jpl.jpl at gmail.com  Wed May 16 06:33:18 2018
From: jpl.jpl at gmail.com (John P. Linderman)
Date: Tue, 15 May 2018 16:33:18 -0400
Subject: [TUHS] PWB - what is the history?
In-Reply-To: <alpine.BSF.2.21.999.1805151245500.80036@orthanc.ca>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <20180514143453.GA26148@mcvoy.com>
 <alpine.BSF.2.21.999.1805150649120.79090@aneurin.horsfall.org>
 <CAJfiPzy0x1owguLm2wJXn78hCNeFq62N8b1tYT-SmWcSZriAZQ@mail.gmail.com>
 <CAEoi9W5FYaRn9YsLiysnmbt5DfnQnfRQ1576He+wi-rw2ypx2g@mail.gmail.com>
 <C92734BB-E8EA-448E-852F-7B9A68B9850B@ccc.com>
 <20180515145938.GC7879@mcvoy.com>
 <CAEoi9W57g18g++yhuiVNkCryY3FAq95COvnuvva6eKSbv68V3g@mail.gmail.com>
 <alpine.BSF.2.21.999.1805151245500.80036@orthanc.ca>
Message-ID: <CAC0cEp_FZbcukKh_8FoQ7d769PELWUROcgihC5YYBENobf_bBg@mail.gmail.com>

My recollection of the research/PWB split (I wasn't in either center) was
that research (wisely) decided not to get into the business of software
support or committing to a stable system, so PWB forked off to be a
supported, stable version of UNIX. It was used by many of the computer
centers within the Labs because of the promise of support and stability.
Support included published manuals, with the hand of Ted Dollota (whose
first language wasn't even English) creating some amazingly good documents.
There was some idea exchange between research/and PWB (like the Mashey
shell and the Bourne shell incorporating support for what is now thought of
as "here documents"), but research was focused on innovation and PWB was
focused on support. AT&T management no doubt were looking to an OS on their
(IMHO mostly disastrous) entry into the computer business, for which they
agreed to be broken up.

On Tue, May 15, 2018 at 3:48 PM, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:

> I think you mean 'style' and 'diction'. I thought those came from
>> research? I
>> remember seeing papers about them in a manual; maybe 7th Ed or 4.2/4.3BSD?
>>
>
> IIRC they were written up in the BSTJ "Unix" number.
>
> Similarly with learn: I have a vague memory of seeing it with BSD, but I
>> thought it came from 6th or 7th edition. A quick look shows a copy in 7th
>> Ed.
>>
>
> I remmber learn being present on at least one early Xenix release I played
> with.  I've long forgotten the details of which release, though.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180515/82c8f10a/attachment.html>

From bakul at bitblocks.com  Wed May 16 06:49:26 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Tue, 15 May 2018 13:49:26 -0700
Subject: [TUHS] Who used *ROFF?
In-Reply-To: Your message of "Mon, 14 May 2018 19:22:58 -0700."
 <201805150222.w4F2Mwnn004038@darkstar.fourwinds.com>
References: <20180512110127.0B81418C08E@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.999.1805151115220.79090@aneurin.horsfall.org>
 <20180515020611.5A16F156E7DB@mail.bitblocks.com>
 <201805150222.w4F2Mwnn004038@darkstar.fourwinds.com>
Message-ID: <20180515204933.B4D3A157419B@mail.bitblocks.com>

On Mon, 14 May 2018 19:22:58 -0700 Jon Steinhart <jon at fourwinds.com> wrote:
Jon Steinhart writes:
> Bakul Shah writes:
> > On Tue, 15 May 2018 11:21:22 +1000 Dave Horsfall <dave at horsfall.org> wrote:
> > Dave Horsfall writes:
> > > On Sat, 12 May 2018, Noel Chiappa wrote:
> > > 
> > > > I'm pretty sure 'ed' was the only editor available at that point.
> > > 
> > > I boss I used to work for insisted that we all learn "ed", because one day
> > > it might be the only editor available to you; well, one day he was right,
> > > when /usr on a client's box got creamed after a head crash...
> >
> > Your boss must've been an optimist.
> >
> > I once had to rescue a system where the root dir block was
> > lost.  No ed.  Luckily our bootrom had commands for peek/poke
> > & disk block IO.  The v7 filesystem layout was simple enough
> > and I remembered enough of it that I was able to patch it
> > enough to bring it up and run fsck.
> 
> If we're gonna get into "when I was young" stories we need to get
> back to repairing filesystems from the front panel switches.

:-)

My point was when Murphy's Law  strikes, you can't rely having
even "ed".  And it did strike us at a bad time -- 24 hours
before our flight to Las Vegas (for Comdex) where we wanted to
show off our *only* working prototype computer.

As for entering stuff from the front panel switches, my first
boss in Silicon Valley had told me that as a postdoc he had
entered an experimental *compiler* through the front panel
switches on a Minsk-2!  I never got around to asking him for
the details though.

[Minsk-2 was a discrete transistor Russian computer, with 4K
of 37 bit words. I/O via paper tape.]


From clemc at ccc.com  Wed May 16 07:11:06 2018
From: clemc at ccc.com (Clem Cole)
Date: Tue, 15 May 2018 17:11:06 -0400
Subject: [TUHS] PWB - what is the history?
In-Reply-To: <CAC0cEp_FZbcukKh_8FoQ7d769PELWUROcgihC5YYBENobf_bBg@mail.gmail.com>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <20180514143453.GA26148@mcvoy.com>
 <alpine.BSF.2.21.999.1805150649120.79090@aneurin.horsfall.org>
 <CAJfiPzy0x1owguLm2wJXn78hCNeFq62N8b1tYT-SmWcSZriAZQ@mail.gmail.com>
 <CAEoi9W5FYaRn9YsLiysnmbt5DfnQnfRQ1576He+wi-rw2ypx2g@mail.gmail.com>
 <C92734BB-E8EA-448E-852F-7B9A68B9850B@ccc.com>
 <20180515145938.GC7879@mcvoy.com>
 <CAEoi9W57g18g++yhuiVNkCryY3FAq95COvnuvva6eKSbv68V3g@mail.gmail.com>
 <alpine.BSF.2.21.999.1805151245500.80036@orthanc.ca>
 <CAC0cEp_FZbcukKh_8FoQ7d769PELWUROcgihC5YYBENobf_bBg@mail.gmail.com>
Message-ID: <CAC20D2PhU=74mph9HLa-LdN87NKjPiNSLFacEq5Ng-+5t1wbqA@mail.gmail.com>

On Tue, May 15, 2018 at 4:33 PM, John P. Linderman <jpl.jpl at gmail.com>
wrote:

> AT&T management no doubt were looking to an OS on their (IMHO mostly
> disastrous) entry into the computer business, for which they agreed to be
> broken up.
>
Actually, I think the behavior at the time shows that they wanted to be in
the hardware business -- *e.g. the 3B20​*

*​vs. DEC and IBM's offerings of the day*.  What they failed to understand
was to be in the SW​ business it meant that their customers (IBM, DEC, HP,
Microsoft) needed to succeed in selling >>their own<< hardware by using
AT&T's SW.
ᐧ
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180515/58e69195/attachment.html>

From lyndon at orthanc.ca  Wed May 16 07:41:22 2018
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Tue, 15 May 2018 14:41:22 -0700 (PDT)
Subject: [TUHS] PWB - what is the history?
In-Reply-To: <CAC20D2PhU=74mph9HLa-LdN87NKjPiNSLFacEq5Ng-+5t1wbqA@mail.gmail.com>
References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU>
 <20180514143453.GA26148@mcvoy.com>
 <alpine.BSF.2.21.999.1805150649120.79090@aneurin.horsfall.org>
 <CAJfiPzy0x1owguLm2wJXn78hCNeFq62N8b1tYT-SmWcSZriAZQ@mail.gmail.com>
 <CAEoi9W5FYaRn9YsLiysnmbt5DfnQnfRQ1576He+wi-rw2ypx2g@mail.gmail.com>
 <C92734BB-E8EA-448E-852F-7B9A68B9850B@ccc.com>
 <20180515145938.GC7879@mcvoy.com>
 <CAEoi9W57g18g++yhuiVNkCryY3FAq95COvnuvva6eKSbv68V3g@mail.gmail.com>
 <alpine.BSF.2.21.999.1805151245500.80036@orthanc.ca>
 <CAC0cEp_FZbcukKh_8FoQ7d769PELWUROcgihC5YYBENobf_bBg@mail.gmail.com>
 <CAC20D2PhU=74mph9HLa-LdN87NKjPiNSLFacEq5Ng-+5t1wbqA@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.999.1805151437550.80036@orthanc.ca>

> Actually, I think the behavior at the time shows that they wanted to be in the
> hardware business -- e.g. the 3B20​

And for that they failed miserably.

I still throw up upon hearing the phrase "3B4000."  What a horrible, 
horrible, piece of hardware.

From doug at cs.dartmouth.edu  Wed May 16 09:05:17 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Tue, 15 May 2018 19:05:17 -0400
Subject: [TUHS] Who used *ROFF?
Message-ID: <201805152305.w4FN5HnZ006290@coolidge.cs.Dartmouth.EDU>

> I still find pic really useful ...  > I don't know of any other tool
that lets you do drawings like that

Unix had "ideal", a remarkable language by Chris Van Wyk, based on complex
numbers and capable of some constraint solving. Its code seemed to be
lost but can now be found in one of the online v10 repositories. I've
been meaning to try to resurrect it. If anyone has already done so,
I'd love to hear about it.

I, too, have some pic macros, though no big coherent packages, to do
things like  polar coordinates and solving for the intersection of lines
and circles. I have even in extremis made filled triangles with scripts
that massage PostScript by deleting corners of filled rectangles. Then
from triangles you can, with patience, make polygons.

Doug


From noel.hunt at gmail.com  Wed May 16 09:12:22 2018
From: noel.hunt at gmail.com (Noel Hunt)
Date: Wed, 16 May 2018 09:12:22 +1000
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <201805152305.w4FN5HnZ006290@coolidge.cs.Dartmouth.EDU>
References: <201805152305.w4FN5HnZ006290@coolidge.cs.Dartmouth.EDU>
Message-ID: <CAGfO01yzDm6hf0S=FLBB6EUm-aepxTvWCycUgCDNo9n7BWgNzw@mail.gmail.com>

I have built ideal several times over the years. I have
only tested it on the samples in the manual, in particular
the diagram Brian Kernighan used for the 'cbt' documentation.
I believe there was one bug, which was found by John Mackin
at Sydney University many years ago so the code I have has
that documented, well, patched.


On Wed, May 16, 2018 at 9:05 AM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> > I still find pic really useful ...  > I don't know of any other tool
> that lets you do drawings like that
>
> Unix had "ideal", a remarkable language by Chris Van Wyk, based on complex
> numbers and capable of some constraint solving. Its code seemed to be
> lost but can now be found in one of the online v10 repositories. I've
> been meaning to try to resurrect it. If anyone has already done so,
> I'd love to hear about it.
>
> I, too, have some pic macros, though no big coherent packages, to do
> things like  polar coordinates and solving for the intersection of lines
> and circles. I have even in extremis made filled triangles with scripts
> that massage PostScript by deleting corners of filled rectangles. Then
> from triangles you can, with patience, make polygons.
>
> Doug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180516/67f6e471/attachment.html>

From dave at horsfall.org  Wed May 16 09:31:34 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 16 May 2018 09:31:34 +1000 (EST)
Subject: [TUHS] Good ol' ed (Was *ROFF)
In-Reply-To: <20180515151810.GE7879@mcvoy.com>
References: <01e701d3ec45$e7211580$b5634080$@ronnatalie.com>
 <201805151417.w4FEHcIF009897@freefriends.org>
 <20180515143752.GA7115@mcvoy.com>
 <201805151509.w4FF9axM016451@freefriends.org>
 <20180515151810.GE7879@mcvoy.com>
Message-ID: <alpine.BSF.2.21.999.1805160924570.79090@aneurin.horsfall.org>

On Tue, 15 May 2018, Larry McVoy wrote:

>> (Boy, are we just a bunch of old farts, or what ... :-)
>
> I'm not old, oh, wait.  And get off my lawn!  :)

Well, I turned 65.5 the other day, and am now looking forward to my first 
Age Pension payment; does that make me old?

As for my lawn, I feed the magpies on it every morning :-)  I buy meat 
especially for them (I'm not much of a carnivore myself, but I do like the 
occasional snag).

-- Dave


From dave at horsfall.org  Wed May 16 09:45:08 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 16 May 2018 09:45:08 +1000 (EST)
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <20180515155621.0B986200C2@orac.inputplus.co.uk>
References: <201805151252.w4FCq3Fx002374@coolidge.cs.Dartmouth.EDU>
 <CAC20D2M5-krMuR-EK=EyufUwjtLJTZeucfByknCFbD3qy5jqpg@mail.gmail.com>
 <201805151423.w4FENYlQ010613@freefriends.org>
 <20180515155621.0B986200C2@orac.inputplus.co.uk>
Message-ID: <alpine.BSF.2.21.999.1805160940160.79090@aneurin.horsfall.org>

On Tue, 15 May 2018, Ralph Corderoy wrote:

> Eric S. Raymond has a long-term plan underway to get all man-page source 
> moved to DocBook or asciidoc using his doclifter program, and convincing 
> projects to make the switch.  Unfortunately, some have.  DocBook stinks 
> and it shows how long the project has been going that Eric chose it back 
> when it and XML were still shiny.

I like the manpage format!  It tells me everything I need to know, in the 
correct order, and it's in good old plain ASCII...

Unfortunately it seems that the youngsters of today (i.e. those with no 
sense of Unix history whatsoever) have been suckled on this Whizzy-Wig 
stuff.

-- Dave


From lm at mcvoy.com  Wed May 16 09:48:18 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 15 May 2018 16:48:18 -0700
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <alpine.BSF.2.21.999.1805160940160.79090@aneurin.horsfall.org>
References: <201805151252.w4FCq3Fx002374@coolidge.cs.Dartmouth.EDU>
 <CAC20D2M5-krMuR-EK=EyufUwjtLJTZeucfByknCFbD3qy5jqpg@mail.gmail.com>
 <201805151423.w4FENYlQ010613@freefriends.org>
 <20180515155621.0B986200C2@orac.inputplus.co.uk>
 <alpine.BSF.2.21.999.1805160940160.79090@aneurin.horsfall.org>
Message-ID: <20180515234818.GL7879@mcvoy.com>

On Wed, May 16, 2018 at 09:45:08AM +1000, Dave Horsfall wrote:
> On Tue, 15 May 2018, Ralph Corderoy wrote:
> 
> >Eric S. Raymond has a long-term plan underway to get all man-page source
> >moved to DocBook or asciidoc using his doclifter program, and convincing
> >projects to make the switch.  Unfortunately, some have.  DocBook stinks
> >and it shows how long the project has been going that Eric chose it back
> >when it and XML were still shiny.
> 
> I like the manpage format!  It tells me everything I need to know, in the
> correct order, and it's in good old plain ASCII...

+1 - DocBook does nothing for me but it appears that I'm losing that argument.
The kids will get the mess they deserve I suppose.


From jnc at mercury.lcs.mit.edu  Wed May 16 09:56:36 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue, 15 May 2018 19:56:36 -0400 (EDT)
Subject: [TUHS] PWB - what is the history?
Message-ID: <20180515235636.946A418C0AB@mercury.lcs.mit.edu>

    > From: Jon Forrest <nobozo at gmail.com>

    > John Mashey had a lot to do with PWB so maybe he can say a few words
    > about it if he's on here.

It would be great to have some inside info about the relationship among the
Research, USG and PWB systems. Clearly there was comunication, and things got
passed around, but we know so little about what was happening during the
period between V6 and V7 when a lot happened (e.g. the changes to C, just
mentioned).

E.g. check out the PWB1 version of exec():

  https://minnie.tuhs.org//cgi-bin/utree.pl?file=PWB1/sys/sys/os/sys1.c

It's been changed from V6 to copy the arguments into swap space, _not_ buffers
allocated from the system buffer pool (which is how V6 does it). So, who did
this originally - did the PWB people do it, or was it something the research
people did, that PWB picked up?

I used to think it was USG, but there's a 'Unix Program Description' document
prepared by USG, dated January 1976, and it's still clearly using the V6
approach. The PWB1 release was allegedly July, 1977:

  https://minnie.tuhs.org//cgi-bin/utree.pl?file=PWB1

(Which is, AFAIK, the _only_ set of sources we have for after V6 and before V6
- other than the MIT system, which seems to be basically PWB1.)

So who did the exec() changes, originally?

And I could list a bunch more like this...

    Noel


From jnc at mercury.lcs.mit.edu  Wed May 16 10:08:26 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue, 15 May 2018 20:08:26 -0400 (EDT)
Subject: [TUHS] PWB - what is the history?
Message-ID: <20180516000826.B0E1118C0AB@mercury.lcs.mit.edu>

    > From: Clem Cole

    > Programmer's Workbench - aka PWB was John Mashey and team in Whippany.
    > They took a V6 system and make some changes

I was suprised to find, reading the article on it in the Unix BSTJ issue, that
the system changes were less than I'd thought. Some of the stuff in the PWB1
release that we have (see previous message) is _not_ described in that article
(which is fairly detailed), which further compounds the lack of clarity over
who/what/when between V6 and V7.

    > Noel may know how it made it to MIT

That I _do_ know! There was some sort of Boy Scouts group at Bell (not sure
exactly where) and one of the members went to MIT. I think he was doing
undergraduate research work in the first group at MIT to have Unix (Steve
Ward's), but anyway he had some connection there; and I think also had a
summer job at Bell. He was the Bell->MIT conduit.

    > PWB 2.0 was released a few years later and was based on the UNIX/TS
    > kernel and some other changes and it was around this time that the UNIX
    > Support Group was formed

??? If PWB1 was in July '77, and PWB2 was some years later, USG couldn't have
been formed 'around [that] time' because there's that USG document from
January '76?

     Noel


From dave at horsfall.org  Wed May 16 10:43:30 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 16 May 2018 10:43:30 +1000 (EST)
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <68021D24-BCD4-4C2F-AF01-4E7E084AB56B@xs4all.nl>
References: <20180512110127.0B81418C08E@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.999.1805151115220.79090@aneurin.horsfall.org>
 <20180515020611.5A16F156E7DB@mail.bitblocks.com>
 <201805150222.w4F2Mwnn004038@darkstar.fourwinds.com>
 <6200BC9B-57F4-4221-BFAC-A7494A3A3277@orthanc.ca>
 <68021D24-BCD4-4C2F-AF01-4E7E084AB56B@xs4all.nl>
Message-ID: <alpine.BSF.2.21.999.1805161035460.79090@aneurin.horsfall.org>

On Tue, 15 May 2018, Jaap Akkerhuis wrote:

> Early unixes had dsw: Delete by SWitch register.

Needed because the file system was then so !@#›%-up that "rm" wouldn't 
work, so the i-number had to be keyed in.

It was also known as Delete Sh*t Work :-)

I think that "clri" was written shortly thereafterwards; I have a paper on 
its use somewhere in the archives, from around the 70-80s.

-- Dave

From dave at horsfall.org  Wed May 16 21:11:14 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 16 May 2018 21:11:14 +1000 (EST)
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <20180515234818.GL7879@mcvoy.com>
References: <201805151252.w4FCq3Fx002374@coolidge.cs.Dartmouth.EDU>
 <CAC20D2M5-krMuR-EK=EyufUwjtLJTZeucfByknCFbD3qy5jqpg@mail.gmail.com>
 <201805151423.w4FENYlQ010613@freefriends.org>
 <20180515155621.0B986200C2@orac.inputplus.co.uk>
 <alpine.BSF.2.21.999.1805160940160.79090@aneurin.horsfall.org>
 <20180515234818.GL7879@mcvoy.com>
Message-ID: <alpine.BSF.2.21.999.1805162057420.79090@aneurin.horsfall.org>

On Tue, 15 May 2018, Larry McVoy wrote:

>> I like the manpage format!  It tells me everything I need to know, in 
>> the correct order, and it's in good old plain ASCII...
>
> +1 - DocBook does nothing for me but it appears that I'm losing that 
> argument. The kids will get the mess they deserve I suppose.

Proof by example: "TERM= man man" i.e. turn off all possible highlighting 
etc, and it's still readable (but you do get a warning about your terminal 
not being fully functional or something - big deal).  Try doing *that* 
with your fancy doc system...

I've forgotten who designed the "man" format (JFO?) but it's great, and they
deserved some sort of an award for it.

As for the kids of today, well, eventually they'll learn that their kids 
in turn will get to choose their nursing home :-)

-- Dave, not quite old enough for a nursing home yet


From doug at cs.dartmouth.edu  Thu May 17 00:05:24 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Wed, 16 May 2018 10:05:24 -0400
Subject: [TUHS] PWB - what is the history?
Message-ID: <201805161405.w4GE5OeJ012025@coolidge.cs.Dartmouth.EDU>

> I think you mean 'style' and 'diction'. I thought those came from
research? I 
> remember seeing papers about them in a manual; maybe 7th Ed or 4.2/4.3BSD?

They were in WWB (writers workbench) not PWB (programmers workbench).
WWB was a suite of Unix programs, organized by Nina MacDonald of USG.
It appeared in various Unix versions, including research v8-v10.

Lorinda Cherry in research wrote most of the basic tools in WWB,
most notably style, diction, and the really cool "parts" that
underlay style. William Vesterman at Rutgers suggested style and
diction. Having parts up her sleeve, Lorinda was able to turn them out
almost overnight. Most anyone else would scarcely have known how to
begin to make style.

Just yesterday Lorinda received a Pioneer in Tech award from the National
Center for Women in IT. Parts and eqn, both initiated by her, certainly
justify that honor.

[Parts did a remarkable job of tagging text with parts of speech, without
getting bogged down in the swamp of parsing English. It was largely
implemented in sed--certainly one of the grander programs written in that
language. Style reported statistics like length of words, frequency of
adjectives, and variety of sentence structure. Diction flagged cliches
and other common infelicities. WWB offered advice based on the findings
of these and other text-analysis programs.]

Doug


From rudi.j.blom at gmail.com  Thu May 17 14:37:17 2018
From: rudi.j.blom at gmail.com (Rudi Blom)
Date: Thu, 17 May 2018 11:37:17 +0700
Subject: [TUHS] PWB - what is the history?
Message-ID: <CAMYpm86vp4TgNFKKduS4C6vwckX1fkkjSjrr3+T1KQKESKh=1Q@mail.gmail.com>

>Date: Wed, 16 May 2018 10:05:24 -0400
>From: Doug McIlroy <doug at cs.dartmouth.edu>
>To: tuhs at minnie.tuhs.org
>Cc: lorinda.cherry at gmail.com
>Subject: Re: [TUHS] PWB - what is the history?
>Message-ID: <201805161405.w4GE5OeJ012025 at coolidge.cs.Dartmouth.EDU>
>Content-Type: text/plain; charset=us-ascii
>
<snip>
>They were in WWB (writers workbench) not PWB (programmers workbench).
>WWB was a suite of Unix programs, organized by Nina MacDonald of USG.
>It appeared in various Unix versions, including research v8-v10.
>
>Lorinda Cherry in research wrote most of the basic tools in WWB,
...

I see Ms. Cherry also has a wiki page
https://en.wikipedia.org/wiki/Lorinda_Cherry which  has "Cherry raced
rally cars as a hobby".

and the page contains a link to an interesting document which brings
us back to the PWB
 "A Research UNIX Reader:
 Annotated Excerpts from the Programmer’s Manual,
 1971-1986
 M. Douglas McIlroy"

- uncle rubl


From blake at mcbride.name  Fri May 18 01:28:53 2018
From: blake at mcbride.name (Blake McBride)
Date: Thu, 17 May 2018 10:28:53 -0500
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <alpine.BSF.2.21.999.1805121313070.79090@aneurin.horsfall.org>
References: <CAJfiPzzeniiZjj0z9p8Y8e==T6WJ0W1B_8iutj4uZaNVTf+iQQ@mail.gmail.com>
 <CBBD3ECE-2A0C-4DAE-ACD9-344FA6FC6DFF@orthanc.ca>
 <alpine.BSF.2.21.999.1805121209240.79090@aneurin.horsfall.org>
 <A32F6D0F-E125-4A2A-ABC8-44E9FE170BB2@orthanc.ca>
 <alpine.BSF.2.21.999.1805121246080.79090@aneurin.horsfall.org>
 <alpine.BSF.2.21.999.1805121313070.79090@aneurin.horsfall.org>
Message-ID: <CABwHSOt0TU1We9d5JyzPtYWnXg5wcfcDa6fkryuB+1fHMyRycg@mail.gmail.com>

We laugh, but I've found that it can be true (up-hill in both directions)!
Let me explain...

I used to ride my bicycle around the top of a large hill.  It went up and
down, but I ended up in the same place that I started.  One would think
that, since I ended up in the same place, I necessarily went up-hill and
down-hill the same amount - but not true!

It took me an hour to ride around that hill.  The up-hill parts were hard
and I went slowly.  The down-hill parts were fast and easy.  Turns out, I'd
spend 45 minutes going up-hill and 15 minutes going-down-hill.  Not equal!
So, while I may have "theoretically" went up and down the same amount.  In
terms of time and my perceptions, it was up-hill most of the way!

Blake McBride


On Fri, May 11, 2018 at 10:19 PM, Dave Horsfall <dave at horsfall.org> wrote:

> On Sat, 12 May 2018, Dave Horsfall wrote:
>
> <accent=Irish>
>>
>> And you tell that to the young people of today. and they won't believe
>> you.
>>
>
> Arrgghh!  It was the four *Yorkshiremen*, of course...
>
> -- Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180517/67345273/attachment.html>

From dave at horsfall.org  Mon May 21 12:23:31 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 21 May 2018 12:23:31 +1000 (EST)
Subject: [TUHS] Obsolescence Guaranteed (fwd)
Message-ID: <alpine.BSF.2.21.999.1805211219300.810@aneurin.horsfall.org>

Might be of interest to the denizens here...

-- Dave

---------- Forwarded message ----------
Date: Sun, 20 May 2018 17:56:39 +1000
From: Richard
To: Dave
Subject: Obsolescence Guaranteed

The things people are doing with Raspberry Pis these days…

       http://obsolescence.wixsite.com/obsolescence/pidp-11-technical-details


of it an ‘8 is more to your taste…
       http://obsolescence.wixsite.com/obsolescence/pidp-8


Cheers,
Richard


From mike.ab3ap at gmail.com  Mon May 21 20:35:10 2018
From: mike.ab3ap at gmail.com (Mike Markowski)
Date: Mon, 21 May 2018 06:35:10 -0400
Subject: [TUHS] Obsolescence Guaranteed (fwd)
In-Reply-To: <alpine.BSF.2.21.999.1805211219300.810@aneurin.horsfall.org>
References: <alpine.BSF.2.21.999.1805211219300.810@aneurin.horsfall.org>
Message-ID: <CANq1pfnTrU_r5Qshh8_88iFyswMYG95ARxJ-8A-1hDr1us96Dw@mail.gmail.com>

Here 's a series of photos showing my build.  It's a really easy thing to
make and a lot of fun when finished.

   http://udel.edu/~mm/pidp8i/

Mike Markowski

On Sun, May 20, 2018 at 10:23 PM, Dave Horsfall <dave at horsfall.org> wrote:

> Might be of interest to the denizens here...
>
> -- Dave
>
> ---------- Forwarded message ----------
> Date: Sun, 20 May 2018 17:56:39 +1000
> From: Richard
> To: Dave
> Subject: Obsolescence Guaranteed
>
> The things people are doing with Raspberry Pis these days…
>
>       http://obsolescence.wixsite.com/obsolescence/pidp-11-technic
> al-details
>
>
> of it an ‘8 is more to your taste…
>       http://obsolescence.wixsite.com/obsolescence/pidp-8
>
>
> Cheers,
> Richard
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180521/892ee676/attachment.html>

From wkt at tuhs.org  Tue May 22 06:22:34 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 22 May 2018 06:22:34 +1000
Subject: [TUHS] Genealogy of PDP-11 Unix
Message-ID: <20180521202234.GA22144@minnie.tuhs.org>

I had an e-mail from someone who said:

   PDP-11 Sys V is apparently derived from Unix CB 3.0, not from the
   normal route... Or so says the great interweb :)
   I found a family tree that suggests this. Know anything about this?

I hadn't heard of this before, can anybody substantiate or negate this
assertion, or shed more light on the genealogy od PDP-11 System V?

Thanks, Warren


From clemc at ccc.com  Tue May 22 06:30:51 2018
From: clemc at ccc.com (Clem cole)
Date: Mon, 21 May 2018 13:30:51 -0700
Subject: [TUHS] Genealogy of PDP-11 Unix
In-Reply-To: <20180521202234.GA22144@minnie.tuhs.org>
References: <20180521202234.GA22144@minnie.tuhs.org>
Message-ID: <065D3A8C-9A89-4EC8-9196-8409A5435709@ccc.com>

It contains Features from CB Unix but was not the same thing.  In particular shared memory and semaphores were contributed by Dale’s team but it was PWB 3.0 that was rebranded system III and then updated and released by USG aka summit eventually as sys V.   System IV was not released outside the bell system I’m not sure if it ever went out inside. 

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

> On May 21, 2018, at 1:22 PM, Warren Toomey <wkt at tuhs.org> wrote:
> 
> I had an e-mail from someone who said:
> 
>  PDP-11 Sys V is apparently derived from Unix CB 3.0, not from the
>  normal route... Or so says the great interweb :)
>  I found a family tree that suggests this. Know anything about this?
> 
> I hadn't heard of this before, can anybody substantiate or negate this
> assertion, or shed more light on the genealogy od PDP-11 System V?
> 
> Thanks, Warren


From imp at bsdimp.com  Tue May 22 08:22:57 2018
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 21 May 2018 16:22:57 -0600
Subject: [TUHS] Genealogy of PDP-11 Unix
In-Reply-To: <065D3A8C-9A89-4EC8-9196-8409A5435709@ccc.com>
References: <20180521202234.GA22144@minnie.tuhs.org>
 <065D3A8C-9A89-4EC8-9196-8409A5435709@ccc.com>
Message-ID: <CANCZdfqUnS=NTrioJ=Op1w6NPiiqNHiA=j3+biHEhsTgi1FrLQ@mail.gmail.com>

In case people are wondering, I found this
https://www.quora.com/What-is-Unix-and-why-is-it-important which contains a
blue-oval chart that shows it being derived from CB Unix 3. But that the
sources were also different than the ones for VAXen, etc. At least that's
the implication here. Is this chart in error?

Warner

On Mon, May 21, 2018 at 2:30 PM, Clem cole <clemc at ccc.com> wrote:

> It contains Features from CB Unix but was not the same thing.  In
> particular shared memory and semaphores were contributed by Dale’s team but
> it was PWB 3.0 that was rebranded system III and then updated and released
> by USG aka summit eventually as sys V.   System IV was not released outside
> the bell system I’m not sure if it ever went out inside.
>
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not
> quite.
>
> > On May 21, 2018, at 1:22 PM, Warren Toomey <wkt at tuhs.org> wrote:
> >
> > I had an e-mail from someone who said:
> >
> >  PDP-11 Sys V is apparently derived from Unix CB 3.0, not from the
> >  normal route... Or so says the great interweb :)
> >  I found a family tree that suggests this. Know anything about this?
> >
> > I hadn't heard of this before, can anybody substantiate or negate this
> > assertion, or shed more light on the genealogy od PDP-11 System V?
> >
> > Thanks, Warren
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180521/c7f43e33/attachment.html>

From clemc at ccc.com  Tue May 22 08:48:38 2018
From: clemc at ccc.com (Clem Cole)
Date: Mon, 21 May 2018 15:48:38 -0700
Subject: [TUHS] Genealogy of PDP-11 Unix
In-Reply-To: <CANCZdfqUnS=NTrioJ=Op1w6NPiiqNHiA=j3+biHEhsTgi1FrLQ@mail.gmail.com>
References: <20180521202234.GA22144@minnie.tuhs.org>
 <065D3A8C-9A89-4EC8-9196-8409A5435709@ccc.com>
 <CANCZdfqUnS=NTrioJ=Op1w6NPiiqNHiA=j3+biHEhsTgi1FrLQ@mail.gmail.com>
Message-ID: <CAC20D2MsMZ0uZF2UUoZzomNpRs-NjxknPBE+dWPW_egzAwBg1Q@mail.gmail.com>

@Warner Losh - the picture with the blue balloons is so wrong....   There
are a ton of errors, starting with claiming PWB 1.0 came from Fifth Edition

On Mon, May 21, 2018 at 3:22 PM, Warner Losh <imp at bsdimp.com> wrote:

> In case people are wondering, I found this https://www.quora.com/
> What-is-Unix-and-why-is-it-important which contains a blue-oval chart
> that shows it being derived from CB Unix 3. But that the sources were also
> different than the ones for VAXen, etc. At least that's the implication
> here. Is this chart in error?
>
> Warner
>
>
> On Mon, May 21, 2018 at 2:30 PM, Clem cole <clemc at ccc.com> wrote:
>
>> It contains Features from CB Unix but was not the same thing.  In
>> particular shared memory and semaphores were contributed by Dale’s team but
>> it was PWB 3.0 that was rebranded system III and then updated and released
>> by USG aka summit eventually as sys V.   System IV was not released outside
>> the bell system I’m not sure if it ever went out inside.
>>
>> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not
>> quite.
>>
>> > On May 21, 2018, at 1:22 PM, Warren Toomey <wkt at tuhs.org> wrote:
>> >
>> > I had an e-mail from someone who said:
>> >
>> >  PDP-11 Sys V is apparently derived from Unix CB 3.0, not from the
>> >  normal route... Or so says the great interweb :)
>> >  I found a family tree that suggests this. Know anything about this?
>> >
>> > I hadn't heard of this before, can anybody substantiate or negate this
>> > assertion, or shed more light on the genealogy od PDP-11 System V?
>> >
>> > Thanks, Warren
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180521/c2eca630/attachment.html>

From imp at bsdimp.com  Tue May 22 08:53:07 2018
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 21 May 2018 16:53:07 -0600
Subject: [TUHS] Genealogy of PDP-11 Unix
In-Reply-To: <CAC20D2MsMZ0uZF2UUoZzomNpRs-NjxknPBE+dWPW_egzAwBg1Q@mail.gmail.com>
References: <20180521202234.GA22144@minnie.tuhs.org>
 <065D3A8C-9A89-4EC8-9196-8409A5435709@ccc.com>
 <CANCZdfqUnS=NTrioJ=Op1w6NPiiqNHiA=j3+biHEhsTgi1FrLQ@mail.gmail.com>
 <CAC20D2MsMZ0uZF2UUoZzomNpRs-NjxknPBE+dWPW_egzAwBg1Q@mail.gmail.com>
Message-ID: <CANCZdfpaMBgj_1BBhZutxY4RxeMWCmELFpgy_UMrcKniMKao0Q@mail.gmail.com>

OK. So I should ignore it then...  Thanks for the clarification...

Warner

On Mon, May 21, 2018 at 4:48 PM, Clem Cole <clemc at ccc.com> wrote:

> @Warner Losh - the picture with the blue balloons is so wrong....   There
> are a ton of errors, starting with claiming PWB 1.0 came from Fifth Edition
>
> On Mon, May 21, 2018 at 3:22 PM, Warner Losh <imp at bsdimp.com> wrote:
>
>> In case people are wondering, I found this https://www.quora.com/Wha
>> t-is-Unix-and-why-is-it-important which contains a blue-oval chart that
>> shows it being derived from CB Unix 3. But that the sources were also
>> different than the ones for VAXen, etc. At least that's the implication
>> here. Is this chart in error?
>>
>> Warner
>>
>>
>> On Mon, May 21, 2018 at 2:30 PM, Clem cole <clemc at ccc.com> wrote:
>>
>>> It contains Features from CB Unix but was not the same thing.  In
>>> particular shared memory and semaphores were contributed by Dale’s team but
>>> it was PWB 3.0 that was rebranded system III and then updated and released
>>> by USG aka summit eventually as sys V.   System IV was not released outside
>>> the bell system I’m not sure if it ever went out inside.
>>>
>>> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not
>>> quite.
>>>
>>> > On May 21, 2018, at 1:22 PM, Warren Toomey <wkt at tuhs.org> wrote:
>>> >
>>> > I had an e-mail from someone who said:
>>> >
>>> >  PDP-11 Sys V is apparently derived from Unix CB 3.0, not from the
>>> >  normal route... Or so says the great interweb :)
>>> >  I found a family tree that suggests this. Know anything about this?
>>> >
>>> > I hadn't heard of this before, can anybody substantiate or negate this
>>> > assertion, or shed more light on the genealogy od PDP-11 System V?
>>> >
>>> > Thanks, Warren
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180521/24496514/attachment.html>

From ron at ronnatalie.com  Tue May 22 11:08:14 2018
From: ron at ronnatalie.com (Ron Natalie)
Date: Mon, 21 May 2018 21:08:14 -0400
Subject: [TUHS] Genealogy of PDP-11 Unix
In-Reply-To: <CAC20D2MsMZ0uZF2UUoZzomNpRs-NjxknPBE+dWPW_egzAwBg1Q@mail.gmail.com>
References: <20180521202234.GA22144@minnie.tuhs.org>
 <065D3A8C-9A89-4EC8-9196-8409A5435709@ccc.com>
 <CANCZdfqUnS=NTrioJ=Op1w6NPiiqNHiA=j3+biHEhsTgi1FrLQ@mail.gmail.com>
 <CAC20D2MsMZ0uZF2UUoZzomNpRs-NjxknPBE+dWPW_egzAwBg1Q@mail.gmail.com>
Message-ID: <032701d3f169$5d996370$18cc2a50$@ronnatalie.com>

Yep, as we say, it has more holes in it than Sonny Corleone.

 

 

From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Clem Cole
Sent: Monday, May 21, 2018 6:49 PM
To: Warner Losh
Cc: The Eunuchs Hysterical Society
Subject: Re: [TUHS] Genealogy of PDP-11 Unix

 

@Warner Losh - the picture with the blue balloons is so wrong....   There are a ton of errors, starting with claiming PWB 1.0 came from Fifth Edition

 

On Mon, May 21, 2018 at 3:22 PM, Warner Losh <imp at bsdimp.com> wrote:

In case people are wondering, I found this https://www.quora.com/What-is-Unix-and-why-is-it-important which contains a blue-oval chart that shows it being derived from CB Unix 3. But that the sources were also different than the ones for VAXen, etc. At least that's the implication here. Is this chart in error?

 

Warner

 

 

On Mon, May 21, 2018 at 2:30 PM, Clem cole <clemc at ccc.com> wrote:

It contains Features from CB Unix but was not the same thing.  In particular shared memory and semaphores were contributed by Dale’s team but it was PWB 3.0 that was rebranded system III and then updated and released by USG aka summit eventually as sys V.   System IV was not released outside the bell system I’m not sure if it ever went out inside. 

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


> On May 21, 2018, at 1:22 PM, Warren Toomey <wkt at tuhs.org> wrote:
> 
> I had an e-mail from someone who said:
> 
>  PDP-11 Sys V is apparently derived from Unix CB 3.0, not from the
>  normal route... Or so says the great interweb :)
>  I found a family tree that suggests this. Know anything about this?
> 
> I hadn't heard of this before, can anybody substantiate or negate this
> assertion, or shed more light on the genealogy od PDP-11 System V?
> 
> Thanks, Warren

 

 

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

From dave at horsfall.org  Tue May 22 16:16:28 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 22 May 2018 16:16:28 +1000 (EST)
Subject: [TUHS] Obsolesence guaranteed
Message-ID: <alpine.BSF.2.21.999.1805221612160.810@aneurin.horsfall.org>

WHo'll be the first to run our favourite OS with one of these?

     http://obsolescence.wixsite.com/obsolescence/pidp-11-technical-details

``From a hardware perspective, the PiDP is just a frontpanel for a 
Raspberry PI. In the hardware section below, the technical details of the 
front panel are explained. In fact, the front panel could just as easily 
be driven by any microcontroller (or FPGA), it only lights the leds and 
scans the switch positions.''

-- Dave


From wkt at tuhs.org  Wed May 23 13:38:31 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 23 May 2018 13:38:31 +1000
Subject: [TUHS] Fwd: Old Unix manuals, TMs, etc
Message-ID: <20180523033831.GB4066@minnie.tuhs.org>

All, I've just received the following e-mail. I am not able to physically
get these documents, but if you are interested in them, feel free to contact
Mel yourself.

Cheers, Warren

----- Forwarded message from meljmel-unix at yahoo.com -----

Date: Wed, 23 May 2018 13:30:09 +1000 (AEST)
From: meljmel-unix at yahoo.com
To: Warren T <wkt at tuhs.org>
Subject: Old Unix manuals, TMs, etc


Hi,

I started working at Bell Labs in 1971 and although
not in the computing science research department, I
was in another department down the hall.  As a result
I have many old Unix manuals, TM's and other papers
that I wish to dispose of.  I found you when I did a
search to see if there was anyone who might want them.
Appended below is a list of what I have.  If you are
interested in any of it or know who else might be, please
let me know.  If I can't find anyone to take them I guess
I'll just throw them out.

Mel
meljmel-unix at yahoo.com

==========
These are the old Unix Manuals I have:

    UNIX PROGRAMMER'S MANUAL
    Program Generic PG-1C300 Issue 2
    Published by the UNIX Support Group
    January, 1976

    UNIX PROGRAMMER'S MANUAL
    Program Generic PG-1C300 Issue 3
    Published by the UNIX Support Group
    March, 1977

    UNIX User's Manual
    Release 3.0
    T.A. Dolotta
    S. B. Olsson
    A.G. Petrucceli
	Editors
    June 1980
    Laboratory 364
    Bell Telephone Laboratories, Incorporated
    Murray Hill, NJ 07974

    The C Programmer's Handbook
    AT&T Bell Laboratories
    February 1984
    M. I. Bolsky
    P. G. Matthews
    System Training Center
    Copyright 1984
    Piscataway, New Jersey 08854

    Unix System V Quick Reference Guide
    Copyright 1985 AT&T Technologies, Inc
    307-130

    UNIX TIME-SHARING SYSTEM
    PROGRAMMER'S MANUAL
    Research Version
    Ninth Edition, Volume 1
    September, 1986
    AT&T Bell Laboratories
    Murray Hill, New Jersey

    The Vi User's Handbook
    by Morris I. Bolsky
    Systems Training Center
    Copyright 1984 AT&T Bell Laboratories Incorporated
    Copyright 1985 AT&T Technologies, Inc

    Unix Research System Programmer's Manual
    Tenth Edition, Volume I
    Computing Science Research Center
    Murray Hill, New Jersey
    1990, American Telephone and Telegraph Company
    Bell Laboratories Division
    ISBN 0-03-047532-5
    A. G. Hume
    M. D. McIlroy
    October, 1989

    Unix Research System Papers
    Tenth Edition, Volume II
    Computing Science Research Center
    AT&T Bell Laboratories
    Murray Hill, New Jersey
    1990, American Telephone and Telegraph Company
    Bell Laboratories Division
    ISBN 0-03-047529-5
    A. G. Hume
    M. D. McIlroy
    January, 1990

----------

These are old Unix Technical Memorandum and Papers I have:

    The C Reference Manual
    January 15, 1974
    TM: 74-1273-1
    D. M. Ritchie

    Programming in LIL: A Tutorial
    June 17, 1974
    TM: 74-1352-6

    LIL Reference Manual
    June 19, 1974
    TM: 74-1352-8

    A Description of the UNIX File System
    September 16, 1975
    Author J. F. Maranzano

    The Portable C Library
    May 16, 1975
    TM: 75-1274-11
    Author: M. E. Lesk

    Lex - A Lexical Analyzer Generator
    July 21, 1975
    TM: 75-1274-15
    Author: M. E. Lesk

    Introduction to Scheduling and Switching under UNIX
    October 20, 1975
    TM: 75-8234-7
    Author: T. M. Raleigh

    Make - A program for Maintaining Computer Programs
    December 5, 1975
    TM: 75-1274-26
    Author: S. I. Feldman

    UNIX Programming
    Brian w. Kernighan
    Denis M. Ritchie
    ? 1975 ?
    Bell Laboratories, Murray Hill, New Jersey 07974
    "This paper is an introduction to programming on Unix.
    The emphasis is on how to write programs that interface
    to the operating system."

    The C Language Calling Sequence
    September 26, 1977
    TMs: 77-1273-15, 77-1274-13
    Authors: A.C. Johnson, D.M. Ritchie, M.E. Lesk

    Lint, a C Program Checker
    September 16, 1977
    TM: 77-1273-14
    Author: S. C. Johnson

    The M4 Macor Processor
    April 1, 1977
    TM: 77-1273-6
    Authors: Brian W. Kernighan, Dennis M. Ritchie

    C Reference Manual
    Dennis M. Ritchie
    May 1, 1977
    Murray Hill, New Jersey 07974

    C Language Portability
    September 22, 1977
    Author: B. A. Tague

    Variable Length Argument Lists in C
    June 12, 1978
    Author: Andrew Koenig

    An Introduction to the UNIX Shell
    July 21, 1978
    TM: 78-1274-4
    Author: S.R. Bourne

    SED - A Non-Interactive Text Editor
    August 15, 1978
    TM: 78-1270-1
    Author: Lee E. McMahon

    UNIX Shell Tutorial
    July 14, 1981
    TM: 81-59322-5
    Author: J. R. Mashey

    Awk - A pattern Scanning and Processing Language
    Programmer's Manual
    June 19, 1985
    Authors: Alfred V. Aho, Brian W. Kernighan, Peter J. Weinberger
    TMs: 11272-850619-06TM, 11276-850619-09TM, 11273-850619-03TM

    Yacc: Yet Another Compiler-Compiler
    July 31. 1978
    TM: 78-1273-4
    Author: Stephen C. Johnson

    RATFOR - A Preprocessor for a Rational Fortran
    October 22, 1976
    TM: 76-1273-10
    Author Brian W. Kernighan

Miscellaneous undated (but old) papers:

    On the Security of UNIX
    Dennis M. Ritchie

    A New Input-Output Package
    D. M. Ritchie

    The Unix I/O System
    Dennis M. Ritchie

    Programming in C - A tutorial
    Brian W. Kernighan
    ? Date ?

==========


----- End forwarded message -----


From arnold at skeeve.com  Thu May 24 03:53:53 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 23 May 2018 11:53:53 -0600
Subject: [TUHS] Fwd: Old Unix manuals, TMs, etc
In-Reply-To: <20180523033831.GB4066@minnie.tuhs.org>
References: <20180523033831.GB4066@minnie.tuhs.org>
Message-ID: <201805231753.w4NHrr53017669@freefriends.org>

There are some real finds here, esp the 9th and 10th Edition manuals.
I hope someone gets them from him...

Arnold

Warren Toomey <wkt at tuhs.org> wrote:

> All, I've just received the following e-mail. I am not able to physically
> get these documents, but if you are interested in them, feel free to contact
> Mel yourself.
>
> Cheers, Warren
>
> ----- Forwarded message from meljmel-unix at yahoo.com -----
>
> Date: Wed, 23 May 2018 13:30:09 +1000 (AEST)
> From: meljmel-unix at yahoo.com
> To: Warren T <wkt at tuhs.org>
> Subject: Old Unix manuals, TMs, etc
>
>
> Hi,
>
> I started working at Bell Labs in 1971 and although
> not in the computing science research department, I
> was in another department down the hall.  As a result
> I have many old Unix manuals, TM's and other papers
> that I wish to dispose of.  I found you when I did a
> search to see if there was anyone who might want them.
> Appended below is a list of what I have.  If you are
> interested in any of it or know who else might be, please
> let me know.  If I can't find anyone to take them I guess
> I'll just throw them out.
>
> Mel
> meljmel-unix at yahoo.com
>
> ==========
> These are the old Unix Manuals I have:
>
>     UNIX PROGRAMMER'S MANUAL
>     Program Generic PG-1C300 Issue 2
>     Published by the UNIX Support Group
>     January, 1976
>
>     UNIX PROGRAMMER'S MANUAL
>     Program Generic PG-1C300 Issue 3
>     Published by the UNIX Support Group
>     March, 1977
>
>     UNIX User's Manual
>     Release 3.0
>     T.A. Dolotta
>     S. B. Olsson
>     A.G. Petrucceli
> 	Editors
>     June 1980
>     Laboratory 364
>     Bell Telephone Laboratories, Incorporated
>     Murray Hill, NJ 07974
>
>     The C Programmer's Handbook
>     AT&T Bell Laboratories
>     February 1984
>     M. I. Bolsky
>     P. G. Matthews
>     System Training Center
>     Copyright 1984
>     Piscataway, New Jersey 08854
>
>     Unix System V Quick Reference Guide
>     Copyright 1985 AT&T Technologies, Inc
>     307-130
>
>     UNIX TIME-SHARING SYSTEM
>     PROGRAMMER'S MANUAL
>     Research Version
>     Ninth Edition, Volume 1
>     September, 1986
>     AT&T Bell Laboratories
>     Murray Hill, New Jersey
>
>     The Vi User's Handbook
>     by Morris I. Bolsky
>     Systems Training Center
>     Copyright 1984 AT&T Bell Laboratories Incorporated
>     Copyright 1985 AT&T Technologies, Inc
>
>     Unix Research System Programmer's Manual
>     Tenth Edition, Volume I
>     Computing Science Research Center
>     Murray Hill, New Jersey
>     1990, American Telephone and Telegraph Company
>     Bell Laboratories Division
>     ISBN 0-03-047532-5
>     A. G. Hume
>     M. D. McIlroy
>     October, 1989
>
>     Unix Research System Papers
>     Tenth Edition, Volume II
>     Computing Science Research Center
>     AT&T Bell Laboratories
>     Murray Hill, New Jersey
>     1990, American Telephone and Telegraph Company
>     Bell Laboratories Division
>     ISBN 0-03-047529-5
>     A. G. Hume
>     M. D. McIlroy
>     January, 1990
>
> ----------
>
> These are old Unix Technical Memorandum and Papers I have:
>
>     The C Reference Manual
>     January 15, 1974
>     TM: 74-1273-1
>     D. M. Ritchie
>
>     Programming in LIL: A Tutorial
>     June 17, 1974
>     TM: 74-1352-6
>
>     LIL Reference Manual
>     June 19, 1974
>     TM: 74-1352-8
>
>     A Description of the UNIX File System
>     September 16, 1975
>     Author J. F. Maranzano
>
>     The Portable C Library
>     May 16, 1975
>     TM: 75-1274-11
>     Author: M. E. Lesk
>
>     Lex - A Lexical Analyzer Generator
>     July 21, 1975
>     TM: 75-1274-15
>     Author: M. E. Lesk
>
>     Introduction to Scheduling and Switching under UNIX
>     October 20, 1975
>     TM: 75-8234-7
>     Author: T. M. Raleigh
>
>     Make - A program for Maintaining Computer Programs
>     December 5, 1975
>     TM: 75-1274-26
>     Author: S. I. Feldman
>
>     UNIX Programming
>     Brian w. Kernighan
>     Denis M. Ritchie
>     ? 1975 ?
>     Bell Laboratories, Murray Hill, New Jersey 07974
>     "This paper is an introduction to programming on Unix.
>     The emphasis is on how to write programs that interface
>     to the operating system."
>
>     The C Language Calling Sequence
>     September 26, 1977
>     TMs: 77-1273-15, 77-1274-13
>     Authors: A.C. Johnson, D.M. Ritchie, M.E. Lesk
>
>     Lint, a C Program Checker
>     September 16, 1977
>     TM: 77-1273-14
>     Author: S. C. Johnson
>
>     The M4 Macor Processor
>     April 1, 1977
>     TM: 77-1273-6
>     Authors: Brian W. Kernighan, Dennis M. Ritchie
>
>     C Reference Manual
>     Dennis M. Ritchie
>     May 1, 1977
>     Murray Hill, New Jersey 07974
>
>     C Language Portability
>     September 22, 1977
>     Author: B. A. Tague
>
>     Variable Length Argument Lists in C
>     June 12, 1978
>     Author: Andrew Koenig
>
>     An Introduction to the UNIX Shell
>     July 21, 1978
>     TM: 78-1274-4
>     Author: S.R. Bourne
>
>     SED - A Non-Interactive Text Editor
>     August 15, 1978
>     TM: 78-1270-1
>     Author: Lee E. McMahon
>
>     UNIX Shell Tutorial
>     July 14, 1981
>     TM: 81-59322-5
>     Author: J. R. Mashey
>
>     Awk - A pattern Scanning and Processing Language
>     Programmer's Manual
>     June 19, 1985
>     Authors: Alfred V. Aho, Brian W. Kernighan, Peter J. Weinberger
>     TMs: 11272-850619-06TM, 11276-850619-09TM, 11273-850619-03TM
>
>     Yacc: Yet Another Compiler-Compiler
>     July 31. 1978
>     TM: 78-1273-4
>     Author: Stephen C. Johnson
>
>     RATFOR - A Preprocessor for a Rational Fortran
>     October 22, 1976
>     TM: 76-1273-10
>     Author Brian W. Kernighan
>
> Miscellaneous undated (but old) papers:
>
>     On the Security of UNIX
>     Dennis M. Ritchie
>
>     A New Input-Output Package
>     D. M. Ritchie
>
>     The Unix I/O System
>     Dennis M. Ritchie
>
>     Programming in C - A tutorial
>     Brian W. Kernighan
>     ? Date ?
>
> ==========
>
>
> ----- End forwarded message -----


From krewat at kilonet.net  Thu May 24 04:31:33 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 23 May 2018 14:31:33 -0400
Subject: [TUHS] Fwd: Old Unix manuals, TMs, etc
In-Reply-To: <201805231753.w4NHrr53017669@freefriends.org>
References: <20180523033831.GB4066@minnie.tuhs.org>
 <201805231753.w4NHrr53017669@freefriends.org>
Message-ID: <44aecdb6-b0e0-cd04-7151-38375cb7c713@kilonet.net>

Where are they located?


On 5/23/2018 1:53 PM, arnold at skeeve.com wrote:
> There are some real finds here, esp the 9th and 10th Edition manuals.
> I hope someone gets them from him...
>
> Arnold
>
> Warren Toomey <wkt at tuhs.org> wrote:
>
>> All, I've just received the following e-mail. I am not able to physically
>> get these documents, but if you are interested in them, feel free to contact
>> Mel yourself.
>>
>> Cheers, Warren
>>
>> ----- Forwarded message from meljmel-unix at yahoo.com -----
>>
>> Date: Wed, 23 May 2018 13:30:09 +1000 (AEST)
>> From: meljmel-unix at yahoo.com
>> To: Warren T <wkt at tuhs.org>
>> Subject: Old Unix manuals, TMs, etc
>>
>>
>> Hi,
>>
>> I started working at Bell Labs in 1971 and although
>> not in the computing science research department, I
>> was in another department down the hall.  As a result
>> I have many old Unix manuals, TM's and other papers
>> that I wish to dispose of.  I found you when I did a
>> search to see if there was anyone who might want them.
>> Appended below is a list of what I have.  If you are
>> interested in any of it or know who else might be, please
>> let me know.  If I can't find anyone to take them I guess
>> I'll just throw them out.
>>
>> Mel
>> meljmel-unix at yahoo.com
>>
>> ==========
>> These are the old Unix Manuals I have:
>>
>>      UNIX PROGRAMMER'S MANUAL
>>      Program Generic PG-1C300 Issue 2
>>      Published by the UNIX Support Group
>>      January, 1976
>>
>>      UNIX PROGRAMMER'S MANUAL
>>      Program Generic PG-1C300 Issue 3
>>      Published by the UNIX Support Group
>>      March, 1977
>>
>>      UNIX User's Manual
>>      Release 3.0
>>      T.A. Dolotta
>>      S. B. Olsson
>>      A.G. Petrucceli
>> 	Editors
>>      June 1980
>>      Laboratory 364
>>      Bell Telephone Laboratories, Incorporated
>>      Murray Hill, NJ 07974
>>
>>      The C Programmer's Handbook
>>      AT&T Bell Laboratories
>>      February 1984
>>      M. I. Bolsky
>>      P. G. Matthews
>>      System Training Center
>>      Copyright 1984
>>      Piscataway, New Jersey 08854
>>
>>      Unix System V Quick Reference Guide
>>      Copyright 1985 AT&T Technologies, Inc
>>      307-130
>>
>>      UNIX TIME-SHARING SYSTEM
>>      PROGRAMMER'S MANUAL
>>      Research Version
>>      Ninth Edition, Volume 1
>>      September, 1986
>>      AT&T Bell Laboratories
>>      Murray Hill, New Jersey
>>
>>      The Vi User's Handbook
>>      by Morris I. Bolsky
>>      Systems Training Center
>>      Copyright 1984 AT&T Bell Laboratories Incorporated
>>      Copyright 1985 AT&T Technologies, Inc
>>
>>      Unix Research System Programmer's Manual
>>      Tenth Edition, Volume I
>>      Computing Science Research Center
>>      Murray Hill, New Jersey
>>      1990, American Telephone and Telegraph Company
>>      Bell Laboratories Division
>>      ISBN 0-03-047532-5
>>      A. G. Hume
>>      M. D. McIlroy
>>      October, 1989
>>
>>      Unix Research System Papers
>>      Tenth Edition, Volume II
>>      Computing Science Research Center
>>      AT&T Bell Laboratories
>>      Murray Hill, New Jersey
>>      1990, American Telephone and Telegraph Company
>>      Bell Laboratories Division
>>      ISBN 0-03-047529-5
>>      A. G. Hume
>>      M. D. McIlroy
>>      January, 1990
>>
>> ----------
>>
>> These are old Unix Technical Memorandum and Papers I have:
>>
>>      The C Reference Manual
>>      January 15, 1974
>>      TM: 74-1273-1
>>      D. M. Ritchie
>>
>>      Programming in LIL: A Tutorial
>>      June 17, 1974
>>      TM: 74-1352-6
>>
>>      LIL Reference Manual
>>      June 19, 1974
>>      TM: 74-1352-8
>>
>>      A Description of the UNIX File System
>>      September 16, 1975
>>      Author J. F. Maranzano
>>
>>      The Portable C Library
>>      May 16, 1975
>>      TM: 75-1274-11
>>      Author: M. E. Lesk
>>
>>      Lex - A Lexical Analyzer Generator
>>      July 21, 1975
>>      TM: 75-1274-15
>>      Author: M. E. Lesk
>>
>>      Introduction to Scheduling and Switching under UNIX
>>      October 20, 1975
>>      TM: 75-8234-7
>>      Author: T. M. Raleigh
>>
>>      Make - A program for Maintaining Computer Programs
>>      December 5, 1975
>>      TM: 75-1274-26
>>      Author: S. I. Feldman
>>
>>      UNIX Programming
>>      Brian w. Kernighan
>>      Denis M. Ritchie
>>      ? 1975 ?
>>      Bell Laboratories, Murray Hill, New Jersey 07974
>>      "This paper is an introduction to programming on Unix.
>>      The emphasis is on how to write programs that interface
>>      to the operating system."
>>
>>      The C Language Calling Sequence
>>      September 26, 1977
>>      TMs: 77-1273-15, 77-1274-13
>>      Authors: A.C. Johnson, D.M. Ritchie, M.E. Lesk
>>
>>      Lint, a C Program Checker
>>      September 16, 1977
>>      TM: 77-1273-14
>>      Author: S. C. Johnson
>>
>>      The M4 Macor Processor
>>      April 1, 1977
>>      TM: 77-1273-6
>>      Authors: Brian W. Kernighan, Dennis M. Ritchie
>>
>>      C Reference Manual
>>      Dennis M. Ritchie
>>      May 1, 1977
>>      Murray Hill, New Jersey 07974
>>
>>      C Language Portability
>>      September 22, 1977
>>      Author: B. A. Tague
>>
>>      Variable Length Argument Lists in C
>>      June 12, 1978
>>      Author: Andrew Koenig
>>
>>      An Introduction to the UNIX Shell
>>      July 21, 1978
>>      TM: 78-1274-4
>>      Author: S.R. Bourne
>>
>>      SED - A Non-Interactive Text Editor
>>      August 15, 1978
>>      TM: 78-1270-1
>>      Author: Lee E. McMahon
>>
>>      UNIX Shell Tutorial
>>      July 14, 1981
>>      TM: 81-59322-5
>>      Author: J. R. Mashey
>>
>>      Awk - A pattern Scanning and Processing Language
>>      Programmer's Manual
>>      June 19, 1985
>>      Authors: Alfred V. Aho, Brian W. Kernighan, Peter J. Weinberger
>>      TMs: 11272-850619-06TM, 11276-850619-09TM, 11273-850619-03TM
>>
>>      Yacc: Yet Another Compiler-Compiler
>>      July 31. 1978
>>      TM: 78-1273-4
>>      Author: Stephen C. Johnson
>>
>>      RATFOR - A Preprocessor for a Rational Fortran
>>      October 22, 1976
>>      TM: 76-1273-10
>>      Author Brian W. Kernighan
>>
>> Miscellaneous undated (but old) papers:
>>
>>      On the Security of UNIX
>>      Dennis M. Ritchie
>>
>>      A New Input-Output Package
>>      D. M. Ritchie
>>
>>      The Unix I/O System
>>      Dennis M. Ritchie
>>
>>      Programming in C - A tutorial
>>      Brian W. Kernighan
>>      ? Date ?
>>
>> ==========
>>
>>
>> ----- End forwarded message -----



From mike.ab3ap at gmail.com  Thu May 24 04:39:19 2018
From: mike.ab3ap at gmail.com (Mike Markowski)
Date: Wed, 23 May 2018 14:39:19 -0400
Subject: [TUHS] Fwd: Old Unix manuals, TMs, etc
In-Reply-To: <201805231753.w4NHrr53017669@freefriends.org>
References: <20180523033831.GB4066@minnie.tuhs.org>
 <201805231753.w4NHrr53017669@freefriends.org>
Message-ID: <CANq1pfn4xvXvU7cPhDuTeOiLy=gGANTu1uaYvHgzeKCxP9nLmw@mail.gmail.com>

I contacted Mel and hope to hear back.  We should have room in our lab at
work (Army Research Lab), and I'll do my best to scan or photograph things
if it happens.  Someone else might have already been in touch, however, or
might live closer to him than me.  I'm unsure where he's located but am
guessing NJ is likely!

Mike Markowski (in eastern PA)

On Wed, May 23, 2018 at 1:53 PM, <arnold at skeeve.com> wrote:

> There are some real finds here, esp the 9th and 10th Edition manuals.
> I hope someone gets them from him...
>
> Arnold
>
> Warren Toomey <wkt at tuhs.org> wrote:
>
> > All, I've just received the following e-mail. I am not able to physically
> > get these documents, but if you are interested in them, feel free to
> contact
> > Mel yourself.
> >
> > Cheers, Warren
> >
> > ----- Forwarded message from meljmel-unix at yahoo.com -----
> >
> > Date: Wed, 23 May 2018 13:30:09 +1000 (AEST)
> > From: meljmel-unix at yahoo.com
> > To: Warren T <wkt at tuhs.org>
> > Subject: Old Unix manuals, TMs, etc
> >
> >
> > Hi,
> >
> > I started working at Bell Labs in 1971 and although
> > not in the computing science research department, I
> > was in another department down the hall.  As a result
> > I have many old Unix manuals, TM's and other papers
> > that I wish to dispose of.  I found you when I did a
> > search to see if there was anyone who might want them.
> > Appended below is a list of what I have.  If you are
> > interested in any of it or know who else might be, please
> > let me know.  If I can't find anyone to take them I guess
> > I'll just throw them out.
> >
> > Mel
> > meljmel-unix at yahoo.com
> >
> > ==========
> > These are the old Unix Manuals I have:
> >
> >     UNIX PROGRAMMER'S MANUAL
> >     Program Generic PG-1C300 Issue 2
> >     Published by the UNIX Support Group
> >     January, 1976
> >
> >     UNIX PROGRAMMER'S MANUAL
> >     Program Generic PG-1C300 Issue 3
> >     Published by the UNIX Support Group
> >     March, 1977
> >
> >     UNIX User's Manual
> >     Release 3.0
> >     T.A. Dolotta
> >     S. B. Olsson
> >     A.G. Petrucceli
> >       Editors
> >     June 1980
> >     Laboratory 364
> >     Bell Telephone Laboratories, Incorporated
> >     Murray Hill, NJ 07974
> >
> >     The C Programmer's Handbook
> >     AT&T Bell Laboratories
> >     February 1984
> >     M. I. Bolsky
> >     P. G. Matthews
> >     System Training Center
> >     Copyright 1984
> >     Piscataway, New Jersey 08854
> >
> >     Unix System V Quick Reference Guide
> >     Copyright 1985 AT&T Technologies, Inc
> >     307-130
> >
> >     UNIX TIME-SHARING SYSTEM
> >     PROGRAMMER'S MANUAL
> >     Research Version
> >     Ninth Edition, Volume 1
> >     September, 1986
> >     AT&T Bell Laboratories
> >     Murray Hill, New Jersey
> >
> >     The Vi User's Handbook
> >     by Morris I. Bolsky
> >     Systems Training Center
> >     Copyright 1984 AT&T Bell Laboratories Incorporated
> >     Copyright 1985 AT&T Technologies, Inc
> >
> >     Unix Research System Programmer's Manual
> >     Tenth Edition, Volume I
> >     Computing Science Research Center
> >     Murray Hill, New Jersey
> >     1990, American Telephone and Telegraph Company
> >     Bell Laboratories Division
> >     ISBN 0-03-047532-5
> >     A. G. Hume
> >     M. D. McIlroy
> >     October, 1989
> >
> >     Unix Research System Papers
> >     Tenth Edition, Volume II
> >     Computing Science Research Center
> >     AT&T Bell Laboratories
> >     Murray Hill, New Jersey
> >     1990, American Telephone and Telegraph Company
> >     Bell Laboratories Division
> >     ISBN 0-03-047529-5
> >     A. G. Hume
> >     M. D. McIlroy
> >     January, 1990
> >
> > ----------
> >
> > These are old Unix Technical Memorandum and Papers I have:
> >
> >     The C Reference Manual
> >     January 15, 1974
> >     TM: 74-1273-1
> >     D. M. Ritchie
> >
> >     Programming in LIL: A Tutorial
> >     June 17, 1974
> >     TM: 74-1352-6
> >
> >     LIL Reference Manual
> >     June 19, 1974
> >     TM: 74-1352-8
> >
> >     A Description of the UNIX File System
> >     September 16, 1975
> >     Author J. F. Maranzano
> >
> >     The Portable C Library
> >     May 16, 1975
> >     TM: 75-1274-11
> >     Author: M. E. Lesk
> >
> >     Lex - A Lexical Analyzer Generator
> >     July 21, 1975
> >     TM: 75-1274-15
> >     Author: M. E. Lesk
> >
> >     Introduction to Scheduling and Switching under UNIX
> >     October 20, 1975
> >     TM: 75-8234-7
> >     Author: T. M. Raleigh
> >
> >     Make - A program for Maintaining Computer Programs
> >     December 5, 1975
> >     TM: 75-1274-26
> >     Author: S. I. Feldman
> >
> >     UNIX Programming
> >     Brian w. Kernighan
> >     Denis M. Ritchie
> >     ? 1975 ?
> >     Bell Laboratories, Murray Hill, New Jersey 07974
> >     "This paper is an introduction to programming on Unix.
> >     The emphasis is on how to write programs that interface
> >     to the operating system."
> >
> >     The C Language Calling Sequence
> >     September 26, 1977
> >     TMs: 77-1273-15, 77-1274-13
> >     Authors: A.C. Johnson, D.M. Ritchie, M.E. Lesk
> >
> >     Lint, a C Program Checker
> >     September 16, 1977
> >     TM: 77-1273-14
> >     Author: S. C. Johnson
> >
> >     The M4 Macor Processor
> >     April 1, 1977
> >     TM: 77-1273-6
> >     Authors: Brian W. Kernighan, Dennis M. Ritchie
> >
> >     C Reference Manual
> >     Dennis M. Ritchie
> >     May 1, 1977
> >     Murray Hill, New Jersey 07974
> >
> >     C Language Portability
> >     September 22, 1977
> >     Author: B. A. Tague
> >
> >     Variable Length Argument Lists in C
> >     June 12, 1978
> >     Author: Andrew Koenig
> >
> >     An Introduction to the UNIX Shell
> >     July 21, 1978
> >     TM: 78-1274-4
> >     Author: S.R. Bourne
> >
> >     SED - A Non-Interactive Text Editor
> >     August 15, 1978
> >     TM: 78-1270-1
> >     Author: Lee E. McMahon
> >
> >     UNIX Shell Tutorial
> >     July 14, 1981
> >     TM: 81-59322-5
> >     Author: J. R. Mashey
> >
> >     Awk - A pattern Scanning and Processing Language
> >     Programmer's Manual
> >     June 19, 1985
> >     Authors: Alfred V. Aho, Brian W. Kernighan, Peter J. Weinberger
> >     TMs: 11272-850619-06TM, 11276-850619-09TM, 11273-850619-03TM
> >
> >     Yacc: Yet Another Compiler-Compiler
> >     July 31. 1978
> >     TM: 78-1273-4
> >     Author: Stephen C. Johnson
> >
> >     RATFOR - A Preprocessor for a Rational Fortran
> >     October 22, 1976
> >     TM: 76-1273-10
> >     Author Brian W. Kernighan
> >
> > Miscellaneous undated (but old) papers:
> >
> >     On the Security of UNIX
> >     Dennis M. Ritchie
> >
> >     A New Input-Output Package
> >     D. M. Ritchie
> >
> >     The Unix I/O System
> >     Dennis M. Ritchie
> >
> >     Programming in C - A tutorial
> >     Brian W. Kernighan
> >     ? Date ?
> >
> > ==========
> >
> >
> > ----- End forwarded message -----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180523/1b4889fe/attachment.html>

From gtaylor at tnetconsulting.net  Thu May 24 04:47:36 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 23 May 2018 12:47:36 -0600
Subject: [TUHS] Fwd: Old Unix manuals, TMs, etc
In-Reply-To: <CANq1pfn4xvXvU7cPhDuTeOiLy=gGANTu1uaYvHgzeKCxP9nLmw@mail.gmail.com>
References: <20180523033831.GB4066@minnie.tuhs.org>
 <201805231753.w4NHrr53017669@freefriends.org>
 <CANq1pfn4xvXvU7cPhDuTeOiLy=gGANTu1uaYvHgzeKCxP9nLmw@mail.gmail.com>
Message-ID: <ec3104fc-3713-4fbe-b3b8-223f3cb41568@spamtrap.tnetconsulting.net>

On 05/23/2018 12:39 PM, Mike Markowski wrote:
> I contacted Mel and hope to hear back.  …
> …  Someone else might have already been in touch,  …

I emailed Mel directly and expressed interest in the following books:

  · The M4 Marco Processor
  · SED - A Non-Interactive Text Editor
  · Awk - A pattern Scanning and Processing Language
  · Yacc: Yet Another Compiler-Compiler
  · RATFOR - A Preprocessor for a Rational Fortran

Here's my comment as to why I'm interested in the aforementioned titles.

> I am interested in the following items if they are unclaimed.  I used 
> sed and awk on a daily basis.  I also have what some would consider 
> an unhealthy interest in M4.  I've written things in M4 that some 
> might say become their own markup language for config files.  Which is 
> reminiscent of what I think YACC is supposed to be, hence my interest 
> in that Technical Memorandum, to learn more.  RATFOR, likewise.

The only title that I'd *really* /like/ to get my hands on is "The M4 
Macro Processor".  (See aforementioned unhealthy interest in M4.)

I'm quite happy to share with the community.  I just want to save the 
materials from the bin if nobody else claims them.

Note:  I've not heard anything back from Mel yet.



-- 
Grant. . . .
unix || die

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

From krewat at kilonet.net  Thu May 24 04:49:19 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 23 May 2018 14:49:19 -0400
Subject: [TUHS] Fwd: Old Unix manuals, TMs, etc
In-Reply-To: <CANq1pfn4xvXvU7cPhDuTeOiLy=gGANTu1uaYvHgzeKCxP9nLmw@mail.gmail.com>
References: <20180523033831.GB4066@minnie.tuhs.org>
 <201805231753.w4NHrr53017669@freefriends.org>
 <CANq1pfn4xvXvU7cPhDuTeOiLy=gGANTu1uaYvHgzeKCxP9nLmw@mail.gmail.com>
Message-ID: <382a8946-03b5-bc0f-7d57-77eb7e1cd59e@kilonet.net>

I'm about 40 miles out on Long Island - contact me if needed.

On 5/23/2018 2:39 PM, Mike Markowski wrote:
> I contacted Mel and hope to hear back.  We should have room in our lab 
> at work (Army Research Lab), and I'll do my best to scan or photograph 
> things if it happens.  Someone else might have already been in touch, 
> however, or might live closer to him than me.  I'm unsure where he's 
> located but am guessing NJ is likely!
>
> Mike Markowski (in eastern PA)
>
> On Wed, May 23, 2018 at 1:53 PM, <arnold at skeeve.com 
> <mailto:arnold at skeeve.com>> wrote:
>
>     There are some real finds here, esp the 9th and 10th Edition manuals.
>     I hope someone gets them from him...
>
>     Arnold
>
>     Warren Toomey <wkt at tuhs.org <mailto:wkt at tuhs.org>> wrote:
>
>     > All, I've just received the following e-mail. I am not able to
>     physically
>     > get these documents, but if you are interested in them, feel
>     free to contact
>     > Mel yourself.
>     >
>     > Cheers, Warren
>     >
>     > ----- Forwarded message from meljmel-unix at yahoo.com
>     <mailto:meljmel-unix at yahoo.com> -----
>     >
>     > Date: Wed, 23 May 2018 13:30:09 +1000 (AEST)
>     > From: meljmel-unix at yahoo.com <mailto:meljmel-unix at yahoo.com>
>     > To: Warren T <wkt at tuhs.org <mailto:wkt at tuhs.org>>
>     > Subject: Old Unix manuals, TMs, etc
>     >
>     >
>     > Hi,
>     >
>     > I started working at Bell Labs in 1971 and although
>     > not in the computing science research department, I
>     > was in another department down the hall.  As a result
>     > I have many old Unix manuals, TM's and other papers
>     > that I wish to dispose of.  I found you when I did a
>     > search to see if there was anyone who might want them.
>     > Appended below is a list of what I have.  If you are
>     > interested in any of it or know who else might be, please
>     > let me know.  If I can't find anyone to take them I guess
>     > I'll just throw them out.
>     >
>     > Mel
>     > meljmel-unix at yahoo.com <mailto:meljmel-unix at yahoo.com>
>     >
>     > ==========
>     > These are the old Unix Manuals I have:
>     >
>     >     UNIX PROGRAMMER'S MANUAL
>     >     Program Generic PG-1C300 Issue 2
>     >     Published by the UNIX Support Group
>     >     January, 1976
>     >
>     >     UNIX PROGRAMMER'S MANUAL
>     >     Program Generic PG-1C300 Issue 3
>     >     Published by the UNIX Support Group
>     >     March, 1977
>     >
>     >     UNIX User's Manual
>     >     Release 3.0
>     >     T.A. Dolotta
>     >     S. B. Olsson
>     >     A.G. Petrucceli
>     >       Editors
>     >     June 1980
>     >     Laboratory 364
>     >     Bell Telephone Laboratories, Incorporated
>     >     Murray Hill, NJ 07974
>     >
>     >     The C Programmer's Handbook
>     >     AT&T Bell Laboratories
>     >     February 1984
>     >     M. I. Bolsky
>     >     P. G. Matthews
>     >     System Training Center
>     >     Copyright 1984
>     >     Piscataway, New Jersey 08854
>     >
>     >     Unix System V Quick Reference Guide
>     >     Copyright 1985 AT&T Technologies, Inc
>     >     307-130
>     >
>     >     UNIX TIME-SHARING SYSTEM
>     >     PROGRAMMER'S MANUAL
>     >     Research Version
>     >     Ninth Edition, Volume 1
>     >     September, 1986
>     >     AT&T Bell Laboratories
>     >     Murray Hill, New Jersey
>     >
>     >     The Vi User's Handbook
>     >     by Morris I. Bolsky
>     >     Systems Training Center
>     >     Copyright 1984 AT&T Bell Laboratories Incorporated
>     >     Copyright 1985 AT&T Technologies, Inc
>     >
>     >     Unix Research System Programmer's Manual
>     >     Tenth Edition, Volume I
>     >     Computing Science Research Center
>     >     Murray Hill, New Jersey
>     >     1990, American Telephone and Telegraph Company
>     >     Bell Laboratories Division
>     >     ISBN 0-03-047532-5
>     >     A. G. Hume
>     >     M. D. McIlroy
>     >     October, 1989
>     >
>     >     Unix Research System Papers
>     >     Tenth Edition, Volume II
>     >     Computing Science Research Center
>     >     AT&T Bell Laboratories
>     >     Murray Hill, New Jersey
>     >     1990, American Telephone and Telegraph Company
>     >     Bell Laboratories Division
>     >     ISBN 0-03-047529-5
>     >     A. G. Hume
>     >     M. D. McIlroy
>     >     January, 1990
>     >
>     > ----------
>     >
>     > These are old Unix Technical Memorandum and Papers I have:
>     >
>     >     The C Reference Manual
>     >     January 15, 1974
>     >     TM: 74-1273-1
>     >     D. M. Ritchie
>     >
>     >     Programming in LIL: A Tutorial
>     >     June 17, 1974
>     >     TM: 74-1352-6
>     >
>     >     LIL Reference Manual
>     >     June 19, 1974
>     >     TM: 74-1352-8
>     >
>     >     A Description of the UNIX File System
>     >     September 16, 1975
>     >     Author J. F. Maranzano
>     >
>     >     The Portable C Library
>     >     May 16, 1975
>     >     TM: 75-1274-11
>     >     Author: M. E. Lesk
>     >
>     >     Lex - A Lexical Analyzer Generator
>     >     July 21, 1975
>     >     TM: 75-1274-15
>     >     Author: M. E. Lesk
>     >
>     >     Introduction to Scheduling and Switching under UNIX
>     >     October 20, 1975
>     >     TM: 75-8234-7
>     >     Author: T. M. Raleigh
>     >
>     >     Make - A program for Maintaining Computer Programs
>     >     December 5, 1975
>     >     TM: 75-1274-26
>     >     Author: S. I. Feldman
>     >
>     >     UNIX Programming
>     >     Brian w. Kernighan
>     >     Denis M. Ritchie
>     >     ? 1975 ?
>     >     Bell Laboratories, Murray Hill, New Jersey 07974
>     >     "This paper is an introduction to programming on Unix.
>     >     The emphasis is on how to write programs that interface
>     >     to the operating system."
>     >
>     >     The C Language Calling Sequence
>     >     September 26, 1977
>     >     TMs: 77-1273-15, 77-1274-13
>     >     Authors: A.C. Johnson, D.M. Ritchie, M.E. Lesk
>     >
>     >     Lint, a C Program Checker
>     >     September 16, 1977
>     >     TM: 77-1273-14
>     >     Author: S. C. Johnson
>     >
>     >     The M4 Macor Processor
>     >     April 1, 1977
>     >     TM: 77-1273-6
>     >     Authors: Brian W. Kernighan, Dennis M. Ritchie
>     >
>     >     C Reference Manual
>     >     Dennis M. Ritchie
>     >     May 1, 1977
>     >     Murray Hill, New Jersey 07974
>     >
>     >     C Language Portability
>     >     September 22, 1977
>     >     Author: B. A. Tague
>     >
>     >     Variable Length Argument Lists in C
>     >     June 12, 1978
>     >     Author: Andrew Koenig
>     >
>     >     An Introduction to the UNIX Shell
>     >     July 21, 1978
>     >     TM: 78-1274-4
>     >     Author: S.R. Bourne
>     >
>     >     SED - A Non-Interactive Text Editor
>     >     August 15, 1978
>     >     TM: 78-1270-1
>     >     Author: Lee E. McMahon
>     >
>     >     UNIX Shell Tutorial
>     >     July 14, 1981
>     >     TM: 81-59322-5
>     >     Author: J. R. Mashey
>     >
>     >     Awk - A pattern Scanning and Processing Language
>     >     Programmer's Manual
>     >     June 19, 1985
>     >     Authors: Alfred V. Aho, Brian W. Kernighan, Peter J. Weinberger
>     >     TMs: 11272-850619-06TM, 11276-850619-09TM, 11273-850619-03TM
>     >
>     >     Yacc: Yet Another Compiler-Compiler
>     >     July 31. 1978
>     >     TM: 78-1273-4
>     >     Author: Stephen C. Johnson
>     >
>     >     RATFOR - A Preprocessor for a Rational Fortran
>     >     October 22, 1976
>     >     TM: 76-1273-10
>     >     Author Brian W. Kernighan
>     >
>     > Miscellaneous undated (but old) papers:
>     >
>     >     On the Security of UNIX
>     >     Dennis M. Ritchie
>     >
>     >     A New Input-Output Package
>     >     D. M. Ritchie
>     >
>     >     The Unix I/O System
>     >     Dennis M. Ritchie
>     >
>     >     Programming in C - A tutorial
>     >     Brian W. Kernighan
>     >     ? Date ?
>     >
>     > ==========
>     >
>     >
>     > ----- End forwarded message -----
>
>

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

From clemc at ccc.com  Thu May 24 05:03:34 2018
From: clemc at ccc.com (Clem Cole)
Date: Wed, 23 May 2018 12:03:34 -0700
Subject: [TUHS] Fwd: Old Unix manuals, TMs, etc
In-Reply-To: <ec3104fc-3713-4fbe-b3b8-223f3cb41568@spamtrap.tnetconsulting.net>
References: <20180523033831.GB4066@minnie.tuhs.org>
 <201805231753.w4NHrr53017669@freefriends.org>
 <CANq1pfn4xvXvU7cPhDuTeOiLy=gGANTu1uaYvHgzeKCxP9nLmw@mail.gmail.com>
 <ec3104fc-3713-4fbe-b3b8-223f3cb41568@spamtrap.tnetconsulting.net>
Message-ID: <CAC20D2MNkiWykN4m-g1v2vPbj7NS11Vj7w7q06HEbTd5C94wfA@mail.gmail.com>

Grant - the troff input for all of those titles you listed should be in the
/usr/doc directory in the V6 or V7 archives that Warren has.   It's pretty
easy to push them through groff, you may have to tweak the input a little
though.   Contact me off list if you still need help,

Clem
ᐧ

On Wed, May 23, 2018 at 11:47 AM, Grant Taylor via TUHS <
tuhs at minnie.tuhs.org> wrote:

> On 05/23/2018 12:39 PM, Mike Markowski wrote:
>
>> I contacted Mel and hope to hear back.  …
>> …  Someone else might have already been in touch,  …
>>
>
> I emailed Mel directly and expressed interest in the following books:
>
>  · The M4 Marco Processor
>  · SED - A Non-Interactive Text Editor
>  · Awk - A pattern Scanning and Processing Language
>  · Yacc: Yet Another Compiler-Compiler
>  · RATFOR - A Preprocessor for a Rational Fortran
>
> Here's my comment as to why I'm interested in the aforementioned titles.
>
> I am interested in the following items if they are unclaimed.  I used sed
>> and awk on a daily basis.  I also have what some would consider an
>> unhealthy interest in M4.  I've written things in M4 that some might say
>> become their own markup language for config files.  Which is reminiscent of
>> what I think YACC is supposed to be, hence my interest in that Technical
>> Memorandum, to learn more.  RATFOR, likewise.
>>
>
> The only title that I'd *really* /like/ to get my hands on is "The M4
> Macro Processor".  (See aforementioned unhealthy interest in M4.)
>
> I'm quite happy to share with the community.  I just want to save the
> materials from the bin if nobody else claims them.
>
> Note:  I've not heard anything back from Mel yet.
>
>
>
> --
> Grant. . . .
> unix || die
>
>
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180523/3cf6624c/attachment.html>

From wkt at tuhs.org  Thu May 24 11:09:13 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 24 May 2018 11:09:13 +1000
Subject: [TUHS] Old Unix manuals, TMs, etc
Message-ID: <20180524010913.GB10344@minnie.tuhs.org>

----- Forwarded message from meljmel-unix at yahoo.com -----

Warren,

Thanks for your help.  To my amazement in one day I received
8 requests for the documents you posted on the TUHS mailing
list for me.  If you think it's appropriate you can post that
everything has been claimed.  I will be mailing the Unix TMs
and other papers to Robert Swierczek <rmswierczek at gmail.com>
who said he will scan any one-of-a-kind items and make them
available to you and TUHS.  The manuals/books will be going
to someone else who very much wanted them.

Mel

----- End forwarded message -----


From lars at nocrew.org  Thu May 24 16:14:44 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Thu, 24 May 2018 06:14:44 +0000
Subject: [TUHS] History of top
Message-ID: <7wzi0p60mj.fsf@junk.nocrew.org>

Hello,

I'm curious about the history of "top".  As far as I can see, the first
version was written by William LeFebvre and posted to net.sources in
1984.  I'm surprised it appeared that late.  Were there any other
versions or similar Unix programs before that?

Best regards,
Lars Brinkhoff


From dave at horsfall.org  Thu May 24 19:35:54 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 24 May 2018 19:35:54 +1000 (EST)
Subject: [TUHS] History of top
In-Reply-To: <7wzi0p60mj.fsf@junk.nocrew.org>
References: <7wzi0p60mj.fsf@junk.nocrew.org>
Message-ID: <alpine.BSF.2.21.999.1805241928420.810@aneurin.horsfall.org>

On Thu, 24 May 2018, Lars Brinkhoff wrote:

> I'm curious about the history of "top".  As far as I can see, the first 
> version was written by William LeFebvre and posted to net.sources in 
> 1984.  I'm surprised it appeared that late.  Were there any other 
> versions or similar Unix programs before that?

My memory is failing me, but I seem to recall that here in Oz we had a
similar program, possibly written by Piers Lauder?  Or IanJ?

It was called "ss" or something, for "system status", and I dimly recall
modifying it (or suggesting same) to show the hostname.

-- Dave


From jason-tuhs at shalott.net  Thu May 24 20:58:38 2018
From: jason-tuhs at shalott.net (jason-tuhs at shalott.net)
Date: Thu, 24 May 2018 03:58:38 -0700 (PDT)
Subject: [TUHS] History of top
In-Reply-To: <alpine.BSF.2.21.999.1805241928420.810@aneurin.horsfall.org>
References: <7wzi0p60mj.fsf@junk.nocrew.org>
 <alpine.BSF.2.21.999.1805241928420.810@aneurin.horsfall.org>
Message-ID: <alpine.LRH.2.21.1805240344290.11938@waffle.shalott.net>


>> I'm curious about the history of "top".  As far as I can see, the first 
>> version was written by William LeFebvre and posted to net.sources in 
>> 1984. I'm surprised it appeared that late.  Were there any other 
>> versions or similar Unix programs before that?

> My memory is failing me, but I seem to recall that here in Oz we had a 
> similar program, possibly written by Piers Lauder?  Or IanJ?
>
> It was called "ss" or something, for "system status", and I dimly recall 
> modifying it (or suggesting same) to show the hostname.

BSD's systat is similar.

The current manpage says it was released in 4.3 BSD, but the copyright 
notices in the code go back to 1980, with comments crediting "Bill Reeves 
at Lucasfilm."

https://www.retro11.de/ouxr/211bsd/usr/src/ucb/PORT/systat/pigs.c.html


  -Jason



From mike.ab3ap at gmail.com  Thu May 24 21:18:58 2018
From: mike.ab3ap at gmail.com (Mike Markowski)
Date: Thu, 24 May 2018 07:18:58 -0400
Subject: [TUHS] Old Unix manuals, TMs, etc
In-Reply-To: <20180524010913.GB10344@minnie.tuhs.org>
References: <20180524010913.GB10344@minnie.tuhs.org>
Message-ID: <CANq1pfmAZJdXKc4N_g8wRmm4PbMEhSEttbmvOmatTcBXw_3xFQ@mail.gmail.com>

On Wed, May 23, 2018 at 9:09 PM, Warren Toomey <wkt at tuhs.org> wrote:

> ----- Forwarded message from meljmel-unix at yahoo.com -----
>
> Warren,
>
> Thanks for your help.  To my amazement in one day I received
> 8 requests for the documents you posted on the TUHS mailing
> list for me.  If you think it's appropriate you can post that
> everything has been claimed.  I will be mailing the Unix TMs
> and other papers to Robert Swierczek <rmswierczek at gmail.com>
> who said he will scan any one-of-a-kind items and make them
> available to you and TUHS.  The manuals/books will be going
> to someone else who very much wanted them.
>
> Mel
>
>
> ----- End forwarded message -----
>

Thanks, Warren.  As an fyi to the group, I was too late with my request and
the Army Research Lab's Tech Library will not be the lucky recipient.

Mike Markowksi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180524/a80bae1b/attachment.html>

From jnc at mercury.lcs.mit.edu  Thu May 24 22:20:21 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu, 24 May 2018 08:20:21 -0400 (EDT)
Subject: [TUHS] History of top
Message-ID: <20180524122021.857BC18C09A@mercury.lcs.mit.edu>

    > From: Lars Brinkhoff

    > I'm surprised it appeared that late. Were there any other versions or
    > similar Unix programs before that?

The MIT ~PWB1 system had a thing called 'dpy', I think written at MIT based on
'ps' (and no doubt inspired by ITS' PEEK), which had similar functionality.
Seems like it never escaped, though. Man page and source here:

  http://ana-3.lcs.mit.edu/~jnc/tech/unix/man1/dpy.1
  http://ana-3.lcs.mit.edu/~jnc/tech/unix/s1/dpy.c

The top of my hard-copy man page says 'November 1977', but I suspect it dates
back further than that.

     Noel



From clemc at ccc.com  Fri May 25 00:09:43 2018
From: clemc at ccc.com (Clem Cole)
Date: Thu, 24 May 2018 07:09:43 -0700
Subject: [TUHS] History of top
In-Reply-To: <20180524122021.857BC18C09A@mercury.lcs.mit.edu>
References: <20180524122021.857BC18C09A@mercury.lcs.mit.edu>
Message-ID: <CAC20D2NkAYBCq2xF-2aO6ep-zvdBy1J=a5PszcviO2JN1hzu8g@mail.gmail.com>

On Thu, May 24, 2018 at 5:20 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Lars Brinkhoff
>
>     > I'm surprised it appeared that late. Were there any other versions or
>     > similar Unix programs before that?
>
> The MIT ~PWB1 system had a thing called 'dpy', I think written at MIT
> based on
> 'ps' (and no doubt inspired by ITS' PEEK), which had similar functionality.
> Seems like it never escaped, though. Man page and source here:
>
>   http://ana-3.lcs.mit.edu/~jnc/tech/unix/man1/dpy.1
>   http://ana-3.lcs.mit.edu/~jnc/tech/unix/s1/dpy.c
>
> The top of my hard-copy man page says 'November 1977', but I suspect it
> dates
> back further than that.
>
>      Noel
>
> There were a bunch of these​ - originally mods off of ps(1) that kicked
around at different UNIX sites.   CMU's locally hacked ps was similar to
dpy and BSD's *stat programs (systatm vmstat, ...). The problem all of
these had was getting the data out of the OS.   The original scheme used by
ps being it ran setuid/gid, and then was able to opening /dev/kmem and
reading interesting data structures the kernel.  A big problem was that ps
and the OS had to be compiled with exactly the same headers and you really
had to know the layout and the obvious security concerns of using
setuid/gid to control things.

FreeBSD's sysctl and V8's /proc would finally clean that up by making a
formal interface to the OS and controlling what was available in a more
granular manner both from a data structure as well as security path.
 Although before /proc came to being (/proc was a UNIX innovation), the
sysctl(2) like interface was reinvented a few times, as it really was not
new with UNIX.   It's very much like a similar scheme that came from TOPS,
RSX and VMS (which the Masscomp system parroted being ex-DECies almost
exactly the same as VMS).  I believe that Sun had something also, but  I've
forgotten its name, Larry might remember.   But so did  DG-OS and many of
the other commercial UNIXs snd I would not be surprised if many University
hacks did it also.

My favorite of all of these was the one that George Gobble at Purdue built
when he did the Dual VAX.   He also spliced an PDP-11 on the UBA on the
their Dual Vax System and wrote a program that like top(1) refreshed itself
(at least as fast as once a sec IIRC).  It would read the VAX memory and
then display what the OS was doing in real time.   He did a neat talk in a
mid-1980's USENIX with a movie from it.   They found an interesting bug in
the BSD scheduler which had been there since 6th edition, which had never
really been noticed until people could visually watch what as happening and
actually get enough information about how processes were being handled.
[This was also around the time one of the first '0-day' issues with UNIX
was found by ghg and team which is now a cute story but at the time was
quite worrisome].


​The best I remember, the popularity of top(1) started because it was first
released as USENET came of age; and thus it got wide distribution.  By that
point, ​ *BSD was the 'standard' in most places, and this the *stat
commands were pretty well known. The top(1) program consolidated these into
a single one, plus it used the curses library so it could be left running
on a glass TTY.   As Vaxen were being used as large timesharing systems for
Universities to teach with, such a program was handy for the sys admins to
keep an eye on what was happening.

Clem

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

From ron at ronnatalie.com  Fri May 25 00:43:54 2018
From: ron at ronnatalie.com (Ronald Natalie)
Date: Thu, 24 May 2018 10:43:54 -0400
Subject: [TUHS] History of top
In-Reply-To: <CAC20D2NkAYBCq2xF-2aO6ep-zvdBy1J=a5PszcviO2JN1hzu8g@mail.gmail.com>
References: <20180524122021.857BC18C09A@mercury.lcs.mit.edu>
 <CAC20D2NkAYBCq2xF-2aO6ep-zvdBy1J=a5PszcviO2JN1hzu8g@mail.gmail.com>
Message-ID: <7E6D7CCC-4077-4A62-87FE-F58A2CCCD8A9@ronnatalie.com>


I remember George’s Unibus monitoring hack.    It was noted at the time that he didn’t have any bus terminators.   The SBI had CPUs on both ends and the Unibus had the monitoring 11/23 at the far end.

We built one of the Dual vaxes at BRL (BRL-VGR).   It was pretty straight forward, just needed to obtain (well we had it fabbed) a new cardcage and redo a special set of SBI cables to be an mirror image.
It was amazing how cheap this was compared to the 782 abomination (not to even mention the VaxCluster and it’s horrendous HSC50 that I ended up administering later at RU).



From ron at ronnatalie.com  Fri May 25 00:50:03 2018
From: ron at ronnatalie.com (Ronald Natalie)
Date: Thu, 24 May 2018 10:50:03 -0400
Subject: [TUHS] Control-T (was top)
In-Reply-To: <CAC20D2NkAYBCq2xF-2aO6ep-zvdBy1J=a5PszcviO2JN1hzu8g@mail.gmail.com>
References: <20180524122021.857BC18C09A@mercury.lcs.mit.edu>
 <CAC20D2NkAYBCq2xF-2aO6ep-zvdBy1J=a5PszcviO2JN1hzu8g@mail.gmail.com>
Message-ID: <DF20553B-A166-485F-8965-E3AC0ECB91FA@ronnatalie.com>


Another related creeping featurism was the integration of the control-T feature that was prevalent in many of the DEC 10/20 OSs.
When Mike Muuss was doing some scheduling tweaks he decided that being able to list out all the processes on the terminal with a few parameters (he had the weighted load averages at the top of the list).
It became real handy for me when I set out to reverse engineer how the Csh used job control as well.

For those who aren’t old time kernel hacks, there are two structures associated with every process.   The “proc” structure has essential things like uid/gid and memory sizes and priority.   The proc structure always was resident making it ripe pickings for control-T.    More detailed information including the stack of the process (and hence the command line arguments), were in the user structure.    While the user structure of the currently running process was always resident (and on the PDP-11 at 140000, which meant you could use the display register to display the UID to figure out who the CPU hog was).    This made it harder for the “ps”-like things to get.    I finally relented and put a copy of the first few bytes of the arg list in the proc structure.




From clemc at ccc.com  Fri May 25 01:01:14 2018
From: clemc at ccc.com (Clem Cole)
Date: Thu, 24 May 2018 08:01:14 -0700
Subject: [TUHS] Control-T (was top)
In-Reply-To: <DF20553B-A166-485F-8965-E3AC0ECB91FA@ronnatalie.com>
References: <20180524122021.857BC18C09A@mercury.lcs.mit.edu>
 <CAC20D2NkAYBCq2xF-2aO6ep-zvdBy1J=a5PszcviO2JN1hzu8g@mail.gmail.com>
 <DF20553B-A166-485F-8965-E3AC0ECB91FA@ronnatalie.com>
Message-ID: <CAC20D2OtUMSq85MtopyAouh6yrRjRwSG+fVW4Pb1mP2jnEMvuQ@mail.gmail.com>

below...

On Thu, May 24, 2018 at 7:50 AM, Ronald Natalie <ron at ronnatalie.com> wrote:

>
> Another related creeping featurism was the integration of the control-T
> feature that was prevalent in many of the DEC 10/20 OSs.
>
​Yeah I still sometimes missed that hack.  Zimmerman (of EMACS fame) put it
into the Masscomp tty handler.  He may have had it in an MIT system.   That
was the best UNIX version I ever used.​

That said, with a window manager on my modern Mac, I just leave 'Activity
Monitor' running, so I don't need it like I did when we ran on glass ttys.

​Actually, my favorite Control-T story is not from UNIX, but from TwinEx.
 When you typed Control-T on that system, it would reply with '*running,
load average, ...mumble stats, more mumble and more stats*.'   In the late
1970s, Stanford had a DEC System-20 called 'LOTS' which they bought for the
undergrads for teaching.​   Somebody (who will be left nameless) modified
the OS so the 'running' part changed depending on value of the load
average.  * i.e.* running, jogging, walking, crawling.   But the
administration made them remove the hack when it came back as 'dying' most
of the time.

Clem

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

From krewat at kilonet.net  Fri May 25 01:08:24 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Thu, 24 May 2018 11:08:24 -0400
Subject: [TUHS] Control-T (was top)
In-Reply-To: <DF20553B-A166-485F-8965-E3AC0ECB91FA@ronnatalie.com>
References: <20180524122021.857BC18C09A@mercury.lcs.mit.edu>
 <CAC20D2NkAYBCq2xF-2aO6ep-zvdBy1J=a5PszcviO2JN1hzu8g@mail.gmail.com>
 <DF20553B-A166-485F-8965-E3AC0ECB91FA@ronnatalie.com>
Message-ID: <e4e0b668-e1b0-8743-2eee-d4616c579ead@kilonet.net>

On 5/24/2018 10:50 AM, Ronald Natalie wrote:
> Another related creeping featurism was the integration of the control-T feature that was prevalent in many of the DEC 10/20 OSs.
Control-T in TOPS-10 was done straight out of the monitor. If you were 
on a slow 300 baud or 110 baud terminal on say a DZ11*, and kept hitting 
Control-T really fast, you'd slow down everything else on the machine as 
there was no buffering of serial TTY I/O and the monitor would sit and 
wait for each character to be transmitted.

ak

* a DZ11 is UNIBUS and was only available on a KS10 - but I'd imagine 
any straight serial port on a KA/KI/KL10 would do the same. If you were, 
say, on a DCA mux, that had a 14.4K serial link straight into the 
UNIBUS, there was much less of an effect.


From lars at nocrew.org  Fri May 25 01:48:25 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Thu, 24 May 2018 15:48:25 +0000
Subject: [TUHS] Control-T (was top)
In-Reply-To: <CAC20D2OtUMSq85MtopyAouh6yrRjRwSG+fVW4Pb1mP2jnEMvuQ@mail.gmail.com>
 (Clem Cole's message of "Thu, 24 May 2018 08:01:14 -0700")
References: <20180524122021.857BC18C09A@mercury.lcs.mit.edu>
 <CAC20D2NkAYBCq2xF-2aO6ep-zvdBy1J=a5PszcviO2JN1hzu8g@mail.gmail.com>
 <DF20553B-A166-485F-8965-E3AC0ECB91FA@ronnatalie.com>
 <CAC20D2OtUMSq85MtopyAouh6yrRjRwSG+fVW4Pb1mP2jnEMvuQ@mail.gmail.com>
Message-ID: <7wr2m13vhy.fsf@junk.nocrew.org>

Clem Cole wrote:
> Stanford had a DEC System-20 called 'LOTS' which they bought for the
> undergrads for teaching.​ Somebody (who will be left nameless) modified
> the OS so the 'running' part changed depending on value of the load
> average. i.e.  running, jogging, walking, crawling.

Another PDP-10 operating system (from MIT) had this:
Warp (fastest), zoom, fly, run, walk, tenex, multix (slowest).


From jpl.jpl at gmail.com  Fri May 25 06:57:28 2018
From: jpl.jpl at gmail.com (John P. Linderman)
Date: Thu, 24 May 2018 16:57:28 -0400
Subject: [TUHS] Fwd: unix
In-Reply-To: <34739FA1-36C3-480B-854A-078E2AFF0D9C@gmail.com>
References: <34739FA1-36C3-480B-854A-078E2AFF0D9C@gmail.com>
Message-ID: <CAC0cEp_bot9MbuB9o-tUkY80w1cBEL4eWisKQjoVmZkvHAnsYw@mail.gmail.com>

A worthy question.
---------- Forwarded message ----------
From: Richard Haight <dickhaight at gmail.com>
Date: Thu, May 24, 2018 at 2:53 PM
Subject: unix
To: jpl.jpl at gmail.com


Recently I was asked if I still had a spare deck of the Unix-25 cards.
Hadn’t thought of them in years. But it made me realize that 2019 will be
the 50th. Is anyone working on something to mark the anniversary?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180524/e0a7993a/attachment.html>

From aksr at t-com.me  Fri May 25 17:01:03 2018
From: aksr at t-com.me (aksr)
Date: Fri, 25 May 2018 09:01:03 +0200
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <CAGfO01yzDm6hf0S=FLBB6EUm-aepxTvWCycUgCDNo9n7BWgNzw@mail.gmail.com>
References: <201805152305.w4FN5HnZ006290@coolidge.cs.Dartmouth.EDU>
 <CAGfO01yzDm6hf0S=FLBB6EUm-aepxTvWCycUgCDNo9n7BWgNzw@mail.gmail.com>
Message-ID: <20180525070103.GA4673@lap>

On Wed, May 16, 2018 at 09:12:22AM +1000, Noel Hunt wrote:
> I have built ideal several times over the years. I have
> only tested it on the samples in the manual, in particular
> the diagram Brian Kernighan used for the 'cbt' documentation.
> I believe there was one bug, which was found by John Mackin
> at Sydney University many years ago so the code I have has
> that documented, well, patched.

If it's possible, I would like to see that code.


Thanks,
Alexander


From dave at horsfall.org  Fri May 25 17:40:28 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 25 May 2018 17:40:28 +1000 (EST)
Subject: [TUHS] Who used *ROFF?
In-Reply-To: <20180525070103.GA4673@lap>
References: <201805152305.w4FN5HnZ006290@coolidge.cs.Dartmouth.EDU>
 <CAGfO01yzDm6hf0S=FLBB6EUm-aepxTvWCycUgCDNo9n7BWgNzw@mail.gmail.com>
 <20180525070103.GA4673@lap>
Message-ID: <alpine.BSF.2.21.999.1805251736420.810@aneurin.horsfall.org>

On Fri, 25 May 2018, aksr wrote:

>> I believe there was one bug, which was found by John Mackin at Sydney 
>> University many years ago so the code I have has that documented, well, 
>> patched.
>
> If it's possible, I would like to see that code.

RIP John "Iron Bar" Mackin; he and I had some memorable fights, over on 
aus.flame...

-- Dave


From dave at horsfall.org  Mon May 28 08:34:05 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 28 May 2018 08:34:05 +1000 (EST)
Subject: [TUHS] Alan Turing and his computable numbers
Message-ID: <alpine.BSF.2.21.999.1805280827080.813@aneurin.horsfall.org>

On this day in 1936, notable mathematician Alan Turing submitted his 
thesis "On Computable Numbers", thereby laying the foundations for today's 
computers.

Sigh; if only he hadn't eaten that apple...  And we'll never know whether 
it was murder or suicide.

-- Dave


From toby at telegraphics.com.au  Mon May 28 08:38:59 2018
From: toby at telegraphics.com.au (Toby Thain)
Date: Sun, 27 May 2018 18:38:59 -0400
Subject: [TUHS] Alan Turing and his computable numbers
In-Reply-To: <alpine.BSF.2.21.999.1805280827080.813@aneurin.horsfall.org>
References: <alpine.BSF.2.21.999.1805280827080.813@aneurin.horsfall.org>
Message-ID: <e9097e4b-7ed9-3590-b88a-eb04e0eb9ba2@telegraphics.com.au>

On 2018-05-27 6:34 PM, Dave Horsfall wrote:
> On this day in 1936, notable mathematician Alan Turing submitted his
> thesis "On Computable Numbers", thereby laying the foundations for
> today's computers.
> 
> Sigh; if only he hadn't eaten that apple...  And we'll never know
> whether it was murder or suicide.

What's the "murder" theory?

I thought the question was whether it was deliberate suicide or a lab
accident. Not that I'm a Turing expert...

--Toby


> 
> -- Dave
> 



From dave at horsfall.org  Mon May 28 09:14:05 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 28 May 2018 09:14:05 +1000 (EST)
Subject: [TUHS] Alan Turing and his computable numbers
In-Reply-To: <e9097e4b-7ed9-3590-b88a-eb04e0eb9ba2@telegraphics.com.au>
References: <alpine.BSF.2.21.999.1805280827080.813@aneurin.horsfall.org>
 <e9097e4b-7ed9-3590-b88a-eb04e0eb9ba2@telegraphics.com.au>
Message-ID: <alpine.BSF.2.21.999.1805280859320.813@aneurin.horsfall.org>

On Sun, 27 May 2018, Toby Thain wrote:

>> Sigh; if only he hadn't eaten that apple...  And we'll never know 
>> whether it was murder or suicide.
>
> What's the "murder" theory?

A jealous lover, apparently, who knew that he liked apples.

> I thought the question was whether it was deliberate suicide or a lab
> accident. Not that I'm a Turing expert...

Can't remember where I saw it (it was a book on Turing's life), but given 
that homosexuality was illegal at the time, no doubt the police would've 
had an interest in spreading the story...  You know, "this is what can 
happen to you if you become a homo" etc (despite the fact that it's quite 
common amongst mammals).

-- Dave

From peter at rulingia.com  Mon May 28 09:54:57 2018
From: peter at rulingia.com (Peter Jeremy)
Date: Mon, 28 May 2018 09:54:57 +1000
Subject: [TUHS] Alan Turing and his computable numbers
In-Reply-To: <e9097e4b-7ed9-3590-b88a-eb04e0eb9ba2@telegraphics.com.au>
References: <alpine.BSF.2.21.999.1805280827080.813@aneurin.horsfall.org>
 <e9097e4b-7ed9-3590-b88a-eb04e0eb9ba2@telegraphics.com.au>
Message-ID: <20180527235457.GE96747@server.rulingia.com>

On 2018-May-27 18:38:59 -0400, Toby Thain <toby at telegraphics.com.au> wrote:
>> Sigh; if only he hadn't eaten that apple...  And we'll never know
>> whether it was murder or suicide.
>
>What's the "murder" theory?

I hadn't heard the "murder" theory but a quick search turned up:
https://www.warhistoryonline.com/war-articles/was-alan-turing-murdered-author-roger-bristow-says-yes.html

I guess that's possible but I thought he'd lost all his clearances.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180528/43d66a1c/attachment.sig>

From dave at horsfall.org  Mon May 28 18:13:52 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 28 May 2018 18:13:52 +1000 (EST)
Subject: [TUHS] Alan Turing and his computable numbers
In-Reply-To: <20180527235457.GE96747@server.rulingia.com>
References: <alpine.BSF.2.21.999.1805280827080.813@aneurin.horsfall.org>
 <e9097e4b-7ed9-3590-b88a-eb04e0eb9ba2@telegraphics.com.au>
 <20180527235457.GE96747@server.rulingia.com>
Message-ID: <alpine.BSF.2.21.999.1805281752021.813@aneurin.horsfall.org>

On Mon, 28 May 2018, Peter Jeremy wrote:

>> What's the "murder" theory?
>
> I hadn't heard the "murder" theory but a quick search turned up: 
> https://www.warhistoryonline.com/war-articles/was-alan-turing-murdered-author-roger-bristow-says-yes.html

Fascinating article; one thing's for sure though: if the FBI was involved 
then we'll never know for sure.

> I guess that's possible but I thought he'd lost all his clearances.

Yeah, but my conspiracist side says that because he knew about Verona and 
could possibly be compromised, someone wanted him very dead...

-- Dave


From lars at nocrew.org  Mon May 28 20:31:56 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Mon, 28 May 2018 10:31:56 +0000
Subject: [TUHS] History of top
In-Reply-To: <20180524122021.857BC18C09A@mercury.lcs.mit.edu> (Noel Chiappa's
 message of "Thu, 24 May 2018 08:20:21 -0400 (EDT)")
References: <20180524122021.857BC18C09A@mercury.lcs.mit.edu>
Message-ID: <7wlgc4ystf.fsf@junk.nocrew.org>

> The MIT ~PWB1 system had a thing called 'dpy', I think written at MIT
> based on 'ps' (and no doubt inspired by ITS' PEEK)

Indeed my hidden agenda was to find a link between top and PEEK.
But apparently the inspiration came from VMS:

http://web.archive.org/web/20170527120123/http://www.unixtop.org:80/about.shtml


From paul.winalski at gmail.com  Tue May 29 08:32:23 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Mon, 28 May 2018 18:32:23 -0400
Subject: [TUHS] Control-T (was top)
In-Reply-To: <e4e0b668-e1b0-8743-2eee-d4616c579ead@kilonet.net>
References: <20180524122021.857BC18C09A@mercury.lcs.mit.edu>
 <CAC20D2NkAYBCq2xF-2aO6ep-zvdBy1J=a5PszcviO2JN1hzu8g@mail.gmail.com>
 <DF20553B-A166-485F-8965-E3AC0ECB91FA@ronnatalie.com>
 <e4e0b668-e1b0-8743-2eee-d4616c579ead@kilonet.net>
Message-ID: <CABH=_VQ+R4svobbrcX12sL67qBN_+icViH8L=T+wx_csJ2KebA@mail.gmail.com>

On 5/24/18, Arthur Krewat <krewat at kilonet.net> wrote:
>
> * a DZ11 is UNIBUS and was only available on a KS10 - but I'd imagine
> any straight serial port on a KA/KI/KL10 would do the same. If you were,
> say, on a DCA mux, that had a 14.4K serial link straight into the
> UNIBUS, there was much less of an effect.

DZ11s were available on PDP-11s and VAXen as well as the KS10.
Because the controller had no buffer it was dirt cheap.  OK, perhaps,
for a realtime or lab application, but if you were doing timesharing
it could bring the CPU to its knees in short order.  Some idiot
decided to use the same idea (no buffer in the controller) to reduce
the cost of the TU58 (aka DECtape II),  Unlike the original DECtape,
which was extremely reliable, the TU58 was prone to frequent data
overrun and underrun errors even if you set things up such that it got
top scheduler priority.

-Paul W.


From clemc at ccc.com  Tue May 29 09:11:22 2018
From: clemc at ccc.com (Clem cole)
Date: Mon, 28 May 2018 19:11:22 -0400
Subject: [TUHS] Control-T (was top)
In-Reply-To: <CABH=_VQ+R4svobbrcX12sL67qBN_+icViH8L=T+wx_csJ2KebA@mail.gmail.com>
References: <20180524122021.857BC18C09A@mercury.lcs.mit.edu>
 <CAC20D2NkAYBCq2xF-2aO6ep-zvdBy1J=a5PszcviO2JN1hzu8g@mail.gmail.com>
 <DF20553B-A166-485F-8965-E3AC0ECB91FA@ronnatalie.com>
 <e4e0b668-e1b0-8743-2eee-d4616c579ead@kilonet.net>
 <CABH=_VQ+R4svobbrcX12sL67qBN_+icViH8L=T+wx_csJ2KebA@mail.gmail.com>
Message-ID: <1A91F61B-90CB-4B19-B800-D5B41D09C831@ccc.com>

And the other issue was besides not enough buffering DZ11s and the TU58 assumes  software (^S/^Q) for the flow control (DH11s with the DM11 option has hardware (RTS/CTS) to control the I/O rate.  So this of course made 8bit data diificult too. And as Paul points out, with HW flow the priority could have been lower. But the HW folks assumed a so called 3 wire interface because they thought they were saving money.  

A few years later when people tried to put high speed modems like the Trailblazers on them, let’s say the Unix folks quickly abandoned any hope.   Ken O’Humundro at Able Computer has quite a business in his ‘DHDM’ board that was cheaper than the DZ, more ports, full DMA and of course full hardware flow control.  

Btw it was not just DEC.  The original hw version of Masscomp MC500 had the same issue in cpu board brcause Jeff Mitchell (who had been one the 11/34 designer) did not know any better. I fixed the MPU board when it was relaided out and our first 8 port serial controller had rewritten microcode from the original OEM to allow trailblazers to work right (fortunately then HW was there on the serial board but it was just being ignored in the original firmware).

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

> On May 28, 2018, at 6:32 PM, Paul Winalski <paul.winalski at gmail.com> wrote:
> 
>> On 5/24/18, Arthur Krewat <krewat at kilonet.net> wrote:
>> 
>> * a DZ11 is UNIBUS and was only available on a KS10 - but I'd imagine
>> any straight serial port on a KA/KI/KL10 would do the same. If you were,
>> say, on a DCA mux, that had a 14.4K serial link straight into the
>> UNIBUS, there was much less of an effect.
> 
> DZ11s were available on PDP-11s and VAXen as well as the KS10.
> Because the controller had no buffer it was dirt cheap.  OK, perhaps,
> for a realtime or lab application, but if you were doing timesharing
> it could bring the CPU to its knees in short order.  Some idiot
> decided to use the same idea (no buffer in the controller) to reduce
> the cost of the TU58 (aka DECtape II),  Unlike the original DECtape,
> which was extremely reliable, the TU58 was prone to frequent data
> overrun and underrun errors even if you set things up such that it got
> top scheduler priority.
> 
> -Paul W.


From krewat at kilonet.net  Tue May 29 09:32:05 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Mon, 28 May 2018 19:32:05 -0400
Subject: [TUHS] Control-T (was top)
In-Reply-To: <1A91F61B-90CB-4B19-B800-D5B41D09C831@ccc.com>
References: <20180524122021.857BC18C09A@mercury.lcs.mit.edu>
 <CAC20D2NkAYBCq2xF-2aO6ep-zvdBy1J=a5PszcviO2JN1hzu8g@mail.gmail.com>
 <DF20553B-A166-485F-8965-E3AC0ECB91FA@ronnatalie.com>
 <e4e0b668-e1b0-8743-2eee-d4616c579ead@kilonet.net>
 <CABH=_VQ+R4svobbrcX12sL67qBN_+icViH8L=T+wx_csJ2KebA@mail.gmail.com>
 <1A91F61B-90CB-4B19-B800-D5B41D09C831@ccc.com>
Message-ID: <56824524-1d3b-4405-ca20-faa1731fbf66@kilonet.net>


On 5/28/2018 7:11 PM, Clem cole wrote:
> A few years later when people tried to put high speed modems like the Trailblazers on them
Hence why, in the early 90's, I used an 80486DX2-66 PC with 16550 UARTs 
for modems instead of the Sun IPC to do USENET ;)




From beebe at math.utah.edu  Tue May 29 08:43:13 2018
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Mon, 28 May 2018 16:43:13 -0600
Subject: [TUHS] History of top
Message-ID: <CMM.0.95.0.1527547393.beebe@gamma.math.utah.edu>

Lars Brinkhoff <lars at nocrew.org> reports on Mon, 28 May 2018 10:31:56 +0000:

>> But apparently the inspiration came from VMS:
>> http://web.archive.org/web/20170527120123/http://www.unixtop.org:80/about.shtml

That link contains the statement

>> The first version of top was completed in the early part of 1984.

However, on TOPS-20, which was developed several years before VMS, but
still from the same corporation, we had the sysdpy utility which
produced a similar display as top does.  

>From my source archives, I find in score/4-utilities/sysdpy.mac the
ending comments:

	;462 -  DON'T DO A RLJFN AFTER A CLOSF IN NEWDPY
	;<4.UTILITIES>SYSDPY.MAC.58,  2-Jun-79 14:15:54, EDIT BY DBELL
	;461 -  START USING STANDARD TOPS-20 EDIT HISTORY CONVENTIONS, AND
	;       REMOVE OLD EDIT HISTORY.
	...
	;COPYRIGHT (C) 1976,1977,1978,1979 BY DIGITAL EQUIPMENT \
         CORPORATION, MAYNARD, MASS.

I therefore expect that there was 460-entry list of log messages that
predated 2-Jun-1979, and likely went back a few years.  Two other
versions of sysdpy.mac in my archives have also dropped log messages
before 461.

Even before TOPS-20, on the CDC 6400 SCOPE operating system, there was
a similar tool (whose name I no longer recall) that gave a
continuously updated display of system-wide process activity. That was
available in at least late 1973.

I suspect that top-like displays were added to most other interactive
operating systems, as soon as screen terminals made updates convenient
without wasting console paper.  One of the first questions likely to
be asked by interactive users is "what is my job doing?".  

In a TOPS-20 terminal window, you could type Ctl-T to get a one-line
status report for the job that was currently running from your
terminal.  For many users, that was preferable to sysdpy, and it was
heavily used.



-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------


From clemc at ccc.com  Tue May 29 10:16:00 2018
From: clemc at ccc.com (Clem cole)
Date: Mon, 28 May 2018 20:16:00 -0400
Subject: [TUHS] History of top
In-Reply-To: <CMM.0.95.0.1527547393.beebe@gamma.math.utah.edu>
References: <CMM.0.95.0.1527547393.beebe@gamma.math.utah.edu>
Message-ID: <827486DE-0795-4E99-A0D2-5BDC7542AE53@ccc.com>

Below

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

> On May 28, 2018, at 6:43 PM, Nelson H. F. Beebe <beebe at math.utah.edu> wrote:
> ....
> I suspect that top-like displays were added to most other interactive
> operating systems, as soon as screen terminals made updates convenient without wasting console paper.  One of the first questions likely to be asked by interactive users is "what is my job doing?".  
Absolutely true - all interactive systems had something like it that I remember. Certainly the 10s but as you point out CDC.  I remember  In the early - mid 1970s CMU had a display outside of the computer center and in the terminal room on a ‘large screen display’ connected to the 360/67 system which ran TSS - IBM’s timesharing system - systat ran constantly. 

As I said before there were lots of versions that were hacks off of ps in the Unix world.  Top as we know it was just a matter of time. 

Clem

From dave at horsfall.org  Tue May 29 11:12:09 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 29 May 2018 11:12:09 +1000 (EST)
Subject: [TUHS] Control-T (was top)
In-Reply-To: <CABH=_VQ+R4svobbrcX12sL67qBN_+icViH8L=T+wx_csJ2KebA@mail.gmail.com>
References: <20180524122021.857BC18C09A@mercury.lcs.mit.edu>
 <CAC20D2NkAYBCq2xF-2aO6ep-zvdBy1J=a5PszcviO2JN1hzu8g@mail.gmail.com>
 <DF20553B-A166-485F-8965-E3AC0ECB91FA@ronnatalie.com>
 <e4e0b668-e1b0-8743-2eee-d4616c579ead@kilonet.net>
 <CABH=_VQ+R4svobbrcX12sL67qBN_+icViH8L=T+wx_csJ2KebA@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.999.1805291057420.813@aneurin.horsfall.org>

On Mon, 28 May 2018, Paul Winalski wrote:

> DZ11s were available on PDP-11s and VAXen as well as the KS10. Because 
> the controller had no buffer it was dirt cheap.  OK, perhaps, for a 
> realtime or lab application, but if you were doing timesharing it could 
> bring the CPU to its knees in short order.  Some idiot decided to use 
> the same idea (no buffer in the controller) to reduce the cost of the 
> TU58 (aka DECtape II), Unlike the original DECtape, which was extremely 
> reliable, the TU58 was prone to frequent data overrun and underrun 
> errors even if you set things up such that it got top scheduler 
> priority.

Odd; I have a clear recollection that UNSW's driver (or was it Basser?) 
did not use interrupts (too slow, as you point out) but used the clock 
interrupt to empty the silos every so often.  I'd check the source in the 
Unix Archive, but I don't remember which disk image it's in; what I do 
remember was that it went like a bat out of hell, and Elec Eng had 
something like eight of them on their 11/70.

Can anyone confirm or deny this?

We also had a DZ-11 on our 11/60 (and the 11/40 before that), and it 
worked OK, keeping the DJ-11 company.

-- Dave, possibly suffering from mental bit-rot


From lyndon at orthanc.ca  Tue May 29 11:34:22 2018
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Mon, 28 May 2018 18:34:22 -0700
Subject: [TUHS] History of top
In-Reply-To: <827486DE-0795-4E99-A0D2-5BDC7542AE53@ccc.com>
References: <CMM.0.95.0.1527547393.beebe@gamma.math.utah.edu>
 <827486DE-0795-4E99-A0D2-5BDC7542AE53@ccc.com>
Message-ID: <A879E3F6-9E59-4034-90A8-3D8A74F31C86@orthanc.ca>


> On May 28, 2018, at 5:16 PM, Clem cole <clemc at ccc.com> wrote:
> 
> I remember  In the early - mid 1970s CMU had a display outside of the computer center and in the terminal room on a ‘large screen display’ connected to the 360/67 system which ran TSS - IBM’s timesharing system - systat ran constantly.

MTS had something similar.  At the U of Alberta, it displayed the HASP batch and print queues on a monitor in the "I/O" room  on the 2nd floor of the General Services Building, where you came to submit card decks and pick up print jobs.  My memory says that was part of the HASP system operator job.

I think there might have been a top-style variant of "$SYSTEMSTATUS <mumble>" that would run on the public 3270 (and AJ510) terminals.  But I would have to fire up Hercules to confirm that.

--lyndon



From jnc at mercury.lcs.mit.edu  Tue May 29 12:55:11 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 28 May 2018 22:55:11 -0400 (EDT)
Subject: [TUHS] Control-T (was top)
Message-ID: <20180529025511.C6E0318C08A@mercury.lcs.mit.edu>

    > From: Paul Winalski

    > DZ11s ... the controller had no buffer

Huh? The DZ11 did have an input buffer. (See the 'terminals and communications
handbook', 1978-79 edition, page 2-238: "As each character is received ...
the data bits are placed ... in a .. 64-word deep first-in/first-out hardware
buffer, called a 'silo'.")

Or did you mean output:

    > if you were doing timesharing it could bring the CPU to its knees in
    > short order

The thing that killed an OS was the fact that output was programmed I/O, a
character at a time; using interrupt-driven operation, it took an interrupt
per character. So for a 9600 baud line, 9 bits/character (1 start + 7 data + 1
stop - depending on the line configuration), that's about 1000 characters per
second -> 1000 interrupts per second.

The DH11 used DMA for output, and was much easier on the machine.

	Noel


From lars at nocrew.org  Tue May 29 16:53:22 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Tue, 29 May 2018 06:53:22 +0000
Subject: [TUHS] History of top
In-Reply-To: <CMM.0.95.0.1527547393.beebe@gamma.math.utah.edu> (Nelson
 H. F. Beebe's message of "Mon, 28 May 2018 16:43:13 -0600")
References: <CMM.0.95.0.1527547393.beebe@gamma.math.utah.edu>
Message-ID: <7wd0xfvtp9.fsf@junk.nocrew.org>

Nelson H. F. Beebe wrote:
> I therefore expect that there was 460-entry list of log messages that
> predated 2-Jun-1979, and likely went back a few years.  Two other
> versions of sysdpy.mac in my archives have also dropped log messages
> before 461.

The copyright notice goes back to 1976, which is about then TOPS-20 was
first released, right?

Is this a TOPS-10 version of SYSDPY?  It was copyrighted in 1970.

http://pdp-10.trailing-edge.com/bb-jr93e-bb/14/7,6/ap014/sysdpy.x14.html

> Even before TOPS-20, on the CDC 6400 SCOPE operating system, there was
> a similar tool (whose name I no longer recall) that gave a
> continuously updated display of system-wide process activity. That was
> available in at least late 1973.

I didn't mean to start a mine-is-older-than-yours, but anyway, PEEK
is documented in AI memo 169 from November 1968.


From clemc at ccc.com  Wed May 30 00:18:57 2018
From: clemc at ccc.com (Clem Cole)
Date: Tue, 29 May 2018 10:18:57 -0400
Subject: [TUHS] History of top
In-Reply-To: <7wd0xfvtp9.fsf@junk.nocrew.org>
References: <CMM.0.95.0.1527547393.beebe@gamma.math.utah.edu>
 <7wd0xfvtp9.fsf@junk.nocrew.org>
Message-ID: <CAC20D2NQyUKZBp-EPC4bzG6=xkxSZj=vKmvWTthbKg-Yyga-fg@mail.gmail.com>

On Tue, May 29, 2018 at 2:53 AM, Lars Brinkhoff <lars at nocrew.org> wrote:
>
> The copyright notice goes back to 1976, which is about then TOPS-20 was
> first released, right?
>
​Tops-20 or TENEX (aka Twin-Ex).   Tenex was earlier, and came in house to
DEC and was renamed Tops-20 when DEC released the DEC System20 series
(20/40 and 20/60 originally).​



>
> Is this a TOPS-10 version of SYSDPY?  It was copyrighted in 1970.
>
> http://pdp-10.trailing-edge.com/bb-jr93e-bb/14/7,6/ap014/sysdpy.x14.html

​Could be -- looks about right,  I do not have a running 10 in simh to
check it these days.  But that looks reasonable,​




>
> I didn't mean to start a mine-is-older-than-yours

​Sorry, did not mean to start that.  I just wanted to make sure people knew
that Top was not really a Unix-ism or anything new with VMS, or the PDP-10s
for that matter and clarify the origin.  The idea of displaying status was
pretty important in those days for the system as a whole.
As Lyndon pointed out, being able to monitor the batch systems was another
use of this type of display; but that was slightly different than dpy, peek
and the like.
​  This was really to tell the user, when the system would get to your
work.   BTW, ^T was cool on Tenex, because being interactive, it was just
your process and helped you know how where ​your 'active' process stood
relative to the other things the system was doing (i.e. was it running or
waiting and how busy was the system as a whole).

As terminals (paper and glass) became more the norm (*i.e.* interactive /
time sharing system​
s), both the operators of the system as well as the users wanted to keep
track of what was going on to the system -- i.e. processes that were in the
run queue.   In those days, most systems were in a 'computer room' and the
human operator could do much to keep the system running, from mounting mag
tapes to changing system priorities, assigning resources as needed.
Remember in late 1960s dollars, a 4Mbyte 360/67 like what CMU had at the
time, was valued in the $5M range, a PDP-10 was likely to be about $1.5M.
 So the cost of a human operator was valuable, you really wanted to get
100% out of that system - and the people who actually paid for computing
(like the business office or some research project) needed to get
priority.   A tool like this was needed for the operators to know what was
going on and adjust.

The CDC systems had a glass display as the console, that ran the tool
mentioned before.   The Univac, DEC and IBM systems tended to use paper
based consoles for commands and operator status, but often had some sort of
glass display near the console that the operators monitored (I have picture
of me in the CMU computer room from those days and the displays are on my
left).  I don't know how the the GE/Honeywell system were equipted for a
console, as while I was user of same early in my career, I was never an
operator/system admin - i.e. never behind the glass door with them.

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

From krewat at kilonet.net  Wed May 30 01:10:39 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Tue, 29 May 2018 11:10:39 -0400
Subject: [TUHS] History of top
In-Reply-To: <CAC20D2NQyUKZBp-EPC4bzG6=xkxSZj=vKmvWTthbKg-Yyga-fg@mail.gmail.com>
References: <CMM.0.95.0.1527547393.beebe@gamma.math.utah.edu>
 <7wd0xfvtp9.fsf@junk.nocrew.org>
 <CAC20D2NQyUKZBp-EPC4bzG6=xkxSZj=vKmvWTthbKg-Yyga-fg@mail.gmail.com>
Message-ID: <49115fa5-fd98-c180-f35c-aa058f55e7da@kilonet.net>

On 5/29/2018 10:18 AM, Clem Cole wrote:
>
>
>     Is this a TOPS-10 version of SYSDPY?  It was copyrighted in 1970.
>
>     http://pdp-10.trailing-edge.com/bb-jr93e-bb/14/7,6/ap014/sysdpy.x14.html
>     <http://pdp-10.trailing-edge.com/bb-jr93e-bb/14/7,6/ap014/sysdpy.x14.html>
>
> ​Could be -- looks about right,  I do not have a running 10 in simh to 
> check it these days.  But that looks reasonable,​
>
>
This is definitely TOPS-10:

SYSDPY:	JFCL			;ALLOW FOR CCL ENTRY
	SETZB	0,ZER		;CLEAR OUT SCRATCH
	MOVE	A,[ZER,,ZER+1]
	BLT	A,LZER
	MOVEI	17,1		;CLEAR
	BLT	17,16		; ACS
	MOVE	P,[IOWD PDLEN,PDLST]  ;INITIALIZE PDL POINTER
	SETZ	F,		;NO FLAGS
	SETOM	.FRAJR		;AUTOMATIC ROLL FEATURE
	JUMPPT	A,,KA10		;SEE IF KI-10
	TRO	F,FR.KIX!FR.KIP	;YES--SET FLAG
KA10:	MOVE	A,[%CNVER]	;GET MONITOR VERSION
	GETTAB	A,		;GET MONITOR VERSION VIA UUO!!
	 SETZM	A		;VERY OLD!!
	MOVEM	A,MONVER	;  TESTS
	MOVX	A,%CNDJB	;ASK MONITOR FOR
	GETTAB	A,		;PJOBN/DEVJOB INFORMATION
	 MOVE	A,[POINT 9,20,35]  ;6-SERIES MONITORS
	HRRM	A,PJOBNO	;SAVE DEVJOB INDEX
	HLLM	A,PJOBNP	;AND POINTER TO JOB NUMBER IN SAME

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

From usotsuki at buric.co  Wed May 30 01:48:34 2018
From: usotsuki at buric.co (Steve Nickolas)
Date: Tue, 29 May 2018 11:48:34 -0400 (EDT)
Subject: [TUHS] History of top
In-Reply-To: <CAC20D2NQyUKZBp-EPC4bzG6=xkxSZj=vKmvWTthbKg-Yyga-fg@mail.gmail.com>
References: <CMM.0.95.0.1527547393.beebe@gamma.math.utah.edu>
 <7wd0xfvtp9.fsf@junk.nocrew.org>
 <CAC20D2NQyUKZBp-EPC4bzG6=xkxSZj=vKmvWTthbKg-Yyga-fg@mail.gmail.com>
Message-ID: <alpine.BSF.2.02.1805291147350.75317@frieza.hoshinet.org>

On Tue, 29 May 2018, Clem Cole wrote:

> ​  This was really to tell the user, when the system would get to your
> work.   BTW, ^T was cool on Tenex, because being interactive, it was just
> your process and helped you know how where ​your 'active' process stood
> relative to the other things the system was doing (i.e. was it running or
> waiting and how busy was the system as a whole).

I found ^T useful on FreeBSD, where it does more or less the same thing.

-uso.

From paul.winalski at gmail.com  Wed May 30 02:54:57 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Tue, 29 May 2018 12:54:57 -0400
Subject: [TUHS] History of top
In-Reply-To: <CMM.0.95.0.1527547393.beebe@gamma.math.utah.edu>
References: <CMM.0.95.0.1527547393.beebe@gamma.math.utah.edu>
Message-ID: <CABH=_VRqM+G5KJt38D=H=387rp39iSdsmgm0mmTcbEq67aerXw@mail.gmail.com>

On 5/28/18, Nelson H. F. Beebe <beebe at math.utah.edu> wrote:
>
> I suspect that top-like displays were added to most other interactive
> operating systems, as soon as screen terminals made updates convenient
> without wasting console paper.  One of the first questions likely to
> be asked by interactive users is "what is my job doing?".

And even to non-interactive operating systems.  Inspired by systat and
sysdpy on TOPS-10, I implemented similar functionality for DOS/VS on
the IBM System/370.  It did a continuously updating display of what
each partition was doing on a 3277 transaction terminal.  Very useful
for the system operator.  OS/VS1 had a similar utility.

-Paul W.


From krewat at kilonet.net  Wed May 30 03:08:13 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Tue, 29 May 2018 13:08:13 -0400
Subject: [TUHS] History of top
In-Reply-To: <CABH=_VRqM+G5KJt38D=H=387rp39iSdsmgm0mmTcbEq67aerXw@mail.gmail.com>
References: <CMM.0.95.0.1527547393.beebe@gamma.math.utah.edu>
 <CABH=_VRqM+G5KJt38D=H=387rp39iSdsmgm0mmTcbEq67aerXw@mail.gmail.com>
Message-ID: <a0dd2a71-6cc4-df1c-1969-be310ad39ca5@kilonet.net>

On my SIMH running TOPS-10 7.03:

.DIR SYS:SYSTEM.EXE


SYSTEM  EXE  1188  <155>   11-Oct-01    703(31042) DSKB:   [1,4]

.DIR SYS:SYSDPY.*


SYSDPY  EXE    56  <055>    7-Mar-86    703(634) DSKB:   [1,4]

 From a TOPS-10 6.03A system I managed to cobble together to boot on a KS10:

.DIR SYS:SYSDPY.*

SYSDPY  CTL     4  <000>   28-Feb-77    DSKC:   [1,4]
SYSDPY  EXE    40  <055>   30-Mar-77    433(550)
SYSDPY  MAC   192  <000>    6-Jul-76
SYSDPY  MEM     1  <000>    7-Dec-78
   Total of 237 blocks in 4 files on DSKC: [1,4]


 From SYSDPY.MAC:

SUBTTL  SYSTAT FOR DISPLAYS -- %433(550) -- 6 JUL 76
SUBTTL /TCK 11-JAN-74
VSYSDPY==433
VWHO==0
VMINOR==0
VEDIT==550
;*** COPYRIGHT 1968, 1969, 1970, 1971, 1972, 1973, 1974, 1975, 1976 
DIGITAL EQUIPMENT CORP., MAYNARD, MASS. ***

SEARCH jobdat,C
;EDIT HISTORY

;EDIT LEVEL 471 TO 472

;EDIT 1  SYSVBX DID NOT RUN WITHOUT A CORE ARGUMENT ,AS  CORE
;         EXPANSION WAS DONE AFTER A LOCK UUO




From paul.winalski at gmail.com  Wed May 30 03:10:15 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Tue, 29 May 2018 13:10:15 -0400
Subject: [TUHS] Control-T (was top)
In-Reply-To: <20180529025511.C6E0318C08A@mercury.lcs.mit.edu>
References: <20180529025511.C6E0318C08A@mercury.lcs.mit.edu>
Message-ID: <CABH=_VRNs1dt=6tKBPcpuk84g9bd6jonPqWejn7kB9zO9DtcEA@mail.gmail.com>

On 5/28/18, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>
> The thing that killed an OS was the fact that output was programmed I/O, a
> character at a time; using interrupt-driven operation, it took an interrupt
> per character.
>
> The DH11 used DMA for output, and was much easier on the machine.

Yes, I meant output.  Thanks for refreshing my hazy memory.  I found
the TU58 technical manual online.  It turns out that the TU58 did have
a data buffer, but it's only 128 bytes, so transferring each 512-byte
block required multiple messages and interrupts, and that introduces
the overrun/underrun problems.

Most large VAX timesharing systems used the DH11.

-Paul W.


From jnc at mercury.lcs.mit.edu  Wed May 30 04:49:55 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue, 29 May 2018 14:49:55 -0400 (EDT)
Subject: [TUHS] Control-T (was top)
Message-ID: <20180529184955.2FE1218C088@mercury.lcs.mit.edu>

    > From: Dave Horsfall

    > I have a clear recollection that UNSW's driver (or was it Basser?)  did
    > not use interrupts .. but used the clock interrupt to empty the silos
    > every so often. I'd check the source in the Unix Archive, but I don't
    > remember which disk image it's in ... Can anyone confirm or deny this?

I found this one:

  https://minnie.tuhs.org//cgi-bin/utree.pl?file=AUSAM/sys/dmr/dz.c

which seems to be the one you're rhinking of, or close to it.

It actually does use interrupts, on both sides - sort of. On the input side,
it uses the 'silo alarm', which interrupts when the input buffer has 16
characters in it. This has the same issue as the silo on the DH11 - if there
are less characters than that waiting, the host never gets an interrupt. Which
may be why it does the timer-based input check also?

The output side is entirely interrupt driven; it _does_ reduce the number of
interrupts by checking _every_ output line (on every DZ11 in the machine) to
see if that line's ready for a character when it gets any output interrupt,
which will definitely seriously reduce the number of output interrupts - but
even then, if _one_ line is going flat out, that's still 1000 interrupts per
second.

	Noel


From jnc at mercury.lcs.mit.edu  Wed May 30 04:55:23 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue, 29 May 2018 14:55:23 -0400 (EDT)
Subject: [TUHS] History of top
Message-ID: <20180529185523.D2F1718C088@mercury.lcs.mit.edu>

    > From: Clem Cole

    > Tops-20 or TENEX (aka Twin-Ex).

ISTR the nickname we used was 'TWENEX'?

BTW, the first 20 at MIT (MIT-XX) had a 'Dos Equis' label prominently stuck to
it... :-)

      Noel



From clemc at ccc.com  Wed May 30 05:14:30 2018
From: clemc at ccc.com (Clem Cole)
Date: Tue, 29 May 2018 15:14:30 -0400
Subject: [TUHS] History of top
In-Reply-To: <20180529185523.D2F1718C088@mercury.lcs.mit.edu>
References: <20180529185523.D2F1718C088@mercury.lcs.mit.edu>
Message-ID: <CAC20D2NyG=sVfkOXAz7bLEWCQCXM-DAcf83k83HHH=7WASOoeg@mail.gmail.com>

On Tue, May 29, 2018 at 2:55 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Clem Cole
>
>     > Tops-20 or TENEX (aka Twin-Ex).
>

​Right -- Brain freeze...​



>
> ISTR the nickname we used was 'TWENEX'?
>
> BTW, the first 20 at MIT (MIT-XX) had a 'Dos Equis' label prominently
> stuck to
> it... :-)

​Cute....​

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

From crossd at gmail.com  Wed May 30 06:11:30 2018
From: crossd at gmail.com (Dan Cross)
Date: Tue, 29 May 2018 16:11:30 -0400
Subject: [TUHS] History of top
In-Reply-To: <20180529185523.D2F1718C088@mercury.lcs.mit.edu>
References: <20180529185523.D2F1718C088@mercury.lcs.mit.edu>
Message-ID: <CAEoi9W4CL-q-zrJT80FDLbT1K6f6SesS0qzp9zfZjfH1s3_G3A@mail.gmail.com>

On Tue, May 29, 2018 at 2:55 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Clem Cole
>
>     > Tops-20 or TENEX (aka Twin-Ex).
>
> ISTR the nickname we used was 'TWENEX'?
>
> BTW, the first 20 at MIT (MIT-XX) had a 'Dos Equis' label prominently
> stuck to
> it... :-)


"I don't always use computers, but when I do, I prefer PDP-10s."

        - Dan C.

ObRef: https://www.youtube.com/watch?v=fYdwe3ArFWA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180529/6e4423ad/attachment.html>

From krewat at kilonet.net  Wed May 30 06:57:14 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Tue, 29 May 2018 16:57:14 -0400
Subject: [TUHS] History of top
In-Reply-To: <CAEoi9W4CL-q-zrJT80FDLbT1K6f6SesS0qzp9zfZjfH1s3_G3A@mail.gmail.com>
References: <20180529185523.D2F1718C088@mercury.lcs.mit.edu>
 <CAEoi9W4CL-q-zrJT80FDLbT1K6f6SesS0qzp9zfZjfH1s3_G3A@mail.gmail.com>
Message-ID: <e0e3ed00-e398-f929-4d75-9840b9cd44e3@kilonet.net>

On 5/29/2018 4:11 PM, Dan Cross wrote:
> "I don't always use computers, but when I do, I prefer PDP-10s."
>
>         - Dan C.
Write-in for President in 2020.



From norman at oclsc.org  Wed May 30 07:21:57 2018
From: norman at oclsc.org (Norman Wilson)
Date: Tue, 29 May 2018 17:21:57 -0400
Subject: [TUHS]  Control-T (was top)
Message-ID: <1527628921.23282.for-standards-violators@oclsc.org>

Back in 1980 or 1981, when I first started hacking
on UNIX but still had some TOPS-10 DNA lingering in
my blood, I put in a really simple control-T
implementation.  Control-T became a new signal-
generating character in the tty driver; it sent
signal 16.  Unlike interrupt and quit, it did not
flush input or output buffers.  Unlike any other
signal, SIG_DFL caused the signal to be silently
ignored.  (I don't remember why I didn't just teach
/etc/init and login to set that signal to SIG_IGN
by default; maybe I looked and found too many other
programs that monkeyed with every signal, maybe I
just didn't think of it.)

I then wrote a little program meant to be run in the
background from .profile, that dug around in /dev/kmem,
figured out what was likely nearest-to-foreground process
associated with the same terminal, and printed a little
status info for that process.

It didn't take long for the remaining TOPS-10 DNA to
leach away, and besides it is much easier to run some
program in another window now that that is almost always
possible, so I don't miss it.  But I like that idea
better than, in effect, hacking a mini-ps into the kernel,
even though the kernel doesn't have to do as much work
to get the data.

I also thought it made more sense to have a general
mechanism that could be used for other things.  That
even happened once.  The systems I ran were used, among
other things, for developing SMP, the symbolic-manipulation
interpreter worked on by Stephen Wolfram, Geoffrey Fox,
Chris Cole, and a host of graduate and undergraduate students.
(My memory of who deserves credit differs somewhat from
that of at least one person named.)  SMP, by its nature,
sometimes had to spend a substantial time sitting and
computing.  Someone (probably Wolfram, says my aging
memory) heard about the control-T stuff, asked me how
to use it, and added code to SMP so that during a long
computation control-T would tell you something about
what it was doing and how it was progressing.

Since the signal was, like interrupt and kill, sent
to the whole process group, there was no conflict if
you also had my little control-T monitor running in
the background.

I never tried to send my hacked-up UNIX to anyone else,
so if anyone else did the same sort of control-T hack,
they likely invented it independently.

Norman Wilson
Toronto ON


From norman at oclsc.org  Wed May 30 07:32:20 2018
From: norman at oclsc.org (Norman Wilson)
Date: Tue, 29 May 2018 17:32:20 -0400
Subject: [TUHS] DZ11s (was Control-T (was top))
Message-ID: <1527629543.23531.for-standards-violators@oclsc.org>

Long ago, at Caltech, I ran a VAX which had a mix of DZ11s and
Able DH/DMs.  The latter were indeed much more pleasant, both
because of their DMA output and their fuller modem control.

For the DZ11s we used a scheme that originated somewhere in
the USG-UNIX world: output was handled through a KMC11.
Output interrupts were disablled on the DZ; a program
running in the KMC fetched output data with DMA, then
spoon-fed it into the DZ, polling the status register
to see when it was OK to send more, then sending an
interrupt to the host when the entire data block had
been sent.

The KMC, for those fortunate enough not to have programmed
it, has a very simple processor sort of on the level of
microcode.  It has a few specialized registers and a
simple instruction set which I don't think had all four
of the usual arithmetic ops.  I had to debug the KMC
program so I had to learn about it.

When I moved to Bell Labs a few years later, we didn't
need the KMC to drive serial lines--Dennis's stream I/O
code was able to do that smoothly enough, even with DZ11s
on a VAX-11/750 (and without any assembly-language help
either!).  But my experience with the KMC was useful
anyway: we used them as protocol-offload processors for
Datakit, and that code needed occasional debugging and
tweaking too.  Bill Marshall had looked after that stuff
in the past, but was happy to have someone else who
wasn't scared of it.

Norman Wilson
Toronto ON


From norman at oclsc.org  Wed May 30 07:35:55 2018
From: norman at oclsc.org (Norman Wilson)
Date: Tue, 29 May 2018 17:35:55 -0400
Subject: [TUHS] History of top
Message-ID: <1527629758.23858.for-standards-violators@oclsc.org>

Arthur Krewat:

On 5/29/2018 4:11 PM, Dan Cross wrote:
> "I don't always use computers, but when I do, I prefer PDP-10s."
>
> B  B  B  B  - Dan C.

  Write-in for President in 2020.

===

Only if he's Not Insane.

Norman Wilson
Toronto ON


From krewat at kilonet.net  Wed May 30 07:45:45 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Tue, 29 May 2018 17:45:45 -0400
Subject: [TUHS] History of top
In-Reply-To: <1527629758.23858.for-standards-violators@oclsc.org>
References: <1527629758.23858.for-standards-violators@oclsc.org>
Message-ID: <bced3aa4-2836-9dce-5a45-be7f5a2a6340@kilonet.net>



On 5/29/2018 5:35 PM, Norman Wilson wrote:
> "prefer PDP-xx"
By definition, not insane.




From bqt at update.uu.se  Wed May 30 08:45:59 2018
From: bqt at update.uu.se (Johnny Billquist)
Date: Wed, 30 May 2018 00:45:59 +0200
Subject: [TUHS] Control-T (was top)
In-Reply-To: <mailman.1.1527559201.18622.tuhs@minnie.tuhs.org>
References: <mailman.1.1527559201.18622.tuhs@minnie.tuhs.org>
Message-ID: <7e1853d1-7eaf-98f5-783b-c9582729d830@update.uu.se>

On 2018-05-29 04:00, Clem cole<clemc at ccc.com> wrote:
> 
> And the other issue was besides not enough buffering DZ11s and the TU58 assumes  software (^S/^Q) for the flow control (DH11s with the DM11 option has hardware (RTS/CTS) to control the I/O rate.  So this of course made 8bit data diificult too. And as Paul points out, with HW flow the priority could have been lower. But the HW folks assumed a so called 3 wire interface because they thought they were saving money.

Uh? Say what? What does XON/XOFF flow control have to do with 8bit data?

And no, DEC was not trying to save money. They were actually sticking to 
the standard. Something very few companies managed to do, especially 
when it came to the RS-232 standard.
The "hardware flow control" is actually an abuse of the half duplex 
signalling.
And it does not necessarily work as you might expect if modems are in 
the middle.
You could get by with just three wires on serial ports, but DEC usually 
did want people to have more wires connected, in order to detect when a 
device was connected or not. But no, they did not abuse the half duplex 
control to do hardware flow control. The DZ11 also have partial modem 
control. You cannot run them in half-duplex mode, and they do not 
support the secondary channel stuff, but they do support more than just 
the 3 wires.

> A few years later when people tried to put high speed modems like the Trailblazers on them, let’s say the Unix folks quickly abandoned any hope.   Ken O’Humundro at Able Computer has quite a business in his ‘DHDM’ board that was cheaper than the DZ, more ports, full DMA and of course full hardware flow control.

Yes. It's essentially a DH11 with a partial DM11 on just one board, 
while the original DH11/DM11 was a fully 9-slot backplane. So it was a 
really good alternative. The DH11 is much better than the DZ11, but did 
in fact cost more. The Able board gave the DH11 capabilities at a much 
lower cost, and taking much less space in the box. And it actually 
performed better than the DH11. But it did not support the full 
functionality of the DM11. But what was lacking was the half duplex 
stuff, which noone really cared about anymore anyway.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From clemc at ccc.com  Wed May 30 10:19:32 2018
From: clemc at ccc.com (Clem cole)
Date: Tue, 29 May 2018 20:19:32 -0400
Subject: [TUHS] Control-T (was top)
In-Reply-To: <7e1853d1-7eaf-98f5-783b-c9582729d830@update.uu.se>
References: <mailman.1.1527559201.18622.tuhs@minnie.tuhs.org>
 <7e1853d1-7eaf-98f5-783b-c9582729d830@update.uu.se>
Message-ID: <32AC88B9-7065-407E-9687-F3BED82B39F2@ccc.com>

A few comments.  

1). If you grab ^s/^q from the alphabet it means you can send raw 8 bit data because they are valid characters (yes you can use escape chars but it gets very bad)

2) RTS/CTS flow signaling was very much part of the standard but it’s optional  and was used differently by the bell modem interface spec as you point out. I have the spec full somewhere.  It was originally in the ECMA standard for RJE stations actually.  IIRC it was the one if the European firms like ICL that created it.  Again IIRC MacNamera describes it also in his early19079s classic book on data com.  

3) DEC did not stick to the standard on the DZ11 neither ECMA interface nor the WE/Bell system standards. either Paul is absolutely right.  It drove MacNamera crazy as I believe he was the lead designer of the original DH which did (the topic came up at a party once).  WE212 modems worked on dz11 for input but just barely and could not use a WE dialer for output (who’s number I now forget). Remember the AT command dialer stuff was not originally a standard from the telcos.  The modems were independent of the dialer (which used the RS-4xx standard and I also have some where and I forget the number).  

15 WE212 Modems went into WE modem rack and the first slot was special and could support either a 16tg modem or a single WE dialer which was common the 15 modems in the rack.  

The logic to make it all work is well described and spelled out in the original UUCP code.

Btw Tom Truscott of UNC I believe built a home made dialer that snapped a relay over the pots line to simulate a dialer using a DR11C and did paper in the 1980 winter usenix in Boulder (aka the black hole) — at the time the AT modem stuff did not yet exist, but universities often did not use the WE standard modems of racks (Racal Vadic was popular) and the original dec dialer interface to the bell system stuff I think I remember was from DEC’s CSS group and not easy to get.  

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

> On May 29, 2018, at 6:45 PM, Johnny Billquist <bqt at update.uu.se> wrote:
> 
>> On 2018-05-29 04:00, Clem cole<clemc at ccc.com> wrote:
>> And the other issue was besides not enough buffering DZ11s and the TU58 assumes  software (^S/^Q) for the flow control (DH11s with the DM11 option has hardware (RTS/CTS) to control the I/O rate.  So this of course made 8bit data diificult too. And as Paul points out, with HW flow the priority could have been lower. But the HW folks assumed a so called 3 wire interface because they thought they were saving money.
> 
> Uh? Say what? What does XON/XOFF flow control have to do with 8bit data?
> 
> And no, DEC was not trying to save money. They were actually sticking to the standard. Something very few companies managed to do, especially when it came to the RS-232 standard.
> The "hardware flow control" is actually an abuse of the half duplex signalling.
> And it does not necessarily work as you might expect if modems are in the middle.
> You could get by with just three wires on serial ports, but DEC usually did want people to have more wires connected, in order to detect when a device was connected or not. But no, they did not abuse the half duplex control to do hardware flow control. The DZ11 also have partial modem control. You cannot run them in half-duplex mode, and they do not support the secondary channel stuff, but they do support more than just the 3 wires.
> 
>> A few years later when people tried to put high speed modems like the Trailblazers on them, let’s say the Unix folks quickly abandoned any hope.   Ken O’Humundro at Able Computer has quite a business in his ‘DHDM’ board that was cheaper than the DZ, more ports, full DMA and of course full hardware flow control.
> 
> Yes. It's essentially a DH11 with a partial DM11 on just one board, while the original DH11/DM11 was a fully 9-slot backplane. So it was a really good alternative. The DH11 is much better than the DZ11, but did in fact cost more. The Able board gave the DH11 capabilities at a much lower cost, and taking much less space in the box. And it actually performed better than the DH11. But it did not support the full functionality of the DM11. But what was lacking was the half duplex stuff, which noone really cared about anymore anyway.
> 
>    Johnny
> 
> -- 
> Johnny Billquist                  || "I'm on a bus
>                                  ||  on a psychedelic trip
> email: bqt at softjar.se             ||  Reading murder books
> pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From clemc at ccc.com  Wed May 30 10:20:59 2018
From: clemc at ccc.com (Clem cole)
Date: Tue, 29 May 2018 20:20:59 -0400
Subject: [TUHS] Control-T (was top)
In-Reply-To: <32AC88B9-7065-407E-9687-F3BED82B39F2@ccc.com>
References: <mailman.1.1527559201.18622.tuhs@minnie.tuhs.org>
 <7e1853d1-7eaf-98f5-783b-c9582729d830@update.uu.se>
 <32AC88B9-7065-407E-9687-F3BED82B39F2@ccc.com>
Message-ID: <0BE40FCF-23F4-4C0C-B33F-A541E3F19FBC@ccc.com>

Argh.  Can not send ... 8 bit data 

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

> On May 29, 2018, at 8:19 PM, Clem cole <clemc at ccc.com> wrote:
> 
> A few comments.  
> 
> 1). If you grab ^s/^q from the alphabet it means you can send raw 8 bit data because they are valid characters (yes you can use escape chars but it gets very bad)
> 
> 2) RTS/CTS flow signaling was very much part of the standard but it’s optional  and was used differently by the bell modem interface spec as you point out. I have the spec full somewhere.  It was originally in the ECMA standard for RJE stations actually.  IIRC it was the one if the European firms like ICL that created it.  Again IIRC MacNamera describes it also in his early19079s classic book on data com.  
> 
> 3) DEC did not stick to the standard on the DZ11 neither ECMA interface nor the WE/Bell system standards. either Paul is absolutely right.  It drove MacNamera crazy as I believe he was the lead designer of the original DH which did (the topic came up at a party once).  WE212 modems worked on dz11 for input but just barely and could not use a WE dialer for output (who’s number I now forget). Remember the AT command dialer stuff was not originally a standard from the telcos.  The modems were independent of the dialer (which used the RS-4xx standard and I also have some where and I forget the number).  
> 
> 15 WE212 Modems went into WE modem rack and the first slot was special and could support either a 16tg modem or a single WE dialer which was common the 15 modems in the rack.  
> 
> The logic to make it all work is well described and spelled out in the original UUCP code.
> 
> Btw Tom Truscott of UNC I believe built a home made dialer that snapped a relay over the pots line to simulate a dialer using a DR11C and did paper in the 1980 winter usenix in Boulder (aka the black hole) — at the time the AT modem stuff did not yet exist, but universities often did not use the WE standard modems of racks (Racal Vadic was popular) and the original dec dialer interface to the bell system stuff I think I remember was from DEC’s CSS group and not easy to get.  
> 
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
> 
>>> On May 29, 2018, at 6:45 PM, Johnny Billquist <bqt at update.uu.se> wrote:
>>> 
>>> On 2018-05-29 04:00, Clem cole<clemc at ccc.com> wrote:
>>> And the other issue was besides not enough buffering DZ11s and the TU58 assumes  software (^S/^Q) for the flow control (DH11s with the DM11 option has hardware (RTS/CTS) to control the I/O rate.  So this of course made 8bit data diificult too. And as Paul points out, with HW flow the priority could have been lower. But the HW folks assumed a so called 3 wire interface because they thought they were saving money.
>> 
>> Uh? Say what? What does XON/XOFF flow control have to do with 8bit data?
>> 
>> And no, DEC was not trying to save money. They were actually sticking to the standard. Something very few companies managed to do, especially when it came to the RS-232 standard.
>> The "hardware flow control" is actually an abuse of the half duplex signalling.
>> And it does not necessarily work as you might expect if modems are in the middle.
>> You could get by with just three wires on serial ports, but DEC usually did want people to have more wires connected, in order to detect when a device was connected or not. But no, they did not abuse the half duplex control to do hardware flow control. The DZ11 also have partial modem control. You cannot run them in half-duplex mode, and they do not support the secondary channel stuff, but they do support more than just the 3 wires.
>> 
>>> A few years later when people tried to put high speed modems like the Trailblazers on them, let’s say the Unix folks quickly abandoned any hope.   Ken O’Humundro at Able Computer has quite a business in his ‘DHDM’ board that was cheaper than the DZ, more ports, full DMA and of course full hardware flow control.
>> 
>> Yes. It's essentially a DH11 with a partial DM11 on just one board, while the original DH11/DM11 was a fully 9-slot backplane. So it was a really good alternative. The DH11 is much better than the DZ11, but did in fact cost more. The Able board gave the DH11 capabilities at a much lower cost, and taking much less space in the box. And it actually performed better than the DH11. But it did not support the full functionality of the DM11. But what was lacking was the half duplex stuff, which noone really cared about anymore anyway.
>> 
>>   Johnny
>> 
>> -- 
>> Johnny Billquist                  || "I'm on a bus
>>                                 ||  on a psychedelic trip
>> email: bqt at softjar.se             ||  Reading murder books
>> pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From dave at horsfall.org  Wed May 30 11:05:32 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 30 May 2018 11:05:32 +1000 (EST)
Subject: [TUHS] Control-T (was top)
In-Reply-To: <20180529184955.2FE1218C088@mercury.lcs.mit.edu>
References: <20180529184955.2FE1218C088@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.21.999.1805301057350.13066@aneurin.horsfall.org>

On Tue, 29 May 2018, Noel Chiappa wrote:

> I found this one:
>
>  https://minnie.tuhs.org//cgi-bin/utree.pl?file=AUSAM/sys/dmr/dz.c
>
> which seems to be the one you're rhinking of, or close to it.

Not sure; I'm positive that there were two drivers: the one above, and,
aha!  One called dz.c-elec, which was the one that I meant.

Ah yes:

/*
  *	DZ-11 driver
  *	------------
  *
  *	OPTIMIZED dz driver to handle multiple dzs as efficiently
  *	as possible.  The efficiency is gained by disabling all
  *	dz transmitter interrupts and using a KW11-P to generate
  *	suitable interrupts.  Carrier is supported but not Ring.
  *
  *				Ian Johnstone	UNSW
  *				May 1979
  */

Note this bit:

     #define	NDZ		 7		/* no. of dz-11s */

As I said, it went like a bat out of hell :-)  You'd be nuts to use
the interrupt per xmit char...

-- Dave


From dave at horsfall.org  Wed May 30 11:10:44 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 30 May 2018 11:10:44 +1000 (EST)
Subject: [TUHS] Control-T (was top)
In-Reply-To: <7e1853d1-7eaf-98f5-783b-c9582729d830@update.uu.se>
References: <mailman.1.1527559201.18622.tuhs@minnie.tuhs.org>
 <7e1853d1-7eaf-98f5-783b-c9582729d830@update.uu.se>
Message-ID: <alpine.BSF.2.21.999.1805301107500.13066@aneurin.horsfall.org>

On Wed, 30 May 2018, Johnny Billquist wrote:

> Uh? Say what? What does XON/XOFF flow control have to do with 8bit data?

Err, how do you send data that happen to be XON/OFF?  By futzing around
with DLE (which I've never seen used)?

-- Dave


From lars at nocrew.org  Wed May 30 15:05:55 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Wed, 30 May 2018 05:05:55 +0000
Subject: [TUHS] History of top
In-Reply-To: <20180529185523.D2F1718C088@mercury.lcs.mit.edu> (Noel Chiappa's
 message of "Tue, 29 May 2018 14:55:23 -0400 (EDT)")
References: <20180529185523.D2F1718C088@mercury.lcs.mit.edu>
Message-ID: <7wmuwhspfw.fsf@junk.nocrew.org>

Noel Chiappa wrote:
> BTW, the first 20 at MIT (MIT-XX) had a 'Dos Equis' label prominently
> stuck to it... :-)

I recently learned that XX's MINITS gateway was called XI.


From arnold at skeeve.com  Wed May 30 19:06:21 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 30 May 2018 03:06:21 -0600
Subject: [TUHS] Control-T (was top)
In-Reply-To: <1527628921.23282.for-standards-violators@oclsc.org>
References: <1527628921.23282.for-standards-violators@oclsc.org>
Message-ID: <201805300906.w4U96LZD017677@freefriends.org>

There was a patch floating around circa 1984 that did Control-T
as a mini-ps inside the kernel. We put it into our Vax running
4.2 at Georgia Tech and then later I put it into the Vaxen
I ran at the Emory U. Computing Center running 4.3 + NFS fromm
Mt. Xinu.

It was a cute thing to have.  One of the faculty at Georgia Tech
who had come from MIT saw it and was totally surprised it was
in Unix. :-)

Lord only knows where we got it from. Probably Unix Wizards
or something ...

Arnold

Norman Wilson <norman at oclsc.org> wrote:

> Back in 1980 or 1981, when I first started hacking
> on UNIX but still had some TOPS-10 DNA lingering in
> my blood, I put in a really simple control-T
> implementation.  Control-T became a new signal-
> generating character in the tty driver; it sent
> signal 16.  Unlike interrupt and quit, it did not
> flush input or output buffers.  Unlike any other
> signal, SIG_DFL caused the signal to be silently
> ignored.  (I don't remember why I didn't just teach
> /etc/init and login to set that signal to SIG_IGN
> by default; maybe I looked and found too many other
> programs that monkeyed with every signal, maybe I
> just didn't think of it.)
>
> I then wrote a little program meant to be run in the
> background from .profile, that dug around in /dev/kmem,
> figured out what was likely nearest-to-foreground process
> associated with the same terminal, and printed a little
> status info for that process.
>
> It didn't take long for the remaining TOPS-10 DNA to
> leach away, and besides it is much easier to run some
> program in another window now that that is almost always
> possible, so I don't miss it.  But I like that idea
> better than, in effect, hacking a mini-ps into the kernel,
> even though the kernel doesn't have to do as much work
> to get the data.
>
> I also thought it made more sense to have a general
> mechanism that could be used for other things.  That
> even happened once.  The systems I ran were used, among
> other things, for developing SMP, the symbolic-manipulation
> interpreter worked on by Stephen Wolfram, Geoffrey Fox,
> Chris Cole, and a host of graduate and undergraduate students.
> (My memory of who deserves credit differs somewhat from
> that of at least one person named.)  SMP, by its nature,
> sometimes had to spend a substantial time sitting and
> computing.  Someone (probably Wolfram, says my aging
> memory) heard about the control-T stuff, asked me how
> to use it, and added code to SMP so that during a long
> computation control-T would tell you something about
> what it was doing and how it was progressing.
>
> Since the signal was, like interrupt and kill, sent
> to the whole process group, there was no conflict if
> you also had my little control-T monitor running in
> the background.
>
> I never tried to send my hacked-up UNIX to anyone else,
> so if anyone else did the same sort of control-T hack,
> they likely invented it independently.
>
> Norman Wilson
> Toronto ON


From clemc at ccc.com  Thu May 31 00:39:57 2018
From: clemc at ccc.com (Clem Cole)
Date: Wed, 30 May 2018 10:39:57 -0400
Subject: [TUHS] Serial Interfaces (was ^T and Top)
Message-ID: <CAC20D2OsjGoMAm6b0kq4Rqbp0=fiKFb78KzjM1DOaRbDKPE9Jg@mail.gmail.com>

On Tue, May 29, 2018 at 9:10 PM, Dave Horsfall <dave at horsfall.org> wrote:

> On Wed, 30 May 2018, Johnny Billquist wrote:
>
> Uh? Say what? What does XON/XOFF flow control have to do with 8bit data?
>>
>
> Err, how do you send data that happen to be XON/OFF?  By futzing around
> with DLE (which I've never seen used)?


Right - you have to escape things and it is a real mess.  I have seen some
of the SI/SO/DLE stuff in mechanical systems like ticker tape.  I never saw
a real 8-bit interface try to do it and succeed -- its messy and suspect
when data overruns occurs all hell break loose.  By the time of 8 bits and
speed of 9.6K protocol's like UUCP, or IP over serial did not even bother.
I suspect in the old 5-bit baudot code times, it was more popular to get a
larger character set, but the speeds were much slower (and the UART not yet
invented by Gordon Bell).​

By the time of the PDP-11, hardware flow was the norm in many (most)
interfaces.  I never understood why DEC got ^S/^Q happy.   You can really
see the issues with it on my PiDP-8, running DOS/8 because the flow is done
by the OS and its much to late to be able to react.   So you get screens
full of data before the ^S is proceeded.

Once Gordon creates the UART, Western Digital licensed it and made it into
a chip which most folks used.   DEC started to use the WD chipset in PDP-8
serial interfaces - it always struck me as strange that HW flow was not
used more.  The KL11/DL11 supported the wires, although the SW had to do
the work.    As I said, MacNamara supported it in the DH11, if I recall (I
don't have the prints in any more), he put an AND gate in the interrupt
bit, so the OS does not get an transfer complete interrupt unless the "I'm
ready" signal is available from the other side.

When I lectured data com to folks years ago, I liked to express the ECMA
serial interface in this manner:

There are 6 signal wires and one reference (signal) ground:

   1. Data XMT (output)
   2. Data RCV (input)
   3. I'm Alive (output)
   4. He's Alive (input)
   5. I'm Ready (output)
   6. He's Ready (input)

Everything else is either extra protocol to solve some other problem, or is
for signal quality (*i.e. *shielding, line balancing etc.).  The names of
which signals match to which actual pins on the ECMA interface can be a
little different depending on the manufacturer of the 'Data Communicating
Equipment (DCE - *a.k.a.* the modem) and the Data Terminating Equipment
(DTE - *a.k.a.* the host).

BTW: ECMA and the WE did specify both signal names and the connectors to
use and I think the European Telco's did also (but I only ever saw a German
spec and it was in German which I do not read).   DCE's are supposed to be
sockets (female and originally DB25)s and DTE's were suppose to plugs
(male).   If you actually follow the spec properly, you never have issues.
The problem was the a number terminal manufactures used the wrong sex
connector, as a lot of them never read the specs [the most famous being the
Lear Siegler ADM3 which was socketed like a DCE but pinned as a DTE -
probably was it was cheap and thus became very popular).

Also to confuse things where it got all weird was how the DCE's handled
answering the phone.  And it was because of the answering that we got all
the messy stuff like Ring, Data Set/Terminal Ready/Carrier and the like.
The different DCE manufacturers in different countries had different answer
protocols, than the original Bell system.  IIRC the original WE103 needed
help from host.  Support for Auto-answer was a later feature of the WE212.

The different protocols are all laid in well in another late 60s/early 70s
data com book from an UMass Prof, who's name I now forget (his book is
white with black letters called 'Data Communications' , as opposed to
MacNamaras dark blue DEC Press book 'Principles of Data Communications').

So ... coming back to Unix for this list...   AT&T owned Western Electric
(WE) who was the largest US manufacturer of DCE's [see 1949 law suit/the
consent decree et al].  In fact at Bell Labs, a lot people using UNIX did
not have 'hardwired terminals' - they had a modem connection.    So, Unix
as a system and tends to have support for DTE/DCE in the manner WE intended
it to be as a result.   It's not surprising that see it in the solutions
that are there.
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180530/ddd78c79/attachment.html>

From bqt at update.uu.se  Thu May 31 08:10:19 2018
From: bqt at update.uu.se (Johnny Billquist)
Date: Thu, 31 May 2018 00:10:19 +0200
Subject: [TUHS] Control-T (was top)
In-Reply-To: <32AC88B9-7065-407E-9687-F3BED82B39F2@ccc.com>
References: <mailman.1.1527559201.18622.tuhs@minnie.tuhs.org>
 <7e1853d1-7eaf-98f5-783b-c9582729d830@update.uu.se>
 <32AC88B9-7065-407E-9687-F3BED82B39F2@ccc.com>
Message-ID: <fae79614-4785-0c14-9ab8-6e81b2f2c265@update.uu.se>

Clem...

On 30.05.18 02:19, Clem cole wrote:
> A few comments.
> 
> 1). If you grab ^s/^q from the alphabet it means you can send raw 8 bit data because they are valid characters (yes you can use escape chars but it gets very bad)

But this has nothing to do with 8 bit data. It's equally true if you are 
using 7 bit data. It is totally disconnected from the 8th bit.
You sometimes also have problem with 8bit data because of parity 
fiddling and whatnot, and thus any mention of 8bit data usually actually 
means something related to the topic of getting the 8th bit though 
cleanly, which is not always the case. Heck, there are even internet 
protocols to this day that don't guarantee that they are 8bit clean.

What you are talking about is simply the problem when you have inband 
signalling, and is a totally different problem than 8bit data.

> 2) RTS/CTS flow signaling was very much part of the standard but it’s optional  and was used differently by the bell modem interface spec as you point out. I have the spec full somewhere.  It was originally in the ECMA standard for RJE stations actually.  IIRC it was the one if the European firms like ICL that created it.  Again IIRC MacNamera describes it also in his early19079s classic book on data com.

RTS/CTS signalling is certainly a part of the standard, but it is not 
meant for flow control. It is for half duplex and the way to signal when 
you want to change the direction of communication.

It is meant for *half duplex* communication. Not flow control.

> 3) DEC did not stick to the standard on the DZ11 neither ECMA interface nor the WE/Bell system standards. either Paul is absolutely right.  It drove MacNamera crazy as I believe he was the lead designer of the original DH which did (the topic came up at a party once).  WE212 modems worked on dz11 for input but just barely and could not use a WE dialer for output (who’s number I now forget). Remember the AT command dialer stuff was not originally a standard from the telcos.  The modems were independent of the dialer (which used the RS-4xx standard and I also have some where and I forget the number).

The DZ11 explicitly says it only have limited modem control. It does 
indeed not support half duplex communication.

The AT "standard" was never actually a standard. It's only a defacto 
standard, but is just something Hayes did, as I'm sure you know.

   Johnny

> 
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
> 
>> On May 29, 2018, at 6:45 PM, Johnny Billquist <bqt at update.uu.se> wrote:
>>
>>> On 2018-05-29 04:00, Clem cole<clemc at ccc.com> wrote:
>>> And the other issue was besides not enough buffering DZ11s and the TU58 assumes  software (^S/^Q) for the flow control (DH11s with the DM11 option has hardware (RTS/CTS) to control the I/O rate.  So this of course made 8bit data diificult too. And as Paul points out, with HW flow the priority could have been lower. But the HW folks assumed a so called 3 wire interface because they thought they were saving money.
>>
>> Uh? Say what? What does XON/XOFF flow control have to do with 8bit data?
>>
>> And no, DEC was not trying to save money. They were actually sticking to the standard. Something very few companies managed to do, especially when it came to the RS-232 standard.
>> The "hardware flow control" is actually an abuse of the half duplex signalling.
>> And it does not necessarily work as you might expect if modems are in the middle.
>> You could get by with just three wires on serial ports, but DEC usually did want people to have more wires connected, in order to detect when a device was connected or not. But no, they did not abuse the half duplex control to do hardware flow control. The DZ11 also have partial modem control. You cannot run them in half-duplex mode, and they do not support the secondary channel stuff, but they do support more than just the 3 wires.
>>
>>> A few years later when people tried to put high speed modems like the Trailblazers on them, let’s say the Unix folks quickly abandoned any hope.   Ken O’Humundro at Able Computer has quite a business in his ‘DHDM’ board that was cheaper than the DZ, more ports, full DMA and of course full hardware flow control.
>>
>> Yes. It's essentially a DH11 with a partial DM11 on just one board, while the original DH11/DM11 was a fully 9-slot backplane. So it was a really good alternative. The DH11 is much better than the DZ11, but did in fact cost more. The Able board gave the DH11 capabilities at a much lower cost, and taking much less space in the box. And it actually performed better than the DH11. But it did not support the full functionality of the DM11. But what was lacking was the half duplex stuff, which noone really cared about anymore anyway.
>>
>>     Johnny
>>
>> -- 
>> Johnny Billquist                  || "I'm on a bus
>>                                   ||  on a psychedelic trip
>> email: bqt at softjar.se             ||  Reading murder books
>> pdp is alive!                     ||  tryin' to stay hip" - B. Idol


-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From dave at horsfall.org  Thu May 31 08:46:46 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 31 May 2018 08:46:46 +1000 (EST)
Subject: [TUHS] Serial Interfaces (was ^T and Top)
In-Reply-To: <CAC20D2OsjGoMAm6b0kq4Rqbp0=fiKFb78KzjM1DOaRbDKPE9Jg@mail.gmail.com>
References: <CAC20D2OsjGoMAm6b0kq4Rqbp0=fiKFb78KzjM1DOaRbDKPE9Jg@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.999.1805310839290.13066@aneurin.horsfall.org>

On Wed, 30 May 2018, Clem Cole wrote:

> Right - you have to escape things and it is a real mess.  I have seen 
> some of the SI/SO/DLE stuff in mechanical systems like ticker tape.  I 
> never saw a real 8-bit interface try to do it and succeed -- its messy 
> and suspect when data overruns occurs all hell break loose.  By the time 
> of 8 bits and speed of 9.6K protocol's like UUCP, or IP over serial did 
> not even bother.  I suspect in the old 5-bit baudot code times, it was 
> more popular to get a larger character set, but the speeds were much 
> slower (and the UART not yet invented by Gordon Bell).​ 

Actually, the closest I've seen DLE being used was in SLIP and PPP; if you
needed to send a Frame End then it was escaped with (I think) 0xFF, and that
in turn was escaped.  All it took was a finite state machine...  Of course,
those links used RTS/CTS, but you had to flag the end of a frame (packet)
somehow.

-- Dave

From paul.winalski at gmail.com  Thu May 31 09:01:19 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Wed, 30 May 2018 19:01:19 -0400
Subject: [TUHS] Serial Interfaces (was ^T and Top)
In-Reply-To: <alpine.BSF.2.21.999.1805310839290.13066@aneurin.horsfall.org>
References: <CAC20D2OsjGoMAm6b0kq4Rqbp0=fiKFb78KzjM1DOaRbDKPE9Jg@mail.gmail.com>
 <alpine.BSF.2.21.999.1805310839290.13066@aneurin.horsfall.org>
Message-ID: <CABH=_VS6NzfZfA0fDWn7rZ0g4_29DGLdc=7uCb7CoWPMaoYYSA@mail.gmail.com>

On 5/30/18, Dave Horsfall <dave at horsfall.org> wrote:
>
> Actually, the closest I've seen DLE being used was in SLIP and PPP;

I dimly recall that DLE was used by the IBM bisync half-duplex
protocol used by HASP RJE stations and 2741 golfball terminals.  I
think it was made part of ASCII to support those sorts of protocols.

-Paul W.


From pete at dunnington.plus.com  Thu May 31 09:14:03 2018
From: pete at dunnington.plus.com (Pete Turnbull)
Date: Thu, 31 May 2018 00:14:03 +0100
Subject: [TUHS] Control-T (was top)
In-Reply-To: <fae79614-4785-0c14-9ab8-6e81b2f2c265@update.uu.se>
References: <mailman.1.1527559201.18622.tuhs@minnie.tuhs.org>
 <7e1853d1-7eaf-98f5-783b-c9582729d830@update.uu.se>
 <32AC88B9-7065-407E-9687-F3BED82B39F2@ccc.com>
 <fae79614-4785-0c14-9ab8-6e81b2f2c265@update.uu.se>
Message-ID: <f4611502-eafd-5b0f-ba3d-ffa3309c0bdf@dunnington.plus.com>

On 30/05/2018 23:10, Johnny Billquist wrote:
> On 30.05.18 02:19, Clem cole wrote:

>> 1). If you grab ^s/^q from the alphabet it means you can send raw 8 
>> bit data because they are valid characters (yes you can use escape 
>> chars but it gets very bad)
> 
> But this has nothing to do with 8 bit data.
[...]
> What you are talking about is simply the problem when you have inband 
> signalling, and is a totally different problem than 8bit data.

True, but what I believe Clem meant was "binary data".  He did write 
"raw data".

> RTS/CTS signalling is certainly a part of the standard, but it is not 
> meant for flow control. It is for half duplex and the way to signal when 
> you want to change the direction of communication.
> 
> It is meant for *half duplex* communication. Not flow control.

Actually, for both, explicitly in the standard.  The standard (which I 
have in front of me, RS232C August 1969 reaffirmed June 1981) does 
indeed explain at length how to use it for half duplex turnaround but 
also indicates how to use it for flow control.  It states the use on 
one-way channels and full-duplex channels to stop transmission in a 
paragraph before the paragraph discussing half duplex.

> The AT "standard" was never actually a standard. It's only a defacto 
> standard, but is just something Hayes did, as I'm sure you know.

Except for ITU-T V.250, which admittedly is a Recommendation not a Standard.

-- 
Pete
Pete Turnbull


