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