> From: Dave Horsfall
> The ARPAnet reached four nodes on this day in 1969 (anyone know which?)
SRI, UCSD, UCLA, Utah:
http://www.chiappa.net/~jnc/tech/arpageo.html
All West Coast, plus Utah. Next was BBN; if you look at the IMP numbers, in
HOSTS.TXT, they were assigned in order of installation.
> at least one "history" site reckoned the third node was connected in
> 1977 ... Well, I can believe that perhaps there were only three left by
> then...
No:
http://www.chiappa.net/~jnc/tech/arpalog.html
1977 was not too many years before the peak in size (with the MILNET split
coming in October, 1983). Per:
http://www.chiappa.net/~jnc/tech/arpanet.html
"Prior to the split, in 1983, there were 113 IMPs in the ARPANET; after the
ARPANET/MILNET split, the MILNET consisted of 65 nodes, leaving the ARPANET
with 68 nodes."
Noel
On Wed, Nov 29, 2017 at 08:00:55PM +0100, Steffen Nurpmeso wrote:
> Larry McVoy <lm(a)mcvoy.com> wrote:
> |On Mon, Nov 27, 2017 at 07:06:51PM -0500, Ron Natalie wrote:
> |> 1977 marks my entry into the world of UNIX. I've always stated there was
> |> only one person who truly understood nroff and he was dead.
> |> I mourn the fact that of all the UNIX greats I've met, I missed out on
> |> Ossanna.
>
> |I think one could argue that James Clark has a pretty good handle on
> |roff (having written the GNU version of nroff/troff/tbl/eqn/pic etc).
>
> And Werner Lemberg, who carried the torch for the last almost two
> decades. He brought in some really great improvements, like
> arguments for strings, which allows to write pretty much TeX like
> a.k.a. inline if you want to (as in "this is \*[I talic] text").
Yep. James exited stage left and Werner stepped in. I mean no disrespect
to anyone, I was just saying that James has a really good handle on roff,
he redid it all. I admire him for doing so (even though I curse the fact
that he did it in C++).
All,
Was Unix ever ported to a PDP8, or any other 12 bit environment, for
that matter? If not, why not? My understanding, such as it is, is that
Unix was created on the PDP7 - btw, thank you very much, Ken Thompson,
you definitely changed my world :), which is an 18bit machine, and that
it soon found its first real home on the 16 bit PDP11 series of machines
(an 11/20), and from there, ever upward or at least ever onward. I'm
curious about it for historical reasons, of course, but also because
I've been messing around in the PDP8 emulation world and enjoying the
excursion into simplified ISA and memory architectures.
-will
So tape I can see being more weird, but isn't raw disk just "don't put it
in buffer cache"?
>From what I've been able to gather early tape in Unix was dicey, something
about the driver doing seek. Was there more to it than that?
On Tue, Nov 21, 2017 at 02:33:55AM +0000, Clem Cole wrote:
> It???s not so much that they don???t mix, it???s not quite the same. Some
> coprocessor ideas work really well into the Unix I/O model, others don't.
> Raw disk and tape I/O ala a PDP11 or VAX for instance is not easy on an
> IBM channel controller or a CDC PPU.
>
>
>
>
>
>
>
>
> On Mon, Nov 20, 2017 at 6:45 PM Larry McVoy <lm(a)mcvoy.com> wrote:
>
> > On Mon, Nov 20, 2017 at 06:43:28PM -0500, Ron Natalie wrote:
> > >
> > >
> > > > I get that PDP-11 and VAX used memory mapped I/O but was that somehow
> > > exposed above the device driver layer? If so, I missed that, because I
> > had
> > > no conceptual or technical problem with talking to an I/O
> > >
> > > > channel, it was pretty easy. And I suck at writing drivers.
> > >
> > > There's nothing that restricts a device driver to memory mapped I/O.
> > You
> > > do what ever you have to do to initiate the I/O. Even the x86's
> > originally
> > > used special instructions to start the I/O (in/out). The DENELCOR HEP
> > > supercomputer (we did this port around 1983) we had to bounce I/O
> > requests
> > > off a separate I/O processor different from where the kernel was running.
> > > Similar constucts were used on other machines.
> >
> > Yeah, that's what I thought. But other people were saying that I/O
> > processors and Unix didn't mix. I don't get that, seems like whatever
> > the model is is hidden under the driver, that's the whole point of the
> > driver design is it not?
> >
> --
> Sent from a handheld expect more typos than usual
--
---
Larry McVoy lm at mcvoy.comhttp://www.mcvoy.com/lm
> From: Charles Anthony
> Entry points are usually defined as "foo$bar", where "foo" is the
> segment name, and "bar" an entry point in the segment symbol table. I
> believe that the degerate case of "foo$" is treated as "foo$foo" by the
> shell.
So I'm curious about how this, and additional names, interact. (For those who
aren't familiar with Multics, a segment [file, sort of] can have multiple
names. This is sort of like 'hard links' in Unix, except that in Multics one
name, the "primary name" is very slightly preeminent. See here:
http://web.mit.edu/multics-history/source/Multics/mdds/mdd006.compout
page 2-5, for more, if you're interested.)
So if I have a segment with primary name 'foo', and additional names 'bar' and
'zap', and I say 'zap' to the Multics shell, I assume it does a call to
zap$zap, which finds the segment with the primary name 'foo', and calls the
'zap' entry therein?
> Multics rulez; UNIX droolz
Dude, you clearly have Very Large brass ones to send that to this list! :-)
Noel
Early on, when multics was understood to have
one big, segemented address space, it was expected
that PL/I name qualification ($) would serve to address
segments. I do not know whether that idea was
actually implemented.
Doug
My favorite reduction to absurdity was /bin/true. Someone decided we
needed shell commands for true and false. Easy enough to add a script that
said "exit 0" or exit 1" as its only line.
Then someone realized that the "exit 0" in /bin true was superfluous, the
default return was 0. /bin/true turned into an empty, yet executable, file.
Then the lawyers got involved. We got a version of a packaged UNIX (I
think it was Interactive Systems). Every shell script got twelve lines of
copyright/license boilerplate. Including /bin true.
The file had nothing but useless comment in it.
> Multics had some kind of `attach' and `detach' of I/O streams, well
> known to Ossanna, so perhaps dup(2), and a Thompson-shell syntax to go
> with it meant `>' was earmarked early on.
According to "The Evolution of the Unix Timesharing System", full path names
arrived later than I/O redirection, so by they time they needed a separator,
'>' and '<' were gone. '/' also has the advantage of being a non-shift
character!
Noel
PS: Re-reading that, I see that early Unix did not have an exec() call (as I
was just discussing); it was done in user mode, with normal read and write
calls.
> On Tue, Nov 28, 2017 at 2:36 PM, Paul Winalski <paul.winalski(a)gmail.com>
> wrote:
>
>> MS/DOS patterned its command line
>> ​ ​
>> syntax after RT-11 and inherited the slash as a command option
>> introduction from there.
>
> ​Minor correction... To do a CDC style patient zero history ;-) RT11 took
> it from DOS/8, CP/M took it from RT11, then finally DOS-86 which became
> PC-DOS ney MS/DOS took it from CP/M.
I think Gary Kildall was very much into the PDP-8 when teaching at the
Naval Post Graduate School in the early 70's (doing the FORTRAN/8 compiler
for instance). Can't find the link now, but I read somewhere that his
work with the 8008 and 8080 was guided by the idea of having a PDP-8 like
machine in his home office. For CP/M's command syntax RT11 probably did
not come into it. I just had a quick glance through the CP/M 1.4 - 2.2
manuals, and I did not see slash options (or any other option character).
Microsoft bought QDOS as a base for PC-DOS/MS-DOS. The QDOS system calls
were done such that converting existing 8080 CP/M code with Intel's source
level 8080-to-8086 asm converter would generate the correct code. The FAT
file system was modeled after the one used by MS Disk BASIC for the 8086.
Not sure where the QDOS command line came from, other than CP/M. MS did a
lot of its early development on a PDP-10: perhaps that was an inspiration
too.
Sorry for getting off-Unix-topic...
