Ken Iverson was born in 1920; he is (in)famous for inventing APL. And if
you haven't used APL\360 on a dumb Kleinschmidt[*] terminal, you didn't
miss anything.
[*]
And that's the first time I've seen a spell-checker suggest that it be
replaced with "Consummated".
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
Some time ago, someone posted an early Unix image that I recall
running. I know it was pre-groups but don't recall anything else and
I can't find either the images or mailing list references either
locally or on tuhs.org. Does anyone recall the details.
Also, I've seen suggestions that there's a 2.11BSD patch later than
447 but I can't find anything "official" and www.2bsd.com is either
down or inaccessible from all the systems I have access to. Does
anyone know if 448 or later were released? And given the issues with
www.2bsd.com would someone be willing to mirror it (assuming we can
got a copy of it)?
--
Peter Jeremy
> I got it.
Ta muchly! All seems OK now, after TUHS moved to a new ISP (linode,
which, ahem, is known for hosting spammers).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
1 2 3... Is this mic on? Tap tap...
Seriously, my anti-spam defences were having an issue with this list for a
while, so let's see whether it comes back.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
Could whoever runs this broken mirror please fix the damned mailer so that
it handles my RFC-compliant banner? I do not appreciate retries every
five seconds or so, because Dovecot cannot seem to handle a multi-line
SMTP banner (a great spam defence); I have since firewalled the IP address
of 45.79.103.53 out of self-defence.
Thank you.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
All,
I'm stuck trying to determine what is going on with v6tar on v6. It
seems to work ok for files, but gets confused with subdirectories. I set
up a test folder structure:
t/dmr/vs.c
t/dmr/vt.c
t/ken/prf.c
then I created a tarball
tar cvf t.tar t
then I tried to extract the tarball. It made a mess:
# tar xvf t.tar
Tar: blocksize = 17
y ?
tar: t/ken/prf.c - cannot create
y ?
y ?
tar: t/dmr/vs.c - cannot create
y ?
y ?
tar: t/dmr/vt.c - cannot create
That was ugly and all of it was output. What exactly did I wind up with?:
# ls -l
total 19
drwxrwxrwx 2 root 32 Oct 10 12:54 y
-rw-rw-rw- 1 root 8704 Oct 10 12:54 t.tar
Ugh. Probably don't need the y directory...
# rmdir y
y ?
# ls y
y not found
Wow! It appears that I am unable to delete the y directory or list it by
name. That can't be good. Any ideas of how to remove this directory are
welcome.
Not to be deterred by one small failure, I copied the same tarball over
to v7 on the off chance that maybe v6tar isn't really for v6, but more
for moving files(and directories) over to v7 as Haley and Ritchie
describe, and lo and behold tar on v7 is able to extract both files and
directories from the same tarball without any trouble:
# tar xvf t.tar
Tar: blocksize = 17
x t/ken/prf.c, 2301 bytes, 5 tape blocks
x t/dmr/vs.c, 1543 bytes, 4 tape blocks
x t/dmr/vt.c, 834 bytes, 2 tape blocks
# ls -l
total 18
drwxrwxr-x 4 root 64 Dec 31 19:27 t
-rw-rw-r-- 1 root 8704 Dec 31 19:27 t.tar
# ls t
dmr
ken
# ls t/dmr
vs.c
vt.c
# ls t/ken
prf.c
Interesting. After looking at the tar source, the question marks in the
output appear to be coming from somewhere outside of tar (perhaps mkdir
or chown?). Also, the "cannot create" message comes from the following
snippet of the tar source, which looks reasonable:
...
if ((ofile = creat(dblock.dbuf.name, stbuf.st_mode & 07777)) < 0) {
fprintf(stderr, "tar: %s - cannot create\n",
dblock.dbuf.name);
...
I think this error is simply an effect related to the failure to create
the necessary directories properly. The code to do that looks pretty
straightforward:
checkdir(name)
register char *name;
{
register char *cp;
int i;
for (cp = name; *cp; cp++) {
if (*cp == '/') {
*cp = '\0';
if (access(name, 01) < 0) {
if (fork() == 0) {
execl("/bin/mkdir", "mkdir",
name, 0);
execl("/usr/bin/mkdir",
"mkdir", name, 0);
fprintf(stderr, "tar: cannot
find mkdir!\n");
done(0);
}
while (wait(&i) >= 0);
chown(name, stbuf.st_uid, stbuf.st_gid);
}
*cp = '/';
}
}
}
I speculate that chown is causing the "?" to be displayed. Is it safe
enough for me to add printf statements around this code to see what's
going on, or is there a better approach?
Thanks,
Will
/dev/makefile on the V7 distribution tape (or at least the
unpacked image I have that I believe to be same) says:
ht:
/etc/mknod mt0 b 7 64
/etc/mknod mt1 b 7 0
/etc/mknod rmt0 c 15 64
/etc/mknod rmt1 c 15 0
/etc/mknod nrmt0 c 15 192
/etc/mknod nrmt1 c 15 128
chmod go+w mt0 mt1 rmt0 rmt1 nrmt0 nrmt1
According to /usr/sys/dev/ht.c, the minor device
number was used as follows:
minor(dev) & 07 slave unit number
minor(dev) & 070 controller unit number
minor(dev) & 0100 tape density: set == 800 bpi, clear 1600
minor(dev) & 0200 no-rewind flag
It takes some digging in the source code (and the PDP-11
Peripherals Handbook) to understand all this numerology.
In most of the code, minor(dev) & 077 is just treated as
a unit number (fair enough). The use of 0200 appears only
as a magic number in htopen; that of 0100 only as a magic
number in htstart, and that only implied: the test is
not minor(dev) & 0100, but
unit = minor(bp->b_dev) & 0177;
if(unit > 077)
Not so bad when the whole driver is only 376 lines of code,
but it wouldn't have hurt to make it 400 lines if that
meant fewer magic numbers.
Anyway, what all this means is that /dev/*mt0 and /dev/*mt1
both actually meant slave 0 on TU16 controller 0, but mt0
was 800 bpi and mt1 1600 bpi. Hence, I would guess, tar's
default to mt1.
My first exposure to the insides of UNIX was in the High
Energy Physics group at Caltech. Some of our systems had
multiple tape drives and every drive supported multiple
densities, so we invented for ourselves a system like that
many other sites invented, with names like /dev/rmt3h to
mean the third tape drive at high density. (Hence the
USG naming scheme of /dev/rmt/3h and the like--not that
we taught it to them, just that many places had the same
idea.)
Our world wasn't nearly as exciting as that of our neighbors,
across the building and three floors down, in the Space
Radiation Laboratory. They had a huge room full of racks
of magtapes full of data from satellites, and many locally-
written tools for extracting the data so researchers could
work on it. The hardware was an 11/70 with eight tape drives,
and at any given time at least half the the drives would be
spinning. One of the drives was seven-track rather than
nine-track, because some of the satellite data had been
written in that format.
Fair disclosure: I had a vague memory that the `drive number'
in the device name had been recycled for other purposes,
but couldn't remember whether it was density or something
else. (I'm a little surprised none of the other old-timers
here remembered that, but maybe I worked with tapes more than
them.) But I had to dig into the source code for the details;
I didn't remember all that. And I did have to climb up to the
high shelf in my home office for a Peripherals Handbook to
understand the magic numbers being stuffed into registers!
Norman Wilson
Toronto ON
> I have no memory of why Ken used mt1 not mt0. Doug may know.
I don't know either. Come to think of it, I can't remember ever
using tar without option -f. Direct machine-to-machine trasfer,
e.g. by uucp, took a lot of business away from magtape soon
after tar was introduced. Incidentally, I think tar was written
by Chuck Haley or Greg Chesson, not Ken.
Doug