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: On 4/30/18, Noel Chiappa 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: On Mon, Apr 30, 2018 at 8:05 AM, Noel Chiappa 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: 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: 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: 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: References: Message-ID: 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: References: Message-ID: 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: References: Message-ID: On Monday, May 7, 2018, A. P. Garcia 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: 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: References: <201805060229.w462T9Ee018534@coolidge.cs.Dartmouth.EDU> Message-ID: 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 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: References: <201805060229.w462T9Ee018534@coolidge.cs.Dartmouth.EDU> 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 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> <201805080039.w480dwfd005761@darkstar.fourwinds.com> Message-ID: 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: References: <201805060229.w462T9Ee018534@coolidge.cs.Dartmouth.EDU> <201805080039.w480dwfd005761@darkstar.fourwinds.com> 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> <201805080039.w480dwfd005761@darkstar.fourwinds.com> Message-ID: <20180508041157.C9ED9156E510@mail.bitblocks.com> On Mon, 07 May 2018 17:39:58 -0700 Jon Steinhart 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: Message-ID: <1525730080.S.4783.16394.f5-147-236.1525767277.6983@webmail.rediffmail.com> >I blame people like Lennart Poettering who seem to be hellbent on erasing Linux's origins...I don'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: 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: Message-ID: 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" To:"The Eunuchs Hysterical Society" 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: 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: References: 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: <20180508122429.GG999@thunk.org> Message-ID: <20180508135121.7D70C156E510@mail.bitblocks.com> On Tue, 08 May 2018 08:24:29 -0400 "Theodore Y. Ts'o" 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: <20180508122429.GG999@thunk.org> <20180508135121.7D70C156E510@mail.bitblocks.com> Message-ID: 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: 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> <201805080039.w480dwfd005761@darkstar.fourwinds.com> <20180508041157.C9ED9156E510@mail.bitblocks.com> Message-ID: On 8 May 2018 at 00:11, Bakul Shah wrote: > On Mon, 07 May 2018 17:39:58 -0700 Jon Steinhart 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: On Tue, May 8, 2018 at 9:17 AM, Noel Chiappa 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: 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: References: <20180508122429.GG999@thunk.org> <20180508135121.7D70C156E510@mail.bitblocks.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: 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" To: "Bakul Shah" Cc: "The Eunuchs Hysterical Society" 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: 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: <146d3e969e94918e80c3d7dae01f0a839968e6bb@webmail.yaccman.com> Message-ID: On Tue, May 8, 2018 at 11:31 AM, 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. > ​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: 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: References: <201805060229.w462T9Ee018534@coolidge.cs.Dartmouth.EDU> Message-ID: On 5/7/18, George Michaelson 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: 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 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: 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: <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 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: On Tue, May 8, 2018 at 12:36 PM, Larry McVoy 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: 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: <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: On Tue, May 8, 2018 at 1:06 PM, wrote: > Larry McVoy 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: 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: <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: References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com> <20180508163643.GA16384@mcvoy.com> <201805081706.w48H62gd027214@freefriends.org> Message-ID: On Tuesday, May 8, 2018, Dan Cross wrote: > On Tue, May 8, 2018 at 1:06 PM, wrote: > >> Larry McVoy 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: 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: <20180508122429.GG999@thunk.org> <95a2a49d689b9a9c844e76ebf8385885@bl.org> <20180508172043.GB16384@mcvoy.com> Message-ID: 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: <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: References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com> <20180508163643.GA16384@mcvoy.com> <201805081706.w48H62gd027214@freefriends.org> 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: 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> <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: 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> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> Message-ID: 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: References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com> <20180508163643.GA16384@mcvoy.com> <201805081706.w48H62gd027214@freefriends.org> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> Message-ID: On Tue, May 8, 2018 at 12:35 PM, Arthur Krewat 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: 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 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: 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: References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com> <20180508163643.GA16384@mcvoy.com> <201805081706.w48H62gd027214@freefriends.org> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> Message-ID: > 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: References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com> <20180508163643.GA16384@mcvoy.com> <201805081706.w48H62gd027214@freefriends.org> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> 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: 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: References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com> <20180508163643.GA16384@mcvoy.com> <201805081706.w48H62gd027214@freefriends.org> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> Message-ID: 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: 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: References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com> <20180508163643.GA16384@mcvoy.com> <201805081706.w48H62gd027214@freefriends.org> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> 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> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> <1b32c1a7-69ae-6593-cd01-156f15b87edc@spamtrap.tnetconsulting.net> Message-ID: 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 , 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 (LOCAL) kilowatt = 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: 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> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> <1b32c1a7-69ae-6593-cd01-156f15b87edc@spamtrap.tnetconsulting.net> Message-ID: 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> <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: 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: References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com> <20180508163643.GA16384@mcvoy.com> <201805081706.w48H62gd027214@freefriends.org> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> <1b32c1a7-69ae-6593-cd01-156f15b87edc@spamtrap.tnetconsulting.net> 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: 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: References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com> <20180508163643.GA16384@mcvoy.com> <201805081706.w48H62gd027214@freefriends.org> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> <1b32c1a7-69ae-6593-cd01-156f15b87edc@spamtrap.tnetconsulting.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: 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: 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: 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> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> <00c501d3e702$65f60850$31e218f0$@ronnatalie.com> Message-ID: 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: 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: References: <20180508151722.49CFC18C079@mercury.lcs.mit.edu> <92064c68-1ab9-085f-3259-10efdf94da11@kilonet.net> Message-ID: 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: 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." References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com> <20180508163643.GA16384@mcvoy.com> <201805081706.w48H62gd027214@freefriends.org> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> Message-ID: <20180508200135.47C7B156E510@mail.bitblocks.com> On Tue, 08 May 2018 12:00:48 -0700 Lyndon Nerenberg 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: On Tue, May 8, 2018 at 1:44 PM, Ron Natalie 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: 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: 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? 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 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 (*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 - 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: 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: <20180508122429.GG999@thunk.org> <95a2a49d689b9a9c844e76ebf8385885@bl.org> <20180508172043.GB16384@mcvoy.com> Message-ID: 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: References: <007a01d3e6f4$3c9c47c0$b5d4d740$@ronnatalie.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> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> <00c501d3e702$65f60850$31e218f0$@ronnatalie.com> Message-ID: Em ter, 8 de mai de 2018 16:26, Ron Natalie 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: 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: References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com> <20180508163643.GA16384@mcvoy.com> <201805081706.w48H62gd027214@freefriends.org> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> Message-ID: > > 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: References: <20180508122429.GG999@thunk.org> <20180508135121.7D70C156E510@mail.bitblocks.com> Message-ID: On May 8, 2018, at 7:53 AM, Clem Cole 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 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: References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com> <20180508163643.GA16384@mcvoy.com> <201805081706.w48H62gd027214@freefriends.org> Message-ID: <337b387a-081d-cba3-7e9c-b535267ddd91@gmail.com> > On Tue, May 8, 2018 at 1:06 PM, > 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> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> <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: 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> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> <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> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> <20180508200135.47C7B156E510@mail.bitblocks.com> Message-ID: 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: 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> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> <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: 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> <20180508204342.GA58741@wopr> Message-ID: On Tue, May 8, 2018 at 4:43 PM, Kurt H Maier 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: 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> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> <990f91e8-01c0-cf25-4889-43e1580398ef@kilonet.net> Message-ID: 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 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: 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: 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: References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com> <20180508163643.GA16384@mcvoy.com> <201805081706.w48H62gd027214@freefriends.org> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> <990f91e8-01c0-cf25-4889-43e1580398ef@kilonet.net> 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: References: 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: References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com> <20180508163643.GA16384@mcvoy.com> <201805081706.w48H62gd027214@freefriends.org> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> <00c501d3e702$65f60850$31e218f0$@ronnatalie.com> Message-ID: 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: 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> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> <990f91e8-01c0-cf25-4889-43e1580398ef@kilonet.net> <8120ea75-3573-0931-bf35-f18bf2e4c9f3@kilonet.net> Message-ID: On 8 May 2018 at 18:32, Arthur Krewat 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: 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: References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com> <20180508163643.GA16384@mcvoy.com> <201805081706.w48H62gd027214@freefriends.org> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> <00c501d3e702$65f60850$31e218f0$@ronnatalie.com> Message-ID: <5FC9A20A-22A3-4EAF-8227-49D5839A9F76@orthanc.ca> > On May 8, 2018, at 3:55 PM, Grant Taylor via TUHS 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> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> <00c501d3e702$65f60850$31e218f0$@ronnatalie.com> <5FC9A20A-22A3-4EAF-8227-49D5839A9F76@orthanc.ca> Message-ID: On 8 May 2018 at 19:16, Lyndon Nerenberg wrote: > > > On May 8, 2018, at 3:55 PM, Grant Taylor via TUHS > 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: 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: References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com> <20180508163643.GA16384@mcvoy.com> <201805081706.w48H62gd027214@freefriends.org> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> <00c501d3e702$65f60850$31e218f0$@ronnatalie.com> <5FC9A20A-22A3-4EAF-8227-49D5839A9F76@orthanc.ca> Message-ID: 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 wrote: > On 8 May 2018 at 19:16, Lyndon Nerenberg wrote: >> >> >> > On May 8, 2018, at 3:55 PM, Grant Taylor via TUHS >> > 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> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> <00c501d3e702$65f60850$31e218f0$@ronnatalie.com> <5FC9A20A-22A3-4EAF-8227-49D5839A9F76@orthanc.ca> Message-ID: 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: 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: References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com> <20180508163643.GA16384@mcvoy.com> <201805081706.w48H62gd027214@freefriends.org> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> <00c501d3e702$65f60850$31e218f0$@ronnatalie.com> <5FC9A20A-22A3-4EAF-8227-49D5839A9F76@orthanc.ca> 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: 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: References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com> <20180508163643.GA16384@mcvoy.com> <201805081706.w48H62gd027214@freefriends.org> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> <00c501d3e702$65f60850$31e218f0$@ronnatalie.com> <5FC9A20A-22A3-4EAF-8227-49D5839A9F76@orthanc.ca> Message-ID: On May 8, 2018, at 5:22 PM, Grant Taylor 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: 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: > On May 8, 2018, at 8:31 AM, Steve Johnson 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 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: 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: References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com> <81216ABB-D4DF-4A63-B26D-6DB2A5428E1F@johnlabovitz.com> Message-ID: 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: References: <146d3e969e94918e80c3d7dae01f0a839968e6bb@webmail.yaccman.com> 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 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: References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com> <81216ABB-D4DF-4A63-B26D-6DB2A5428E1F@johnlabovitz.com> 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> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> <1b32c1a7-69ae-6593-cd01-156f15b87edc@spamtrap.tnetconsulting.net> <4501e9ed-7e1f-e96e-0986-2166db13c8fc@spamtrap.tnetconsulting.net> Message-ID: 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> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> <00c501d3e702$65f60850$31e218f0$@ronnatalie.com> <5FC9A20A-22A3-4EAF-8227-49D5839A9F76@orthanc.ca> Message-ID: On Tue, 8 May 2018, Lyndon Nerenberg wrote: > >> On May 8, 2018, at 3:55 PM, Grant Taylor via TUHS 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> <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: References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com> <20180508163643.GA16384@mcvoy.com> <201805081706.w48H62gd027214@freefriends.org> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> <990f91e8-01c0-cf25-4889-43e1580398ef@kilonet.net> <8120ea75-3573-0931-bf35-f18bf2e4c9f3@kilonet.net> Message-ID: On Tue, 8 May 2018, Henry Bent wrote: > On 8 May 2018 at 18:32, Arthur Krewat 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: References: <1525796737.680198.1365037152.60B79FDC@webmail.messagingengine.com> <20180508163643.GA16384@mcvoy.com> <201805081706.w48H62gd027214@freefriends.org> <1525802016.2020176.1365125208.2706032F@webmail.messagingengine.com> <990f91e8-01c0-cf25-4889-43e1580398ef@kilonet.net> Message-ID: 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/ --- Robert Diamond rob at robdiamond.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3862 bytes Desc: not available URL: 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: 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: 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 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: References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com> <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net> 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: 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: 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: On 9 May 2018, at 22:54, Grant Taylor via TUHS 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: References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com> <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.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> <1cfffd7b-4490-7ebc-d892-b603d8312f9d@spamtrap.tnetconsulting.net> Message-ID: 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: References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com> <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net> <1cfffd7b-4490-7ebc-d892-b603d8312f9d@spamtrap.tnetconsulting.net> Message-ID: On 09/05/2018, Nemo 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: References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com> <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net> <1cfffd7b-4490-7ebc-d892-b603d8312f9d@spamtrap.tnetconsulting.net> 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: 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 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: 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: 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 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: 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 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> <1cfffd7b-4490-7ebc-d892-b603d8312f9d@spamtrap.tnetconsulting.net> <69bc5bc2-b1cb-7d68-379c-57c579af9bd9@spamtrap.tnetconsulting.net> Message-ID: On 9 May 2018 at 19:28, Grant Taylor via TUHS 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: 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 wrote: > > > On May 9, 2018, at 8:49 PM, Grant Taylor via TUHS > 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: 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: References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com> <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net> <1cfffd7b-4490-7ebc-d892-b603d8312f9d@spamtrap.tnetconsulting.net> <69bc5bc2-b1cb-7d68-379c-57c579af9bd9@spamtrap.tnetconsulting.net> 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: 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: 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: 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 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: On Thu, May 10, 2018, 11:28 AM Grant Taylor via TUHS 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: 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: 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: 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: 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: 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: 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: References: Message-ID: <201805101734.w4AHYHtj018212@freefriends.org> Clem Cole 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? > 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: 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: References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com> <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net> Message-ID: 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: References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com> <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net> 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 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: References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com> <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net> 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: References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com> <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net> Message-ID: below... On Thu, May 10, 2018 at 5:09 PM, Dave Horsfall 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: 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: References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com> <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net> 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: 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: References: <88495996-4947-4DAD-962F-62022DF76FED@robdiamond.com> <8e31213a-4741-a7d7-f102-526658251ade@spamtrap.tnetconsulting.net> Message-ID: 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 wrote: > below... > > On Thu, May 10, 2018 at 5:09 PM, Dave Horsfall 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: References: <04c44cba-fefe-b5c6-d683-618ed3ddb0cb@spamtrap.tnetconsulting.net> <9D7839FC-A3EB-4211-887D-BCE67229E1D6@orthanc.ca> Message-ID: > On May 10, 2018, at 7:10 AM, John P. Linderman 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: References: <04c44cba-fefe-b5c6-d683-618ed3ddb0cb@spamtrap.tnetconsulting.net> <9D7839FC-A3EB-4211-887D-BCE67229E1D6@orthanc.ca> Message-ID: 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 wrote: > > > On May 10, 2018, at 7:10 AM, John P. Linderman > 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: 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> <8ac8822b-e17b-4763-7d1c-3460a713183e@spamtrap.tnetconsulting.net> Message-ID: On Thu, May 10, 2018 at 4:59 PM, Grant Taylor via TUHS 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: 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> <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> <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 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> <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: 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: References: <04c44cba-fefe-b5c6-d683-618ed3ddb0cb@spamtrap.tnetconsulting.net> <9D7839FC-A3EB-4211-887D-BCE67229E1D6@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: 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: References: <04c44cba-fefe-b5c6-d683-618ed3ddb0cb@spamtrap.tnetconsulting.net> <9D7839FC-A3EB-4211-887D-BCE67229E1D6@orthanc.ca> Message-ID: 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: 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> <3d317540-757f-7a24-941d-b8f0ced91e87@spamtrap.tnetconsulting.net> Message-ID: > On May 10, 2018, at 8:42 PM, Grant Taylor via TUHS 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: References: <04c44cba-fefe-b5c6-d683-618ed3ddb0cb@spamtrap.tnetconsulting.net> <9D7839FC-A3EB-4211-887D-BCE67229E1D6@orthanc.ca> <3d317540-757f-7a24-941d-b8f0ced91e87@spamtrap.tnetconsulting.net> 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: 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> <3d317540-757f-7a24-941d-b8f0ced91e87@spamtrap.tnetconsulting.net> <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 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> <8ac8822b-e17b-4763-7d1c-3460a713183e@spamtrap.tnetconsulting.net> <20180511012945.GI8335@thunk.org> Message-ID: On Thu, May 10, 2018 at 9:29 PM, Theodore Y. Ts'o 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: 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 (Sorry for vertical orientation and non-Unix-related content) --- Robert Diamond rob at robdiamond.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3862 bytes Desc: not available URL: 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: 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: 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: References: Message-ID: > On May 11, 2018, at 6:40 PM, Nemo 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: References: Message-ID: 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: References: Message-ID: > On May 11, 2018, at 7:11 PM, Dave Horsfall 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: References: Message-ID: On Fri, 11 May 2018, Lyndon Nerenberg wrote: >> We used to walk up-hill to work, both ways... > > And it felt *good* :-) And you tell that to the young people of today. and they won't believe you. -- 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: References: Message-ID: On Sat, 12 May 2018, Dave Horsfall wrote: > > > 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: References: 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: References: 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: 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> <3d317540-757f-7a24-941d-b8f0ced91e87@spamtrap.tnetconsulting.net> <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 " 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: 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: <594a8368-2b49-f184-3c35-929d6f2615d4@spamtrap.tnetconsulting.net> Message-ID: 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 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: 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: References: Message-ID: On Fri, May 11, 2018 at 6:21 PM, Dave Horsfall 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: 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: 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: 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: >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> > >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 > 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: References: 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 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: 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: On 12/05/2018, Noel Chiappa 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: 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 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: 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: <20180513065204.GD7079@eureka.lemis.com> Message-ID: 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 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 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: 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" > To: > 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: 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: References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU> 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: References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU> Message-ID: 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 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 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: References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU> 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: References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU> 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 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 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 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> <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> <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> <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 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 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 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> <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> <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: References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU> 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> <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: On Mon, May 14, 2018 at 9:58 AM, Noel Chiappa 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: 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 >> 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> <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 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> <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 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> <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 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> <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: > > 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: 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: 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: On Mon, May 14, 2018 at 1:13 PM, Noel Chiappa wrote: > > From: Ralph Corderoy > > >> 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: 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: References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU> <6447802C-34AD-4F73-ACBC-8C14D9500306@ccc.com> Message-ID: On Mon, May 14, 2018 at 5:32 PM, Jaap Akkerhuis 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: 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> <6447802C-34AD-4F73-ACBC-8C14D9500306@ccc.com> Message-ID: > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: Message signed with OpenPGP URL: 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: References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU> Message-ID: 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: References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU> 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: 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: References: <20180512110127.0B81418C08E@mercury.lcs.mit.edu> Message-ID: <4521D159-F19A-479C-9D5A-B1FFDAE658C4@orthanc.ca> > On May 14, 2018, at 6:21 PM, Dave Horsfall 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." References: <20180512110127.0B81418C08E@mercury.lcs.mit.edu> Message-ID: <20180515020611.5A16F156E7DB@mail.bitblocks.com> On Tue, 15 May 2018 11:21:22 +1000 Dave Horsfall 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> <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 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> <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 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> <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 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> <20180515020611.5A16F156E7DB@mail.bitblocks.com> <201805150222.w4F2Mwnn004038@darkstar.fourwinds.com> <6200BC9B-57F4-4221-BFAC-A7494A3A3277@orthanc.ca> <20180515024532.GG26148@mcvoy.com> Message-ID: 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> <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 wrote: > > >> On May 14, 2018, at 7:22 PM, Jon Steinhart 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: On Tue, May 15, 2018 at 8:52 AM, Doug McIlroy 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: 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: References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU> <20180514143453.GA26148@mcvoy.com> Message-ID: On 14/05/2018, Dave Horsfall 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" 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 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: References: <201805151252.w4FCq3Fx002374@coolidge.cs.Dartmouth.EDU> Message-ID: <201805151423.w4FENYlQ010613@freefriends.org> Clem Cole 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" 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: References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU> <20180514143453.GA26148@mcvoy.com> Message-ID: On Tue, May 15, 2018 at 10:07 AM, Nemo wrote: > On 14/05/2018, Dave Horsfall 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: 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: 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 wrote: > >> On Tue, May 15, 2018 at 08:17:38AM -0600, arnold at skeeve.com wrote: >> "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. >> >> 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: References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU> <20180514143453.GA26148@mcvoy.com> Message-ID: 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 wrote: > > On Tue, May 15, 2018 at 10:07 AM, Nemo wrote: > > On 14/05/2018, Dave Horsfall 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: 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: References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU> <20180514143453.GA26148@mcvoy.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 wrote: > > > > On Tue, May 15, 2018 at 10:07 AM, Nemo wrote: > > > On 14/05/2018, Dave Horsfall 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: References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU> <20180514143453.GA26148@mcvoy.com> Message-ID: On Tue, May 15, 2018 at 10:55 AM, Clem cole wrote: > On May 15, 2018, at 10:37 AM, Dan Cross wrote: > > On Tue, May 15, 2018 at 10:07 AM, Nemo wrote: > > > On 14/05/2018, Dave Horsfall 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: 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: References: <01e701d3ec45$e7211580$b5634080$@ronnatalie.com> <201805151417.w4FEHcIF009897@freefriends.org> <20180515143752.GA7115@mcvoy.com> Message-ID: 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 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 wrote: > > > >> On Tue, May 15, 2018 at 08:17:38AM -0600, arnold at skeeve.com wrote: > >> "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. > >> > >> 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: 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> <20180515145938.GC7879@mcvoy.com> Message-ID: On Tue, May 15, 2018 at 8: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. > 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 wrote: > > > > > > On Tue, May 15, 2018 at 10:07 AM, Nemo wrote: > > > > On 14/05/2018, Dave Horsfall 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: 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> <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> <20180515145938.GC7879@mcvoy.com> Message-ID: On Tue, May 15, 2018 at 10: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. > 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 wrote: > > > > > > On Tue, May 15, 2018 at 10:07 AM, Nemo wrote: > > > > On 14/05/2018, Dave Horsfall 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: 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> <20180515145938.GC7879@mcvoy.com> Message-ID: On Tue, May 15, 2018 at 10: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. ​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: 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> <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> <201805151423.w4FENYlQ010613@freefriends.org> <20180515155621.0B986200C2@orac.inputplus.co.uk> Message-ID: On Tue, May 15, 2018 at 11:56 AM, 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. > xkcd on Standards (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: 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: On Tue, May 15, 2018 at 9:34 AM, Jon Steinhart 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: 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: References: <201805151252.w4FCq3Fx002374@coolidge.cs.Dartmouth.EDU> <201805151423.w4FENYlQ010613@freefriends.org> <20180515155621.0B986200C2@orac.inputplus.co.uk> Message-ID: On Tue, May 15, 2018 at 10:33 AM, Clem Cole wrote: > > > On Tue, May 15, 2018 at 11:56 AM, 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. >> > xkcd on Standards (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: 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> <201805151423.w4FENYlQ010613@freefriends.org> <20180515155621.0B986200C2@orac.inputplus.co.uk> Message-ID: <201805151655.w4FGtlbw029930@freefriends.org> > Arnold wrote: > > DocBook. Bleah. 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. > > 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: 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: 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: References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU> <20180514143453.GA26148@mcvoy.com> <20180515145938.GC7879@mcvoy.com> Message-ID: > 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: References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU> <20180514143453.GA26148@mcvoy.com> <20180515145938.GC7879@mcvoy.com> Message-ID: 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 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: 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> <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 wrote: Jon Steinhart writes: > Bakul Shah writes: > > On Tue, 15 May 2018 11:21:22 +1000 Dave Horsfall 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: References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU> <20180514143453.GA26148@mcvoy.com> <20180515145938.GC7879@mcvoy.com> Message-ID: On Tue, May 15, 2018 at 4:33 PM, John P. Linderman 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: 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: References: <201805141219.w4ECJo5G030533@coolidge.cs.Dartmouth.EDU> <20180514143453.GA26148@mcvoy.com> <20180515145938.GC7879@mcvoy.com> Message-ID: > 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: 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 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: 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: 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> <201805151423.w4FENYlQ010613@freefriends.org> <20180515155621.0B986200C2@orac.inputplus.co.uk> Message-ID: 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: References: <201805151252.w4FCq3Fx002374@coolidge.cs.Dartmouth.EDU> <201805151423.w4FENYlQ010613@freefriends.org> <20180515155621.0B986200C2@orac.inputplus.co.uk> 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 > 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> <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: 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> <201805151423.w4FENYlQ010613@freefriends.org> <20180515155621.0B986200C2@orac.inputplus.co.uk> <20180515234818.GL7879@mcvoy.com> Message-ID: 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: >Date: Wed, 16 May 2018 10:05:24 -0400 >From: Doug McIlroy >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 > >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: References: Message-ID: 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 wrote: > On Sat, 12 May 2018, Dave Horsfall wrote: > > >> >> 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: 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: 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: References: Message-ID: 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 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: 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 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: 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 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 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: 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: References: <20180521202234.GA22144@minnie.tuhs.org> <065D3A8C-9A89-4EC8-9196-8409A5435709@ccc.com> Message-ID: @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 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 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 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: 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: References: <20180521202234.GA22144@minnie.tuhs.org> <065D3A8C-9A89-4EC8-9196-8409A5435709@ccc.com> Message-ID: OK. So I should ignore it then... Thanks for the clarification... Warner On Mon, May 21, 2018 at 4:48 PM, Clem Cole 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 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 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 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: 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: References: <20180521202234.GA22144@minnie.tuhs.org> <065D3A8C-9A89-4EC8-9196-8409A5435709@ccc.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 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 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 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: 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: 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 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 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 > 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 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 >> 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: 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, wrote: > There are some real finds here, esp the 9th and 10th Edition manuals. > I hope someone gets them from him... > > Arnold > > Warren Toomey 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 > > 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: 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: References: <20180523033831.GB4066@minnie.tuhs.org> <201805231753.w4NHrr53017669@freefriends.org> Message-ID: 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: 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: References: <20180523033831.GB4066@minnie.tuhs.org> <201805231753.w4NHrr53017669@freefriends.org> 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, > wrote: > > There are some real finds here, esp the 9th and 10th Edition manuals. > I hope someone gets them from him... > > Arnold > > Warren Toomey > 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 > > > 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: 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: References: <20180523033831.GB4066@minnie.tuhs.org> <201805231753.w4NHrr53017669@freefriends.org> Message-ID: 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: 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 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: 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: References: <7wzi0p60mj.fsf@junk.nocrew.org> Message-ID: >> 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: On Wed, May 23, 2018 at 9:09 PM, Warren Toomey 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 > 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: 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: On Thu, May 24, 2018 at 5:20 AM, Noel Chiappa 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: 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: References: <20180524122021.857BC18C09A@mercury.lcs.mit.edu> 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: References: <20180524122021.857BC18C09A@mercury.lcs.mit.edu> Message-ID: 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: References: <20180524122021.857BC18C09A@mercury.lcs.mit.edu> Message-ID: below... On Thu, May 24, 2018 at 7: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. > ​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: 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: References: <20180524122021.857BC18C09A@mercury.lcs.mit.edu> Message-ID: 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: (Clem Cole's message of "Thu, 24 May 2018 08:01:14 -0700") References: <20180524122021.857BC18C09A@mercury.lcs.mit.edu> 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: A worthy question. ---------- Forwarded message ---------- From: Richard Haight 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: 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: References: <201805152305.w4FN5HnZ006290@coolidge.cs.Dartmouth.EDU> 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> <20180525070103.GA4673@lap> Message-ID: 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: 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: References: Message-ID: 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: References: Message-ID: 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: References: Message-ID: <20180527235457.GE96747@server.rulingia.com> On 2018-May-27 18:38:59 -0400, 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? 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: 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: <20180527235457.GE96747@server.rulingia.com> Message-ID: 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: References: <20180524122021.857BC18C09A@mercury.lcs.mit.edu> Message-ID: On 5/24/18, Arthur Krewat 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: References: <20180524122021.857BC18C09A@mercury.lcs.mit.edu> 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 wrote: > >> On 5/24/18, Arthur Krewat 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> <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: Lars Brinkhoff 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: References: 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 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: References: <20180524122021.857BC18C09A@mercury.lcs.mit.edu> Message-ID: 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: <827486DE-0795-4E99-A0D2-5BDC7542AE53@ccc.com> Message-ID: > On May 28, 2018, at 5:16 PM, Clem cole 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 " 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: (Nelson H. F. Beebe's message of "Mon, 28 May 2018 16:43:13 -0600") References: 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: <7wd0xfvtp9.fsf@junk.nocrew.org> Message-ID: On Tue, May 29, 2018 at 2:53 AM, Lars Brinkhoff 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: 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: References: <7wd0xfvtp9.fsf@junk.nocrew.org> 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 > > > ​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: 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: References: <7wd0xfvtp9.fsf@junk.nocrew.org> Message-ID: 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: References: Message-ID: On 5/28/18, Nelson H. F. Beebe 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: References: Message-ID: 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: On 5/28/18, Noel Chiappa 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: On Tue, May 29, 2018 at 2:55 PM, Noel Chiappa 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: 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: On Tue, May 29, 2018 at 2:55 PM, Noel Chiappa 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: 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: References: <20180529185523.D2F1718C088@mercury.lcs.mit.edu> Message-ID: 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: 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: References: Message-ID: <7e1853d1-7eaf-98f5-783b-c9582729d830@update.uu.se> On 2018-05-29 04:00, Clem cole 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: <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 wrote: > >> On 2018-05-29 04:00, Clem cole 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: <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 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 wrote: >>> >>> On 2018-05-29 04:00, Clem cole 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: 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: <7e1853d1-7eaf-98f5-783b-c9582729d830@update.uu.se> Message-ID: 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 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: On Tue, May 29, 2018 at 9:10 PM, Dave Horsfall 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: 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: <7e1853d1-7eaf-98f5-783b-c9582729d830@update.uu.se> <32AC88B9-7065-407E-9687-F3BED82B39F2@ccc.com> Message-ID: 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 wrote: >> >>> On 2018-05-29 04:00, Clem cole 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: References: Message-ID: 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: References: Message-ID: On 5/30/18, Dave Horsfall 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: References: <7e1853d1-7eaf-98f5-783b-c9582729d830@update.uu.se> <32AC88B9-7065-407E-9687-F3BED82B39F2@ccc.com> Message-ID: 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