TUHS

tuhs@tuhs.org

5 participants
6532 discussions

Re: [TUHS] Windows Notepad to support Unix line endings

by norman＠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

7 years, 1 month

Old Usenet newsreader source code?

by Seth Morabito

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(a)loomcom.com

7 years, 1 month

unix "awesome list"

by A. P. Garcia

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

7 years, 1 month

Re: [TUHS] /dev/drum

by Johnny Billquist

On 08.05.18 04:00, jnc(a)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(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

7 years, 1 month

Fun with early troff.

by Ron Natalie

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.

7 years, 1 month

Re: [TUHS] unix "awesome list"

by jnc＠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

7 years, 1 month

Re: [TUHS] [groff] Brian Kernighan on the evoution of eqn, pic, grap into troff

by Doug McIlroy

> 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

7 years, 1 month

Re: [TUHS] /dev/drum

by jnc＠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

7 years, 1 month

Re: [TUHS] /dev/drum

by jnc＠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

7 years, 1 month

Re: [TUHS] /dev/drum

by jnc＠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

7 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS