On 2020-07-29 15:17, Paul Koning wrote:
>
>
>> On Jul 29, 2020, at 5:50 AM, Johnny Billquist <bqt(a)softjar.se> wrote:
>>
>> Just a small comment. Whoever it was that thought DECtape was a tape was making a serious mistake. DECtapes are very different from magtapes.
>>
>> Johnny
>
> Depends on what you're focusing on. Most tapes are not random-write. DECtape and EL-X1 tape are exceptional in that respect. But tapes, DECtape include, have access time proportional to delta block number (and that time is large) unlike disks.
>
> From the point of view of I/O semantics, the first point is significant and the second one not so much.
True. But seek times are in the end only relevant as an aspect of the
speed of the thing, nothing else.
However, seek times on DECtape aren't really comparable to magtape
either. Because DECtape deals with absolute block numbers. So you can
always, no matter where you are, find out where you are, and how far you
will need to move to get to the correct block.
With magtapes, this is pretty much impossible. You'll have to rewind,
and then start seeking.
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
OK, I was able to locate 2bsd.tar.gz and spencer_2bsd.tar.gz in the
archive. Neither is an installation tape. It appears that they are just
tarballs of their respective systems (there are very minor differences
between the two).
In the TAPE file in the tarball, it talks about reading the tar program
off of the tape using:
dd if=/dev/mt0 bs=1b skip=1 of=tar
Well, tar is definitely not located at that address, which implies that
the tarball isn't a distro tape. This note in the archive used to read:
...
The remaining gzipped tar files are other 2BSD distributions supplied by
Keith Bostic, except for spencer_2bsd.tar.gz which came from Henry Spencer.
They do not contain installation tape images. The 2.9BSD-Patch directory
contains patches to 2.9BSD dated August 85, and again supplied by Keith Bostic.
...
now it reads:
...
2.11BSD 2.11BSD-pl195.tar is a copy of 2.11BSD at patch level 195, supplied
by Tom Ivar Helbekkmo. spencer_2bsd.tar.gz is a version of 2BSD which came
from Henry Spencer.
...
I recall having to do something with cont.a files, which are not present
on these images. So, my questions is, does anyone know of or have an
actual 2bsd tape/tape image?
Thanks,
Will
Here's where I found the tarballs:
https://www.tuhs.org/Archive/Distributions/UCB/
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
All,
About a week ago, Bill English passed away. He was a Xerox guy, who
along with Douglas Engelbart of "Mother of all demos" fame, created our
beloved mouse:
https://www.bbc.com/news/technology-53638033
I remember, back in the mid-1980's being part of a focus group
evaluating Microsoft's mouse. Wow, time flies.
-Will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
> From: Lars Brinkhoff
> I haven't investigated it thoroughly, but I do see a file .DOVR.;.SPOOL
> 8 written in C by Eliot Moss.
> ...
> When sending to the DOVER, the spooler waits until Spruce is
> free before sending another file.
Ah, so there was a spooler on the ITS machine as well; I didn't know/remember
that.
I checked on CSR, and it did use TFTP to send it to the Alto spooler:
HOST MIT-SPOOLER, LCS 2/200,SERVER,TFTPSP,ALTO,[SPOOLER]
I vaguely recall the Dover being named 'Spruce', but that name wasn't in the
host table... I have this vague memory that 'MIT-Spooler' was the Alto which
prove the Dover, but now that I think about it, it might have been another one
(which ran only TFTP->EFTP spooler software). IIRC the Dover as a pain to run,
it required a very high bit rate, and the software to massage it was very
tense; so it may have made sense to do the TFTP->EFTP (I'm pretty sure the
vanilla Dover spoke EFTP, but maybe I'm wrong, and it used the PUP stream
protocol) in another machine.
It'd be interesting to look at the Dover spooler on ITS, and see if/how one
got to the CHAOS network from C - and if so, how it identified the protocol
translating box.
Noel
> From: Will Senn
> $c
> 0177520: ~signal(016,01) from ~sysinit+034
> 0177542: ~sysinit() from ~main+010
> 0177560: _main() from start+0104
> If this means it got signal 16... or 1 from the sysinit call (called
> from main)
I'm not sure that interpretation is correct. I think that trace shows signal()
being called from sysinit().
On V6, signal() was a system call which one could use to set the handlers for
signals (or set them to be ignored, or back to the default action). In. 2.11
it seems to be a shim layer which provides the same interface, but uses
the Berserkly signal system interface underneath:
https://www.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/include/signal.hhttps://www.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/man/cat3/signal.0
So maybe the old binary for kermit is still trying to use the (perhaps
now-removed) signal system call?
Noel
> From: Lars Brinkhoff
> the Dover printer spooler was written using Snyder's C compiler
I'm not sure if that's correct. I don't remember with crystal clarity all the
details of how we got files to the Dover, but here's what I recall (take with
1/2 a grain of salt, my memory may have dropped some bits). To start with,
there were different paths from the CHAOS and TCP/IP worlds. IIRC, there was a
spooler on the Alto which ran the Dover, and the two worlds had separate paths
to get to it.
>From the CHAOS world, there was a protocol translation which ran on whatever
machine had the AI Lab's 3Mbit Ethernet interface - probably MIT-AI's
CHAOS-11? If you look at the Macro-11 code from that, you should see it - IIRC
it translated (on the fly) from CHAOS to EFTP, the PUP prototocol which the
spooler ran 'natively'.
>From the IP world, IIRC, Dave Clark had adapted his Alto TCP/IP stack (written
in BCPL) to run in the spooler alongside the PUP software; it included a TFTP
server, and people ran TFTP from TCP/IP machines to talk to it. (IP access to
the 3Mbit Ethernet was via another UNIBUS Ethernet interface which was plugged
into an IP router which I had written. The initial revision was in Macro-11; a
massive kludge which used hairy macrology to produce N^2 discrete code paths,
one for every pair of interfaces on the machine. Later that was junked, and
replaced with the 'C Gateway' code.)
I can, if people are interested, look on the MIT-CSR machine dump I have
to see how it (a TCP/IP machine) printed on the Dover, to confirm that
it used TFTP.
I don't recall a role for any PDP-10 C code, though. I don't think there was a
spooler anywhere except on the Dover's Alto. Where did that bit about the
PDP-10 spooler in C come from, may I enquire? Was it a CMU thing, or something
like that?
Noel
> My unscientific survey of summer students was that they either came
> from scouts, or were people working on advanced degrees in college.
Not all high-school summer employees were scouts (or scout equivalents -
kids who had logins on BTL Unix machines). I think in particular of Steve
Johnson and Stu Feldman, who eventually became valued permanent employees.
The labs also hired undergrad summer employees. I was one.
Even high-school employees could make lasting contributions. I am
indebted to Steve for a technique he conceived during his first summer
assignment: using macro definitions as if they were units of associative
memory. This view of macros stimulated previously undreamed-of uses.
Doug
I'm running 211bsd pl 431 in SimH on FreeBSD. I've got networking
working on a tap interface both inbound and outbound. I still have a few
issues hanging around that are bugging me, but I'll eventually get to
them. One that is of concern at the moment is kermit. It is in the
system under /usr/new/kermit. When I call it, I get:
kermit
Bad system call - core dumped
I don't see core anywhere and if I did, I'd need to figure out what to
do with it anyway (mabye adb), but I'm wondering if anyone's used kermit
successfully who is on pl 431 or knows what's going on?
Thanks,
Will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
I've always been intrigued with regexes. When I was first exposed to
them, I was mystified and lost in the greediness of matches. Now, I use
them regularly, but still have trouble using them. I think it is because
I don't really understand how they work.
My question for y'all has to do with early unix. I have a copy of
Thompson, K. (1968). Regular expression search algorithm. Communications
of the ACM, 11(6), 419-422. It is interesting as an example of
Thompson's thinking about regexes. In this paper, he presents a
non-backtracking, efficient, algorithm for converting a regex into an
IBM 7094 (whatever that is) program that can be run against text input
that generates matches. It's cool. It got me to thinking maybe the way
to understand the unix regex lies in a careful investigation into how it
is implemented (original thought, right?). So, here I am again to ask
your indulgence as the latecomer wannabe unix apprentice. My thought is
that ed is where it begins and might be a good starting point, but I'm
not sure - what say y'all?
I also have a copy of the O'Reilly Mastering Regular Expressions book,
but that's not really the kind of thing I'm talking about. My question
is more basic than how to use regexes practically. I would like to
understand them at a parsing level/state change level (not sure that's
the correct way to say it, but I'm really new to this kind of lingo).
When I'm done with my stepping through the source, I want to be able to
reason that this is why that search matched that text and not this text
and why the search was greedy, or not greedy because of this logic here...
If my question above isn't focused or on topic enough, here's an
alternative set to ruminate on and hopefully discuss:
1. What's the provenance of regex in unix (when did it appear, in what
form, etc)?
2. What are the 'best' implementations throughout unix (keep it pre 1980s)?
3. What are some of the milestones along the way (major changes, forks,
disagreements)?
4. Where, in the source, or in a paper, would you point someone to
wanting to better understand the mechanics of regex?
Thanks!
Will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
> 1. What's the provenance of regex in unix (when did it appear, in what form, etc)?
> 2. What are the 'best' implementations throughout unix (keep it pre1980s)?
> 3. What are some of the milestones along the way (major changes, forks, disagreements)?
The editor ed was in Unix from day 1. For the necessarily tiny
implementation, Ken discarded various features
from the ancestral qed. Among the casualties was alternation
in regular expressions. It has never fully returned.
Ken's original paper described a method for simulating all paths
of a nondeterministic finite automaton in parallel, although he
didn't describe it in these exact terms. This meant he had to
keep track of up to n possible states, where n is the number of
terminal symbols in the regular expression.
"Computing Reviews" published a scathing critique of the paper:
everyone knows a deterministic automaton can recognize regular
expressions with one state transition per input character; what
a waste of time to have to keep track of multiple states! What the
review missed was that the size of the DFA can be exponential in n.
For one-shot use, as in an editor, it can take far longer to construct
the DFA than to run it.
This lesson came home with a vengeance when Al Aho wrote egrep,
which implemented full regular expressions as DFA's. I happened
to be writing calendar(1) at the same time, and used egrep to
search calendar files for dates in rather free formats for today
and all days through the next working day. Here's an example
(egrep interprets newline as "|"):
(^|[ (,;])(([Aa]ug[^ ]* *|(08|8)/)0*1)([^0123456789]|$)
(^|[ (,;])((\* *)0*1)([^0123456789]|$)
(^|[ (,;])(([Aa]ug[^ ]* *|(08|8)/)0*2)([^0123456789]|$)
(^|[ (,;])((\* *)0*2)([^0123456789]|$)
(^|[ (,;])(([Aa]ug[^ ]* *|(08|8)/)0*3)([^0123456789]|$)
(^|[ (,;])((\* *)0*3)([^0123456789]|$)
Much to Al's chagrin, this regular expression took the better
part of a minute to compile into a DFA, which would then run in
microseconds. The trouble was that the DFA was enormously
bigger than the input--only a tiny fraction of the machine's
states would be visited; the rest were useless. That led
him to the brilliant idea of constructing the machine on
the fly, creating only the states that were pertinent to
the input at hand. That innovation made the DFA again
competitive with an NFA.
Doug
